Rahul Garg’s Feedback Flywheel is the closing piece of a three-article series on reducing friction in AI-assisted development. The series covers context anchoring (how does the model know what it needs before the first message), a correction ledger (how do errors get logged during a session), and now the flywheel: how does learning from a single developer’s session become a team resource.
The argument is not that developers are lazy about documentation. It is that the interaction surface between a developer and an AI coding tool has no structural home for collective knowledge. The session ends, the window closes, and everything that was learned about which prompts work, what context the model needs, and where it reliably fails stays in one person’s head. The next session starts from scratch.
Why This Is a Structural Problem, Not a Discipline Problem
Consider what happens in a typical AI coding session. The developer writes an initial prompt, gets something close but not quite right, refines the context, corrects an incorrect assumption the model made about the codebase, steers away from a pattern the model defaults to that doesn’t match the project’s conventions, and eventually arrives at something usable. The commit records the result. The twenty intermediate exchanges that produced it are invisible to everyone else.
Code review, by contrast, works precisely because it is structurally attached to the artifact. The diff is visible. The comments are inline. The record persists. The trigger is the PR opening, which everyone on the team can see. There is a social contract around participation. None of this emerged from developer discipline; it emerged from tooling (GitHub’s pull request interface, in particular) that made the review a structural part of the workflow, not a separate activity requiring a context switch.
AI session knowledge has none of those structural advantages. The trigger for capture is invisible: the session ends. The initial participant is only the developer who ran the session. The output has no obvious visibility mechanism. Teams that want to transfer this knowledge have to ritualize it explicitly, which is exactly where most adoption efforts break down.
The Knowledge That Resists Transfer
The specific character of AI session knowledge makes this worse. It is largely tacit in the Nonaka and Takeuchi sense: procedural, conditional on context that cannot be fully specified, and hard to articulate in retrospect. The correction that fixed a problem looks obvious after the session. The insight does not feel valuable in the moment because you are already past it.
There is also a timing problem. The post-session cognitive window is short. The context, the missteps, the steering decisions: these degrade quickly, especially after a mentally demanding session. If the capture requires significant effort, it does not happen. If it requires a context switch to a separate tool, it does not happen. The threshold for capture has to be low enough that it fits inside the natural end of the session.
What the Flywheel Actually Requires
Garg identifies three shared artifacts that form the mechanism of the flywheel.
Context files are the highest-leverage artifact. Tools like Claude Code’s CLAUDE.md, Cursor’s .cursorrules, and GitHub Copilot’s repository-level instruction customization are machine-readable files that load automatically into every session. This is a fundamentally different property from a wiki page or a shared document: it doesn’t require anyone to remember to look something up. A well-maintained CLAUDE.md encodes architecture overview, naming conventions, module boundaries, areas where the model makes incorrect assumptions, and error-handling patterns. Improvements to it apply automatically to every future session for every team member.
# Project Context
## Architecture
This is a Discord bot using discord.js v14. Commands are registered as slash commands.
All command handlers live in src/commands/. The dispatcher is in src/dispatcher.ts.
## Known Model Pitfalls
- Do not suggest callbacks for async operations; this codebase is entirely async/await
- The config module uses a singleton pattern; do not suggest dependency injection for it
- Error responses to Discord must be ephemeral ({ ephemeral: true }) to avoid cluttering channels
## Conventions
- Use Zod for all input validation
- All database calls go through the repository layer in src/db/A file like this pays for itself the first time it prevents the model from suggesting a pattern the team already rejected. The second time it prevents the same mistake for a different developer on a different day, it has already compounded.
Shared prompt libraries are reusable templates for recurring tasks: test generation, migration scripts, PR summaries, code explanation for non-technical stakeholders. Stored as markdown files in the repository, they are findable without a context switch. The maintenance burden is real: a prompt library that doesn’t evolve with the codebase becomes noise. Clear ownership and periodic review are required.
Session notes and a correction registry are the raw input to the other two artifacts. Short notes, not post-mortems: what context the model needed that wasn’t initially provided, what constraints would have prevented backtracking. A correction registry logs when the model was wrong, how the correction was framed, and what the right output was. When the same correction appears three times in the registry, it should become a constraint in CLAUDE.md.
Where the Loop Breaks
The capture step is the most fragile. If the threshold is high, it doesn’t happen. One sentence at the end of a session is a realistic lower bound. A tag in a PR description annotation is realistic. A separate retrospective document requiring a dedicated calendar slot is not.
Retrieval is the second failure mode. A prompt library that requires deliberate retrieval gets retrieved inconsistently. The artifacts that compound reliably are the ones embedded in the workflow: auto-loaded context files, editor-integrated snippet libraries. Anything requiring a separate lookup will be used by the developers who already know to look for it, not the ones who need it most.
Signal degradation is the long-term failure mode. A CLAUDE.md that becomes a dumping ground accumulates instructions for model versions that no longer behave the same way, notes about refactored subsystems, stale guidance that the model now interprets inconsistently. The same practices that keep any shared documentation healthy apply here: clear ownership, periodic review, discipline to delete obsolete content. The file needs a steward, not just contributors.
There is also an adoption curve problem that Garg’s article gestures at but does not fully resolve. The developers most fluent with AI tools generate the most transferable insight. They are also the least likely to feel the gap, because their local knowledge is already strong. The developers who would benefit most from the shared artifacts are the ones least able to contribute to them initially. In early stages, the practice probably needs someone who can identify what is generalizable versus too context-specific before it reaches the shared files.
A Minimal Starting Point
The compounding argument holds even at small scale. Three practices give most of the value at low overhead:
First, open a CLAUDE.md in the main repository and treat it as a team document. Put it in version control. Review changes to it with the same care as source code. The file does not need to be comprehensive on day one; it needs to exist.
Second, end each AI-heavy session by writing one sentence about what would have made the session go faster. In a shared Slack thread, a PR description annotation, a comments section in a shared notes file. The medium matters less than the habit.
Third, once a month, spend fifteen minutes reading those sentences and deciding which should be promoted into a durable artifact. This is a low-cost ritual that provides the Externalization step that tacit knowledge otherwise never reaches.
The flywheel metaphor is accurate in one respect: the first push is expensive relative to the output. The second push is cheaper. The value is not in any single session’s learnings; it is in the cumulative effect of many sessions improving shared infrastructure that every subsequent session benefits from. That is not a discipline argument. It is a compounding argument, and compounding works even when the individual inputs are small.