What AI Adoption Actually Looks Like on an Engineering Team

Every team I've been part of over the last couple of years has gone through some version of the same arc with AI tools: skepticism, a burst of enthusiasm, a plateau, and then a quieter, more useful phase once the novelty wears off. The teams that get real value out of it tend to land somewhere specific, and it's rarely where the initial hype pointed.

The first wave is always the same

Someone finds a tool that writes a function faster than they can type it, shares it in a team channel, and for about two weeks everyone is trying to get AI to do their job for them. Pull requests get bigger. Review quality drops, because reviewers are now checking code nobody on the team actually wrote line by line. Bugs slip through that a human would have caught throught he classic iterative dev cycle, or by just slowing down.

That phase (hopefully) burns out fast. It should. It's the wrong way to use these tools, but it's also basically unavoidable: you have to hit the ceiling of "just let it write everything" before you figure out what it's actually good at.

Where it earns its keep

Once teams settle down, the useful pattern looks less like delegation and more like a very fast, very literal-minded pair programmer. It's good at:

• Boilerplate and scaffolding: new services, test fixtures, config wiring, the stuff that takes real time but no real thought, and is patternistic or repetitive.
• Reading unfamiliar code: pointing it at a legacy module and asking "what does this do" is often faster than tracing it by hand (though not always 100% accurate).
• First-draft everything: a rough migration script, a first pass at a README, a starting point for a regex you'd otherwise fight with for twenty minutes.

It's less reliable for anything that requires holding the shape of a whole system in context: architectural tradeoffs, why a particular piece of legacy behavior exists, or judgment calls about what not to build. Those still need a person who understands the business and the codebase, not just the syntax. Even with that said, it can get you far on a lot of these topics if you ask the right questions, but you'll have to come up with those questions yourself.

The skill that actually matters now

The engineers who've gotten the most out of this shift aren't the ones who use it the most. They're the ones who were already good at thinking critically and breaking a problem into small, well-scoped pieces before AI tools existed. That skill translates directly: a specific ask gets a more useful answer, and a vague one gets a confident, wrong one. The tools didn't create a new skill so much as they raised the price of not having an old one.

The other shift worth naming: code review got harder, not easier. When a human writes code slowly, the act of writing is itself a first pass of thinking. When a tool generates it in seconds, that thinking has to happen somewhere else, usually in review, which means reviewers need to be more rigorous, not less, even though the code often looks more polished than what a human would have written under time pressure.

Where I've landed

Treat it like a fast collaborator with no context and no accountability. Great for narrowing the distance between "I know what I want" and "I have a first draft," bad at telling you whether what you want is the right thing to build. That second part is still, and I suspect will stay, a people problem.