There's a version of the AI coding tools conversation that I find hard to take seriously.
The enthusiast says one engineer can now replace a team. The sceptic says it is autocomplete and real engineers don't need it.
Both miss the point. The tools change engineering work, just not in the way either camp suggests.
What the data shows
Let's start with what we can measure. This debate has plenty of claims and not much evidence.
Output goes up. Studies report gains of 20–55% on code generation, tests, and documentation, measured through proxies such as time to a first working version.
The second finding gets less attention. CrowdStrike found 2.74 times more security vulnerabilities in AI-assisted production code. Hostinger found that AI-generated code needed more review cycles, especially around edge cases and error handling.
The tools produce more useful first drafts and more subtle errors. The balance depends on the task and the engineer using them.
What actually changes
The first working version arrives faster. For familiar problems such as a standard authentication flow, CRUD endpoint, or boilerplate from a spec, an engineer can get a useful draft quickly.
The junior developer path changes. Experienced engineers benefit most because they can judge the output. Juniors can ship faster without building the same understanding along the way. That gap appears later, when they need to debug, extend, or operate the system.
One engineer can maintain more. An engineer with good judgment can maintain and extend more code. That is the defensible version of "one engineer does what a team used to do": stewardship, not greenfield creation.
Some context switches cost less. Returning to an old codebase, exploring an unfamiliar system, or drafting documentation all become easier.
What doesn't change
Architecture judgment. The tools help with implementation. They don't decide what to build, in which order, or whether the approach will survive the next year.
The cost of complexity. Code that was generated quickly still has to be operated, debugged, and extended. AI tools lower the cost of creation and raise the risk of creating more than you need. Teams that don't account for this end up with larger, more complex codebases than the problems they're solving actually require.
The humans operating the system. Shipping twice as much code doesn't create a team that can operate twice as much system. Small teams can now produce code faster than they can learn to run it.
Security review discipline. Given what the evidence shows about vulnerability rates, teams that adopt AI coding tools without strengthening their security review practices are taking on a liability they may not account for. The tools don't remove the need for review — they change what you're reviewing for.
A more useful frame
AI coding tools add leverage to execution. They amplify good decisions and bad ones.
A team with good engineering judgment and strong review practices will get substantially faster without taking on proportionally more risk. A team without those things will get faster in ways that may not be visible as a problem until something breaks in production.
The leaders handling this well treat it as an engineering practice question. They adapt reviews, define where the tools help, and invest in code review, architecture, and operations before chasing maximum output.
The struggling teams adopted the tools and the speed but kept practices designed for the old baseline.
If you're thinking about sustainable adoption, I'm happy to compare notes.