The Knowledge That Stays With One Person: Making AI Learning Stick Across a Team

There is a pattern that shows up in almost every team that has adopted AI coding tools for a few months. One or two people develop an intuition for prompting. They learn which context to include, which constraints to name explicitly, how to decompose a problem so the model can help effectively. Their velocity climbs. The rest of the team does not see the same gains, because the knowledge lives inside those individuals, invisible and untransferred.

This is the problem that Rahul Garg addresses in the final installment of his series on reducing friction in AI-assisted development. He calls the solution a feedback flywheel: a structured practice for capturing what you learn in an AI session and feeding it back into the team’s shared artifacts, so that individual discoveries become collective capability.

The idea sounds simple, but the mechanics of it are worth unpacking, because most teams are not doing this at all.

Why Individual Learning Doesn’t Transfer

When you figure out how to get Claude or Copilot to produce useful output for a specific class of problem, that knowledge is tacit. You carry it as intuition. You don’t write it down because it felt like a natural part of figuring out the problem, not like a reusable artifact. It’s the same reason that experienced developers rarely document the mental models they use to navigate a codebase; the knowledge is so embedded in practice that it doesn’t feel like knowledge.

AI tool usage compounds this problem. The feedback loop between a developer and an AI model is private by default. Nobody else sees the twenty intermediate prompts that led to a working solution. The commit shows the result; the session that produced it vanishes. Code review has always lost context, but with AI-assisted code the context gap is wider, because the actual reasoning process happened in a tool that leaves no trace in version control.

Garg’s series has been building toward this problem from the beginning. Earlier parts covered reducing context-switching overhead and structuring prompts for consistency. The feedback flywheel is where those practices get institutionalized. It is the mechanism that prevents each team member from having to rediscover the same patterns independently.

What the Flywheel Is Made Of

The core of the practice is a structured review after significant AI sessions. Not after every prompt exchange, but after sessions where you learned something, hit a wall, or produced output that surprised you in either direction. The review asks a specific set of questions: What context did the model need that I didn’t initially provide? What constraints would have prevented backtracking? What would I include in the system prompt if I were doing this again?

The answers to those questions go somewhere shared. For teams using Claude, that often means updating a CLAUDE.md file in the project root. This is a file Claude Code reads on startup to understand the project’s conventions, architecture, and constraints. A team that actively maintains this file is effectively encoding their accumulated AI session learnings into a document that every future session benefits from automatically.

The same principle applies to whatever shared context your tooling supports. Cursor has its .cursorrules file. GitHub Copilot can be shaped through organization-level instructions. The specific mechanism matters less than the habit of treating these files as living team artifacts rather than one-time setup.

Prompt libraries are a related artifact, though they have a narrower scope. A library of effective prompts for specific recurring tasks, checked into the repository alongside the code, solves a different but related problem: not every team member needs to rediscover how to prompt for a migration, a test generation run, or a code review summary. The library degrades quickly if it isn’t maintained, which is why the review practice has to feed directly into it, not operate separately from it.

The Retrospective Connection

Garg’s framing connects to something teams already know how to do: the retrospective. The structure of a blameless postmortem or a sprint retrospective is designed to extract learning from experience and convert it into process change. The feedback flywheel is a retrospective applied to AI usage.

Agile retrospectives have a well-understood failure mode: teams run them, produce action items, and then never follow through because the action items have no owner and no integration with the team’s actual workflow. The feedback flywheel fails the same way if the output of the review session doesn’t land in a specific artifact that gets used. The loop is only a flywheel if it actually feeds back.

This is where Garg’s proposal is more concrete than general advice about knowledge sharing. He is specific about the artifacts: shared context files, prompt libraries, team conventions documents. These are things that get used in the course of normal work, not things filed away in a wiki that nobody reads. The choice of artifact matters because it determines whether the knowledge is accessible at the moment someone needs it.

The Compounding Math

There is an asymmetry between individual and team learning that makes the stakes here higher than they might appear. Individual learning accumulates linearly. Each developer who figures out effective AI patterns gets better over time, but their improvement is bounded by what they personally encounter and have time to reflect on.

Team learning, when it works, compounds differently. If five developers are all contributing observations from their AI sessions into shared artifacts, each of them benefits from the other four’s discoveries. The effective learning rate per developer scales with team size rather than with individual hours. The developer who hasn’t touched a particular area of the codebase in six months can still benefit from the context improvements made by whoever was working there last week.

This is the argument for Communities of Practice in software teams, and it applies here. Etienne Wenger’s work on communities of practice showed that knowledge management in professional settings depends on social practices around sharing, not just on documentation systems. The feedback flywheel is a social practice. The artifacts it produces are the outputs, not the mechanism.

Where This Breaks Down

There are real friction points. Developers in flow do not want to stop and write a retrospective after a productive AI session. The value is invisible and deferred; the cost is immediate. Teams that try to mandate post-session reviews often find compliance drops after the novelty wears off.

The lower-friction version of this practice is integrating the reflection into existing workflows. A pull request description that includes a note about what context the AI needed, and what didn’t work, is a review artifact that takes thirty seconds to write and surfaces in the code review conversation. That’s not a formal retrospective, but over time it builds a record of what the team has learned. Some teams do this in a dedicated Slack channel; some use a lightweight structure in their team docs. The format is less important than the regularity.

The other failure mode is treating shared prompt artifacts as static references rather than as things to be updated. A CLAUDE.md file written during the initial project setup and never touched again reflects a team’s understanding of AI-assisted development at one moment in time. The models change, the codebase evolves, and the prompts that worked six months ago may be suboptimal now. The practice has to include a cadence for reviewing and pruning the artifacts, not just adding to them.

What This Changes

The practical implication of taking Garg’s proposal seriously is that AI tool usage becomes a visible part of the team’s craft, not a private behavior. Senior developers who have developed sophisticated prompting practices have an obligation to make that knowledge available, the same way they would for any other technical skill. Code review, pairing, and onboarding sessions become opportunities to share AI session patterns, not just code patterns.

For teams building in this direction, the starting point is simpler than building a formal feedback system. Start with a CLAUDE.md or equivalent context file, commit to updating it whenever someone discovers something that would have helped at the start of a session, and make that update part of the pull request for the session’s output. That is a minimal feedback loop. It is not fancy, but it is a loop, and a loop is what compounds.