# From novelty to plumbing > The interesting question is no longer whether engineers use AI tools, but where they belong in the workflow and where they quietly make things worse. By Matthew D. Webb · 2026-01-28 · 5 min read Canonical: https://mdwebb.io/articles/ai-in-engineering-teams/ AI involvement: Used to draft and revise this article, images and diagram included. --- The first wave of AI adoption in engineering teams looked exactly like every hype cycle that came before it. Everyone ran the same demos. People generated little apps, asked models to explain quicksort, and posted screenshots of surprisingly competent code with the hushed awe of someone who'd just watched a dog do a card trick. The second wave is the interesting one, because the tools stop being the point. They stop being something to marvel at and disappear into the workflow as infrastructure. Source control did it. CI/CD did it. Cloud and observability did it. Nobody calls any of those innovations anymore; they're just how software gets built. AI is sliding into the same drawer, and that's a sign of success, not boredom. ## The real value isn't code generation The popular story is that AI writes code. In practice that's often the least interesting thing it does. The durable wins show up where generating an answer is cheap and *checking* it is easy: - Scaffolding: tests, fixtures, migrations, API clients, boilerplate. - Knowledge retrieval: finding the right service, API or doc buried somewhere in a large organisation. - Code comprehension: getting through the first pass of an unfamiliar codebase without losing a day. - Review assistance: catching the obvious stuff so a human reviewer can spend their attention on the subtle stuff. - Documentation: producing the draft that, let's be honest, would otherwise never have been written. In every one of those, the engineer is still on the hook for the outcome. The tool lowers the cost of getting to a first draft. It does not, whatever the keynote implied, do away with the need for judgement. ## Who actually benefits is not obvious One assumption worth poking at is that AI mainly helps inexperienced engineers. The picture is messier than that, mind. Some of the cleanest studies actually show juniors adopting these tools fastest and posting the biggest measured gains, and [one careful trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) found experienced developers on mature codebases going *slower* with AI while swearing blind they'd gone faster. So treat any confident number with suspicion. But where seniors do pull ahead, the reason is simple - verification is easy when you already understand the domain. An experienced engineer spots the poor design, the security hole, the hidden dependency, the assumption that doesn't hold, usually at a glance. A less experienced one is far more likely to accept the output because it *looks* right, which is precisely the failure mode plausible-sounding code is built to exploit. AI amplifies the judgement you already have. It doesn't hand you any. [The gap between generating an answer and recognising a good one](/articles/interviewing-engineers-in-the-age-of-ai/) is still very much there. ## Where it quietly costs you > The risk isn't the code AI writes. It's the understanding it lets you skip. Generated code that *works* is often more dangerous than generated code that fails. Broken code forces you to go and understand it. Working code invites you to trust it and move on. Do that enough times and a team starts accumulating systems nobody actually understands, because the effort to produce a solution has fallen faster than the effort to comprehend one. The result isn't necessarily worse code. It's less understanding. And in a complex system, understanding is usually the scarce resource, the thing you most regret not having at 3am during an incident. ## The hidden tax: architectural drift Most AI-generated code is locally reasonable. The trouble is that software isn't judged locally; it's judged as a whole. A model will cheerfully hand you: - A new abstraction that duplicates one you already have. - A dependency for something that already exists elsewhere in the platform. - A service boundary that contradicts the established architecture. - A solution that fixes today's problem and adds to tomorrow's. None of these look wrong on their own. Add them up across a system and they pull it off line.
Two-panel diagram. On the left, five small changes each point in a locally sensible direction. On the right, summed across the system, their combined vector pulls the architecture away from its intended target.
This is exactly why architecture, standards and technical leadership get *more* important in AI-enabled teams, not less. When generating code becomes trivial, holding the thing together becomes the hard part. ## AI-native workflows are emerging The better teams have stopped treating AI as an occasional assistant and started building the workflow around it: - Drafting implementation approaches before the design discussion. - Generating initial test cases before a line of code is written. - Summarising pull requests before review. - Exploring several architectural options before committing to one. - First-pass debugging and log analysis. - Writing the runbooks and docs nobody volunteers for. None of these remove the engineer from the loop. They just cut down the time spent staring at a blank page wondering where to start. ## Leadership matters more than tooling [The organisations getting real results from AI](/articles/what-ai-adoption-actually-looks-like/) are rarely the ones with the fanciest tools. They're the ones with clear expectations. Engineers know what can be delegated, what must be understood, what needs a human review, and what level of verification is expected before something ships. The technology is commoditising fast. The differentiator is operational discipline - conveniently the least purchasable thing on the list. ## From novelty to infrastructure The most important shift is that AI is becoming boring. That's usually how successful technology grows up. The conversation is moving away from whether engineers *should* use AI and towards *where* it belongs in the delivery lifecycle, which is a far healthier thing to be arguing about. The future almost certainly isn't AI replacing engineering teams. It's AI becoming another layer of plumbing: useful, expected, occasionally infuriating, and eventually so embedded in the workflow that nobody bothers to mention it at all. ## Further reading - [The Effects of Generative AI on High-Skilled Work (Microsoft Research)](https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/): three randomised field experiments with Copilot showing a 26% lift in completed tasks, strongest among less experienced developers. - [The Impact of AI on Developer Productivity: Evidence from GitHub Copilot](https://arxiv.org/abs/2302.06590): the early controlled study where Copilot users finished a contained coding task 55.8% faster, a useful baseline for what these tools do on greenfield work. - [Thoughtworks Technology Radar](https://www.thoughtworks.com/radar): opinionated, regularly updated guidance on where AI-assisted engineering practices are actually worth adopting and where to hold off.