“AI-accelerated” is on its way to meaning nothing. It is on every studio’s homepage now, usually with no numbers behind it and no account of what it actually changed. If you run a technical team, you have probably already watched a demo that looked like magic and then wondered what happens when that code meets your data, your integrations and your users.
So here is a breakdown of where we see AI tooling compressing a real build, where it doesn’t, and what that means for how you resource and run delivery.
What gets faster
The wins are concentrated in a few places.
Boilerplate and scaffolding
Setting up a project, wiring routes, writing the CRUD layer, generating types from a schema, stubbing tests, writing the fiftieth data-transformation function that looks like the previous forty-nine. This work is necessary, repetitive, and low in judgement and AI tooling eats it. A developer who used to spend a morning on setup can spend twenty minutes and move on to the part that needs a brain.
First drafts
A first pass at a function, a component, a migration, a regex you would otherwise have to look up. The model gets you to something on the screen quickly, and reacting to a draft is faster than facing a blank file. The keyword is draft. It is a starting point to sharpen, not an answer to ship.
Translation and glue
Moving between languages or frameworks, reading an unfamiliar codebase, explaining what a gnarly legacy function does, converting a spec into a rough implementation. AI is a good translator, and engineers spend a lot of time translating.
Repetitive labour at volume
Renaming across a large codebase in a way a simple find-and-replace cannot, applying a consistent change to a hundred files, drafting documentation from code. Tedious, mechanical, error-prone by hand. Good candidates for assistance.
Notice the pattern. AI reliably speeds up work that is high in labour and low in consequence-if-wrong. That is a real and useful chunk of any build.
What does not get faster
The parts that decide whether a system is any good are exactly the parts AI does not do for you.
Architecture
Deciding how the system is shaped, where the boundaries sit, what to make simple now so it stays changeable later, which trade-offs you are consciously accepting. A model will happily generate an architecture. It will not be accountable for living with it in two years.
Knowing what good looks like
A model can produce code that runs. Whether it is the right code, whether it handles the case that will actually break in production, whether it is secure, whether it will still be legible to the next person, whether it even solves the real problem, all of that is a judgement call that depends on experience the model simply does not have and context it was never given to start with.
Production hardening
The distance between a demo and a system you can put real load, real money and real users through is where most of the actual engineering lives. Error handling, edge cases, security, observability, performance under stress, graceful failure, and messy integration with systems that don’t follow their own documented APIs. AI helps at the margins here but does not close the gaps.
Understanding the problem
The most expensive mistakes are not bad code. They are well-built solutions to the wrong problem. No tool shortcuts the work of understanding what a client actually needs, which is usually different from what was first asked for.
The failure mode nobody puts on the homepage
Here is where it goes wrong. AI-first delivery with no senior oversight produces code that looks plausible but is wrong.
That is a worse failure than code that is obviously broken. Obviously broken fails and gets fixed. Plausible-but-wrong passes a quick read, gets merged, and surfaces later as a subtle bug, a security hole, or a design decision that boxes you in. The model is very good at producing confident, well-formatted, reasonable-looking output. Confident and correct are not the same thing, and telling them apart is a senior skill.
Left unsupervised, an AI-heavy team generates volume: more code, more pull requests, more surface area. Volume is not progress. Without someone who knows what good looks like reviewing it, you are accumulating tech debt faster than before, just with better syntax highlighting. The speed-up on the way in becomes a slow-down later, when someone has to understand, debug and unpick a large body of code nobody fully reasoned about.
Why senior people matter more, not less
A reasonable instinct is that AI lets you get by with a more junior team. It is the wrong read. AI raises the floor on output and raises the value of judgement at the same time, and judgement is what senior people bring.
When typing code is cheap, the bottleneck shifts to deciding what to build, reviewing what got built, and being accountable for whether it is right. The human role shifts up the stack: from writing every line to directing the work, setting the architecture, catching the plausible-but-wrong, and owning the outcome.
A junior developer with AI produces a lot of code they cannot fully evaluate. A senior developer with AI produces the same volume and can tell what’s good. That difference is the whole game. The teams getting real value are not replacing their experienced people. They are pointing them at judgement and review, and handing the labour to the tools.
That is the model we run: AI does the labour, our people do the judgement. It is why our delivery is faster and why the output holds up in production, rather than looking fast in a demo and falling over under load.
The site you are reading this on is the working example. It was built with AI tooling throughout, under senior oversight from our founder, our design director and our head of AI engineering. There is no traditional CMS: the content lives as files in the repository, and editing it is a conversation with Claude that ends in a version-controlled change, so every edit has an author, a reason and a way back.
A recent example, in the unglamorous part where this usually shows up. Our builds had crept to about fifteen minutes. The first suspicion was the images, which had just been re-exported at higher resolution, and that turned out to be wrong. The real cause was that the build was throwing away its own cache of processed images on every run and redoing all of them from scratch. Fixing it took the build from eleven minutes to under one, and the build step itself to five seconds.
It is worth being precise about who did what there, in an article about precisely that. An AI agent found it, working through the build logs on our instruction, and it was better at that than a person would have been. What the humans decided was what it meant: that our design director should not have to re-export his artwork to make a build finish, that the higher resolution was worth keeping, and that the fix belonged in the pipeline rather than in the design. The digging was the tool’s. The call to protect the quality was ours, and that is the part a client is paying for.
How to think about it if you lead a team
A few practical filters.
Treat AI output as a draft from a fast, capable, tireless junior who has no memory of your context and no accountability. You would review that person’s work. Review this the same way, and keep the review with someone experienced.
Be suspicious of speed claims with no measurement behind them. If a partner cannot tell you what got faster and how they know, the “acceleration” is marketing. We measure build speed against how the same work ran before, so the claim is grounded, not asserted.
And do not confuse volume with progress. The right question is not how much code got produced. It is whether the thing works, whether it will keep working, and whether anyone can change it in a year.
The short version
AI compresses the labour of building software: the boilerplate, the first drafts, the translation, the repetitive work. It does not do the architecture, the judgement, the production hardening, or the understanding of the real problem. Those still sit with experienced people, and in an AI-accelerated team they matter more, because they separate fast-and-right from fast-and-wrong.
If you are weighing up how AI could change and improve your delivery, and you want a straight answer, we are happy to talk it through. Contact us to arrange a free 30-minute call, no pressure and no obligation, just a useful conversation about where the real speed-ups are and where the risks can hide.