For decades we assumed that writing software had an inevitable side effect.
While you solved a problem…
…you also learned.
You learned how the codebase was organized.
Why a certain architectural decision existed.
Which modules were fragile.
What dependencies you should never touch.
Which parts of the system hadn’t been modified in ten years.
That learning didn’t happen because someone taught it to you.
It happened because the work itself forced you down that path.
Coding agents are changing that dynamic.
And a new paper proposes a name for that unexpected consequence:
Knowledge Debt.
The idea is as simple as it is uncomfortable.
Your team might be producing more software… while understanding less and less about how it works.
Technical debt has a cousin
We all know about technical debt.
You take a shortcut.
The system keeps working.
But each future change costs a bit more.
Knowledge Debt works differently.
The software might be perfectly written.
The tests might pass.
The architecture might still be excellent.
What degrades isn’t the code.
It’s the team’s knowledge.
And that makes it much harder to detect.
Technical debt ends up showing in production.
Knowledge Debt can remain invisible for months.
How we used to learn
Think about any bug from five years ago.
The process was probably something like this.
Bug
↓
Find where it occurs
↓
Read related files
↓
Follow function calls
↓
Understand the architecture
↓
Test hypotheses
↓
Find the root cause
↓
Implement the fix
The fix was only the final result.
Most of the value was in the journey.
Because during those two hours you also learned:
- who owned that module;
- why that strange workaround existed;
- which components depended on each other;
- what architectural decisions had survived for years;
- where the system’s actual boundaries were.
That knowledge stayed in your head.
And it was there for next time.
How we work today
Now imagine exactly the same bug.
Bug
↓
Claude Code
↓
"I found the problem."
↓
"It's already fixed."
Five minutes.
Excellent productivity.
But there’s an uncomfortable question.
What did the developer actually learn?
Often…
very little.
Reviewing isn’t understanding
A common response is:
“It doesn’t matter. I can always review the generated code.”
But reviewing a diff isn’t the same as going through the mental process that led to it.
It’s like reading the solution to a math problem.
You can understand each line.
That doesn’t mean you would have figured it out on your own.
Or that you could solve the next similar problem without help.
The difference is huge.
Agents show us the destination.
But they often skip the journey.
And that journey is where much of the technical expertise was built.
Incidental knowledge
There’s a very interesting concept in education:
incidental learning.
It’s everything we learn while doing something else.
When you hunted for a bug…
you learned about architecture.
When you wrote tests…
you learned how the people who built that system thought.
When you investigated a regression…
you learned why certain decisions should never be repeated.
None of that appeared in the ticket.
But it ended up forming part of your mental model.
Agents eliminate much of that journey.
And that efficiency has a cost.
A everyday example
Suppose an agent solves an authentication problem.
The Pull Request is flawless.
The tests pass.
Everything works.
Six months later an incident appears.
The developer who originally accepted that PR now has to investigate it.
But they never went through the path that led to that solution.
They never understood:
- why OAuth was chosen over another mechanism;
- what edge cases existed;
- what alternatives the agent discarded;
- what risks it evaluated before implementing the change.
The knowledge never reached the team.
Only the code did.
The paradox
The better coding agents become…
…the easier it is to accumulate Knowledge Debt.
Because the agent no longer just generates code.
It also:
- investigates;
- tests hypotheses;
- navigates the architecture;
- discards incorrect solutions;
- synthesizes information.
Just the activities that used to build experience.
Paradoxically, the more competent the agent is, the fewer opportunities the developer has to build that same knowledge themselves.
Should we stop using agents?
Not at all.
The paper’s conclusion isn’t that we should go back.
It would be as absurd as stopping use of compilers because we used to write assembly.
The productivity that coding agents bring is real.
The right question isn’t whether we should use them.
It’s how do we design workflows where productivity doesn’t replace learning.
Because writing less code can be great news.
Learning less about the system isn’t.
Agents that also teach
I think there’s a huge opportunity there.
Until now we’ve designed agents to produce results.
Maybe the next generation has another goal.
Help develop judgment.
Imagine that, in addition to the Pull Request, the agent delivers something like this.
Why did I choose this solution?
↓
What alternatives did I discard?
↓
What modules did I traverse?
↓
What risks did I find?
↓
What should the next developer know?
That completely changes the experience.
The agent stops being just an executor.
It starts becoming a mentor.
Some practices we can adopt now
We don’t need to wait for a new generation of tools.
There are several things teams can start doing today.
Ask the agent to explain before modifying
Instead of:
“Fix this bug.”
Try:
“Explain first what you think the cause is and only then propose a change.”
That forces the developer to validate their mental model before the code.
Ask for alternatives
A simple question:
“What other solutions did you evaluate and why did you discard them?”
Often teaches more than the final diff.
Rotate reviews
Even though the code was generated by AI.
Reviews remain one of the best mechanisms for collective learning.
Not just to find errors.
Also to share mental models.
Preserve the reasoning
Not just the code.
Keeping architectural decisions, discarded hypotheses, and context turns out to be as important as keeping the Pull Request.
Code explains what we did.
Reasoning explains why.
Measure understanding, not just speed
If your team’s only metrics are:
- tickets closed;
- lines modified;
- delivery time;
it’s very easy for Knowledge Debt to go unnoticed for months.
Maybe we should also ask ourselves:
- Who understands this system?
- How many people could diagnose a critical incident?
- What knowledge are we building beyond software?
The challenge for Engineering Managers
I think this idea goes far beyond engineering.
For years we optimized the pipeline to produce software.
Now we also need to optimize it to produce knowledge.
Because teams don’t scale just by sharing code.
They scale by sharing mental models.
And those models are built by solving problems.
Not just accepting solutions.
Productivity matters.
But a team that produces twice as much software while understanding half of its system is probably accumulating a much more dangerous debt than any pending refactor.
A new responsibility for agents
A few months ago we were discussing how much code they could write.
Then we started talking about memory, knowledge graphs, and runtimes.Knowledge Debt adds another dimension.
Maybe the best coding agent of the future won’t be the one that writes the most code.
It will be the one that leaves the developer understanding more of the system when the session ends than when it began.
That would be a huge change.
Because it would mean that AI doesn’t just increase productivity.
It also enhances the team’s experience.
And I think that should be the real goal.
Not building agents that replace learning.
But agents that accelerate it.
Because software can always be rewritten.
The knowledge a team stops building is much harder to recover.