Faster code, same delivery? What AI is really doing to the pace of software development

A change does not reach users when the code is written. It reaches users after someone understood the problem, wrote the code, reviewed it, ran it through CI, fixed what broke, deployed it and watched it in production. AI has compressed one of those steps enormously. The others moved much less.

This is Amdahl’s law applied to teams: if writing code was a third of the lead time and it now takes a tenth of what it did, the whole pipeline gets faster by far less than ten times. The rest of the lead time is still there, and now it is most of what is left. Acceleration of one step is not acceleration of delivery.

None of this means the change is small. In some kinds of work it is a genuine step change:

• From idea to prototype

  A working prototype that used to take a sprint can now exist by the end of the day. Teams test more ideas before committing to one.

• Mechanical work

  Migrations, boilerplate, test scaffolding, API clients and repetitive refactoring are where agents save the most hours with the least risk.

• Unfamiliar territory

  Reading a legacy codebase, a new framework or a language you rarely touch is no longer a week of ramp-up before the first useful commit.

• Small teams

  Two or three people can now build and run products that once needed a department. That changes who can compete, not only how fast.

When code becomes cheap to produce, everything that has to happen to that code becomes relatively more expensive. We see the same pattern repeat:

• Review becomes the queue. More pull requests, and larger ones, land on the same few reviewers. Their attention is now the scarce resource.
• CI does more work. Agents iterate by running the pipeline. Faster iteration means more runs, and more of them fail on the way to a green build.
• Not every session becomes a change. Some AI work ends in a commit; some ends in an abandoned branch. Both cost time and money, but only one of them shows up in the release notes.
• Decisions stay human-speed. Understanding what the customer needs, agreeing on scope and owning the consequences in production did not get ten times faster.

It is tempting to talk about “AI and software development” as one global curve. In practice the acceleration is very uneven, and the reasons are mostly not technical.

• Price is global, salaries are not. Model usage is priced the same way everywhere, while the cost of an engineering hour varies widely between countries. The same AI bill can be a rounding error for one team and a serious share of the budget for another.
• Regulation sets the ceiling. Banks, healthcare and the public sector adopt more slowly, because data residency, audit and approval processes come first. Their pace is limited by governance, not by tools.
• Legacy systems resist. Greenfield products feel the speed-up first. Decades-old systems with sparse tests and tribal knowledge benefit, but more slowly and with more risk.
• Skills compound. Teams that learned to give agents good context, small tasks and fast feedback get much more out of the same tools than teams that simply turned them on.

So the global picture is less “everyone is faster” and more “the distance between fast and slow teams is growing”. That gap is now set by process and economics more than by access to models.

When something gets cheaper, we usually consume more of it. Software is following the same path. Internal tools nobody would have funded before now get built in an afternoon. Experiments that were too expensive to try are now routine. The world is not just writing the same software faster; it is writing much more software.

That has a cost that arrives later. Every line that ships has to be reviewed, secured, upgraded and eventually understood by someone who did not write it. The pace of creation went up; the pace of maintenance has to keep up with it, and that bill is only starting to come due.

If writing code is no longer the slow part, measuring how fast code is written tells you little. The questions that matter are about the whole change:

1. 1

   Follow the change, not the tool

   Look at the path from task to AI session, commit, pull request, CI and deploy as one unit of work.
2. 2

   Count what never shipped

   Sessions without a commit and pull requests that were closed unmerged are part of the real cost of speed.
3. 3

   Find the new queue

   If review or CI is where changes now wait, that is where the next improvement is, not in yet another coding tool.
4. 4

   Keep unknowns visible

   A number with a missing price is incomplete, not zero. Honest gaps are more useful than confident totals.

This is the view Nythrex is built around: the cost of every change from AI prompt to production, with the basis of each figure shown next to it. How the chain works.

AI has made the act of writing software faster than at any point in history. Whether that turns into faster progress depends on everything around the code: how teams decide, review, test, deploy and pay for the work. The teams that see the whole pipeline, and not just the fastest step in it, are the ones whose speed will actually reach their users.