Rahul Garg’s Feedback Flywheel closes his series on reducing friction in AI-assisted development with what sounds, at first read, like a straightforward proposition: after each AI coding session, harvest what you learned and feed it back into shared artifacts. The team’s CLAUDE.md gets sharper. The prompt library grows. The correction registry accumulates patterns. Over time, individual discovery becomes collective knowledge, and each session starts better than the last.
The mechanism is clean. The challenge is not the mechanism.
The challenge is that AI coding sessions produce a category of knowledge that existing team rituals were not designed to capture. Understanding why requires stepping back from the tooling and thinking about how knowledge moves through organizations at all.
What Tacit Knowledge Actually Means Here
Ikujiro Nonaka’s framework for organizational knowledge distinguishes between explicit knowledge, which can be written down and transferred directly, and tacit knowledge, which lives in practitioners and resists articulation. The classic example is riding a bike: no amount of written description transfers the skill. You acquire it through practice and feedback until the knowledge becomes embodied.
Software teams have always had tacit knowledge problems. The senior engineer who “just knows” which subsystems to avoid touching before a release. The unwritten consensus about what a code review comment means when it’s phrased as a question versus a suggestion. The intuition that a particular design pattern works in this codebase even though the docs say otherwise. Teams manage this through practices that move tacit knowledge toward explicit: pair programming, code review, retrospectives, post-mortems.
Each of those practices has a natural capture moment. Pair programming captures knowledge in real time through conversation. Code review captures it in written comments attached to visible diffs. Retrospectives create a scheduled cadence for surfacing what the team has learned over a sprint or quarter. Post-mortems crystallize incident learnings into documented runbooks and process changes.
What AI coding sessions produce sits outside all of those capture mechanisms, and the reason is structural.
The New Kind of Knowing
When you work with an AI coding tool for a few hours, you develop knowledge at multiple levels simultaneously. Some of it is task-level: you solved the problem, the code works, the PR is open. Some of it is about your codebase specifically: you discovered that the AI consistently misunderstands your event schema unless you explain it a particular way, or that certain prompts reliably produce correct pagination logic while others produce off-by-one errors against your specific database driver.
But the deepest layer is about the collaboration itself: you learned something about how to steer the model toward your team’s patterns, how to phrase constraints to make them stick, where in a session it pays to be more prescriptive and where it pays to leave room for the model to explore. This is knowledge about the human-AI working interface, and it has no clear precedent.
That third layer is almost entirely tacit. You could not write it down before you acquired it. After you acquire it, writing it down is genuinely difficult because the knowledge is partly procedural and partly conditional on context you cannot fully specify in advance. It’s closer to the bike-riding end of Nonaka’s continuum than the “write it in the wiki” end.
Code review does not reach this knowledge. The diff submitted for review shows the outcome; it does not show the ten steering decisions made during the session that shaped the outcome, the prompts that were revised three times, the moment the model went off-track and how that was corrected. Retrospectives reach it only if someone remembers to bring it up, which is unlikely when the session happened two weeks ago and three other fires are on the agenda. Pair programming would reach it, but most AI sessions are solo.
This is the gap the Feedback Flywheel is designed to close: a structured practice that makes the post-session capture moment real rather than aspirational. But naming the gap and building the mechanism does not automatically solve the underlying tacitness problem.
Where the Knowledge Lives After a Session Ends
Consider what happens in the half-hour after a productive AI coding session. The PR is ready. The developer is tired. There is a brief window where the session is still vivid, the decisions are recoverable, and the learnings are accessible. That window is probably shorter than most people assume. Cognitive science on memory consolidation suggests that procedural and contextual memories degrade fastest in the period immediately after learning, particularly under conditions of mental fatigue.
Teams have no existing ritual that triggers in that window. Stand-ups happen in the morning. Retrospectives happen at sprint boundaries. Code review happens when the reviewer gets to it, which is not when the session knowledge is freshest. The post-session moment is unclaimed territory in most team processes.
Garg’s flywheel explicitly colonizes that territory. The practice involves a structured reflection step that happens before the session’s context is closed: what patterns emerged, what friction was encountered, what should change in the shared artifacts as a result. The discipline is not in having the insight during the session, it’s in stopping to write it down before the window closes.
That discipline is harder than it sounds, and it is harder for a specific reason: most of what you learned during the session looks obvious from inside the session. The correction you made to the prompt feels trivial once it worked. The constraint you added to the context document solved the problem so cleanly that it seems like it should have been there from the start. This is the curse of knowledge operating in real time. The insight does not feel valuable in the moment; it feels like catching up to something that was already true.
Retrospectives suffer from a milder version of the same problem. Teams often under-generate action items not because nothing went wrong but because by the time the retrospective happens, the friction has been normalized. The flywheel’s answer is timing: catch the knowledge before normalization sets in.
What “Shared Artifacts” Actually Means in Practice
The Feedback Flywheel’s output needs to go somewhere concrete. Garg points at shared artifacts as the destination, and it is worth being specific about what those look like because the category covers meaningfully different things.
A CLAUDE.md or .cursorrules file is a live operational document. It is read at the start of every session, so anything added to it immediately changes the default behavior for everyone using those tools on the project. This is the highest-leverage artifact for the flywheel. A single well-phrased constraint added after a session where the model repeatedly violated it will save every future session from the same correction loop.
A prompt library is a different kind of artifact: a collection of reusable prompts for recurring tasks. Reviewing a PR against the team’s specific architectural principles. Generating test cases for a particular kind of edge condition. Explaining a diff to a non-technical stakeholder. These prompts encode accumulated steering knowledge in a form that can be shared and reused without requiring anyone to rediscover the phrasing that works. The library degrades if nobody maintains it, but it compounds if the team treats it as a first-class artifact.
A correction registry is the most underrated artifact in this list. The idea is to maintain a record of the corrections the team has applied during sessions: cases where the model produced something incorrect, how the correction was framed, and what the right output looked like. This serves two purposes. First, it provides a searchable record for developers encountering similar problems. Second, it is the raw material for updating the context documents: if the same correction appears three times in the registry, it should probably become a constraint in CLAUDE.md.
None of these artifacts exist naturally in teams that have not created them deliberately. The flywheel depends on them existing, which means the practice has a bootstrapping cost. Early sessions have nowhere to put the learnings because the artifacts are empty. The team has to decide to create them, and the decision feels premature until the artifacts have grown enough to be obviously useful.
The Comparison to Code Review
It is worth comparing the flywheel to code review directly, because code review is the most established knowledge-sharing practice in software teams and the comparison reveals something useful.
Code review works because it is structurally attached to the artifact being reviewed. The diff is visible, the comments are inline, the conversation is captured in the PR thread, and the record persists. The practice has a clear trigger (a PR is opened), a clear participant structure (author and reviewers), and a clear output (comments, approvals, rejections, revisions). The social contract around code review is well-established enough that violating it carries visible costs.
The Feedback Flywheel has none of those structural advantages out of the box. The trigger is “session ends,” which is invisible to teammates. The participant is initially just the developer who ran the session. The output is updates to shared artifacts, which are visible only to people who check those files or get notified about changes to them. The social contract does not exist until the team creates it.
This is not a criticism of the flywheel; it is a description of the work required to make it real. The practice needs the same kind of ritualization that code review has: a shared expectation that updates to shared artifacts are part of finishing a task, not optional cleanup. Teams that treat CLAUDE.md the same way they treat source code, reviewing changes, debating additions, reverting things that do not work, will extract more from the flywheel than teams that treat it as a loose document that anybody can append to.
Why This Series Matters as a Body of Work
The context anchoring, correction ledger, and feedback flywheel articles are not independent practices. They form a coherent theory of how teams should manage their AI-assisted development infrastructure. Context anchoring addresses the session start: how does the model know what it needs to know before the first message? The correction ledger addresses the session itself: how are errors logged in a form that improves future sessions? The flywheel addresses the session end: how does individual learning become team learning?
The gap in most teams’ current practice is not any single one of these. It is the absence of a closed loop. Teams using AI tools typically have some version of context anchoring because the tools require it. They have no systematic correction capture and no structured post-session reflection. The result is that the same corrections get made repeatedly by different developers, the context documents stay frozen at whatever state they were in when someone last thought to update them, and the team’s collective AI-collaboration skills grow only as fast as the least-frequent knowledge-sharing moment, which is usually the retrospective.
The flywheel’s core claim is that the knowledge compounds only if it is captured consistently. That requires the post-session moment to be treated as part of the work, not as an optional reflection that happens when time allows. The ritual is the mechanism. Without the ritual, the flywheel is just a description of what could happen if the knowledge did not evaporate after every session.