Rahul Garg’s Feedback Flywheel, the final piece in his series on reducing friction in AI-assisted development, makes a deceptively simple argument: what you learn in your AI sessions should not stay in your AI session. The observation sounds obvious. The structural failure it points to is not.
Most teams using AI coding assistants are accumulating knowledge at the individual level and losing it at the team level. One developer figures out how to get Claude or Copilot to produce useful migration scripts for their particular schema conventions. Another learns that a specific prompt structure cuts the hallucination rate for their domain. A third discovers that seeding the context window with a particular architectural summary saves three rounds of clarification. None of this gets written down. None of it propagates. The next session starts from scratch.
This is not a failure of discipline. It is a structural problem: the interaction surface between developer and AI tool has no obvious place to park collective knowledge, and the natural feedback loop in that interaction is entirely local. You get better; the team does not.
Why the Flywheel Metaphor Fits
Jim Collins popularized the flywheel concept in Good to Great as a way to describe how compounding momentum works in organizations. The first push is expensive and the wheel barely moves. Each subsequent push gets a little cheaper because the wheel is already spinning. After enough consistent effort the flywheel moves under its own weight.
The same geometry applies to team AI practices. The first team retrospective where someone documents what prompted a particularly good result feels like overhead. The second one builds on the first. By the time a team has a living document of patterns, a shared prompt library, and a convention for tagging sessions that produced surprising results, new team members can onboard into that collective intelligence instead of rediscovering it. The cost of each subsequent push drops; the output of each session rises.
Garg’s proposal is to build this loop deliberately, through structured practices for capturing and redistributing learnings, rather than hoping it emerges organically. It almost never does.
What the Shared Artifacts Actually Look Like
The concrete output of a feedback flywheel practice is a set of living artifacts that accumulate team knowledge about working with AI tools. These take a few recurring forms in teams that have built them.
Context seed files. Tools like Claude Code use CLAUDE.md files to inject persistent context into every session. Cursor has .cursorrules. GitHub Copilot has repository-level instruction files. These are not just setup files; they are knowledge stores. A team that maintains a well-curated CLAUDE.md is, in effect, encoding its collective understanding of what the AI needs to know to be useful in this specific codebase, with these specific conventions, for this specific domain. The file becomes a team artifact that anyone can improve and everyone benefits from.
Prompt libraries and templates. Teams that do a lot of similar tasks with AI assistance, code review, test generation, migration scripts, API documentation, find that certain prompt structures reliably outperform others for their context. A shared prompt library, even as a simple markdown file in the repo, gives everyone access to what the team has learned. It removes the silent tax that every developer pays when they have to rediscover a working prompt from scratch.
Retrospective annotations. The standard sprint retrospective can grow a section for AI session observations. Not extensive post-mortems, just short notes: what worked, what failed, what surprised us. Over several sprints these annotations build a team-legible history of what the AI is good for in your context and where it consistently falls short.
The Knowledge Transfer Problem AI Makes Visible
The friction Garg is naming is not new. Teams have always had the problem of tacit knowledge staying tacit: the senior developer who knows why the authentication flow is structured the way it is, the institutional memory that lives in someone’s head and evaporates when they leave. Nonaka and Takeuchi’s SECI model from the 1990s described this as the socialization-externalization-combination-internalization cycle, the loop by which tacit knowledge becomes explicit, gets combined with other explicit knowledge, and then gets internalized by new people who eventually generate new tacit knowledge of their own.
AI-assisted development accelerates the tacit knowledge accumulation phase without automatically accelerating the externalization phase. You learn faster in individual sessions. The gap between what any given developer knows and what the team as a whole knows grows faster as a result. The feedback flywheel is essentially a forcing function for the externalization step.
This is part of why prompt engineering has not become a recognized team discipline the way code review or pair programming have. The output of prompt engineering is largely invisible. You run a session, get a result, move on. The knowledge about why the result was good stays with you unless someone builds a structure to surface it.
What Makes the Loop Break
Teams that attempt this and abandon it tend to fail at one of two points.
The first is the capture step. If the process for documenting an AI session learning requires significant effort, it does not get done. The threshold needs to be low: a single sentence added to a shared document, a tag in a PR description, a comment in the relevant CLAUDE.md section. The artifact needs to live where the work is, not in a separate system that requires a context switch to reach.
The second failure point is the retrieval step. A shared prompt library that nobody opens is not a knowledge store; it is a graveyard. The artifacts have to be either embedded in the workflow, like a CLAUDE.md that gets loaded automatically, or surfaced at the moment of need, like a searchable snippet library accessible from the editor. Knowledge that requires a deliberate act of retrieval gets retrieved inconsistently.
The teams that get this right tend to treat their context files and prompt libraries the same way they treat source code: under version control, reviewed in PRs, improved incrementally, and owned collectively. A prompt that improves test coverage for a particular module is as worth committing as the module itself.
The Org Chart Problem
There is a subtler issue behind Garg’s proposal that deserves attention. Most team knowledge-sharing practices, retrospectives, documentation days, internal tech talks, are organized around the assumption that the unit of knowledge is a project or a process. The unit of AI session knowledge is different. It is conversational and contextual. It is about what the AI understands and what it does not, what framing produces useful output and what framing produces plausible-sounding nonsense.
This kind of knowledge does not fit neatly into existing documentation templates. A how-to document assumes a repeatable procedure. AI session knowledge is more like calibration data: this model, with this context, in this domain, at this level of specificity, tends to behave in this way. Communicating that requires a different format, closer to a personal log of observations than a technical specification.
Garg’s series has been building toward this conclusion: reducing friction in AI-assisted development is not primarily a tooling problem. It is a practice problem. The tools are already capable of producing significant leverage. The bottleneck is whether the team can build the habits and artifacts that let that leverage compound over time rather than reset with every session.
A Practical Starting Point
If you want to run a minimal version of this in your team, three things get you most of the value with a fraction of the overhead.
First, open a CLAUDE.md or equivalent context file in your main repository if you do not already have one, and make it a team document rather than an individual one. Put it in version control. Review changes to it the same way you review changes to anything else.
Second, end each AI-heavy work session by writing one sentence about what you would do differently next time, and put it somewhere the team can see. A comment in a Slack thread, a line in a shared notes file, a PR description annotation. One sentence. The bar has to be that low or it will not happen consistently.
Third, once a month, spend fifteen minutes in a team meeting reading those sentences aloud and deciding if any of them should be promoted into a durable artifact: a new section in the context file, an entry in the prompt library, a note in the onboarding docs.
That is the flywheel in its simplest form. It is not glamorous. It compounds.