AI-assisted software development

Why it matters

The value of AI-assisted development depends on the task, not the tool. Repetitive code, glue code and well-worn patterns speed up markedly, while new architecture, tricky domain logic and debugging an unfamiliar system move only a little. That is why an average “productivity percentage” across a whole organisation rarely says anything useful. What matters is where you point the AI, and whether the rest of the delivery chain can absorb the extra code.

AI use in software teams is already widespread. Google and DORA’s 2025 report, State of AI-assisted Software Development, published in September 2025, gathered responses from nearly 5,000 practitioners. Of those, 90% said they use AI at work and more than 80% felt it had raised their productivity. The same report names the flip side: AI use correlated positively with delivery throughput but negatively with delivery stability. Speed alone is not enough. According to DORA, what keeps a rising volume of changes from turning into instability is strong automated testing, mature version control practices and fast feedback loops.

What does AI-assisted software development mean?

AI-assisted software development means building software with AI involved across the whole workflow, from generating and refactoring code to reviewing and testing it. It is an umbrella term that spans the full range: code assistants embedded in the editor that complete a line at a time, and more autonomous coding agents that take a task and work it through in several steps. The common thread is that a person sets the goal and owns the result, and the AI produces suggestions within that.

The term says nothing about how much responsibility is handed to the AI. It covers both cautious use, where every line is reviewed, and a looser style, where suggestions are accepted quickly. Those extremes lead to very different outcomes, which is why neighbouring terms such as vibe coding, agentic coding and AI-native development exist to pin down which style is meant.

What separates professional AI-assisted development from vibe coding?

Review is the dividing line. Simon Willison defines vibe coding as building software with a language model without reviewing the code it writes, and says that if a developer reviews the code, tests it and can explain how it works, the work is ordinary software development, regardless of how much of it the model wrote. IBM makes the same point from the other side: code generated this way still needs code review, testing, dependency checks and a security assessment before it goes into production. The tool does not decide which side of the line a team is on. The deciding factor is what the team does at the moment it accepts a change.

It helps to separate three things that one word tends to lump together. The first is who does the work: a person who cannot read code, a technically minded non-developer, an experienced developer new to AI tools, or a developer who works with agents every day. The second is agent autonomy: how far the AI may go on its own before a person steers or approves, from line completion to an agent that works through a whole task. The third is review: whether the output is read, tested and judged before it is accepted. Vibe coding sits at the no-review end of the third axis, whatever the values on the other two. The same tool at the same autonomy level carries a very different risk depending on whether the code is reviewed.

How is it done in practice?

The day-to-day work splits into a few modes that often combine within the same day. A code assistant completes code in the editor as suggestions the developer accepts or rejects; GitHub Copilot and Cursor are the best known. Chat-based use means the developer asks the model for an explanation, a draft or a fix and moves parts of it into the code. A coding agent is handed a whole task and works through it in stages: it reads the codebase, proposes changes, runs tests and corrects itself.

AI is not limited to writing code. It is also used for review (going through a change and flagging issues before merge), generating tests, writing documentation and explaining old code. In all of these, quality depends on the instructions: the more precisely the task, context and constraints are described (prompting), the more useful the suggestion. The decisive step is still the same as it was before AI. A person reads, understands and approves the change.

What does the research say about productivity?

The evidence cuts both ways, and it is best read as a whole. In a controlled experiment by researchers from Microsoft Research, GitHub and MIT Sloan (Peng et al. 2023), developers who wrote an HTTP server in JavaScript with Copilot finished the task about 55.8% faster than a control group (95% confidence interval 21–89%). That result was for a bounded, familiar task, exactly where AI is at its strongest.

From the field the picture is more sober. A randomised trial published by METR in July 2025 followed 16 experienced open-source developers working in their own repositories, which they had worked on for five years on average (246 real tasks). The developers were 19% slower with AI, even though they estimated they had been 20% faster. The gap between measured and perceived is the study’s central warning: your own sense of speed is not a reliable gauge. The authors stress that the result applies to experienced developers in familiar, high-quality codebases and does not generalise to all developers.

In large survey data the direction is similarly split. Google and DORA’s 2024 report surveyed nearly 3,000 working professionals. More than 75% of them leaned on AI for at least one daily task, but 39% had little or no trust in AI-generated code. The same report estimated that a 25% increase in AI use was associated with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. Faster code production does not automatically mean faster or steadier delivery.

Why does code review become the bottleneck?

When AI writes code faster, the constraint moves from writing code to accepting it. Faros AI’s AI Engineering Report 2026 (April 2026) draws on two years of telemetry from 22,000 developers in more than 4,000 teams and compares each organisation’s periods of lowest and highest AI use. The acceptance rate of AI-suggested code rose from 20% to 60%, yet merged pull requests per developer grew by only 16.2%. Median time in review rose by 441.5%, pull requests merged without any review by 31.3%, and incidents per pull request by 242.7%. Faros sells engineering-metrics software, so the findings suit its product, and the report is not peer reviewed. Telemetry is still firmer evidence than a survey.

Review works on two levels that do not replace each other. Machines check what rules can settle: does the code build, do the tests pass, does it follow agreed conventions, does it contain known vulnerabilities. A person checks whether the change does what it was meant to do and whether the remaining risk is acceptable. The automated level scales with the volume of code; the human level does not. That makes review capacity a planning question for the whole organisation, not a step each developer handles alone.

Code quality and technical debt

Faster production shifts the load onto review and maintenance. GitClear’s analysis of 211 million changed lines of code (2020–2024) found that the share of copy-pasted code rose from 8.3% in 2020 to 12.3% in 2024, while refactoring, the reorganising of existing code, fell from around 25% of changed lines in 2021 to under 10% in 2024. More code is being written, less of it is being tidied, and duplicated code blocks have become more common. That is technical debt, and it shows up only later as the cost of maintenance.

DORA’s finding on falling delivery stability fits the GitClear data. When AI makes it easy to produce large batches of change, the risk grows too, unless testing and small batch sizes keep up.

What is comprehension debt?

Comprehension debt is the gap between how much code a system contains and how much of it the team can explain, which Addy Osmani described in March 2026 as the hidden cost of AI-generated code. In a randomised experiment by Shen and Tamkin (2026), developers who handed a whole task to the AI finished somewhat faster but did not learn the library they were working with.

Risks and pitfalls

The biggest pitfall is a suggestion that looks right but is not. In Stack Overflow’s 2025 developer survey, 66% of the 31,476 developers who answered the question named AI solutions that are “almost right, but not quite” as their leading frustration, and 45% said debugging AI-generated code takes more time than usual. In the same survey AI use was widespread (84% of 33,662 respondents use it or plan to, up from 76% in 2024), but trust in its accuracy was low. Of the 33,244 developers who answered that question, 46% distrusted the accuracy of AI tools and only 33% trusted it.

The other risks are concrete. Security: generated code can introduce vulnerabilities or outdated dependencies if it is not checked. Extra rework: a seemingly finished solution can need more fixing than writing it from scratch. Skill erosion: if the basics are delegated wholesale to the machine, understanding of your own codebase thins out. In each of these, responsibility stays with the person, and the focus simply moves from writing to judging.

How does it differ from neighbouring terms?

AI-assisted software development is the umbrella, and the neighbouring terms sit under it according to how much responsibility the person gives up.

• Vibe coding means accepting the AI’s suggestions without reviewing the code. It is sketching, where the feel of the result is what counts. The term was introduced by Andrej Karpathy in February 2025. It suits experiments and prototypes, but not production code, where understanding the code is essential.
• Agentic coding refers to AI acting more autonomously, taking a task and working through it in several steps (reading, editing, running tests, fixing). The emphasis is on the degree of autonomy.
• AI pair programming stresses the interaction: the AI acts as a pair that suggests and explains, while the person steers and decides.
• AI-native development means the broader approach where the whole process and toolchain are designed AI-first, rather than bolted on afterwards.

In practice these styles overlap. The same developer can vibe-code a prototype in the morning and carefully review an agent’s change in the afternoon.

How to adopt it

Start by aiming AI at specific tasks rather than spreading it everywhere. Pick the task types where the benefit is proven (repetitive code, tests, documentation, explaining old code) and keep human review a mandatory part. Measure per task type, not as a single organisation-wide average: one team’s CRUD work may speed up markedly, while a complex data migration does not move, because the bottleneck was never the writing. Plan review capacity before scaling code generation, since faster writing lands on the reviewers first. Keep batch sizes small and testing solid, so that faster production does not turn into weaker stability.

Frequently asked questions

Does AI speed up software development?

It depends on the task. On a bounded, familiar task the speed-up can be large. In the experiment by Peng et al. (2023) the Copilot group finished about 55% faster. On real, complex projects the effect can go the other way: in METR’s trial experienced developers were 19% slower, even though they felt faster. An average across a whole organisation says little; what decides it is where the AI is pointed.

Can you trust AI-generated code?

Only through review. In Stack Overflow’s 2025 survey, 66% of the 31,476 developers who answered the question named solutions that are almost but not quite right as the biggest problem, and more of them distrusted the accuracy of AI tools (46%) than trusted it (33%). The practical rule: the AI produces a suggestion, the person owns the result.

What is the difference between AI-assisted development and vibe coding?

Vibe coding is the end of AI-assisted development where the code is not reviewed. AI-assisted development also covers the careful style, where every change is read, understood and tested. Vibe coding suits experiments, not production code.

Why does AI make code review slower?

Because more code arrives for review than before, while human reviewing capacity stays the same. In Faros AI’s 2026 telemetry, median time in review rose by 441.5% between the periods of lowest and highest AI use, while merged pull requests per developer rose by only 16.2%.

Does AI make code quality worse?

It can, if review and refactoring fall away. In GitClear’s data the share of copy-pasted code grew and the share of refactoring dropped sharply over 2020–2024. Quality does not fall because of AI itself, but because code is produced faster than it is tidied and understood.

Will AI replace software developers?

Not so far. The evidence shows AI shifting the focus from writing code to judging, instructing and understanding it. Responsibility for design, review and the result stays with the person, and it is precisely in the hardest tasks that AI’s benefit is smallest.

Sources

• Peng et al.: The Impact of AI on Developer Productivity — Evidence from GitHub Copilot (2023) – controlled experiment: Copilot group ~55.8% faster on an HTTP-server task (95% CI 21–89%).
• METR (2025): Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity – randomised trial, 16 experienced developers / 246 tasks; 19% slower, measured vs perceived gap.
• Google / DORA (2025): 2025 DORA Report — State of AI-assisted Software Development – nearly 5,000 respondents; 90% use AI, over 80% report productivity gains; throughput up, stability down.
• Google / DORA (2024): Announcing the 2024 DORA Report – nearly 3,000 respondents (report, p. 91); over 75% rely on AI daily, 39% little/no trust; 25% increase associated with −1.5% throughput, −7.2% stability.
• Faros AI (2026): The AI Engineering Report 2026 — The Acceleration Whiplash – telemetry, 22,000 developers / 4,000+ teams over two years; AI code acceptance 20% → 60%, merged PRs per developer +16.2%, median time in review +441.5%, PRs merged without review +31.3%, incidents per PR +242.7%. Vendor report, not peer reviewed.
• Stack Overflow (2025): Developer Survey, AI section – 84% of 33,662 respondents use or plan to (76% in 2024); of 31,476 respondents, 66% “almost right but not quite” and 45% debugging takes more time; of 33,244 respondents, 46% distrust accuracy and 33% trust it.
• GitClear (2025): AI Copilot Code Quality – 211M changed lines; copy-pasted code 8.3% → 12.3% (2020–2024), refactoring (moved code) ~25% → under 10% (2021–2024).
• Addy Osmani, O’Reilly Radar (2026): Comprehension Debt — The Hidden Cost of AI-Generated Code – definition of comprehension debt as the gap between code that exists and code that people understand; first published on the author’s blog in March 2026.
• Shen & Tamkin (2026): How AI Impacts Skill Formation – randomised experiment, 52 developers; AI use impaired conceptual understanding, code reading and debugging without significant average efficiency gains. Preprint.
• Simon Willison (2025): Not all AI-assisted programming is vibe coding – vibe coding defined as building software with a language model without reviewing the code; reviewed, tested and understood code is software development.
• IBM Think: What is vibe coding? – term introduced by Andrej Karpathy in February 2025; generated code still needs code review, testing, dependency checks and security assessment before production.
• Wikipedia: Vibe coding – term introduced by Andrej Karpathy in February 2025; contrast with careful AI-assisted development.
• Wikipedia: AI-assisted software development – overview of the umbrella term and sources.