Technical debt is not necessarily a sign of poor engineering. It can be the price of learning through software in use. As AI accelerates code production beyond our capacity to understand code and context, technical debt increasingly becomes a sociotechnical challenge, Xin Yao noted in her talk "What If Your Biggest Technical Debt Is Social", at GOTO Copenhagen.
Yao quoted Ward Cunningham, who defined debt as "not-quite-right code". Debt sounds like a negative thing, but it can be a deliberate business strategy, she explained:
If we release the code now, well knowing it’s not perfect for the future yet, we’ll get some business feedback, we’ll get some user feedback, we’ll probably get paid for something, and that’s good as a business strategy.
Debt isn’t about poorly written code; it arises when we design software with incomplete knowledge. Hence, debt is the price of learning by doing, Yao argued. Releasing software allows us to test our assumptions against reality. Once we’ve got a learning experience, we have to put that experience back into our code and pay off the debt, she added. The debt becomes problematic when our software doesn’t catch up with our new learning.
Debt can be a good communication strategy toward management. It provides an economic argument for the cost of postponing architectural improvements. However, framing technical debt solely as something to eliminate misses its strategic value. The question is not whether to incur debt, but whether the learning it enables justifies the cost, and whether we actually repay it.
Yao referred to Kent Beck’s article "Earn and Learn," which explores features vs. futures. Features deliver value today, while the future is actually the optionality to adapt those features, Yao explained:
Every bit of code already coded is complexity and a constraint. Every feature removes some future. If you go on producing features, maybe using your LLMs, then at a certain point, all you can do is use your capacity to pay the interest, to fix the code, and you can no longer release features.
The challenge is to balance delivering features with preserving future options, Yao said. Sometimes, delaying a design commitment preserves options until we know more, and this includes postponing some upfront architecture decisions to the last responsible moment as well. As Beck argues, waiting is not laziness; waiting is holding an asset.
Technical debt can therefore be understood as learning made visible in software. We design based on what we know, observe software’s impact, modularity, and its architecture’s implications, and we update our understanding, Yao explained:
The software no longer fits what we now understand, and yesterday’s good understanding becomes today’s debt.
AI introduces a new challenge: software can now be produced faster than teams can develop a shared understanding of its behavior, design decisions and consequences, Yao argued.
Agentic coding makes debt repayment more complex; beyond addressing poorly written AI-generated code, teams must close the gap between what the software actually does and what they understand it to do, while ensuring the code keeps pace with their evolving domain and architectural understanding. Paying off debt is no longer just a technical task, but a sociotechnical one, Yao concluded.
InfoQ interviewed Xin Yao after her talk.
InfoQ: What does learning from technical debt look like, and what benefit does it bring?
Xin Yao: We design and release software based on our best current understanding, then test our assumptions against business and user reality. Paying off debt means incorporating that learning back into the software and closing the gap between what we knew when we released the first iteration and what we know now.
Each iteration creates new debt and new learning. Small batches and tight feedback loops help teams retain the memory of their initial design decisions and continuously repay the old debt with new learning.
InfoQ: What does technical debt look like now that developers are using artificial intelligence?
Yao: With agentic coding, software production can outpace human understanding. Code increasingly becomes a fossil record of agents’ decisions, while humans remain accountable for its consequences. Local productivity gains can create collective costs: more code, weaker ownership and growing gaps in shared understanding.
A study on How Developers Discuss the Burden of AI-Assisted Software Development describes this as "a tragedy of the commons". The danger is not merely more poorly written agentic code, but accelerated learning debt across the sociotechnical system.