Tuhin Nair’s article frames a common conflict. A business reduces uncertainty: ship an experiment, learn from the market, choose the next bet. Senior developers manage complexity and stability: keep the system understandable, reliable, and tied to clear responsibility.
Answering a request with maintenance costs addresses the wrong loop. A better response offers a shorter, cheaper experiment that answers the business question without binding the result to the core system. This turns technical judgment into a path toward evidence.
AI as it exists now exacerbates the tension. It speeds prototypes and additions, but trades off hard against stable, understandable, maintainable systems by turning them into increasingly darker boxes.
If next year’s frontier models can hold the full understanding of the system in mind and make broad, sweeping changes across a codebase without compromising stability, reliability, ownership, or maintainability, the tradeoff disappears. Then we get 50-foot-high vibe-coded cakes, get to eat them too, and they are delicious and healthy. While we are all out of a job.
Excerpts
The copywriter’s diagnosis: You can’t explain away someone else’s problem using your own problems.
You need to show them how your expertise answers their question better than their current approach. In the hiring example, that means a faster, cheaper way to test whether the hire will deliver the outcome they want. A trial project. Contract work. Anything that gives them evidence without betting the company on it.
The discomfort you feel watching that process isn’t just code quality anxiety. It’s watching someone optimise for a different thing than you are. You care about preserving the system. They care about learning whether this bet works.
The real question isn’t whether AI is good at building things. It is. The real question is whether we can use it to learn faster without losing the ability to maintain what we learn from. That’s an organisational problem, not a technical one.