Will AI replace developers — what has actually changed in the work

The short answer is no, and the question itself misleads. What happened is not replacement but a shift. The part of the work that is volume — reading unfamiliar code, repeating a pattern across twenty files, adapting tests — shrank dramatically. The part that requires deciding what to build, what counts as done, and who is accountable when it breaks has not moved at all.

What genuinely shrank?

Mainly the comprehension stage. Entering code you did not write used to be a day of reading before you touched anything. Now you can ask the system questions and get an answer that points at the right files. That is a real change, and it is felt most strongly in exactly the old, tangled systems where it used to hurt most.

Conversion work shrank too: migrations, fitting to a new interface, types. Anything whose pattern is fixed while the details vary. There the difference is not percentages but orders of magnitude in time.

And what did not move?

Three things, all of them about accountability rather than capability. The first is deciding what ships and what waits — a product decision resting on what you know about the customer. The second is defining what counts as working, including what happens when something fails. The third is standing behind the system in front of the people using it.

• What goes into the release — a decision resting on business context, not on code.
• What counts as working, including behaviour in failure states nobody asked for explicitly.
• Who is accountable when it breaks in production at two in the morning.
• Recognising that a proposed solution works but is structurally wrong — the act that takes the most experience.

Is it still worth entering the field?

Yes, but what is worth learning has changed. Command of another language's syntax is worth less than it was; the ability to read a system, spot a wrong decision and state a problem clearly is worth more. Someone who can only write code against a precise specification is sitting exactly where the gap narrowed.

What we see in practice is that a junior developer needs more support than before rather than less — because they receive working code faster than they can judge it. That changes how a team is built. We wrote about the surrounding process in working with an agent in a team and what code review has to catch.

What actually happened to the roles?

What we see is not fewer people but a different mix. Less time on first-draft writing, more on review, definition and decisions. A role that is purely precise execution against a specification is the one being eroded; a role that includes judgement about what is worth building has widened, because there is now more output to judge per unit of time.

What does it mean for someone commissioning development?

That "how many developers are on the team" has become less informative, and "who makes the decisions and who reviews" has become more so. A supplier promising speed from tooling without explaining who judges the output is describing half the picture.

In practice, what separated a good outcome from a bad one on the projects we have seen was not which tool was running but whether there was an automatic gate before merge and a person who knew the system reviewing decisions. Neither of those comes with a licence.