We work with coding agents every day, all day. They genuinely changed the cost of the repetitive part of the job, and we have no interest in playing that down.
Which is exactly why it is worth being precise about what they did not change. Anyone selling acceleration without that second list is selling an expectation that will break halfway through the project.
What actually got faster
A first navigable prototype can be ready in days, and that changes the order of a project. Validating a flow with the people who will use it became more accessible before committing to the definitive build.
Repetitive parts became faster: records, integrations, admin screens and reports. The mechanics of data migration can also accelerate, although deciding what to do with inconsistent data still requires context.
Creating tests also became faster. That does not guarantee good coverage on its own, but it reduces the mechanical work required to get there.
What did not move an inch
Understanding how the operation really works
The hardest part of any bespoke system is finding out how the business actually runs, including the parts that contradict the manual. The official process says one thing; the person who has been doing it for eight years does another, for an excellent reason nobody ever wrote down.
You get at that by sitting alongside them, watching the screen of someone doing the work, asking "and when it goes wrong?" and listening to the whole story. An agent can organize the transcript or summarize what was said. It does not notice the hesitation before an answer, the exception that sounds trivial or the rule that only appears when someone demonstrates the work. This is where many projects fail, not at the typing of code.
Deciding the data model
Modelling is a bet on the future: which entities exist, what is an attribute and what deserves to be an entity, what will need history three years from now.
Getting that bet wrong is the most expensive error in software, because it contaminates everything built on top. And it is precisely where an agent is most confident and least accountable: it will propose a plausible, well-formed, coherent model, and be entirely unaware that this company bills in a way the proposed structure cannot represent.
Migrating dirty data
The real bottleneck in almost every system-replacement project is not building the new one. It is that the old one holds twelve years of accumulated data with duplicate customers, dates in three formats, a negative value that means a refund, and a free-text field called "notes" carrying an entire business rule nobody ever formalised.
Writing the converter got fast. Deciding what to do with each anomaly is still a conversation between people, one at a time.
Deciding what not to build
When building gets cheap, the temptation is to build everything. That is expensive in a different way: every feature that exists is a feature that has to be maintained, understood by whoever joins next, and accounted for in every future change.
An agent tends to be a poor adviser here. It responds to what it was asked and can develop an idea far more easily than question whether the idea should exist. Saying "this one isn't worth it" requires context about cost, operations and strategy. It is the work of someone accountable for the outcome, not the volume.
Answering for a problem in production
At two in the morning, when something breaks, there is a person who has to wake up, understand it and fix it. Responsibility is not transferable to a tool, and that is the difference between a vendor who delivers and one who answers for what they delivered.
The ratio trap
There is a second-order effect that comes up too rarely in the conversation and matters a great deal.
When writing gets cheap, reviewing becomes the bottleneck. The volume of code passing through review grows in the same proportion as the cost of producing it falls, and the human attention available stays exactly what it was.
The result, on an inattentive team, is generated code going to production on a shallow review. It works for the cases that were tested. It carries decisions nobody consciously made. And it will be maintained for years.
Cheap code is not free code. It is code you are going to maintain, and the cost of maintaining did not fall in the same proportion as the cost of writing.
A useful test is to separate two questions. The first is whether the tool can produce the change. The second is who can say that the change represents the business correctly, is safe to release and is worth the cost it will create later. The first became much cheaper. The second still needs someone who understands the context and owns the decision.
What that changes in practice
It changes where the time goes.
If the expensive part is now understanding, deciding and answering for the result, then a project needs to allocate more time to diagnosis and design, not less, even though the build shrank. It is counterintuitive: the phase that got cheap is the one that used to fill the entire schedule, and the temptation is to pocket the saving and promise a shorter deadline.
We would rather spend that slack on the part that is still hard. Agents accelerate the code; the review and the responsibility remain ours.
It is also why we still take on few projects a year. The bottleneck was never how fast you can write.