Most teams that adopt AI coding tools see fast individual gains and slow collective ones. A developer who has spent months with Claude Code or Cursor has built up dense, project-specific intuition: which prompts land, what context the model needs to produce useful output, where it confidently hallucinates in this particular codebase. That knowledge sits entirely in their head, unavailable to teammates, and gone when the developer is out or moves on.
Rahul Garg’s Feedback Flywheel, the closing piece in his series on reducing friction in AI-assisted development published on Martin Fowler’s site, names this gap and proposes a structured practice to close it. The core move is familiar from other engineering disciplines: treat AI session learnings the way mature teams treat incident retrospectives. Capture them, codify them, feed them back into shared artifacts that the whole team reads.
Why Individual Gains Don’t Transfer
The compounding that individual developers experience with AI tools comes from context accumulation. Over time you build a set of phrasings, patterns, and priming techniques that reliably get the model to useful output faster. You learn to front-load architectural context before asking for implementation. You learn that asking “what’s wrong with this approach” gets better signal than “rewrite this.” You learn what your model’s particular failure modes look like in your domain.
This knowledge is not generic. It is bound to your codebase, your problem domain, and the model’s current behavior. A new team member starting fresh does not inherit any of it. They will spend weeks rediscovering what the rest of the team already knows.
Traditional tool knowledge does not create this problem as acutely, because most of it is largely universal. What works in Vim works for everyone using Vim. What works with Claude in a TypeScript Discord bot codebase may not work with Claude in a Python data pipeline, and almost certainly will not survive unchanged through a major model update. The knowledge is contextual and perishable in a way that shell scripting intuition is not.
There is also an asymmetry in how the knowledge degrades. When a developer who mastered Git leaves a team, the institutional knowledge loss is moderate; the tool behaves the same for the next person. When a developer who has spent months learning how to prompt effectively in a specific codebase leaves, the replacement cannot replicate their productivity by reading the documentation. The tool behaves differently depending on how you use it, and nobody wrote down how to use it well.
The Flywheel Mechanism
Garg’s proposal centers on structured harvest-and-feed-back. After AI-intensive sessions, developers note what they learned: which approaches worked, which failed, what context the model needed to succeed. These learnings get distilled into team-shared artifacts that future sessions draw on.
The artifacts take a few forms in practice.
Project context files are the most direct mechanism. Claude Code uses a CLAUDE.md file at the project root, loaded automatically into context for every session. Cursor uses .cursorrules. A well-maintained context file is a compressed version of everything your team has learned about working with AI on this specific codebase. It might describe the architecture, call out areas where the model tends to make incorrect assumptions, specify naming conventions the model would otherwise miss, or include boilerplate prompting patterns for common tasks like writing tests or generating migration scripts.
Shared prompt libraries extend this. Reusable prompt templates for recurring tasks evolve as the team discovers which framing consistently produces good output. These are different from general-purpose prompt guides; they are calibrated to your specific codebase and the team’s specific standards.
Session retrospective notes are lower-fidelity but often the source material for the other two. A few minutes at the end of a productive AI session to note what worked and why, before the context fades, creates the raw material that gets refined into the higher-quality shared artifacts over time.
The “flywheel” framing comes from the reinforcing loop this creates: better shared artifacts produce better sessions, better sessions generate better learnings, better learnings improve the shared artifacts. Each rotation builds on the last.
A Pattern the Industry Has Seen Before
This is structurally similar to how teams institutionalized other practices that initially lived in individual heads.
Code review culture did not emerge automatically when version control became widespread. Teams had to build the habit, create shared norms for what a review should accomplish, and iterate on that process deliberately over years. The knowledge of how to give useful code review was not implicit in the tooling; it was built up through explicit reflection and documented shared standards.
TDD adoption followed a similar arc. Developers who learned the discipline internalized it deeply, but that knowledge did not transfer to teammates passively. Teams that built explicit feedback loops, wrote down what they were learning about how to test effectively, and created shared examples of the practice converged faster than teams that left it to osmosis. The developers who got there first had to make their tacit knowledge legible.
The meaningful difference with AI tools is the velocity of change. Code review norms took years to stabilize across the industry, and once stable, they stayed stable; git blame still works the same way it did a decade ago. AI coding tools are changing fast enough that what your team learned about prompting six months ago may need significant revision today. The feedback loop needs to run faster, and the artifacts need to carry some record of when they were created and under what conditions, so the team can make informed decisions about what to update after a model change.
The Part That Is Hard
Capturing learnings is an extra step at the end of an already productive session. It takes discipline the same way writing a post-incident summary requires discipline: you have already solved the problem, the adrenaline has faded, and the next task is calling. Most developers will not do this consistently unless the team makes it a ritual, in the same way that mature incident response practices bake retrospectives into the process rather than leaving them optional.
The other hard part is signal preservation in shared context files. A CLAUDE.md that starts as a tight, useful set of notes can drift toward a dumping ground. Instructions written for a model version that no longer exists. Notes about a subsystem that got refactored months ago. The file grows, the signal-to-noise ratio drops, and eventually the model is spending part of its context window on stale guidance that produces inconsistent results.
Managing this requires the same practices as managing any shared documentation: clear ownership, periodic review, and the discipline to delete things that no longer apply. Teams that treat their shared AI context files the way they treat wiki pages with no assigned owners end up with the same outcome: a sprawling document nobody trusts.
There is also a granularity problem. A single project-level context file gets loaded for every session, regardless of what the session is about. A developer debugging the authentication layer probably benefits from different priming than one working on the billing system. Some tools support directory-scoped configuration, which helps; others do not. Teams compensate by keeping the file tightly focused and writing task-specific preambles inline, but this is manual work that could be automated.
What Tooling Still Does Not Provide
The Feedback Flywheel is a practice, not a product. Most AI coding tools today offer shared context mechanisms, but few make the feedback loop easy to maintain. There is no standard interface for annotating a prompt with when it was written, which model it was calibrated for, and whether it still holds. There is no tooling that surfaces which parts of a shared context file have been cited in successful sessions versus ignored. Teams are flying blind when they decide what to keep and what to cut.
Dynamic context selection is also largely absent. A 400-line CLAUDE.md loaded wholesale into every session is a blunt instrument. The ideal would be context that adapts to what the current session is actually about, pulling from a richer shared knowledge base rather than a flat file. Some teams are experimenting with retrieval-augmented approaches, embedding their team knowledge and pulling relevant chunks at session time, but this requires infrastructure most teams are not going to build from scratch.
The tooling will improve. In the meantime, the practice has to carry the weight.
Why This Matters Now
Garg’s series ends on the right observation: the gains from AI-assisted development do not compound automatically at the team level. They compound for individuals, and then they disappear when that individual is unavailable or leaves. Building a deliberate feedback practice is how teams close that gap.
The flywheel metaphor is apt. Getting it spinning requires initial effort. Keeping it spinning requires maintenance. Recalibrating it after a major model update requires a willingness to revisit things you thought were settled. But a team that has been running this practice for a year will be working with qualitatively better AI assistance than one that left each developer to figure it out on their own, even if both teams have equally talented people and comparable tooling budgets.
The knowledge is there. The practice of making it collective is what most teams have not built yet.