Articles

The Knowledge Your Team Is Losing

Teams lose valuable knowledge through forgotten decisions and missing context. AI makes this problem impossible to ignore.

Robbin Schuurman

Robbin Schuurman

June 19, 2026
10 minutes

The Future of AI-Powered Product Development: The Knowledge Your Team Is Losing

Article 6 of 9 in the series.

Picture a senior Developer sitting down to debug a production issue in a service her team owns. She has not written most of the surrounding code. An AI coding agent has, over the past year, generated the majority of it, under her team's direction and with her team's approval. The code is well-documented. The tests pass. The Definition of Done has been met, Sprint after Sprint.

She cannot intuit the fault line. The usual instincts, the ones that tell a seasoned Developer that feels wrong, do not fire. She ends up asking the agent to explain the agent's own work back to her. The debugging takes four hours instead of forty minutes.

Nothing about the code is bad. Everything about the knowledge is.

This is the quietest, least-discussed, and, I think, most underestimated shift happening inside AI-powered product teams. The first five articles in this series focused on visible, structural shifts: a Definition of Value, concentrated accountability, refinement as option framing, an Adoption Increment, an Evidence Review. All five are loud shifts. This article is about a silent one. What happens to the tacit knowledge a team used to accumulate by doing the work, when the work is increasingly being done by an agent?

This is a visionary piece, not a predictive one. I cannot tell you what the learning curve on AI-powered teams will look like in five years. I can share how a room full of experienced Professional Scrum Trainers thinks about the risk, and why a simple discipline, starting this Sprint, will protect the knowledge base of your team.

Two Kinds of Knowledge

Ikujiro Nonaka and Hirotaka Takeuchi, in The Knowledge-Creating Company, made a distinction more than 30 years ago, that has only grown more useful with time. Explicit knowledge is what can be written down: documentation, wikis, ticket histories, architecture diagrams, playbooks. Tacit knowledge is what cannot easily be written down: instinct, pattern recognition, the felt sense of this has gone wrong before, here is what to look for.

Make no mistake; Scrum has always valued learning, self-management, and Kaizen. The Scrum Guide is not at fault for anything in this article. What has changed is the mechanism by which tacit knowledge used to accumulate. For thirty years, the mechanism was simple: teams built their instincts by doing the work, together, under pressure, with consequences. Developers learned the code by writing it. Product Owners learned the market by talking to customers. Scrum Masters learned the team by sitting through the hard moments. AI agents are, quietly and without anyone noticing, breaking that mechanism.

What Agents Do to the Learning Loop

Agents produce output without the team having to do the work that used to generate the learning. A Product Backlog item gets drafted. A Developer never writes the first version. A customer interview gets summarized. The Product Owner never sits in the uncomfortable silence that taught them what the customer was really worried about. A retrospective insight gets extracted. The Scrum Master never has to facilitate the conversation that built the team's shared language for what went wrong.

The code gets shipped, and the code understanding does not accumulate. The summary gets produced, and the market feel does not develop. The document gets written, and the team's shared intuition does not sharpen.

I want to name the invisible cost. Call it the Tacit Knowledge Tax. For every piece of work an agent does for the team, a tax is paid in lost tacit learning. Sometimes the tax is tiny and not worth refusing to pay; sometimes it is large, and pays back in pain eighteen months later, when the team confronts a novel problem and discovers nobody on the team has the lived experience to recognize it. The tax is not always visible to leadership, or to the team itself, but it is always quietly real.

Where the Tax Is Cheap, Where It Is Expensive

The tax is cheap on work that is repetitive, routine, and already well-understood: boilerplate, configuration files, standard documentation, first drafts of generic emails, summaries of long-established meeting notes. The team loses almost nothing by letting an agent do this work.

The tax is expensive on work that is how humans build judgment: first-pass customer interviews, first-cut debugging sessions, architecture decisions, refinement conversations on genuinely novel items, retrospective facilitation. In each of these, the struggle of the work is the source of the learning. Outsource the struggle, and you get the output without the learning.

A well-run AI-powered team pays the cheap tax freely, and refuses the expensive tax deliberately. An undisciplined team pays every tax, celebrates the speed, and discovers, a year later, that it cannot solve any problem the agents have not seen before.

A Sibling Tax: Sustainability and Resource Cost

The Tacit Knowledge Tax is the expensive one most teams do not see. A second tax, close to it and worth naming, is the sustainability tax. Every agent call burns compute, water, and power. The carbon and resource cost of running hundreds of agent invocations per engineer per day is no longer negligible at the company level, and is starting to matter at the customer and regulatory level. An AI-powered team that does not measure its agent footprint, and does not ask whether a given task actually needs an agent at all, is optimizing for speed while quietly borrowing against a different kind of ledger. Not every task needs an AI. Teams that decide, deliberately, which tasks do, are going to look more, not less, sophisticated five years from now.

And Do Not Forget the Humans You Are Building For

One more protection worth naming, often forgotten in AI conversations. The work teams do is, ultimately, used by people. UX, human-centered design, customer empathy, and the craft of shaping a thing that fits a human being's context are not ceremonial niceties. They are the part of the work an agent can assist with, but cannot hold accountable for. Protect the hours your team spends with users, watching them, listening to them, designing for them. The teams that treat this as optional in an AI-powered world are the teams whose Increments will technically meet the Definition of Done and quietly fail the only test that matters.

Three Protections a Team Can Put in Place

First, human-only hours. Block one or two hours a week where the team does the work with no AI assistance. Debugging. A customer call. A refinement conversation. The team rebuilds the felt sense that no summary captures.

Second, repurpose the Accountability Test. The three questions from Article 2, Explain, Defend, Redo, are already a tacit-knowledge test in disguise. If a team member cannot redo the work without the agent, the tacit knowledge has evaporated. That is a flag. Act on it.

Third, apprenticeship order. When junior and senior humans work alongside agents, the sequence matters. Juniors do the first draft by hand. Agents assist on the second. Seniors review the third. Reverse that sequence, and juniors never learn to write, debug, or think. They learn to prompt, and prompting is a thin substitute for understanding.

What This Looks Like in Practice

Picture two teams, one year in. Both use AI heavily. Both ship the same volume of features. Both hit the Definition of Done and pass the Adoption Increment bar.

Team A treats every AI-assisted shortcut as free. The team velocity is higher, Sprint over Sprint, for the first eight months. Team B protects a handful of categories: customer interviews, first-draft debugging, refinement of genuinely novel items. Team B's velocity is about fifteen percent lower.

Month fifteen, a new class of production issue appears, one neither team's agents have encountered before. Team B solves it in a day. Team A takes six. Team A's documentation is excellent. Team A's intuition is gone.

The story is hypothetical by design. The pattern it points at is not. Signals of this compounding tax are already showing up in product engineering organizations. The details differ. The pattern does not.

Four Things You Can Do in Your Next Sprint

  1. Name one category of work your team will do without AI assistance this Sprint. Debugging, customer interviews, refinement of a novel item, retrospective facilitation. Pick one. Protect it.
  2. Run your next retrospective as a conversation, not a document. No agent summary. No auto-extracted insights. Talk. Write on a whiteboard. Let the awkward pause happen.
  3. In refinement, have a human talk through the problem before any options are generated. Two minutes. The Product Owner, a Developer, or a stakeholder. No agent in the room for that two minutes. The human framing sets the tacit-knowledge floor.
  4. For one Product Backlog item this Sprint, write the Bet, the Evidence, and the Definition of Done by hand. Yes, actually by hand. The slowness is the point. The learning is in the slowness.

The Turn

The cheapest sentence an executive can say about AI is "it makes the team ten times faster." The most expensive thing an executive can do is believe that sentence without pricing the Tacit Knowledge Tax. A team that pays attention to what is quietly being lost gets to keep the option of learning. A team that does not, does not.

The Scrum values, courage, focus, commitment, respect, and openness, all assume a team capable of learning from its own work. Protect the learning mechanism, or the values become slogans.

Over to You

Pick one category of work your team has handed to an agent over the past six months. Ask yourself: if that agent disappeared tomorrow, could the team still do that work well? If the honest answer is no, you have identified a Tacit Knowledge Tax that has been silently compounding. The next Sprint is when you start paying it down.

The next article goes to the place where the learning the team protects has to live, if it is going to be usable by the humans and the agents who need it. The Product Wall many senior product teams already maintain is about to become something richer, more load-bearing, and, for the first time, as legible to an agent as it is to a human. Call it the Context Lake. See you there.

Contributors

This article was created based on the Scrum.org PST Face-to-Face Event #137 in Amsterdam. It would not have been possible without the discussions with: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton, and Karel Smutný. The arguments here are mine. The thinking is ours.

< Read the previous article

Sources

The Knowledge-Creating Company, Ikujiro Nonaka and Hirotaka Takeuchi

The Fifth Discipline, Peter Senge

Situated Learning, Jean Lave and Etienne Wenger

The Scrum Guide, Schwaber and Sutherland

You Can't Delegate Accountability to an Agent, Article 2 of this series

The Sprint Review Is Broken, Article 5 of this series

Contact

Let’s discuss how we can support your journey.