Nine developers out of ten now use AI to write code. That is not a forecast or a vendor claim: it comes from the DORA study published in September 2025, on a sample of nearly five thousand people worldwide. The median time spent working with an AI assistant is two hours a day.
So the question is no longer whether your software supplier uses AI. The question is which of three levels they use it on, because that decides whether you get a working system or an expensive problem.
Three levels of the same technology
The same language models power three completely different ways of working. The difference is not in the tool. It is in who carries responsibility for the result.
| Level | Who writes the code | Who answers for the result | Where it breaks |
|---|---|---|---|
| Code completion | a person, AI finishes the line | the person | nowhere, it is an ordinary tool, like autocomplete in a text editor |
| Vibe coding | AI, the person accepts without reading | nobody | at the first real load, data error or attempt to extend it |
| AI-assisted engineering | AI, under an engineer’s spec and review | the engineer | where the codebase is large, old and somebody else’s |
Code completion has been around for years and surprises nobody. A person writes, the tool finishes the sentence.
Vibe coding is a term coined by Andrej Karpathy, one of the founders of OpenAI. It describes work where you throw a problem at the model, accept whatever comes out, do not read the diff, and when an error appears you paste it back without comment. For play and for prototypes it works very well. As a way to build the system your company will run on, it does not.
AI-assisted engineering is the third level: the model still generates the code, but every piece has a specification before it is written and a review after, and a human makes the architectural decisions. It is a method, not a tool setting.
The one-sentence test: if nobody can explain why a given part of the system works the way it does, that is not AI-assisted engineering. It is vibe coding with a better name.
The person who coined vibe coding says it is not enough
The separation between the two levels came from the author of the term himself.
On 30 April 2026, after his talk at the Sequoia AI Ascent conference, Karpathy wrote on his blog that vibe coding is now a closed chapter, and named the professional version of this work agentic engineering:
The professional discipline of orchestrating fallible agents while maintaining correctness, security, taste and maintainability. Andrej Karpathy, 30 April 2026
He added a comparison: “Vibe coding raises the floor. Agentic engineering raises the ceiling.”
One word carries the weight here: fallible. The whole method is built on the assumption that the model gets things wrong, and not occasionally but by its nature. That is why it needs a specification before the work, a review after it, automated tests and permission control. Vibe coding assumes the output is good. Engineering assumes it has to be checked.
The naming is still settling, so you will meet “AI-assisted engineering”, “agentic engineering” and “spec-driven development”. They describe the same thing: the machine generates, the human answers for it.
What the work actually looks like
Let us take the mystery out of it, because it sounds more exotic than it looks. One cycle of work on a system feature:
- Specification. The engineer describes what is to be built, what data it connects to and how we will know it works. This is the part where experience makes the difference, and the part that cannot be handed over.
- Generation. The agent writes the code. Usually a quarter of an hour for something that would take a day by hand.
- Review. A person reads every piece and answers two questions: does it do what it was supposed to do, and does it also do something nobody knows about.
- Tests. Automated, run on every change. Without them there is no method, only faster typing.
- Release. A deliberate decision that this goes to production. A human makes it and a human answers for it.
Steps 1, 3 and 5 take roughly 70 percent of the time. Step 2, the one everyone films, is the shortest.
That translates directly into what you buy. You are not paying for the speed of writing code. You are paying for someone who can write a sound specification and catch, in generated code, the bug you cannot see until you go looking for it.
What the data says, for and against
In this field it is easy to find a number to fit a claim. Below is the full set, including results that do not favour the method.
For:
- GitHub and MIT, controlled study (2023): developers with an AI assistant finished the task 55.8% faster. The authors’ own caveat: it was a single, well-defined task written from scratch.
- DORA 2025: over 80% of respondents report a productivity increase, 59% see a positive effect on code quality. For the first time AI adoption correlates positively with delivery throughput, where a year earlier that correlation was negative.
Against:
- METR, controlled study (July 2025): sixteen experienced developers, 246 real tasks in their own, mature repositories. With AI tools they worked 19% slower. More telling than the pace is the perception result: they expected a 24% speed-up, and after the study, having done the work themselves, they still estimated they had been 20% faster.
- Stack Overflow 2025 (over 49 thousand responses): 46% of developers do not trust the accuracy of what AI generates. 45% say debugging AI-written code takes longer.
- DORA 2025: delivery stability continues to decline: more failed changes and more fixes. 24% of respondents report trust in AI-generated code, 30% report a lack of it.
- GitClear, an analysis of 211 million lines of code: the share of code rewritten shortly after being written rose from 3.3% in 2021 to 7.1% in 2025.
In the METR study the gap between perception and measurement reached close to 40 percentage points. The result shows that a subjective sense of speed-up does not match the measurement. This applies to the supplier and to the client's own team alike.
The headline conclusion of DORA 2025 is that AI is an amplifier. It magnifies what the organisation already has. A team with a good process delivers faster. A team with a mess delivers the mess, only more efficiently.
Where the method helps and where it gets in the way
The data above falls into a fairly clear split.
| Strong speed-up | No help, or harm |
|---|---|
| new systems built from scratch | maintaining a large, mature system |
| boilerplate, application scaffolding, integrations | debugging |
| standard data operations | complex, non-obvious domain logic |
| entering an unfamiliar technology | reviewing undocumented code written by others |
So a speed-up claim without a stated scope means little, ours included. Our multiplier, a fivefold speed-up, applies to new systems built from scratch. It does not cover work on somebody else’s legacy or debugging, and it is not universal.
It is worth asking any supplier where their multiplier stops applying. The absence of an answer to that question is itself information.
This is not the same as “a system with AI”
Two things go by the same abbreviation, and they are entirely different purchases:
- AI as a build method. That is what this article is about. The system is built faster and cheaper, but there is no artificial intelligence inside it. It is ordinary, solid software produced at a lower cost.
- AI as a product feature: a language model, search across your own documents, an agent that performs tasks. Here it is your company using AI, not the contractor while writing code.
A supplier may have one, the other, both or neither, and say “we do AI” in every one of those cases. What separates the four kinds of AI software, and what each of them costs, is set out in a separate article: AI software: four different things sold under one name. Which of those you should be buying, and from whom, is the subject of our page on choosing an AI software house.
We tested the method on our own company
You can read about a method or you can test it on yourself. We chose the second: for a year we suspended sales and turned our own company into a laboratory.
Between 11 July and 26 August 2026, so in 46 days, thirteen systems were built. Nine of them run in production today and operate our own company: from a portal monitoring the state of all systems, through handling three mailboxes, to an invoicing automation.
Two of them, with results:
- Finance system. In production on day one, code review closed on day five. Thirty hours of work instead of the four to six months a classic approach would take. See how it was built
- Invoicing automation. Three working hours to build, and the monthly close went from an hour and a half to fifteen minutes. See how it was built
One detail belongs with both numbers: the invoicing automation was built in three hours on the second attempt. The first one, several months earlier, failed, because the level of tool knowledge at the time was not enough to finish it. Same person, same problem, different level of skill.
The speed of writing code did not change. What changed was the knowledge of what to build and how.
Rigour can be shown in numbers the same way pace can: automated tests on the key systems stand at 103/103, 114, 44, 25/25 and 18/18. The roadmap holds 129 items, so the technical debt is counted. A full code review at the end of July produced 13 findings; both high-severity ones were fixed and deployed.
Methodological caveat on the numbers above: this is an experiment run on our own company, without a control group. We compare our own working time against market quotes for the same scope, which is an indication rather than proof. The controlled studies are described above and their results are mixed.
Three questions that verify this with a supplier
They work on us too.
- Who reviews the code before it reaches production? A good answer names a specific person and a specific moment. A bad one is: “AI checks it.”
- Where did this method not help you? Anyone genuinely working this way will list the areas without pausing. Anyone who merely added AI to the offer will be hearing the question for the first time.
- Show me a system you built for yourselves and use every day. A portfolio shows what someone can sell. Their own system shows what they trust enough to work on.
The full list of ten questions, together with what a bad answer to each one sounds like, is on the page about choosing a supplier.
Frequently asked questions
Is AI-assisted engineering the same as vibe coding? No. In vibe coding nobody reads the generated code and nobody answers for the result. In AI-assisted engineering every piece has a specification before it is written, a human review after, and automated tests. The author of the term “vibe coding”, Andrej Karpathy, separated the two levels himself in April 2026, naming the professional version agentic engineering.
Is code written this way of lower quality? It can be, and the risk is documented. The GitClear analysis shows the share of code rewritten shortly after being written rose from 3.3% in 2021 to 7.1% in 2025, and the DORA 2025 report records a decline in delivery stability. The method holds up only where automated tests and human review stand behind it. Without them it is faster production of debt.
Does this mean software should be cheaper now? For new systems built from scratch, yes, and that is the scope in which we say it. A low price without a defined scope is not an advantage, though. It is a transfer of risk from the supplier to you, and it surfaces with every subsequent change.
Can this method maintain an existing, large system? This is the weakest point of the method. The METR study on mature repositories found experienced developers were 19% slower with AI, and 45% of developers in the Stack Overflow survey say debugging AI code takes longer. On a pure maintenance project on large legacy we will not sell you a speed-up, because there is none there.
How do I check whether a supplier really works this way or only says so? Ask them to show a system they built for themselves and use every day. Ask where the method did not help them. The answer to the second question is the best test we know.
Test the method on your own process
A free digital audit takes one to two days and ends with a diagnosis, not a quote. You will hear what can be built quickly in your company, and what is not worth touching at all.
Book a free audit →