Rahul Garg’s concluding piece in his series on reducing friction in AI-assisted development lands on something most teams are quietly experiencing without having named it. The friction he is targeting is not the friction of getting AI tools to work. It is the friction of getting value from AI tools to compound across a team over time. Individual developers get better at working with AI. The team, as a unit, does not.
This is a structural problem, and it deserves a structural answer.
How Individual Learning Fails to Propagate
When a developer spends two hours figuring out how to get Claude or Copilot to reliably generate a certain class of code, they accumulate a kind of tacit knowledge. They know which prompts work, which context to include, which assumptions to make explicit, and which outputs to verify carefully. This knowledge is real and it is valuable. It also lives entirely in their head.
In most team workflows, there is no natural moment where this knowledge surfaces. Code review will catch a bad output, but it will not ask how the prompt that generated it could be better. Standup is the wrong granularity. The retrospective comes too late and at too high a level. The learned pattern dissolves at the end of the session.
This is not a new problem. Tacit knowledge has always been hard to move between people. What is new is the rate at which AI-assisted development generates it. A single afternoon of prompt iteration can accumulate more workflow-specific insight than a week of ordinary development. The firehose is faster than our existing knowledge-management practices can handle.
Garg’s feedback flywheel concept is essentially an argument for making this a deliberate, recurring practice rather than an accident. You schedule time to harvest what you learned, you commit it somewhere shared, and you feed it back into the next session’s starting context. The flywheel metaphor is apt: the first rotation is the hardest, and the value compounds as the artifact improves.
What “Shared Artifacts” Actually Means in Practice
The phrase “shared artifacts” can mean many things, and the implementation details matter more than the principle.
The most lightweight version is a prompt library. A directory in the repository containing .md files with prompts that work for specific, recurring tasks: generating migration scripts, writing test cases for a particular module, reviewing a class of configuration changes. This is low friction to maintain and immediately useful. The problem is that prompts degrade. A prompt that works well against a particular codebase state becomes less reliable as the codebase evolves, and nobody has a natural incentive to go back and update it.
A more durable artifact is a conventions document. If your team has settled on how to instruct the AI about your domain model, your naming conventions, your error-handling patterns, that can be codified once and referenced consistently. Many teams working with Claude Code are already doing this informally with a CLAUDE.md file at the repo root. Anthropic’s tooling is explicitly designed to pick that file up and use it as persistent context. The same pattern applies to Cursor’s .cursorrules and similar conventions in other tools. The difference between doing this deliberately and stumbling into it is whether you update it with intent after learning something new.
The most ambitious version is something closer to a feedback ledger: a structured log of what worked, what did not, and what the team decided to change as a result. This is the retrospective applied at a finer grain. Done well, it creates an audit trail for your team’s evolving relationship with AI tooling and provides raw material for onboarding new team members into that relationship.
The Retrospective Analogy and Where It Breaks
Garg’s approach has a lot in common with the Agile retrospective, and that is both its strength and a signal of where it might struggle. Retrospectives work when teams are disciplined enough to run them consistently and honest enough to say what is actually not working. Many teams are neither, for structural reasons that have nothing to do with individual intentions.
Feedback that flows from AI sessions has an additional challenge: it is often ambiguous. Did the prompt fail because it was written poorly, or because the model has a genuine weakness in this domain, or because the context window was missing something important? Disentangling these takes more care than noticing that your deployment process is slow. There is a risk that feedback gets logged at the wrong level of abstraction and becomes noise rather than signal.
The discipline Garg is proposing requires that developers pause after productive AI sessions and ask not just “did I accomplish the task” but “what did I learn about how to work with this tool in this context.” That is a different mode of attention, and it is not natural in environments where delivery pressure is high. The flywheel only works if someone keeps giving it the first push.
Connecting Individual Sessions to Collective Infrastructure
The teams that get this right are treating their AI tooling configuration as living infrastructure. Not a one-time setup, but something that gets maintained with the same care as the test suite or the CI pipeline. New patterns get added. Old patterns get pruned when they stop working. There is ownership.
This framing changes the economics of the feedback practice. Instead of asking “do we have time to document what we learned,” the question becomes “do we have time to let the infrastructure degrade.” The answer to the second question is usually clearer.
There is a useful parallel in how mature teams handle incident retrospectives. The value of a blameless postmortem is not the meeting itself; it is the action items that get merged into runbooks, alerting configurations, and deployment checklists. The knowledge gets encoded into the system so it does not have to live in someone’s memory. Garg’s feedback flywheel is asking for the same treatment for AI-assisted workflow knowledge.
In practice, this might look like a brief session-end ritual: a developer spends five minutes writing one or two bullet points about what changed in their approach today. Once a week, someone takes those bullets and integrates the useful ones into the team’s shared context files. Once a month, the conventions document gets a review pass. The overhead is low if the practice is consistent. The overhead is high if it accumulates in arrears.
The Adoption Curve Problem
One thing the flywheel framing does not fully address is the adoption curve within a team. AI fluency varies widely. The developer who generates most of the learnable insights is often the one who is already most experienced with the tools. The developer who would benefit most from a well-maintained prompt library is often the one least equipped to contribute to it. This is not a reason to abandon the practice, but it is a reason to think carefully about who owns it.
A deliberate feedback flywheel probably needs a steward, at least in the early stages. Someone who asks the right questions in the right forums, who has a feel for what is worth extracting versus what is too context-specific to generalize, and who is willing to do the unglamorous work of keeping the shared artifacts coherent. As a practice matures, the maintenance can distribute. But assuming it will be collective from day one is usually how it dies from day two.
Garg’s series has been a useful corrective to the assumption that AI adoption in development teams is primarily a tooling problem. It is at least as much a practice problem. Getting the tools installed and the API keys configured is the easy part. Building team habits that make the tools compound in value over time is the harder work, and it is the work that most teams have not yet started.