We have reviewed a lot of codebases in the last two years that were built almost entirely by AI, and they tend to fail in the same way. The screens look finished. The happy path works. Then you look at how data is stored, what happens when two people act at once, or how errors surface, and there is nothing there.
This is not an argument against using AI. We use it on every project and it has genuinely changed how much a small team can deliver. But speed of output and quality of decision are different things, and only one of them got automated.
What AI is good at
Execution. Given a clear target and clear constraints, it produces working code faster than any team could by hand. It is excellent at the well-trodden middle of a problem: forms, views, data plumbing, tests, the second and third version of a pattern that already exists in the codebase.
What it is not good at
Deciding what should exist. It will not tell you that the data model you asked for will make your reporting impossible in six months, or that the approach you chose costs ten times more to run at scale, or that a requirement contradicts one from three weeks ago. It answers the question you asked, confidently, whether or not it was the right question.
Unreviewed AI output is not a shortcut. It is a loan against your future engineering time, at an interest rate you cannot see yet.
How we structure it
Senior engineers set the architecture and the guardrails before any code is generated.
AI does the execution inside those boundaries, at speed.
Every meaningful decision is reviewed and signed off by a human before it ships.
You get a weekly readout in plain language, so the process is legible whether or not you are technical.
None of this slows the work down in a way you would notice. It changes what you are left holding at the end: a product someone can explain, extend and maintain, rather than a large amount of code nobody fully understands.
