Every engineering org I talk to right now is celebrating the same number: velocity. AI writes code faster, PRs merge faster, tickets close faster. Everyone's thrilled. I think we're celebrating the wrong thing, and it's going to bite us.
Here's the uncomfortable truth nobody wants to say out loud: velocity does not equal direction. Generating a massive volume of code doesn't mean your team is moving toward the right business outcome. It doesn't mean you're building something stable or maintainable either. All it means is you're generating a massive volume of code. That's it. And right now, that volume is quietly setting up three separate problems. One is about where the team is headed. One is about what's happening to the codebase underneath them. And one is about what the trip is doing to the people on it.
Problem One: No Destination
I use a metaphor for this because I think it's the clearest way to see what's actually happening.
Picture hopping on a train in Boston with no real destination in mind. You just keep jumping to whichever line looks fastest. Switch here, transfer there, always chasing speed. Eventually you look out the window and you're in Florida. Except you needed to be in San Francisco. Now you get to enjoy the process of unwinding every decision that got you to Florida, which costs you way more time, money, and morale than if you'd just picked a direction at the start.
Now picture boarding that same train with a clear goal: San Diego. You head west on purpose. Maybe halfway through the trip you learn new information and realize you actually need San Francisco instead. Fine. That's a minor adjustment, because you were already pointed roughly the right way. Pivoting from San Diego to San Francisco is a quick reroute. Pivoting from Florida is a different trip entirely.
That's where most AI-assisted engineering teams are right now. Plenty of speed, no destination, and they won't find out they're in Florida until the rebuild bill shows up.
Fix It: Pick the Destination Before You Hit the Gas
Before any team adopts AI tooling at scale, leadership needs to articulate a real architectural and product vision, the San Diego on the map, not just whatever train is leaving next. That destination isn't set in stone forever. Revisit it as the market shifts and customer feedback comes in, so your course corrections stay small, San Diego to San Francisco small, instead of a full reroute from Florida. Skip this step and every fix that follows is just optimizing the wrong trip.
Problem Two: Architecture Rot
Even on a team that knows its destination, there's a second failure mode that AI makes worse. AI tools are great at solving the problem directly in front of them. They have no idea, and no way to know, whether that solution fits into the bigger system. Ask an AI agent to build a component and it'll build you a good one. Ask it whether that component is going to tightly couple two services that should stay independent, and it has no opinion at all.
So teams end up shipping highly polished, locally optimized code that slowly turns the system into a tangle. Nobody decided to build a monolith. It just happened, one perfectly reasonable AI generated PR at a time. Without real oversight, you're not writing technical debt anymore, you're mass producing it.
Fix It: Optimize for Systemic Health, Not Pipeline Volume
Stop counting PRs merged and lines shipped. Those numbers tell you nothing about whether the system is healthy. Instead, measure code health, test coverage, how decoupled your architecture actually is, and how much time your engineers spend fighting technical debt, all judged against the destination you set in problem one. Put real architectural guardrails around your code generation tools so they reinforce system integrity instead of quietly accelerating rot. The guardrails are what turn "AI writes fast" into "AI writes fast in a direction that doesn't collapse on itself."
Problem Three: Burnout Doesn't Disappear, It Just Changes Shape
The AI writes the code, but humans still have to review it, integrate it, and live with it. So the actual workload didn't go away, it just moved. Engineers used to burn out from writing too much code. Now they're burning out from reviewing and debugging an endless stream of AI generated PRs, on top of fighting the merge conflicts that come from everyone's branches moving faster than ever. Spend your day acting as a quality assurance layer for a machine and see how long your sense of ownership lasts. Creative engineering gets replaced by pipeline babysitting, and that's a fast way to lose good people.
Fix It: Value Fulfillment, and Actually Protect Developer Experience
Start by shifting the cultural narrative. The question shouldn't be "how much did we build," it should be "what did we solve, how well, and did it move us toward where we're headed." Engineers who feel ownership over something headed somewhere real stay engaged. Engineers running a feature factory with no destination don't, no matter how fast the factory runs.
But culture alone won't fix the friction, so back it with real investment in developer experience. Build out pipeline guardrails, refine CI/CD, and bring in smarter automated testing specifically to cut down on merge conflict fatigue. This only works because you've already done problems one and two. Once you know your destination and you've got architectural guardrails in place, you know exactly which friction is worth eliminating for your team and which is just noise. Skip those earlier fixes and you're just polishing comfort on a trip that's still headed to Florida.
AI tools are accelerators, not strategies. They will make you faster at whatever direction you're already pointed in, including the wrong one, they will let your architecture rot faster if nobody's watching, and they will burn out whoever's stuck driving. Set the destination first, protect the system second, protect the people third, then hit the gas. That's the only version of this that actually works.