The world didn't end. It was a complete black box, but we followed the runbooks and kept things running, and only learnt enough of the code as needed to fix any issues or add any enhancements that popped up. Diving in, doing some software archaeology, and spot-changing relevant code became a skill we had to develop.
At scale and over time, I would guess that the percentage of code running on machines that is actually understood by anybody approaches 0. Yet the world does not end.
I'm working on a repo these days that's larger than _entire companies_ I worked with in the past. A 10-person team maintaining more code than 100s at a previous job. The _scale_ makes this wildly different from what we're used to, no matter how much "legacy code" you had to maintain before.
Being able to work effectively in large amounts of unfamiliar code was an expectation for mid-level engineers (L62 if I recall correctly). Its not a new skill, but it is increasing in value again.
These legacy codebases could be incredibly massive and documenting how to run them alone could be a multi month reverse engineering project.
Now ai can do all that part. Dealing with a legacy or unknown codebase is so much easier…
What I've found is that even the best models can write very good code "in the small", and the code is mostly correct, but they can be highly problematic in their design, architecture and abstractions they use. The most common problem is that there is a strong tendency to overcomplicate things, and often this can be traced (ironically!) to the agents not having enough context.
E.g. a very common failure mode is that agents are unaware of some invariant in the architecture (or the fact that they could potentially stipulate a new invariant) and write code to handle a dozen edge cases that would never occur. The code is correct, but there's a ton of unnecessary slop.
My suspicion (confirmed by friends and posts on HN) is that at most places, people don't bother reviewing the code and blindly ship all this slop. The reason things haven't imploded yet is a) the code is usually technically correct, and b) all that additional complexity is never exposed to humans -- it is just outsourced to even more agents to manage. Which explains Anthropic's exploding revenue, I suppose.
That said, it's not like things were better before AI. I once had to go Indiana Jones-ing into a humongous legacy Python codebase so full of magic that there were some code paths I could never figure out even with a debugger. I could only tell that if I got a row written to a specific table, some completely disconnected code path elsewhere would get triggered. I suspect what was happening was a function name was being constructed out of 3 different strings from 3 different sources, one of which was a column in the DB row that was getting written, and that function was being eval'd in some thread somewhere.
This was to fix a bug, which I managed to do without ever figuring this flow out. I still spent an inordinate amount of time trying to figure this out before I realized I was being too idealistic and closed the ticket and moved on. I bet an agent would have figured it out though.
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.
But software powers so much of our modern world, seeing companies decide "well maybe we don't understand the code but trust the governance and harness will allow AI to always fix it" is essentially that above hypothesis in action today.
Of course we should proceed with even more powerful tools. We also need even stronger governance of said tools. We don't want an AI-version of the Chernobyl incident but we do want the AI-version of the benefits that nuclear power gives.
It's like an over-eager junior engineer that will implement whatever pattern they read about last week. It just doesn't feel trained on high-quality enterprise, battle-hardened codebases.
Even Opus 5.5 on High thinking still littered a root directory of a JS project with source files without thinking to put it in a 'src' directory. It had to be told to use a testing framework. Had to be told to also test with Firefox (the project already had established Chrome /and/ Firefox targets).
I have to continuously burn tokens and effort correcting it.
I imagine it performs a bit better with a huge corpus of architecture and style guides. But I did expect to get some that for free with the "leading" model.
Same with that situation. One shot code from prompt is still not great. Maybe if you had a prompt with highly detailed requirements for structure and code formatting it would be ok.
I generally hate the look of AI gen code, so I have some pretty detailed code formatting rules for even small edits. And the AIs still ignore them some of the time.
I don't know what I'm getting at here; other than. It is acting pretty human like at this point in the code delivery phase. Human as in asking someone to do your work for you and you not always getting back what you want; as opposed to being good enough to replace your actual work (assuming you are good at the task you are asking from the Agent -- does work pretty fast though. which makes it a trade off worth considering; but then your time is in picking through the code to confirm it is correct).