Why your team is slower than last year

May 2026 update: Four months after this, we shipped the fix—and I learned what I'd missed.

When I wrote this in December, my argument was that the velocity crisis is systemic, not a tooling problem. Turnover, knowledge decay, established products eating 80% of your engineers' time. I still stand by that diagnosis.

What I got wrong was the shape of the fix. I called it “Workflow Intelligence” and gestured at preserving context. Then we shipped the specific thing—a Product Knowledge layer that feeds your AI tools—and spent four months learning what I’d actually missed.

Here’s what I underplayed: AI doesn’t just amplify the established-product problem. It changes its shape. Wrong gets caught—by reviewers, by tests, by QA. Almost right gets shipped. Code that looks correct, uses your patterns, references your variable names, and doesn’t match your product. The velocity hit doesn’t show up as bugs. It shows up as rework you can’t trace and decisions relitigated three sprints later.

Without a context layer, AI accelerates the wrong work.

When we evaluated AI-generated stories against our Glossary, 60% needed changes. Not because the AI was bad. Because it didn’t know our product. It knew code. It didn’t know us.

The fix is structured Product Knowledge—the terminology, workflows, permissions, features, and relationships that define your product. In Atono, Living Stories carry the why from spec through production. AI gets the same context the team does.

That same Product Knowledge can be exported to the AI tools teams already use alongside Jira or Linear, giving every tool the same understanding of your product. One source of truth for repeatable answers, updated as your product evolves, controlled by your team, and permissioned across the organization.

AI builds what you tell it to build. Give it better context, and you get better outcomes.

The original argument still stands: the velocity crisis is systemic. What I got wrong was the shape of the fix. Faster AI doesn’t restore velocity. AI that builds from your product does.

P.S. If you want the data—context gaps across 350 engineering teams, with Refactoring.fm—we put it in the Atono Context Gap Report.

Simple changes that used to take two hours now take two days. Basic operations that should take seconds in your project management tool now take minutes. You’re running harder just to stand still.

If this sounds familiar, you’re experiencing what we call the Velocity Crisis—and you’re far from alone. Most product teams working on established systems face the same challenge.

Here’s what it looks like on the ground: A product manager asks a senior developer, “How does our payment reconciliation system handle refunds across multiple currencies?” Nobody can answer with confidence. The system has been running for three years, processes millions monthly, but the reasoning behind architectural decisions that make it tick? Gone. The context for why certain trade-offs were made in the first place? Scattered across old Slack threads, deprecated wikis, and the memories of people who’ve moved on.

This isn’t a documentation problem. It’s an established product problem—and it’s why your velocity keeps dropping.

Software development exists in two fundamentally different contexts: emerging projects, where teams build something new with fresh architectural decisions, and established products, where years of code, decisions, and context have accumulated.

The industry has a clear favorite. Emerging projects get the conference talks, blog posts, cutting-edge tools, and excitement. AI coding assistants are trained on clean codebases. Best practices assume you’re starting fresh.

But here’s the reality: Gartner estimates that organizations spend up to 80% of their IT budgets on maintenance rather than new development. Most developers spend their days enhancing, maintaining, and evolving systems that have been running for years. Yet tools, practices, and attention remain focused on the 20%.

This creates a fundamental mismatch: teams optimize for work they rarely do and are unprepared for work that dominates their calendars.

So how does this imbalance manifest? It starts with knowledge decay—gradual at first, then accelerating.

Software engineering faces a turnover reality that compounds faster than other industries appreciate. Mercer data show 8.2% turnover in the United States in 2023—already higher than the global average of 6.4%—and that one quarter of US technology companies reported turnover rates approaching 12%. That means in a team of ten engineers, you’re statistically losing one person per year. Over three years, a third of your original team is gone.

Every departure takes institutional knowledge with it: The developer who understood why the caching layer was architected that particular way leaves for a startup. The engineer who understood the historical context behind the API design joins another company. The person who could explain the subtle dependencies between services moves to a new team.

What remains is code without context.

When new developers join, they face a steep learning curve. On average, it takes one to two months to bring a developer up to speed on an established codebase. A survey of developers found that 60.4% cite “not enough time to get familiar with the codebase” as the top onboarding mistake companies make.

Here’s what actually happens: developers spend only 32% of their time writing or improving code, while 35% goes to managing existing code.

That management work increasingly involves reconstruction, and documentation rarely helps. Documentation captures the “what” but rarely the “why.” The trade-offs that shaped architecture live in Slack threads that get archived and forgotten. The subtle patterns specific to the codebase exist only in collective memory, which erodes with every departure.

This is where turnover and documentation failure intersect. Each departure accelerates the decay. Each new hire spends their first months in archaeological mode rather than building. The team grows larger, but effective capacity remains flat—or declines.

The established product becomes a black box, even to the people maintaining it. Problem with a black box: it’s only accessed after the crash.

This knowledge loss has quantifiable consequences—and if you’re an engineering manager, these costs show up in every sprint retrospective.

When senior engineers are the only ones who understand critical systems, they become bottlenecks. Every question funnels through them. They can’t focus on high-value work because they’re constantly explaining context that should be accessible to everyone.

Meanwhile, technical debt costs US enterprises $1.52 trillion annually, representing a massive drain on productivity and innovation. Much of that complexity comes from a lost understanding of how systems were built and why.

AI coding tools promised to solve the productivity crisis. And they have—for emerging projects.

AI assistants like GitHub Copilot, Cursor, and Claude excel with new codebases. The context is clean and clear. Modern patterns are well-represented in training data. But established products present a different challenge. The AI lacks architectural context. It can’t access the historical “why” behind decisions. It doesn’t understand team-specific patterns that make sense in context but aren’t documented.

Without that context, AI makes predictable mistakes: duplicating existing features, violating established patterns, and creating conflicting dependencies.

Here’s the paradox: AI accelerates individual developers significantly, but at the team level, velocity can decrease. Consider the flight drift analogy—when a flight starts just 1% off course, it ends up 10 miles away after one hour. Each developer moves faster individually, but without shared context, they drift in slightly different directions. Those deviations accumulate at integration points.

Individual velocity increases. Team velocity decreases.

The traditional answer is “better documentation”—but that’s been the answer for decades, and the problem keeps getting worse. Documentation requires discipline that evaporates under shipping pressure, and even well-maintained docs drift from reality over time.

Workflow Intelligence takes a different approach: it preserves context as decisions are made, not after the fact.

Remember the payment reconciliation question from the intro that nobody could answer? With Workflow Intelligence, a new developer can see not just the code, but the original story that defined it, the decisions made, and how it connects to related features—without pulling senior engineers away from their work.

The goal isn’t perfect documentation. It’s making established products work more like emerging ones—where you have clarity because context is accessible, not because you happened to be there when decisions were made.

The 80/20 split isn’t going away. Most development will continue to focus on established products—and that’s not a failure. It means you’re building things that last.

But you have a choice. Keep using tools designed for emerging development and wonder why everything takes longer. Or build systems that preserve understanding as products mature.

The industry spent decades optimizing for the 20%. It’s time to build for the 80%.

Because the real bottleneck isn’t writing code—it’s remembering why you wrote it that way. And every quarter you wait, that gap widens. The question isn’t whether you’ll address the Velocity Crisis. It’s whether you’ll do it before the gap becomes insurmountable.