There are two ways to bring AI into a software team. You can treat it as a way to have fewer engineers, or as a way to make the engineers you have go faster. The first framing sounds like savings and usually is not. The second is where the gains live, and the difference between them is the difference between a team that ships more and one that ships a mess quickly.
The question worth asking is how much faster AI makes your best engineers, and under what conditions, rather than how many people it lets you cut. The honest answer is more mixed than either the hype or the backlash admits.
What the evidence shows
AI coding tools help, but not evenly, and the size of the help depends heavily on the task. Two careful studies bracket the range. In a 2022 controlled experiment, GitHub found developers asked to build an HTTP server in JavaScript finished 55 percent faster with an AI assistant than without, cutting the task from about two hours forty minutes to one hour ten. The gain was largest for the less experienced developers.
Then the other end of the range. In 2025, METR ran a randomized trial with experienced open-source developers working in their own mature repositories, codebases they had contributed to for years. With early-2025 AI tools allowed, those developers took 19 percent longer to complete their tasks, not shorter. The striking part: they believed the tools had sped them up by about 20 percent. They were slower and felt faster.
Put the two together and the pattern is clear. AI is strongest on unfamiliar, greenfield, well-bounded work, the kind where a competent developer would otherwise spend time looking things up. It is weakest, and can be a net drag, on deep work inside a large codebase the engineer already knows cold, where the cost of reading and correcting the model's output exceeds the cost of writing the code directly. The perception gap is the part every team should take seriously. You cannot manage this by how fast it feels. You have to look at what ships.
Where AI helps most
Used on the right work, a good engineer moves noticeably faster. The tools are strong at the parts of programming that are mechanical or well-trodden: scaffolding a new service, first-draft tests, boilerplate, and the config nobody enjoys writing. They translate between languages and frameworks competently, and they explain an unfamiliar codebase or an API you have never touched faster than reading the source cold.
They also make a useful second reader. A model reviewing a change catches a class of small bugs that a tired human skims past at the end of a long day: the off-by-one, the unhandled empty case, the branch the tests never exercise. None of this is glamorous, and that is the point. The tedious middle of a task shrinks, and more of the day goes to the parts that need a person.
Where it gets in the way
AI does not know what to build. It does not carry the context of your business, your users, or the decision you made three weeks ago about why the data model works the way it does. It will write confident, clean-looking code for the wrong problem as readily as the right one, and confident-looking wrong code is more expensive than obviously broken code, because it survives a glance.
There is also a tax that rarely gets counted: verification. Every line a model writes is a line someone has to read, understand, and take responsibility for. On unfamiliar work that reading is time you would have spent anyway. On a system an expert knows intimately, it can cost more than writing the code themselves, which is a large part of what the METR result is measuring. Judgment, architecture, and knowing which corner is safe to cut are still the engineer's job, and taking the editor away takes the quality with it.
Why replacing engineers backfires
Teams that set out to replace engineers with AI tend to end up with more code and less understanding, which is a bad trade. Someone still has to own the system when it pages at 2am, and generated code that nobody on the team can explain is a liability, not a saving. The seat you cut to save money comes back as an outage that costs more than the seat did.
There is a slower version of the same failure. A codebase filling up with code no human on the team fully understands accrues a kind of debt that shows on no balance sheet, until the day a subtle bug needs tracing through it and there is no one who can. Understanding is the thing you are paying engineers for. Generate your way past it and you have not removed the cost, you have deferred it to the worst possible moment.
The teams that do well with AI keep their engineers and raise what each one can do. They ship more with the same people, freed from the busywork, with someone who still understands the whole thing.
The risk is a team that cannot work without it
There is a failure mode worth naming: engineers, especially junior ones, who can prompt a model but cannot debug what it produces. If AI writes the code and nobody grows the skill to reason about it, you get a team that moves fast right up until the tool is wrong, and then cannot recover. The GitHub study found the largest gains went to less experienced developers, which is good news for onboarding, but it carries a catch. A junior who leans on a model to get unstuck learns differently, and sometimes less, than one who had to work it out.
The way through is not to ban the tool. It is to use it as a tutor rather than a crutch: have it explain the code it writes, ask it why it chose one approach over another, and make sure the person can defend the result without it. Used that way, AI raises the floor under your whole team. Used carelessly, it hollows out the middle of their skill and you find out years later.
How we help teams adopt it
When we train a team, we do it on their codebase, not a generic slide deck. We pair with your engineers on the work they are already doing and show them where the tools help and where they get in the way, using the distinction above: lean on AI for the greenfield and the boilerplate, stay skeptical of it in the parts of the system your people know best.
We also put guardrails in place so speed does not turn into sprawl. That means review standards that apply to generated code exactly as they would to hand-written code, tests that have to pass before anything ships, and a plain rule that nobody merges code they cannot explain. And we measure outcomes rather than trusting the feeling of speed, because the METR finding is a warning that the feeling is unreliable.
The last piece is control of your data. Where the work is sensitive, the models can run on infrastructure you control, so your code and your prompts do not leave your environment. Where it is not sensitive, a hosted service is cheaper and perfectly fine, and pretending otherwise would just be selling you something. The point is that you decide where each piece of work runs, rather than the tool deciding for you.
The goal is a faster team, not a smaller one
AI will keep getting better at the mechanical parts of building software, and the engineers who know how to direct it, and when to ignore it, will keep pulling ahead of the ones who reach for it reflexively. The aim is not a smaller team. It is a team that ships more of what matters, with a tool that handles the boring parts and the judgment to know which parts those are.
That judgment is easier to apply in a small, senior team than a large one, for the same reasons speed is. We cover those in why small teams ship software faster and why the standard software development lifecycle slows you down. AI changes how fast each person can work. It does not change what good software costs to understand.
