The productivity story around AI coding tools is almost entirely individual. A developer opens their editor, works with Claude or Copilot or Cursor, ships faster, feels good about it. The next developer on the team opens their editor and starts from scratch, working out the same patterns, running into the same walls, rediscovering the same workarounds.
This is the gap that Rahul Garg addresses in the final installment of his series on reducing friction in AI-assisted development at martinfowler.com. His proposal is a structured feedback practice, a mechanism for extracting learnings from individual AI sessions and feeding them back into the team’s shared artifacts. He calls it the feedback flywheel.
The metaphor captures something real. A flywheel stores rotational energy and releases it smoothly, resisting changes in speed. In this development context, each session where a team member figures out something useful, a prompt pattern that works well for a specific problem class, a context structure that makes the AI more accurate, a task decomposition that produces cleaner output, becomes an input. That input gets externalized, captured in some shared artifact. The artifact improves future sessions for everyone. Those improved sessions generate more learnings. The cycle accelerates and becomes self-sustaining.
The Knowledge That Stays in Someone’s Head
The friction here is that AI session knowledge is particularly tacit. When a developer figures out that prepending a brief description of a module’s invariants to a refactoring prompt reliably produces better output, that insight is highly valuable and highly perishable. It lives in their working memory, maybe makes it into a commit message or a Slack thread if they are thoughtful about it, and then disappears.
This is not a new problem for software teams. Tacit knowledge loss is well-documented in the knowledge management literature. Ikujiro Nonaka’s SECI model describes four modes by which knowledge moves in organizations: Socialization (tacit to tacit, through observation and apprenticeship), Externalization (tacit to explicit, through articulation), Combination (explicit to explicit, through synthesis), and Internalization (explicit to tacit, through practice). AI session knowledge tends to stay in Socialization or evaporate before it gets shared at all.
What makes this different from a developer learning a new library is that the knowledge is about the communication layer rather than the subject matter. When you learn a new API, you can encode it in documentation, tests, and code comments. When you learn that a particular way of framing a problem dramatically improves AI output quality, there is no natural home for that insight in conventional development artifacts. It is meta-knowledge, knowledge about how to work with the tool, and teams rarely have good systems for capturing that kind of thing.
Shared Artifacts as the Accumulator
Garg’s proposal centers on feeding learnings back into shared artifacts. The clearest modern example is the CLAUDE.md file that Anthropic recommends for projects using Claude Code. It is a markdown file at the project root that gets included in every AI session as context. Teams that maintain these files well are essentially encoding their collective AI session learnings into a persistent, versioned artifact that participates directly in future interactions.
The same principle applies to .cursorrules files in Cursor, to GitHub Copilot’s repository-level instruction customization, and to any system prompt maintained at the project level. These artifacts are not documentation that a human reads and then mentally translates into AI interactions. They are read by the AI in each session. A poorly maintained or absent artifact means every session starts cold. A well-maintained one means every session benefits from the team’s accumulated operational knowledge.
Beyond context files, shared artifacts in this sense could include:
- Prompt libraries for common task types, stored as templates or annotated examples
- Records of particularly effective AI interactions, for reference when approaching similar problems
- Conventions for how to structure requests for different categories of work
- Notes on failure modes: what the AI gets wrong without specific guidance, and how to provide that guidance
The key property is that these artifacts need continuous updating rather than a quarterly documentation exercise. Each learning that waits six weeks to be captured is six weeks of sessions running without it.
The Retrospective Problem
Teams that run retrospectives might assume a feedback flywheel is just a retrospective with different branding. The difference is material.
A retrospective captures high-level process observations: the PR review cycle takes too long, test coverage on the payment module needs attention, on-call handoffs are losing context. These produce action items that change how the team works going forward. They operate at fairly coarse granularity, and their output is typically a list of things to do differently.
The feedback flywheel Garg describes operates at much finer granularity. It captures specific, concrete learnings from individual AI sessions: what context formulations worked, what prompt structures produced good output for a particular problem class, what the AI consistently got wrong without specific guardrails. These are operational learnings that are immediately actionable, and their value decays quickly if not captured.
The appropriate cadence is probably daily or after each sprint rather than monthly. The output is not an action item list but a direct update to the shared artifacts: a new entry in the prompt library, a refined section in the project context file, an annotated example added to the team’s collection.
The Direct Participation Difference
The reason shared artifacts work better for AI session knowledge than conventional knowledge management tools do is that the artifacts directly participate in AI interactions rather than informing human behavior through an intermediary step.
When a team maintains a wiki page about coding conventions, a developer has to read that page, internalize the conventions, and then apply them in their work. Each step in that chain introduces loss. Developers skip the page, misread it, forget it under deadline pressure, or interpret it differently than the author intended.
When that same convention is encoded in a project context file, it gets applied in every AI session automatically. A well-articulated architectural constraint or coding convention in CLAUDE.md does not have to be read and internalized by each developer and then applied in their AI interactions. It is applied in every session by default. The translation layer that causes most knowledge management to leak value is largely absent.
This means the compounding is real and measurable. Better shared artifacts produce better AI sessions. Better sessions generate more specific, higher-order learnings, because the team is operating above the baseline rather than rediscovering it. Better learnings produce better artifact updates. The team becomes incrementally more sophisticated about AI-assisted development with each cycle, and the pace of improvement increases as the baseline rises.
What the Implementation Actually Requires
Building with AI tools on projects that have real architectural complexity, the difference between a well-maintained context file and a minimal one shows up immediately. A session starting with solid context about module boundaries, state management patterns, and conventions for how different subsystems interact requires much less back-and-forth to produce usable code. A session with no context produces output that is syntactically correct but disconnected from the project’s actual structure.
The learnings that go into a well-maintained context file come mostly from sessions where the AI got something subtly wrong, and where investigating why produced an insight about what the AI needed to know upfront. Those moments of friction are exactly what Garg’s feedback flywheel is designed to capture and preserve rather than let dissipate.
In a team setting, different developers have different sessions, hit different failure modes, and develop different intuitions. Without a structured practice for sharing those discoveries, the team ends up with knowledge concentrated in whoever has spent the most time with the tools, and everyone else running into walls that person already figured out how to avoid.
The implementation cost is low. A lightweight post-session habit, something like a brief shared note or a direct edit to the project context file, is enough to start the flywheel moving. The harder part is cultural: treating AI session learnings as worth capturing at all, rather than treating each session as a closed, individual event that produced some code and nothing else.
The Compounding Return
What Garg’s series on reducing friction in AI-assisted development identifies clearly is that most teams have invested in the AI tools themselves, and some have built initial onboarding and conventions, but very few have built the feedback loop that makes those conventions evolve with the team’s actual experience. The tools improve. The models improve. The shared artifacts, if they exist at all, stay static.
A feedback flywheel is not a complex system to build. It is a disciplined practice of treating AI session learnings as something worth capturing and sharing, building that practice into the team’s workflow at the right cadence, and maintaining the shared artifacts that make those learnings actionable. The teams that build this practice develop a meaningful compound advantage over time, because each productive session makes future sessions more productive, and that dynamic is not available to teams treating each AI session as a closed, individual event with no residue worth preserving.