I understand this post comes from the PoV of a developer, but the key point is:
>Maybe this setup is faster compared to the old way of working. But I also think it’s an unfair comparison. Working like this requires a much deeper involvement of domain and product experts. This involvement would mean writing out every feature and bug fix down to the tiniest detail.
The game-changer here with AI in software development is that now the Subject Matter Experts (SMEs) can directly guide AI (Claude Code, Cursor, Codex...etc) to translate the vision into code, review and iterate.
Yes, you are removing the developer from this step of the process, at least to build the MVP version of the service/backend/frontend.
By doing this,the process goes faster, as AI codes faster and the iteration with the SME goes way faster as well since there is no handover; you also lower the "quality attrition" of the process handover (in this case expert to developer), since the expert will explain the function to an AI that also has the deep knowledge in the expert field.
Obviously developers still are needed for the refactoring/hardening/compliance of that vibe-coded solution with corporate architectural/security guidelines, but soon enough those things will be done by AI too.
We are seeing this happening right now at all the big companies who are having a gigantic wave of employees (tech AND business) using Cursor, Claude Code and Codex.
So the skills will need to change and SMEs and developers will probably merge into one person that will have deep domain expertise, some systems and architecture knowledge to work more effectively with AI.
Of course this new reality will bring a lot of challenges. Like the software governance issue that some companies (e.g. Amazon) having problems with the huge proliferation of vibe coded solutions that overlap with each other (probably with different outputs) and create confusion in the business...
Your point is similar to the post in a sense that all abstractions are deterministic, so you could go connect the higher layer directly to the lower layer, while in LLMs, by their very probabilistic/black box nature you can’t have this direct link.
But isn’t this just a semantics discussion? Is there a rule for abstraction in CS that says it needs to be deterministic (I really don’t know)?
I believe deterministic abstraction to natural language is impossible to reach by the very ambiguous nature of it, we get misunderstandings when we talk to each other so naturally when talking to a machine it would need to be probabilistic to understand how to translate it to code.
Ok, so I am not the only one looking at google maps (also to Santa Helena) and imagining how it is to live there.
Must be some kind of introspective hobby to fantasize about living on remote islands.
There is a term “islandness” which may help to explain the allure - and many research papers on the topic. For me it’s a “smallness” that is the ideal.
Somewhat related but I always wondered if I asked a LLM to create a new language with full focus on LLM coding efficiency, ignoring the need for humans to read it, what would it come with? Binary?
...and I obviously asked Gemini about it and it replied:
"A language optimized exclusively for Large Language Model (LLM) efficiency would prioritize Token Density, Context Window Management, and Architectural Alignment. It would not be binary, as standard LLM architectures (Transformers) process discrete tokens from a predefined vocabulary, not raw bits."
The issue with these LLM-targeting DSLs is that you have to waste a bunch of your context window explaining the grammar and semantics to the LLM, whereas they already speak existing programming languages because they've seen so much existing code. This usually negates the benefits of the DSL.
> So Perplexity's openclaw? Hopefully more secure?
Given the inherent unpredictability of LLMs, I'm not convinced that an openclaw-like system but with more security features bolted on top is really a positive in the sense that the false sense of absolute security probably outweighs whatever actual security has been added.
It is easier to understand that openclaw is definitely insecure.
Exactly. Psychosis (and other mental illnesses) will find something to attach itself to.
The opportunity here is for Google and other LLMs to include safeguards (and be very clear about them) and processes to direct the user, or, in extreme cases, direct health services to avoid a tragedy like this.
reply