AI-assisted coding is genuinely fast. You can go from blank file to working prototype in a fraction of the time it took two years ago. The problem shows up about a week later, when you need to change something and the codebase has quietly become a maze nobody fully understands — including the person who wrote it.
I’ve shipped enough AI-assisted projects now to know that speed is not the constraint. Keeping the thing understandable is.
The coherence problem
When you generate code fast, you generate a lot of it. Patterns multiply. The same logic gets expressed three different ways across three files because each generation session didn’t know about the others. Types drift. Naming drifts. One file uses a utility that another file re-implements from scratch.
None of this shows up in a demo. It shows up when you add a fourth feature and realize you’re now working against the codebase instead of with it.
The fix isn’t to write less AI-assisted code. It’s to review with more discipline. Every generated block I treat as a first draft. I read it the way I’d read a junior engineer’s PR — checking for duplication, checking that the approach is consistent with what’s already there, checking that I actually understand it before I commit it.
What I keep in my own hands
There are parts of a project I don’t hand to the model. Architecture decisions, data shape, the contracts between modules — those I write out in plain language before touching the editor. Not because the model can’t generate an architecture, but because if I don’t own the design, I can’t maintain it.
The model is excellent at filling in the interior of a well-framed problem. Define the edges clearly — what goes in, what comes out, what it must not do — and it produces good work. Leave the edges fuzzy and you get something that appears to work until the requirements shift by an inch.
Staying shippable
The discipline that’s made the biggest difference: I build in vertical slices and ship each one before starting the next. A complete thin path through the system — even if it only handles one case — is worth more than a wide, half-finished implementation.
AI tooling makes horizontal sprawl very easy. You can generate the skeleton of ten features in an afternoon. But ten half-done things that don’t ship are worth less than two things that do. The same constraint applies whether you’re using AI or not. The tooling just makes the temptation stronger.