There's a version of the AI coding tools conversation that I find hard to take seriously.
The enthusiast version: everything is different now, a single engineer can do what a team used to do, the economics of software development have permanently changed. The sceptic version: it's autocomplete, the quality is bad, real engineers don't need it.
Both are wrong in specific ways. What's actually happening is more interesting and more complicated than either version, and the implications for engineering organisations are real but different from what either camp suggests.
What the data shows
Let me start with what's actually measurable, because this conversation tends to involve a lot of assertions and not much evidence.
Output, narrowly defined, does go up. Studies of developers using AI coding tools consistently show productivity gains in the range of 20–55% on tasks like code generation, test writing, and documentation — measured by lines of code produced per hour, time to first working version, and similar proxies. That's a real effect.
But there's a second finding that gets less attention. CrowdStrike's analysis of AI-assisted code in production found a 2.74x increase in security vulnerabilities compared to code written without assistance. Research from Hostinger's engineering teams showed that AI-generated code required significantly more review cycles before it was production-ready, particularly for edge cases and error handling.
The productivity gains are real. So is the quality distribution — AI-generated code tends to produce more correct first drafts and more subtle errors, and the ratio depends heavily on the type of task and the experience of the engineer using the tool.
What actually changes
Time to first working version gets dramatically shorter. For well-understood problems — implementing a standard authentication flow, writing a CRUD endpoint, generating boilerplate from a spec — AI tools are genuinely fast. An engineer who knows what they want can get a working first draft in a fraction of the time.
The junior developer on-ramp gets disrupted. This is the change most people aren't talking about. AI tools are disproportionately useful to experienced engineers who can evaluate the output. For engineers who are still developing that judgement — who are learning by writing code and seeing what happens — the tools create a shortcut that skips the learning. A junior developer can now ship at significantly higher velocity without necessarily developing the underlying understanding. That gap will surface later, when the system they built needs to be debugged, extended, or operated.
The surface area one engineer can maintain expands significantly. An engineer with good judgement can now maintain, extend, and reason about substantially more code than they could before. This is the version of the "one engineer does what a team used to do" claim that's actually supportable — not for greenfield creation, but for stewardship.
Context switching costs go down for certain task types. Returning to a codebase after time away, understanding an unfamiliar part of a system, writing documentation for something you understand but haven't articulated — AI tools reduce the friction on these tasks. Less working memory required to hold the context.
What doesn't change
Architecture judgment. Knowing what to build, in what order, with what tradeoffs — this is not a problem AI coding tools solve. The tools operate at the level of implementation. The decisions about what to implement, and whether the current implementation approach will survive the next year of the product, remain human problems.
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 who have to operate what gets built. An AI-assisted sprint that ships twice as much code doesn't create a team that can operate twice as much system. The operational burden is still carried by people. This is particularly acute for smaller teams — the rate at which code can be produced now significantly outpaces the rate at which the organisation can build expertise to operate 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.
The right frame
AI coding tools are leverage on execution. Like most forms of leverage, they amplify both the good decisions and the 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 technology leaders I've seen handle this well treat it as an engineering practice question, not a tooling question. They think about what the review process needs to look like given AI-generated code. They're explicit about what kinds of tasks the tools are good for and what kinds they're not. They invest in the things that make leverage safe — code review culture, architectural clarity, operational maturity — before maximising the productivity gains.
The teams that are struggling with it tend to have adopted the tools and the velocity without asking what the new risks look like, and without adjusting the practices that were designed for a different baseline.
If you're thinking through how to adopt AI coding tools in a way that's sustainable, I'm happy to talk through it — get in touch.