Architecture
Bets the model can't make for you.
AI is a regression to the median. It writes the code most repositories contain, which is also the code most repositories regret. Senior engineers make architectural choices the model can't: where to draw a boundary, what to abstract, what to leave duplicated.
The intern's loop
A junior accepts whatever shape the model returns. After three sprints the codebase has four ways to make an HTTP call, two retry strategies, three logging conventions, and a 1,200-line service file because the model kept appending to it. Each individual generation looked fine. The cumulative drift is the bill.
Decided before generated
Architecture is decided before generation, not discovered after. Boundaries (modules, services, layers) are picked deliberately, patterns named (one HTTP client, one error type, one config loader), generations that violate them refused. Abstractions land when there's a real second caller, never speculatively. The model gets a tighter playing field, and produces tighter code.
Reads like one engineer wrote it
A repo that reads like one engineer wrote it. Conventions documented, enforced by lint, refactored when they break. New features land cleanly because the seams are designed, not emergent. The model produces code that fits, because it had no other option.
- 01Are boundaries (modules, services, layers) decided before generation or discovered after?
- 02Does your repo have one HTTP client and one error type, or several of each?
- 03Are conventions documented somewhere a new engineer (or model) can find them, or do they live in tribal memory?
- 04When the model returns a 1,200-line service file, does anything stop it from landing as written?