I have spent four pieces on what shifted. This one is about the part that did not, because I think the proportions have been lost somewhere in the last two years, and the proportions are the whole story.
Take an honest look at where the time goes between somebody having an idea and that idea working in production for real users. Writing the code is a slice of it. On the projects I have worked on, not a large slice. Everything around it, deciding what to build, agreeing it with people who disagree, getting it reviewed, getting it through an environment, watching it not work, fixing it at an unsociable hour, is the rest.
Speed up a slice and you get a bounded improvement. That is not a criticism of the tools. It is arithmetic, and it has been the arithmetic of this industry for forty years.
Table of contents
Open Table of contents
Nobody knows what they want
The hardest part of most projects is finding out what is actually needed, and it remains a conversation between people who are unsure, have competing interests, and will change their minds when they see something concrete.
A model will produce an implementation of whatever you describe, extremely quickly. It will not tell you that what you described solves a problem the business does not have, or that the real constraint is a regulatory one nobody mentioned, or that the stakeholder who will veto this has not been in the room.
There is an argument that faster prototyping helps here, and it does, a bit. You can put something concrete in front of people sooner, and people react to concrete things better than to descriptions. That is a genuine improvement. It does not touch the political half of requirements, which is most of it.
Production is still production
A change becomes real when it runs against real traffic, real data and real users, and nothing about that got easier.
Migrations still have to be reversible or carefully one way. Rollouts still need to be staged, because the only honest test of a change is a small amount of real traffic. Feature flags still accumulate and nobody removes them. Capacity still has to exist before the load arrives. Dependencies still fail at inconvenient moments.
Faster code production puts more changes into this pipeline. The pipeline did not widen. If anything, more changes flowing into an unchanged deployment path raises the rate of production incidents, which costs the on call rota something real.
The pager does not care
Three in the morning, a service is degraded, and the job is to work out what is wrong and make it stop. The tools help at the edges: summarising a log, explaining an unfamiliar stack trace, reminding you of a command. I have written separately about what it takes to do that safely, because the summary has to be treated as a suggestion from an untrusted source rather than as a finding.
What they do not do is carry the incident. Diagnosis under time pressure depends on knowing which of forty signals matters, which requires knowing how the system is put together and what normal looks like. That knowledge is built by operating the system over time. It is not in the context window, it is not in the repository, and a person has to have it.
The accountability has not moved either. Somebody writes the incident report, somebody faces the customer, somebody answers to the regulator where one exists. No tool has volunteered to take any of that.
Coordination is untouched
Two teams who disagree about an interface still have to resolve it. A change that needs sign off from security, legal and a platform team still waits for three calendars to align. The decision that needs a director still waits for the director.
This is the part that struck me most. Organisational latency is a very large share of delivery time in any company past a certain size, and it is completely unaffected by how fast anybody writes code. A change that takes two hours to build and nine days to get agreed is now a change that takes twenty minutes to build and nine days to get agreed.
That is a real improvement. It is a seven percent improvement.
Understanding the system you have
Most engineering work is not writing new software. It is changing software that exists, under constraints set by decisions made years ago by people who have left.
To do that safely you have to understand what is there, including the parts that look wrong and are load bearing. Models are genuinely useful here, better than I expected, at explaining unfamiliar code and tracing a path through it. They are useful in the same way a good search tool is useful. They do not supply the judgement about which of three approaches your organisation will tolerate, or which fragile component is scheduled for replacement anyway, or which team will be upset.
Why this matters for the transformation question
If an organisation believes code production was the constraint, it will invest everything in making code production faster and then be puzzled when delivery does not move.
The same mistake has been made repeatedly. It was made with offshoring, with low code platforms, and with every productivity initiative that targeted the typing. Each one delivered something. None delivered what was promised, for the same reason: what was being optimised was not the binding constraint.
The useful question is not how much faster the tools make people write code. It is where the time actually goes in your organisation, measured rather than assumed, and whether the tools touch any of it. For some teams the answer is a lot. For teams whose delivery time is dominated by review queues, environment access and waiting for decisions, the answer is very little, and buying more licences will not change that.
Find the constraint first. It is the oldest advice in the field and it keeps being ignored because measuring where time goes is tedious and buying tools is easy.