*Note:* This is mostly relevant for solo developers, where accountability is much lower than in a team environment.
Code review is the only thing that has kept this house of cards from falling over. So undermining its importance makes me question the hype around LLM tooling even more. I’ve been using these tools since their inception as well, but with AI tooling, we need to hold on to the best practices we’ve built over the last 50 years even more, instead of trying to reinvent the wheel in the name of “rethinking.”
Code generation is cheap, and reviews are getting more and more expensive. If you don’t know what you generated, and your team doesn’t know either because they just rubber-stamped the code since you used AI review, then no one has a proper mental model of what the code actually does.
So when things come crashing down in production, debugging and investigation will be a nightmare. We’re already seeing scenarios where on-call has no idea what’s going on with a system, so they page the SME—and apparently the SME is AI, and the person who did the work also has no idea what’s going on.
Until omniscient AI can do the debugging as well, we need to focus on how we keep practicing the things we’ve organically developed over such a long time, instead of discarding them.
Every abstraction simplifies a bunch of real-world phenomena. The real world is messy, our understanding keeps shifting, and we’re unreliable narrators in the sense that we’re often not even aware of the gaps in our own understanding, let alone good at expressing it.
No matter how much progress we make, as long as reasoning about complex systems is unavoidable, this doesn’t change. We don’t always know what we want, and we can’t always articulate it clearly.
So people building software end up dealing with two problems at once. One is grappling with the intrinsic, irreducible complexity of the system. The other is trying to read the minds of unreliable narrators, including leadership and themselves.
Tools help with the mechanical parts of the job, but they don’t remove the thinking and understanding bottleneck. And since the incentives of leadership, investors, and the people doing the actual work don’t line up, a tug-of-war is the most predictable outcome.
The problem is that if both your interface and implementation are variables where AI can make arbitrary changes with full agency and little verification, maintenance becomes tricky as your understanding of the system as a whole dwindles.
It’s better to be on top of the interface than the implementation. But at the same time, brittle systems caused by overly rigid interfaces are a real thing. In that case, interface exploration can be done by a human with assistance from LLMs, but allowing an LLM to arbitrarily explore and make changes to the interface sounds like a recipe for disaster.
Everyone claims they are x% more productive with LLMs, but once a greenfield project turns into a brownfield one, the second law of thermodynamics kicks in and these disposable components start becoming a liability.
On top of that, Hyrum’s law doesn’t go away just because your software has explicit contracts. In my experience, as more people start losing their agency over the code they generate, the system accumulates implicit cruft over time and other code starts depending on it.
Also, reliability is a reasoning problem. So operational excellence becomes scrappy with this way of working. It works for some software, but I don’t know whether this push to YOLO it is actually a good thing. C-levels are putting immense pressure in many big companies for everyone to adopt these tools and magically increase productivity while decreasing headcount to please investors. Not going too well so far.
A good interface doesn’t magically make vibe-coded implementations with little oversight usable. Rewriting it over and over again in the same manner and expecting improvement is not the kind of engineering I want to do.
Typically, it's not reiterating in the SAME manner. Refactoring happens in the presense of new information. In the case of an agent, that's usually not true.
reply