We, too, have to adjust to this change, this new abstraction layer, because whether we like it or not, the code an LLM will produce in no more than five years will arguably be much, much better than the code any 10x developer could produce even if given months of time and an infinite supply of caffeine.
We "just" need to find a way to confirm that our work in this new abstraction layer - primarily prompt engineering - results in the code functionality that we had in mind, not necessarily the code implementation that we had in mind.
Vibe coding originally meant giving an LLM an instruction, having it regurgitate something potentially wholesome, testing it and feeding back the errors for it to fix it. What I've done in the past couple of months is so, so much more than that. I'm a puppet master and my coding agent is my puppet. I don't need to understand the code when I can describe the problem I want solved and it will do it 100x faster than I ever could.
I didn't use code to describe this level of abstration. I used English prose - and a heck of a lot of software engineering theory, mind you. If you know the solution requires a quad-tree and binary search because in this case, that is the best option, then that's an instruction, not a block of code.
My first lead developer was an old school developer who preferred to look up guidelines and solutions in physical books he had on his desk. Nobody should waste time reinventing the wheel.
To answer your first question, it’s faster for me because I can formulate my request as a developer as if my AI agent was also a developer (in a sense it is) faster than I can figure out how to implement it on my own, especially in a new language and ecosystem. I didn’t just prompt Claude Fable at Max thinking capacity “yo dawg make me a game for iPhone that will make me rich just pick whatever style and stuff” and let it run for a week or two. I brainstormed the idea of the game with my AI agent (Opus 5.5 mostly at High), asked for suggestions, adjusted its proposal to my liking, asked it to flesh out an implementation plan for each milestone of the development journey, worked on different topics as we progressed (introducing complex graphics was sometimes challenging which required a bit of guidance for it to get the assets right), had it create a level editor for me because explaining every single thing was taking too long when I could just drag the sprite a little on my screen and tell it to compile my changes, we worked on ambience audio and sound effects at multiple levels (background, middle, foreground), and the list goes on.
A LOT of work has gone into this project, but without an AI I would not have gotten any further in the time spent than barely figuring out how to get even a simple round ball bouncing on a flat surface in Unity. With AI I’m looking at a feature complete game ready to ship to the App Store after the last bit details have been settled (advertisement laws and whether to monetise one way or the other or not at all, mostly).
AI is an incredibly powerful technology and when you wield it correctly you can go from 1x or 10x engineering to 100x or even 1000x at minimal risk (because you mitigated it along the way).
But when you do care, it becomes important.
And, I suppose, computer code in general is terrible about writing things at the right level of abstraction, or at least human generated code is and I think LLMs do worse, somehow. So there is something to be said for prose as a specification language in most cases.
But I still think we're going to end up with some kind of code to reason about programs. Same way mathematicians have been using mathematical notation to reason about maths. But maybe it will be different code. Who knows, literary programming might catch on.
I, personally, never downvote people I disagree with. Who am I if I don't use another perspective as an opportunity to learn and grow? I can tell that many people agree, too, because my "comment score" is still mostly neutral at the time of writing.
- Implementation-defined: the compiler documents its choice, e.g. sizeof(int).
- Unspecified: the compiler picks from options, e.g. argument evaluation order.
- Undefined: no requirements at all, e.g. signed overflow.
The notes take you through compilers deleting an overflow check and a kernel null check because of undefined behaviour.
There are also abstraction leaks. Spolsky’s Law of Leaky Abstractions says all non-trivial abstractions leak. SQL is one example. Logically equivalent queries can differ in speed by thousands of times.
Also, the translator must be trusted. [See this lecture.](https://www.cl.cam.ac.uk/teaching/2223/R209/Reflections-Trus...) It explains how behaviour can live in a compiler binary and appear in no source.
In other words, formal languages are no different to spoken languages. They exist on a spectrum of ambiguity, assumption, and implied meaning, depending on the domain. Human language has the potential to introduce more ambiguity, assumption, and implied meaning, but that's not a predetermined quality. You can be as detailed as you like in your communication with your AI. To a degree of precision equal to or better than a formal language. You reference this in your last sentence. The distinction is fairly obvious: being specific in English has a much lower skill bar than being specific in C.
One of the more interesting topics in research and philosophy right now is this question of alignment. To what degree to these models understand our meaning when we're not extremely detailed. We can see in research that they're becoming extremely competent at inferring meaning. They can often understand our intent with very few words.