Someone spent two sprints perfecting an accordion component—two sprints of engineering and product design time. The animations were smooth, and it met every accessibility requirement. By any measure, it was a beautiful accordion.
Meanwhile, the team couldn’t articulate which customer problem they were solving that quarter.
I’ve heard the complaint dozens of times: We can’t ship faster because of tech debt. It’s the standard explanation when velocity disappoints. It’s safe and technical. Nobody gets blamed.
Inside these teams, I’ve found that technical debt is rarely the only bottleneck. It often covers for something harder to admit.
I was a bridge product architect at a Series A company pushing for Series B. The business said the market was outpacing its ability to build, so the diagnosis seemed obvious: change how we build.
Over two years they scaled the engineering org and migrated a monolith to 23 microservices. I arrived a bit over halfway through.
Domain-driven design, hexagonal architecture, microservices by the book. An architecture to support millions of daily active users. The reality? The business needed a few thousand tops.
Clarity required describing the customer accurately. That meant saying “no” and acknowledging that the company’s strategy couldn’t satisfy everyone’s incentives.
Blaming engineering was easier. Delivery was slow enough to absorb the company’s confusion without exposing it.
The accordion was a symptom of a deeper issue. When you don’t know what to build, you polish what’s in front of you.
Technical Debt After AI Coding Tools
Ward Cunningham introduced the technical debt metaphor in 1992. I learned it from him directly, at a workshop at New Relic back in 2014. The framing was clarifying: debt isn’t bad, it’s a financing decision. You borrow against future velocity to ship now. The interest compounds. Eventually, you pay it down or go bankrupt. That made sense when paydown was expensive.
AI coding tools have reduced the cost of some refactors, migrations, test coverage, and consolidation—the work teams often cite as evidence of debt. That makes technical debt a weaker blanket explanation for slow delivery. If a tool can complete part of the paydown in an afternoon, the team still has to identify what blocks the release.
On a recent project, we could use Claude Code to refactor a good portion of the system or ship what customers needed first. We shipped the customer request and deferred the refactor.
Refactoring isn’t free, and AI doesn’t erase technical debt. But “we have tech debt” is no longer a sufficient reason to delay work. The team has to name the debt that blocks a specific customer outcome.
Use the Saved Time to Decide
Many teams will use the saved time to increase output without improving their decisions: more features nobody asked for and more architecture for customers they can’t name.
AI coding assistants can return some of the hours once spent on refactoring, migration, and test coverage. Teams can use that time to ask who a feature is for and what those customers need.
At that Series A company, we used what Jade Rubick calls a steel thread: the thinnest slice that crosses system boundaries and ships real value. Instead of building services in parallel, the team finished one customer path before starting the next increment.
"With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case."
The steel thread forced the question they’d been avoiding: which customer matters most right now?