AI-Driven Development Is Not the Same as Writing Code with AI
Summary: AI-driven development is a process decision: each phase states in advance where AI produces a draft and which named person approves it. AI-assisted coding is a tooling decision made by individual engineers. The two are sold under one name, and only the first one changes a delivery date, because only the first one touches how work is verified.
Contents
- Why "we use AI" tells you nothing about your delivery date
- What is AI-driven development?
- The five-checkpoint approval framework
- Introducing it in six steps
- Five mistakes that make AI adoption look like progress
- When NOT to introduce AI-driven development
- Frequently asked questions
Why "we use AI" tells you nothing about your delivery date
Ask five development vendors what AI-driven development means. You will get two unrelated answers wearing the same label. One group describes tools their engineers use. The other describes how their process is organized. The gap between them becomes visible after the contract is signed, when the proposed schedule turns out to look exactly like the schedule before AI.
There is now measured evidence for why the tooling answer is not enough.
METR ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks in repositories they had worked in for years. Before starting, the developers expected AI to make them 24% faster. Afterwards, they estimated it had made them 20% faster. Measured, they were 19% slower with AI tools than without (METR, July 2025). METR is explicit that this is one context, experienced developers in mature codebases they know well, and does not prove AI fails to help developers generally.
Take the caveat seriously and one finding still stands: the direction of the perception gap. A team's own sense of being faster is not a measurement, and in this trial it pointed the wrong way by roughly 39 percentage points.
The industry-scale picture shows the same tension from the other side. The 2025 DORA report found 90% of technology professionals now use AI at work, and that higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. Code review turnaround is named as the constraint, because reviewers carry a heavier cognitive load when auditing AI-generated changes (DORA, 2025).
Read together, the two results say something a procurement checklist rarely captures. Generation capacity and verification capacity are separate. Buying the first without moving the second does not compress a schedule; it relocates the cost to integration, where it arrives as rework.
This article sets out where AI belongs phase by phase, who still signs off, and which phases it does not help at all. It is the working model we apply in our system development service for Japanese enterprises.
What is AI-driven development?
AI-driven development is a process design in which every phase of the work declares, in advance, where AI produces a draft and which named person approves the result. AI-assisted coding is a tooling choice, made by individual engineers, about how they write code.
The difference is not a matter of degree. They change different things, are decided by different people, and fail for different reasons.
| AI-assisted coding | AI-driven development | |
|---|---|---|
| Unit of adoption | The individual engineer | The phase of the process |
| What actually changes | How fast code is typed | Where drafts come from, and who approves them |
| Who decides | Each engineer, per task | Written down before the work starts |
| Where it shows up | Commit volume | Review queue length, rework rate, handover cost |
| Typical failure | Review capacity stays flat | Nobody wrote down who approves what |
A team can adopt every assistant on the market and change its process by nothing at all. Many have. That is a legitimate choice; it is simply not the thing that moves a date, and it should not be priced as though it were.
The five-checkpoint approval framework
This is the table we fill in before a project starts. Every row names what AI drafts, who decides, and what evidence remains afterwards. A row with an empty third column is not a process, it is an intention.
| Phase | AI produces | A person decides | Evidence kept |
|---|---|---|---|
| Requirements | Ambiguous passages extracted from the specification, turned into a question list | Which questions go to the client, and what the answer commits us to | Written Q&A appended to the specification |
| Design | Option sketches, comparable prior art, trade-off summaries | The architecture call, including what was rejected and why | Decision record naming the rejected option |
| Implementation | Draft code, and tests written ahead of the implementation | What is accepted into the branch | Pull request approved by a named reviewer |
| Review | First-pass findings and candidate defects | Which findings are real, and their severity | Review comments referencing the rule that fired |
| Documentation | Updates produced in the same change unit as the code | Whether the document still matches the intent | Documentation diff inside the same pull request |
One rule runs across all five: what may be sent to which AI service is a documented decision about client data, not a judgment each engineer makes alone at their desk.
Introducing it in six steps
Step 1. Measure the current constraint before buying anything. If work already queues at review, faster generation lengthens the queue. DORA names review turnaround as the common bottleneck, so start by checking whether it is yours.
Step 2. Write the approval line down, per phase. For each phase, one sentence: AI drafts X, person in role Y approves. Teams that skip this discover during an incident that nobody had agreed on it.
Step 3. Decide the data rule. Which categories of client data may reach which service, who approved that, and where the record lives. Do this before the first engineer needs it, not after.
Step 4. Start with the checkable phases. Test generation, investigating an unfamiliar codebase, preparing a migration, keeping documentation current. These have defined targets and mechanically verifiable results, so a wrong draft is caught cheaply.
Step 5. Raise verification capacity before generation capacity. More reviewers, smaller pull requests, tests that run on every commit. This is the unglamorous step that decides whether steps 1 to 4 produce a shorter schedule or a larger integration bill.
Step 6. Measure with delivery outcomes, not self-report. Cycle time, change failure rate, rework. The METR trial is the reason: a team's felt speed and its measured speed pointed in opposite directions.
What we learned in production
We built a CPU-only multilingual OCR service that reads identifiers from photographed product labels. The main engine dropped Vietnamese diacritics entirely: Sản phẩm Việt Nam came back as Sn phm Vit Nam, not degraded, simply gone.
Four decisions resolved it, and none of them were code-writing decisions.
We did not fine-tune the main engine. All languages share the same recognition weights, so retraining for Vietnamese put the accuracy already verified for English and Japanese at risk. We added a separate Vietnamese engine instead, leaving the working path untouched.
We kept the second engine disabled by default. It costs roughly five times the footprint of the main engine, so it loads only when a Vietnamese request actually arrives.
We declined to certify it for photographed input. Its accuracy was measured on rendered text, not camera output. Until it is validated on photographs, it stays off for photographs, and we say so rather than quoting the better number.
We chose rule-based identifier extraction over a trained model, so every extracted value can be traced back to the rule that produced it when a false positive needs investigating.
AI assisted throughout that work. It did not make any of those four calls, and no amount of generation speed would have substituted for them. The full measurement method is in the OCR case study.
Five mistakes that make AI adoption look like progress
1. Buying generation capacity while review capacity stays flat. Consequence: throughput and instability rise together, exactly the pattern DORA measured. Avoid it by treating reviewer time as the budget line that has to move first.
2. Never writing down who approves AI output. Consequence: responsibility is clear until the first incident, then it is not. Avoid it with one sentence per phase, stored where the team actually looks.
3. Applying AI to requirements that are not settled. Consequence: the team builds the wrong thing sooner, and the rework arrives earlier and larger. Avoid it by keeping AI on investigation and drafting until the specification stops moving.
4. Leaving the data rule to individual engineers. Consequence: client data reaches services nobody approved, discovered during a security review rather than before it. Avoid it with a documented list, decided once.
5. Measuring adoption by how fast the team feels. Consequence: the number that gets reported upward is the one the METR trial showed can invert. Avoid it by reporting cycle time and change failure rate instead.
When NOT to introduce AI-driven development
The specification is still moving in the phase you want to change. Investigation work can start regardless. Anything downstream of an unsettled requirement should wait, because speed applied to the wrong target produces rework, not delivery.
Nobody can be freed up to review. If review is already saturated, this programme adds pressure to the exact place that is failing. Fix the constraint first.
The data cannot leave your environment and no self-hosted option is approved. For organizations bound by APPI or GDPR, the rule comes before the tooling. A local model may be viable; that is an architecture question, and we wrote up one such case in our CPU-only OCR article.
One engineer, one short prototype. The process overhead exceeds the benefit. Use the assistants and skip the framework.
Frequently asked questions
Is AI-driven development just AI coding assistants with a better name? No. Assistants change how fast an individual writes code. AI-driven development changes which phases produce drafts automatically and where human approval is required. Adopting assistants without changing the process is common and changes little.
Will it shorten our delivery schedule? Only if verification capacity moves with it. DORA found AI adoption raising throughput and instability at the same time, with review turnaround as the constraint. Change the checkable phases first: tests, documentation, codebase investigation.
Our engineers say AI already made them much faster. Is that not evidence? It is a signal, not a measurement. In METR's trial, developers estimated a 20% speedup while measuring 19% slower. Ask for cycle time and change failure rate before and after instead.
Do we need to settle requirements before introducing AI? For phases that depend on requirements, yes. Phases that do not, such as investigating an existing system, can start at any time.
Who is responsible when AI-generated code causes a defect? The same people as before. Treating AI output as a draft approved by a named person leaves the responsibility line unchanged. If nobody can say who approved a change, AI revealed that gap rather than creating it.
How do we tell whether a vendor has a process or only tools? Three questions. Who approves AI output and against what criteria. Which phases deliberately do not use AI. What client data may reach which service, and who decided. A vendor with a process answers with roles and checkpoints; a vendor with tools answers that their engineers check the output.
Conclusion
- Generation capacity and verification capacity are separate budgets. Moving only the first relocates cost to integration.
- The approval line, written per phase before work starts, is what distinguishes a process from a set of tools.
- Self-reported speed is not a measurement. Report cycle time, change failure rate, and rework instead.
If you are deciding which phases of your development process should adopt AI and which should not, book a free consultation. We work through the five checkpoints above against your current process and hand back the findings.
