Ideas
What AI changes, and what it doesn’t, in software engineering
A short list of what AI has changed in the work, a shorter one of what it has not, and what that means for the engineer’s job
Working with AI assistants on real features and real legacy code has left me with a short list of what changed and a shorter one of what did not.
What changed. Writing code is no longer the scarce activity. An assistant produces a plausible implementation faster than I can read it, in any language, with tests if asked. The cost of trying an approach has collapsed, so exploring three designs before choosing one is affordable. And the specification has moved to the centre: what I write down before the code is now what actually gets built, line for line, so it had better be right.
What did not change. Somebody still has to decide what the software should do, what it must never do, and when it is good enough to ship.
The assistant will happily implement a bad idea well
Verification is still the expensive part, and it got more expensive, not less, because there is more code to verify and it arrives faster. And responsibility did not move: when generated code fails in production, nobody asks the model.
The consequence for the job is not that engineers disappear. It is that the centre of gravity moves from producing code to validating it: writing specifications precise enough to be executed, reviewing designs adversarially, keeping invariants explicit, and refusing to merge what cannot be verified. Those were always the senior skills. AI just made them the whole job.
What worries me is not the technology. It is organisations that measure the gain in lines produced and never in lines verified, and that let a mass of generated code ship because it was cheap to produce.
Cheap to produce has never meant cheap to own