AI Agents

AI Coding Agents in 2026: What Buyers Should Know

How Claude Code, Codex, Cursor and Copilot's coding agent changed software delivery, where human review still matters, and what to ask a vendor.

Published 8 min read

A year ago, most AI help in a code editor meant autocomplete and a chat panel. By spring 2026, the main tools can take a task, read through a codebase, make changes across several files, run the tests and hand back a pull request for review.

If you buy software development, this affects how fast a team can move, what a fair quote looks like and which questions you should ask before you sign. This post covers what changed, what the research says, and where a human engineer still has to be in the loop.

Twelve months of agent releases

The shift happened quickly, and most of it in 2025.

  • May 2025. OpenAI released Codex as a research preview: a cloud agent that runs each task in its own isolated environment and can work on several tasks in parallel.
  • May 22, 2025. Anthropic made Claude Code generally available (opens in a new tab) alongside the Claude 4 models, with beta extensions for VS Code and JetBrains and support for background tasks through GitHub Actions.
  • September 25, 2025. GitHub made its Copilot coding agent generally available (opens in a new tab) to paid Copilot subscribers. You assign it a task, it works in an environment powered by GitHub Actions, opens a draft pull request and asks you to review it.
  • Late October 2025. Cursor 2.0 (opens in a new tab) added an interface for running many agents side by side, each isolated in its own git worktree or remote machine.

These products work in different ways, but they share a design. The agent gets a task, works on a branch or in a sandbox, and returns a diff that a person approves or sends back. Human review is part of how every one of them is meant to be used.

What the research says about speed

Adoption is now close to universal among professional developers. The evidence on productivity is more mixed.

The Stack Overflow 2025 Developer Survey (opens in a new tab) found that 84% of respondents use or plan to use AI tools, and about half of professional developers use them every day. About 31% were already using AI agents at work, and 69% of agent users agreed that agents had increased their productivity. Trust ran the other way: 46% said they distrust the accuracy of AI output against 33% who trust it. The most common complaint, picked by 66%, was "AI solutions that are almost right, but not quite," and 45% said debugging AI-generated code takes more time.

Google's 2025 DORA report (opens in a new tab), based on nearly 5,000 technology professionals, found that 90% use AI at work. For the first time, AI adoption showed a positive relationship with delivery throughput. It still showed a negative relationship with delivery stability. The report's authors describe AI as an amplifier: teams with good tests, fast feedback and loosely coupled systems gained, and teams with weak foundations saw their problems grow.

The most careful measurement came from METR. Its randomized trial in early 2025 had 16 experienced open-source developers work on 246 real issues in codebases they knew well. With AI allowed, tasks took 19% longer, even though the developers believed afterwards that AI had made them about 20% faster. In a February 2026 update (opens in a new tab), METR said developers are likely sped up more by today's tools than in early 2025, but that its newer data is only weak evidence of how much. One reason: many developers no longer wanted to take part in a study that asked them to work without AI.

Three conclusions hold up across these sources:

  1. Nearly every development team now uses AI, so the useful question for a buyer is how a vendor uses it.
  2. Self-reported speed is unreliable. Developers in the METR study felt faster while measuring slower.
  3. More code produced faster puts more load on testing and review. DORA's stability finding is the warning sign.

Where coding agents do well

From the tools' own design and the survey data, agents are strongest on work that is well defined and easy to check.

  • Tasks that follow an existing pattern. Adding an endpoint, form or screen that looks like ten others in the codebase. The agent can copy the conventions it finds.
  • Tests for code that already exists. Writing unit tests around current behavior is tedious for people and straightforward to verify.
  • Mechanical changes across many files. Renaming, upgrading a library, moving to a new API version, fixing a class of lint errors.
  • Reading unfamiliar code. Asking an agent to explain where a behavior lives, or what a module does, saves hours when a new engineer joins a project.
  • Prototypes and spikes. Code meant to answer a question and then be thrown away.

What these have in common is a fast way to tell whether the result is right: a passing test suite, a type checker, a screen that matches the design. When that check exists, an agent can loop until it passes. When it doesn't, the agent can produce confident code that misses the point.

Where human review still matters

The "almost right" problem from the Stack Overflow survey is the core risk. Code can compile, pass the tests the agent wrote, and still implement the wrong rule. These areas need an engineer who understands the system:

Architecture and data models. Choosing how data is stored, how services talk to each other and where the boundaries sit is expensive to change later. An agent will build on whatever structure it is given, including a poor one.

Security. Authentication, permissions, input validation, secrets handling and payment flows need line-by-line review. Agents also add dependencies, and every new package is code your product now trusts.

Business rules. Discounts, tax, eligibility, refunds, anything where an edge case costs money. The agent knows what the ticket says. A person knows what the business meant.

Accessibility and performance. Generated UI often looks right in a screenshot and fails a keyboard user or a slow phone. These need real testing.

Ownership. Someone on the team has to understand the code well enough to change it next year without the tool that wrote it. If nobody can explain a module, you have a maintenance problem, whoever typed it.

What this changes when you buy software development

Speed

Routine work moves faster: scaffolding, standard screens, test writing, upgrades. The parts that set a project's real timeline move at roughly the same pace as before. Those are discovery, decisions about scope, design review, user testing and getting feedback from your own team. A vendor promising that AI makes the whole project several times faster is describing the easy half.

Cost

The cost of writing code is falling. The cost of deciding what to build, reviewing it and testing it is not falling at the same rate. A quote should reflect that. Be careful with a bid that is far below others and doesn't explain how the code gets reviewed, because review is where the saved hours tend to come back.

Quality

Quality now depends more on a vendor's guardrails than on how fast its engineers type. Automated tests, type checking, linting, security scanning and required code review used to be good practice. With agents producing more changes per day, they are the main thing keeping the codebase healthy. The DORA findings point the same way: AI helped teams that already had these safety nets.

Questions to ask a vendor about their AI-assisted process

Most development partners use AI tools now. These questions tell you whether they use them with discipline.

  1. Which AI tools do your engineers use, and under what plan? Business and enterprise plans usually come with clearer data handling terms than personal accounts.
  2. Does our code or data leave your environment, and is it used to train models? Ask for the specific terms of the providers they use.
  3. Who reviews AI-generated code before it is merged? The answer you want names a person and a rule, such as "every pull request is approved by an engineer who did not write it."
  4. What automated checks run on every change? Look for tests, type checks, linting, dependency and security scanning, and a coverage target.
  5. How do you handle new dependencies an agent adds? Someone should approve each one.
  6. What work do you keep away from agents? A thoughtful vendor has an answer, often security-sensitive code or production data.
  7. Who owns the code, and does the contract cover AI-generated work? Have your lawyer read the IP clause with this in mind.
  8. Can an engineer walk me through any part of the code? Ask for a short walkthrough of a feature during the project. It shows whether the team understands what it shipped.
  9. How do you know AI is helping? Good answers mention delivery lead time, defect rates or rework, measured over time. "It feels faster" is the answer the METR study warns about.

A vendor who answers these clearly is using agents to get through routine work faster and spending the saved time on review and testing. That is the arrangement you want to pay for.

Getting the benefit without the risk

AI coding agents are now standard equipment for software teams. For buyers, the useful question is how the process around them works: who decides what gets built, who reviews it, and what checks stop a plausible but wrong change from reaching your users.

Planning a new product and want to talk through how an AI-assisted build would work for it? Book a free 30-min call (opens in a new tab) with our team.

Related service: Custom Software Development