Describing what you want and letting a model write it works far better than most sceptics expected. It also produces a large amount of software that nobody can safely change six months later. Both statements are true, and the difference between them is not the model.
What AI is genuinely good at
On a well-specified task inside an existing codebase, a competent model will produce a working implementation faster than a human will. It is unusually strong at the work engineers find tedious: wiring a form to an endpoint, writing the fifteenth variation of a CRUD handler, drafting migrations, generating test cases for a function whose behaviour is already clear.
It is also very good at reading code it has never seen. Handed an undocumented legacy system, a model will reconstruct intent from structure considerably faster than a person can. For modernisation work in particular, that has changed the economics.
What it is bad at, and does not tell you
The failure mode is not that AI writes broken code. Broken code fails loudly and gets fixed. The failure mode is that it writes plausible code — code that works for the case you described and quietly mishandles the case you did not.
- It will invent a plausible API surface rather than checking the real one, and the result compiles.
- It optimises for the request in front of it, not for consistency with decisions made elsewhere in your codebase.
- It rarely says the requirement is wrong. A senior engineer pushes back; a model implements what you asked for.
- It has no stake in the system being maintainable in a year, because it will not be the one maintaining it.
None of these are arguments against using AI. They are a specification for what has to sit around it.
The gates that make it safe
Every AI-generated change should pass exactly the checks you would apply to a new engineer's first pull request. Not more, and definitely not fewer.
- 1Human review by someone who understands the surrounding system and is accountable for the outcome.
- 2Automated tests that actually exercise the change, written or verified as part of the same work.
- 3Security review on anything touching authentication, authorisation, or user data.
- 4An architectural check — does this fit how the rest of the system is built, or does it introduce a fifth way of doing something we already do four ways?
What this does to a project timeline
The honest accounting: AI compresses implementation, which is a real but bounded share of a project. It does not compress discovery, architecture, review, testing, or the conversations where you work out what should actually be built.
So a build does not get four times faster. It gets meaningfully faster, in one phase, and the saving is real enough to matter to a budget. Anyone quoting a larger multiple is either measuring only the coding phase or is not counting the rework.
If you already have a vibe-coded prototype
This is now one of the most common situations we are called into. Someone built a working demo, the business saw it, and now it is supposed to go live. The prototype is not worthless — it is a very precise specification of what the business wants, which is usually the hardest thing to get.
What it typically lacks is error handling, authorisation enforced server-side rather than hidden in the interface, a data model that survives real volume, and any tests. Hardening it is real work, but it is much better-defined work than starting from a blank editor.
The short version
Use AI. Review everything it produces. Hold it to the same architectural standard as hand-written code. The teams getting hurt right now are not the ones using AI too much — they are the ones who removed the review step because the output looked finished.