Eighteen months ago I wrote that AI would change how software gets built. Who hasn’t.
The thing that has surprised me, having spent the intervening eighteen months building HyperMindZ’s agent infrastructure with these tools every working day, is that the half-life of AI-development advice turns out to be about three months. The argument that felt sharp in February is hedge-everything by May and quietly retracted by August. I have a few of my own to retract.
What follows is the short version. What aged well, what aged badly, what I underestimated.
Aged well
Planning compression is real. A thirty-minute design session — written, not whiteboarded — now produces a working first cut by lunch. The compression is not in the typing. It is in the cycle between “what should this do” and “what does it do today.” That cycle used to take a sprint. Now it takes an afternoon. This is the single most durable change.
Test-first is back. TDD was a discipline that asked a lot of engineers and lost the debate on speed grounds. AI-assisted tooling has made generating the test cheap enough that writing it first costs nothing. We have ended up shipping more tests, written earlier, and rewriting fewer of them. The economic objection is gone.
Documentation has a new purpose. The CLAUDE.md-at-the-root pattern — capturing the unwritten rules of how a codebase actually works — has been the highest-leverage practice we have adopted. The point of the document is no longer onboarding humans. It is teaching the agent. The humans benefit as a side effect.
Aged badly
“Multi-AI coordination” was noise. I wrote a long post about orchestrating specialised models against a single task. We tried it. We settled into one primary model and two narrow specialists, and the spreadsheet of seven-tool comparisons is in a drawer. The work was always less about which model and more about which workflow.
“Self-improving systems” was an overclaim. Systems do not improve themselves. They improve when somebody — a human, with judgment — decides what to optimize, what to measure, and when to stop. The model is a competent executor of a chosen optimization. It is not the source of the choice.
The Lego metaphor was wrong. I described AI-assisted development as snapping together pre-built components. The actual experience is closer to writing with a brilliant intern. The intern is fast, surprisingly capable, and produces output that needs taste calibration on almost every paragraph. That is a very different relationship than the one I described.
What I underestimated
Identifying the right problem is still the most important skill, and it has become disproportionately more important, not less. Agents will build the wrong thing fast, and well. The speed at which the model produces a plausible implementation is the same speed at which it produces a plausible implementation of the wrong feature. If your specification is wrong, the model is a force multiplier in the wrong direction.
The corollary is about code review. Code and design review can now be partially automated — a model can scan a diff for the obvious failure modes faster than I can. Partially. The remaining part — the part where a human asks “should this exist,” “is this the right place for it,” “what is the third-order effect on the rest of the system” — has not been automated and, in the medium term, will not be. The judgment that decides what to keep is the part that does not transfer.
- Writing the first cut
- Generating tests
- Scanning diffs for obvious bugs
- Drafting documentation
- Pattern-matching across a large codebase
- Deciding what to build
- Deciding what to keep
- "Is this the right place for it?"
- Third-order effects across the system
- The taste that says ship or rework
The shorter version
The change to the SDLC is smaller than the hype suggests and bigger than the skeptics will admit. Planning and writing got roughly five times faster. The right problem, and the judgment around it, got more important. Most of the practices that survived eighteen months of daily use are about organising the surrounding work — the document at the root of the repo, the test before the code, the plan before the prompt — and not about which model is running underneath.
What did you write eighteen months ago about AI-assisted development that you would revise today?
— Dinesh
Dinesh Bhat