The framing matters. AI as driver sounds like productivity, but in practice it means accepting whatever the model produces, then debugging it after. The slope is gentle and the bottom is far.
AI in the loop is different. The engineer still owns:
- the problem framing
- the architectural constraints
- the acceptance criteria
- the decision to merge
The model accelerates the middle — generating scaffolds, exploring alternatives, drafting tests, surfacing patterns from the codebase. The engineer collapses the gap between I know what I want and the code expresses it.
The tell: a team driven by AI talks about prompts. A team with AI in the loop talks about systems — how their conventions, types, tests and review processes shape what the model can and cannot do well.
The interesting work right now is upstream of the model. The leverage is in making your codebase the kind of place where an AI can do good work, which turns out to be the same things that make it a good place for a human.
flowchart LR
A[Engineer
intent] --> B[Constraints
& conventions]
B --> C[Model]
C --> D[Generated
scaffold]
D --> E[Engineer
judgement]
E -->|Merge| F[System]
E -->|Iterate| C