I spend my weekends coding. Not because you have to. Because I love it. And some time back, I noticed something that I couldn’t stop thinking about: with AI tools, I’m somewhere between 100 and 1,000 times faster building things by myself than before.
That should have been good news when I got back to the office on Monday morning. It wasn’t like that.
My engineers are at least as smart as I am. They use the same tools. So why wasn’t I seeing a 100x speedup? Why were the metrics slow? I sat with this question for a long time, and the answer I came to was uncomfortable: it wasn’t people, and it wasn’t technology. It was us. Our habits. Our processes. In fact, our culture, which was designed years before AI existed and has never been updated to account for it.
AI didn’t create those problems. It just made them unable to ignore it.
Here is a real example. We’ve always had a loose relationship with the internal tools and components we build – utilities, shared libraries, small pieces of infrastructure that are written as a byproduct of building something else. They work, they get used to it, and they stay. There is no owner. There is no maintenance plan. Security patches aren’t applied, bugs pile up, documentation gets out of date. Before AI, the problem was mostly manageable because the volume was manageable. Producing one of these items required real effort, so there was a natural brake on how many there could be. Then the AI removed the brake. Now these components are flourishing everywhere, produced in an afternoon, programmed into code bases throughout the organization, and nobody. The accountability gap has not changed. The production rate did. And what was once a small housekeeping problem is now a vast list of undocumented, unmaintained, unpatched parts that we struggle to keep up with. AI did not create the identity problem. It just subsidizes it to a degree.
This is something no one wants to say out loud when they announce the release of AI: the tool will find your weaknesses before you do. Teams skip documentation and send unwritten code quickly. Teams that skip code reviews ship unreviewed code immediately. Teams where accountability doesn’t make sense will now produce an enormous volume of work that no one person is fully in charge of. AI is an amplifier. It doesn’t care what it raises.
The Basis That Determines Everything
Most conversations about AI adoption start with tools. I want to start before then. Before any discussion of tools, the question to ask is: what does ownership mean to this group?
Not with a vision. By working. Do all developers know exactly what “done” looks like in their work? Can they define what success means, what failure means, and when they need to raise a problem without being asked? These are not soft skills. They are the infrastructure that carries the burdens of an efficient engineering organization. And when that infrastructure falters, AI makes the tremors louder.
The most effective team, before AI, works with what I would call accountability. Leaders have real ownership of their domains, and they drive the decision without waiting to be told. They communicate continuously, especially when things go sideways. They have a shared, clear framework for how work is delegated, how success is defined, and how feedback flows. When that team adopts AI tools, the acceleration is real and inclusive. They are able to direct, modify, and refine their instruction. They treat AI like a conductor treats an orchestra: they don’t play all the instruments, but they are in complete control of the music.
Without that foundation, you’re just giving a loud instrument to someone who doesn’t know how to play.
There are groups that shouldn’t be using AI coding tools yet. Perhaps more than we realize. If your developers are still working out how to do code reviews with any real rigor, adding AI to the mix will help them generate more code that needs better reviews. If your sprint planning is mostly theoretical, AI will help you fill those sprints with a lot of the wrong work, faster. Discipline must come first. Accelerant comes after.
Where ROI Calculations Break Down
What some local leaders always do wrong is how they measure returns. Most ROI discussions about AI tools focus on the volume of output: lines of code generated, tickets closed, velocity numbers. And yes, those are going. But that’s the wrong framework, and it closes off a real opportunity.
Here is the structural problem. Most engineering organizations run on two-week cycles. A sprint is a small unit of measurement of activity, meaning that no matter how fast the AI executes, the container remains the same. Work, like gas, expands to fill the space you provide. So what actually happens is this: The AI makes a week-long task take two days, and the developer fills the remaining time with another sprint task. Speed numbers are slow. Leadership calls you winning. Meanwhile, the tool’s integration capabilities remain virtually untouched.
The real ROI question is not “are we moving fast?” “What are we trying now that we haven’t done before?” AI should change the desire for what is programmed, not just the speed of execution of what is already on the list. The teams that get this are the ones that reframe how they think about work, not just how they do it. I’ve been experimenting with shorter sprint cycles for this reason, not to want more output, but to force a rethinking of how work is measured and to reach a point where execution is no longer a bottleneck.
What Good Really Looks Like
The signal I look for when AI adoption is working is deceptively simple: are developers spending more time thinking and less time writing? To open that. AI is already better than your engineers at typing code. Read all the pages of the document. It doesn’t forget the syntax. It has no bad days. Let it write.
The engineer’s job now is to lead it, to guide it, to challenge its output, and to solve problems that no notice can properly assemble on its own. That requires more mental engagement, not less. It means asking tough questions, catching the places where AI is wrong with confidence, and delivering judgments that no model can replicate. When I see teams working that way, where the AI handles the execution of the machines and the humans handle the judging, that’s when the numbers start to resemble what I experience on my weekends.
Amplification is already happening. The only question is whether you are feeding something worth weighing.
