Why AI-accelerated development doesn't mean lower quality

If you have been quoted a suspiciously fast timeline recently and wondered whether AI was doing the work, you were probably right, and your suspicion is reasonable. There is a lot of AI-assisted code being shipped right now that should not have been.

This article is a defence of the practice, but not an unconditional one. The conditions are the entire argument.

What the fear actually is

Stated plainly, it is: you are using a machine to produce something you do not understand, and I am going to own the consequences.

That is a good fear. It is the correct fear. It is also a fear about a specific failure mode rather than about the tool, and the difference matters, because the failure mode has a name and a fix.

What LLMs are genuinely good at

Being specific here is the only way to be credible about the limits.

• Writing code that resembles code it has seen. Which is most code. A REST endpoint, a form handler, a migration, a test suite for a function whose contract is clear.
• Translation. Between languages, between framework versions, between an API's documentation and a working client for it.
• Volume with consistency. Forty endpoints that all handle errors the same way is a job humans do worse as they get bored. This is a real quality gain, not just a speed one.
• The first draft of the tedious. Fixtures, seed data, documentation stubs, edge-case lists.

What they are bad at, and why it is the dangerous part

• Deciding what to build. A model will implement what you asked for, competently, including when what you asked for was wrong.
• Data modelling. It will produce a schema. It will not know that your business treats a "customer" and an "account" as different things in a way that will matter enormously in year two.
• Knowing what it does not know. This is the one that costs money. A model does not return low confidence and stop. It produces a plausible answer at the same register as a correct one.
• Security judgement in context. It will remember to escape output. It will not notice that this particular endpoint is reachable without authentication because of a routing decision made in a different file.
• Load, cost and failure behaviour. Correct code that issues one query per row is correct, and it will take your site down at ten thousand rows.

Read those two lists together and the pattern is clear. Models are good at implementation and bad at judgement. The failures are not distributed randomly across a project; they cluster precisely in the decisions that are expensive to reverse.

The actual difference: who owns the architecture

Here is the distinction that separates a studio using AI well from one using it badly, and it is not about which model they use.

The bad version: a prompt describing the feature, the output pasted in, a check that it appears to work, ship. The model has made the architectural decisions, silently, as a side effect of implementing. Nobody chose the data model — it emerged. Nobody decided the failure behaviour — it was defaulted.

The good version: a human decides the data model, the interfaces, the failure behaviour and the security boundaries, writes them down, and the model implements inside that. The design space is closed before generation starts. The model is filling in a structure, not choosing one.

That is the entire difference, and it explains why the same tool produces both outcomes.

Review is not optional, and it is not skimming

The second condition, and the one most easily faked.

Reading AI-generated code is harder than reading a colleague's, in a specific way. A junior engineer's mistakes are legible — you can see where they got confused, and the code around a mistake usually looks uncertain too. Model output is uniformly confident. The line that is wrong looks exactly like the lines that are right.

So review has to be adversarial rather than reassuring:

• What happens when this input is empty, hostile, or enormous?
• Is this query inside a loop?
• Is this endpoint actually behind the auth check I think it is?
• What does this do the second time it runs?
• Does this match the plan, or something adjacent to it that was easier to generate?

That last one catches a surprising amount. Models drift toward the most common shape of a thing, so a slightly unusual requirement quietly becomes the usual version of itself.

Where the time saving actually comes from

Worth being precise, because the marketing version of this is wrong.

It does not come from thinking less. Discovery, architecture and review take the same time they always did — arguably review takes longer.

It comes from the gap between deciding what to build and having it built. Typing is compressed. The tedious middle of a project — the twenty similar endpoints, the admin screens, the test scaffolding — stops taking three weeks.

So a project that was twelve weeks becomes seven, not two. Anyone quoting you two was not doing the other five weeks in the first place, and you will find out which five.

What this means for you as a buyer

Questions worth asking anyone using AI in your build:

1. Who decides the data model? If the answer is vague, that is the answer.
2. What does review look like? "We test it" is not review. Testing confirms it does what you expected; review catches what you did not think to expect.
3. Can you explain this code to me? Pick a file, any file. Ownership of code you cannot explain is not ownership.
4. What did you decide not to let it do? The most useful question on this list. Everyone with a considered practice has an answer. Everyone without one hears it as a strange question.

Our position, stated so you can hold us to it

AI writes code here. It does not decide architecture, and nothing it produces reaches a client without a senior engineer having read and understood it. Discovery is human. The build plan is human and written down before implementation starts. Review is a line-by-line read, not a glance at the diff.

The reason to state it that specifically is that "we use AI responsibly" is unfalsifiable, and this is not. If we ship something none of us can explain, we have broken a rule we published, and you can point at it.