Why AI coding is not software engineering yet

“In five years AI will write the software itself.” The sentence sounds bold but is mainly imprecise: it equates writing code with developing software. Break the development process into its activities and it quickly becomes clear which share is really affected – and which one AI tends to grow.

1. The claim and its flaw

Code generation is an activity. Software engineering is the discipline within which that activity happens: clarifying requirements, settling structure, agreeing interfaces, implementing, reviewing, shipping, operating, changing. A model that takes over implementation changes one step of that chain profoundly – and leaves the others largely untouched.

That is not an argument against AI. It is an argument against the wrong expectation, from which wrong planning follows: over-optimistic proposals, thinly staffed reviews, architecture work started too late.

2. The process in eight activities

The list below is deliberately coarse. It is enough, though, to make the question answerable: which parts does a coding agent really address?

3. What actually shifts

The interesting effect is not in the “implementing” row but two rows below. When implementation gets cheaper, the volume to review grows – and reviewing is the one activity in the table that can hardly be automated without undermining exactly the confidence it is supposed to create.

The bottleneck does not disappear, it moves: from the keyboard to the review, from implementation to decision. Teams that see this invest early in automated quality gates and in smaller, reviewable change sets. Teams that do not, find themselves in a paradox after a few months: more output, slower delivery.

4. The arithmetic that rarely works out

A simple example makes this concrete. Suppose implementation accounts for 30% of the total effort and gets 60% faster. The net effect on the project is 18%. If review effort simultaneously rises from 10% to 15%, roughly 13% remains. That is a good number – but it is not the halving some people budget for.

The figures are illustrative and do not replace measuring your own. What matters is the structure of the calculation: the effect hangs on the share of implementation, not on the speed of the model. Anyone who wants a bigger effect therefore has to work on that share – for instance by not recreating recurring groundwork per project at all.

5. Responsibility cannot be generated

Software engineering is also a question of accountability: someone vouches for a system doing what was promised. A model cannot take that on – not out of technical inadequacy, but because accountability is a social and contractual category.

Three consequences follow for daily work:

• Whoever submits a change set is fully responsible for it – regardless of how much of it they typed.
• “The model suggested it that way” is not a justification but a description of what happened.
• Checks should not be relaxed because generated code looks plausible. Plausibility is precisely the property these models optimise for.

6. What this means for teams

The obvious conclusion – “we need fewer juniors” – is dangerous. The activities that remain require exactly the experience you acquire by implementing. Cut the entry level and in five years nobody will be able to make architecture decisions and review generated code with any depth.

A shift in the learning path is more realistic: less time on boilerplate, more time reading, reviewing, modelling and debugging. That is more demanding – and needs deliberate guidance instead of the implicit practice of the past.

7. When AI coding really is enough

There are cases where code generation really does replace almost the entire process – and it is worth naming them rather than denying them:

• Throwaway tools: a script that reshapes a file once and is deleted afterwards.
• Prototypes for making a decision that demonstrably do not go to production – and do not quietly end up there either.
• Explorations: “what would this look like with that library?” as a thinking aid, not as a deliverable.

The difference is not code quality but lifetime and accountability. As soon as somebody operates the software, changes it or relies on it, the full process applies.

Common mistakes

• Extrapolating the productivity gain to the whole project instead of to the implementation share.
• Treating review as a formality even though the volume has grown.
• Postponing architecture work because “the code is already there”.
• Putting prototypes into production without catching up on the process that was skipped.
• Cutting entry-level positions – and with them tomorrow's capacity to review.

Checklist: keeping expectations realistic

Conclusion

AI coding is a very good advance in tooling and no substitute for engineering. The difference is not a question of model quality but of scope: a model produces solutions to stated problems. Software engineering begins before that – with the stating – and ends long after, with operating and changing.

In practice: use AI where it is strong, and invest the effort you free up exactly where it contributes nothing. That is the unspectacular but reliable version of a productivity gain.