Hey, developer, did you even think about the design?
Hey, developer, did you even think about the design?
Reflection on AI-driven backend development
Have you ever read a message like that from a coding agent? I haven’t, unfortunately.
Every time I finish code that an AI generated from my spec, I run it through a review by several agents with different roles and viewpoints, like having several people with different experience review it. Almost every time, I get a pile of remarks of all calibres, from minor to critical. What could be simpler: open a new session, feed it the remarks, let it fix them, run the review again.
This wonderful strategy, however, has one weak spot: are we sure the process converges?
Let me take an example from computational fluid dynamics, a field I came from. Modelling the flow around a body in a steady-state formulation (the conditions on the model’s boundaries do not change), the computer solves the Navier–Stokes equations iteratively, counting on the fact that since the boundary conditions are constant, the fields of velocity, pressure and temperature inside the domain will settle down after some number of steps (Fig. 1). In practice, it goes otherwise. If the CAE engineer sets the problem up imperfectly, the solution falls apart and the physical quantities run off beyond anything reasonable (Fig. 2). And it happens that the process is unsteady by its nature — some turbulent vortex — and a steady solution simply does not exist: the fields fluctuate from step to step (Fig. 3).
In agentic development, the very same question nags at me. Sometimes I set up an experiment and go through the “remarks → fixes → review” loop to the end. The case where the agent finds nothing new on the next round is rare. Usually it gets stuck on a few medium-severity remarks — that is the counterpart of Fig. 3. Or the code grows into a system of crutches and props that works, but maintaining it further will be hellishly hard - the case of Fig. 2.
So, accept it and publish? However, there is another experiment: a patch already committed to Postgres and having survived a major release, the same agents often pass without remarks. That is, the agent's remarks aren't noise on any code; a steady state exists. You just can’t reach it by iterating on fixes.
So at some point I started collecting the agent’s remarks and going back to revise the feature’s design, even when the patch was fairly trivial. Rebuilding the system with the known problems in mind, I write down a set of compromises and contracts up front. Yes, the system comes out imperfect, and some places don’t look great in terms of performance - but you know what you are paying for: to improve this corner case, you will run into such-and-such. A pity, but the system is stable and working, and in the world of relational DBMSs, that is a critical factor for developers.
And now about what actually triggered this post. When I review someone’s work, I run an agent-based review by default and see the same set of remarks the author could have gotten from the same agent in a minute. So why am I the one running it?
The problem is that an AI agent will never say the design is wrong — it thinks in terms of fixes. So, to answer the review with something substantive, I have to invent a design variant that rules out such problems in principle. And what do you think — the next version of the patch arrives within an hour or two. It is natural to assume the author used my remarks as a spec and generated the code.
Wonderful, but then the reviewer turns into an architect, doesn’t he? Inventing a new design is expensive, both in time and effort, while generating code is fast. So such a reviewer quickly becomes the bottleneck. So far, that is how it goes for me. It follows that we all now have to become architects, leaving the developer’s role to the AI agent.
On the other hand, the agent writes code imperfectly and often stumbles in a flat place — simply because it makes its own decision on some nuance nobody wrote down, and that may matter for the user. We cannot fit 20+ years of experience into a limited context, can we? So we still have to go down to the lower level and check the code more or less line by line. That means jumping between levels of abstraction, which is even harder work.
What remains is the dilemma of agentic development, for which I cannot find a fitting solution: how to rebuild the process and redistribute roles anew, so that everyone keeps the level of abstraction that matches their role? Or how do I teach an AI agent to criticise my approach boldly and revise the design on its own?
What do you do?
THE END.
Madrid, Spain. 27 October 2026.
Conserving CPU's cycles ... is free today. But if you enjoyed this post, you can tell Conserving CPU's cycles ... that their writing is valuable by pledging a future subscription. You won't be charged unless they enable payments.
© 2026 Andrei Lepikhov
548 Market Street PMB 72296, San Francisco, CA 94104