Most of the argument about AI in engineering is about whether to use it at all. We use it in every stage of our work, so the question we find more useful is what it changed.
What changed is specific. AI turned out to be good at the task engineers spent most of their day on, which is writing code that already has a clear shape. It did not get good at deciding what to build, what to leave out, or what a system should look like in two years. So the work did not disappear. It moved.
The failure we plan around
Ask people what goes wrong with AI-assisted development and they describe obviously broken code. Obviously broken code gets caught in review quickly, the same as anyone else's.
The expensive failure is clean code.
It is well structured and sensibly named, it comes with tests, and it was written against a requirement the model misread in the first paragraph. Nothing about it looks wrong, so it passes review. That version costs days, and they are spent before anyone asks the question that would have caught it.
Traced back, the cause is upstream, and it is usually one of three things. The instruction was ambiguous and got resolved by guessing. The scope was too large for one step, so the model invented the parts that were not specified. Or the repository had no written conventions to anchor to, so it picked plausible ones that did not match anything else in the codebase.
Those are specification problems, and they slowed human engineers down for years before any of this. The difference now is speed. A vague instruction used to produce a confused engineer who came back and asked. Now it produces four hundred lines that look finished.
Where the effort went instead
Most of our time now goes on requirements and design, and less of it on typing code.
A requirement arrives as a sentence with a lot of unstated assumptions inside it. The job is to turn it into a problem statement that says what happens in the awkward cases, and to write down what is out of scope. That second list matters more than it sounds.
An unstated exclusion is a gap, and a gap is where a confident wrong answer goes.
AI is useful in this stage, in a role people underuse. Ask it what is unclear about a requirement and it produces a long list of questions in the time it takes to reread the thing. Most are obvious. A few are ones we would have missed, and sometimes one of those changes the design.
Then an RFC, before any code. What we propose, the alternatives we rejected and why, the data migration, the rollback, and what we expect to break. Its first job is to be argued with while arguing is still cheap. Its second job is to be the instruction an AI works from, because a scoped written plan is precise enough to follow.
Prototypes stopped being expensive
Teams used to skip prototypes and argue over descriptions instead, because a throwaway version cost a week nobody would authorise. With AI building most of it, that cost has dropped far enough to change the habit.
When a clickable version of a disagreement takes an afternoon, "let's look at it first" becomes the cheap option. We build them to be thrown away and we often build more than one, because the fastest way to end an argument about two designs is to put both in front of someone.
Style guides earn their keep twice
A repository with a written style guide, stated conventions and a record of its architecture decisions gives the model conventions to follow instead of ones to invent.
None of this is AI overhead. A new engineer joining the team needs the same documents, and most teams never got round to writing them because the cost of not having them was diffuse. With AI in the loop that cost shows up in the first review, which finally makes the case.
The rest of the discipline is unremarkable and old. One scoped change at a time, small enough for a reviewer to hold in mind. Tests as part of the change, written with it. An RFC for anything that touches money, personal data, or a public interface.
What never leaves a person
AI is in every stage of our work and in charge of none of them. Where the line sits follows from what people and models are each good at.
Two things we will not do at all. Generated code does not reach production without a person having read it. And we do not use AI to produce the numbers in a report or the findings in an audit, because the entire value of those is that we checked them.
The short version
AI being good at coding has not left engineers with less to do. The parts of the job that were always the hardest, deciding what to build and describing it precisely enough to be right, now decide the outcome. Those were the parts worth doing all along.