At a glance
AI is extraordinarily good at producing code. It is extraordinarily bad at deciding what code should exist, how it should fit together, and what ought to happen when something goes wrong. Those are two different jobs, and only one of them has been automated.
This is the first post in a series about building software with AI properly, and everything else we write will hang off this one idea. So let us be clear up front: we are not anti-AI. We use it every day. We are against pretending it does a job it does not do.
What AI is genuinely brilliant at
Give a modern model a well-defined problem and it will write the code faster than you can describe it. Boilerplate. Data transformations. Test scaffolding. The regex you would otherwise spend twenty minutes losing an argument with. The fiddly parts of an API integration you have written a hundred times before.
It is tireless, it does not get bored at four in the afternoon, and it does not make the kind of typo you then spend an afternoon hunting.
Used well, that is a real step change. Work that took a good developer a day takes an hour. We are not going to pretend otherwise, and anyone telling you AI is useless for development has not used it seriously.
What it cannot do
Ask it how your system should be built and it will give you an answer. That is precisely the problem. It will always give you an answer, delivered with identical confidence whether it is sensible or catastrophic.
Architecture is a series of judgement calls that depend on things the model cannot see. How your business actually works. What your data will look like in three years. Which parts will get hammered in the first week of December. What your team can realistically maintain once the original developer has moved on. What the regulator expects. What happens when two people click the same button at the same moment.
None of that is in the prompt. Most of it is not written down anywhere at all. It lives in the head of someone who has watched software fail before and remembers exactly why.
Why the difference does not show up straight away
Here is the cruel part. Badly architected software works fine at first.
One person clicking around a demo will not expose a missing database index, or a query that fetches records without checking who is allowed to see them, or two processes quietly writing over each other. The app looks finished. It demos beautifully. You show it to people and they nod.
Then you get busy, and the bill arrives all at once. Pages that took a fifth of a second take twenty. A customer sees information belonging to another customer. Invoice numbers start duplicating. Bugs appear that nobody can reproduce, because they only happen when two things collide.
Success is what breaks this kind of software. Which is a horrible thing to discover at the exact moment things are finally going well.
The line: AI-assisted development versus vibe coding
This is the distinction we keep coming back to, and it is worth stating plainly.
AI-assisted development means a developer decides how the system works, uses AI to do the typing, reads every line it produces, and owns the result. If it breaks, they know where to look. If it needs changing in two years, someone can change it.
Vibe coding means the AI is the developer. You describe what you want, accept what comes back because it appears to work, and nobody on your side genuinely understands the output. There is nobody to ask, because no human ever made the decisions.
The code can look identical. The entire difference is whether a person is accountable for it.
And in fairness to vibe coding: it is fine. It is genuinely brilliant for prototypes, side projects and internal tools with a handful of users. It becomes a liability the moment the software holds other people's data, gets busy, or has to survive longer than a demo. Prototype away. Just be honest with yourself about which side of that line you are standing on.
Someone has to own the result
If you take one thing from this series, make it this. Every piece of software that lasts has a human being who understands it and is answerable for it.
That person decides the data structure. That person notices the missing permission check. That person knows why a particular decision was made and what it will cost to reverse. AI can hand them a great deal of the work, and increasingly does. It cannot be that person, because it does not carry the consequences.
The question worth asking about any AI-built system is not "does it work?" It is "who understands this, and what happens when they are not available?" If the honest answer is nobody, you do not have software. You have a liability with a nice interface.
What this looks like in practice
We use AI constantly. It never touches architecture, data design or security decisions unsupervised, and every line it writes gets reviewed by someone who could have written it themselves. That is the whole trick, and it is not complicated. It just requires someone who knows what they are looking at.
If you want the longer version of how we work, that is what AI development, done properly covers. The rest of this series digs into the specifics: the security holes we find every single time, why AI never adds the database index you need, what the last twenty per cent actually costs, and the honest verdict on the tools everyone is using.
AI is a brilliant typist. Let it type. Just do not let it decide.
Not sure which side of the line your own software is on? Our AI Code Audit is a fixed-price £495 review that tells you plainly what you are dealing with, or get in touch for a no-pressure conversation.
