The Compounding Problem

My impression is that teams adopting AI tools at roughly the same time can arrive at very different places six months later. The difference often lies less in talent or tooling than in whether they have a practice of capturing what worked.

Without a learning system, AI effectiveness flatlines. The team uses the tools. The tools are useful. But the way the team uses them does not evolve. The same gaps in the priming document cause the same corrections. The same ambiguous instructions produce the same mediocre outputs. The same failure patterns recur without anyone connecting the dots. What is missing is not effort — it is a mechanism for the effort to accumulate.

These artifacts create surfaces for learning. But surfaces alone are passive. A priming document does not update itself when the AI defaults to a deprecated API. A review command does not add a new check when a category of bug slips through. They need an active practice of feeding learnings back in.

Consider what a single session can look like when the loop is in place. A developer uses a generation instruction to implement a new service endpoint. A review instruction then runs on the output — and flags a missing authorization check, exactly the kind of oversight the generation instruction did not explicitly require. The developer fixes the issue and, before closing the session, adds one line to the team's learning log: Authorization checks on new endpoints not enforced by generation instruction. That file lives in the repository and is already part of the priming context for subsequent sessions. The next developer to implement an endpoint benefits from that observation without knowing the exchange happened; the authorization check is now part of what the AI verifies from the first pass. The generation instruction did not change. The priming context changed. The system learned. That is the flywheel: each rotation of the loop leaves the infrastructure a little better prepared for the next.

Commands evolve: when a review command misses something, it is a command waiting to be updated. The same principle applies to every artifact in the team's AI infrastructure: each should evolve based on what the team observes in practice. The question is how to make that evolution systematic rather than accidental.

The update itself can happen in different ways. Sometimes a developer edits the shared artifact directly, especially when the change requires judgment or careful wording. In other cases, an agent can draft or apply the update as part of the workflow, with a developer reviewing it before it becomes part of the team's shared context. I would not make one mechanism mandatory. What matters is that the learning is captured, validated, and fed back into the artifacts the team actually uses.

Four Types of Signal

AI interactions generate signal: information about what the team's artifacts capture well and what they miss. I find it useful to categorize this signal into four types, each mapping to a specific destination in the infrastructure.

Context signal. What the AI needed to know but did not: gaps in the priming document, missing conventions, outdated version numbers. Each correction a developer makes is a signal that the priming document is incomplete. When the AI keeps using the deprecated Prisma 4.x API, that is not a model failure; it is a priming gap. The version note is missing, so the AI defaults to its training data. Every “no, we do it this way” is a line that belongs in the priming document but is not there yet.

Instruction signal. Prompts and phrasings that produced notably good or bad results. When a particular way of framing a request consistently yields better output (a specific constraint that prevents the AI from jumping ahead, a decomposition that produces cleaner architecture) that phrasing belongs in a shared command, not in one developer's head. Instruction signal is the difference between personal fluency and team capability. As long as it stays personal, the team's effectiveness depends on who happens to be prompting.

Workflow signal. Sequences of interaction that succeeded: conversation structures, task decomposition approaches, workflows that reliably produced good outcomes. These are the team's emerging playbooks. A developer who discovers that designing API contracts before implementation consistently produces better results has found a workflow pattern. A developer who finds that asking the AI to critique its own output before proceeding catches issues earlier has found another. These workflow patterns, once identified, are transferable, but only if someone captures them.

Failure signal. Where the AI produced something wrong, and why. The root cause matters more than the symptom. A failure caused by missing context is a priming gap. A failure caused by poor instruction is a command gap. A failure caused by a model limitation is a boundary to document. With root-cause thinking, each failure points to a specific artifact that can be improved. Consider a developer asking the AI to generate a domain model. The output compiles — but on review, the domain objects are nearly anemic: data containers with all behavior pushed into service classes. It is neither a context failure nor a model limitation: the AI knew the project's bounded contexts and is capable of generating rich domain models. It is a command gap: the generation instruction never specified that behavior belongs in the domain objects, not in the classes around them. A single constraint added to the generation instruction is the fix.

The mapping is concrete. Context signal feeds back into priming documents. Instruction signal feeds back into shared commands. Workflow signal feeds back into team playbooks. Failure signal feeds back into guardrails and documented anti-patterns. The feedback loop has specific inputs and specific destinations; it is not an abstract aspiration to “get better at AI.” Not every observation clears the bar: one-off edge cases and personal style preferences stay personal. The signal worth capturing is one that recurred, or that any developer on the team would hit working on the same problem. It is a practice of updating particular artifacts based on those observations.

The Practice

The feedback loop works at four cadences, each matched to the weight of the update.

After each session: a brief reflection, not a formal process. One question: did anything happen in this session that should change a shared artifact? Often the answer is no. The session went fine, the priming document had what the AI needed, the commands caught what they should catch. When the answer is yes, the update is immediate: a line added to the priming document, a check added to a command, a note in a feature document. The discipline is in the question, not in the overhead. The act of asking takes seconds. The act of updating, when warranted, takes minutes. The easiest way to establish the habit is to anchor it to an existing checkpoint: a field in the PR template, a single line in the standup, or the act of closing the editor at end of day. The trigger matters less than the consistency.

At the stand-up: for teams that already have a daily stand-up, this is a natural place to spread useful learning quickly. A simple question such as “did anyone learn something with the AI yesterday that the rest of us should know?” can turn one person's discovery into shared practice without adding another meeting.

At the retrospective: an agenda item in the existing sprint retrospective: what worked with AI this sprint? What friction did we hit? What will we update? The outputs are concrete: a priming document revision, a command refinement, a new anti-pattern documented. This is where individual observations become team decisions. One developer's discovery that a particular constraint improves code review output becomes the team's updated review command. The tech lead or a designated owner makes the final call on what gets committed to shared artifacts; the retrospective is the forum for surfacing options, not for reaching consensus on every detail.

Periodically: a review of whether the artifacts are actually being used and whether they remain current. Which commands are being run? Which are ignored? Where are the remaining gaps? This is the lightest cadence, quarterly, or when the team senses that the artifacts have drifted from practice.

The practice is lightweight by design. The heaviest cadence is a five-minute agenda item in a meeting that already exists. If the practice requires its own meeting, it will be the first thing cut when the team is busy — which is precisely when learning matters most.

Knowing the practice is running is different from knowing it is working.

Measuring What Changes

Most teams that try to measure AI effectiveness measure the wrong things. Speed (lines generated, time to first output) measures volume, not value. A fast output that requires extensive rework is not a productivity gain. It is rework with extra steps.

What actually matters is harder to measure but more informative: first-pass acceptance rate (how often the AI's initial output is usable without major revision), iteration cycles (how many back-and-forth rounds a task requires), post-merge rework (how much fixing happens after code ships), and principle alignment (whether the output follows the team's architectural standards). These are the indicators that the feedback loop is working: the team's artifacts are capturing more of what the AI needs, and the AI's output is converging toward what the team expects.

For teams already tracking DORA metrics, these indicators can serve as useful leading signals. Fewer iteration cycles usually mean less rework per change, which in turn helps shorten lead time. Higher principle alignment means architectural drift is caught earlier, before it reaches production, which should reduce the change failure rate. The feedback loop is not a separate initiative so much as a way of improving the outcomes the team already cares about. If DORA metrics are not yet part of the practice, a simpler proxy will do: how often does the team say “the AI knew exactly what to do”? Tracked informally, that frequency gives an early indication that the artifacts are helping before the broader delivery metrics move.

The honest framing: these metrics are difficult to track rigorously. Counting iteration cycles requires a consistent definition of what constitutes a “cycle”; that definition varies by task complexity. First-pass acceptance is a judgment call, not a binary. In practice, the signal is often qualitative. The team notices that AI sessions are smoother, that commands catch more issues, that new team members ramp up faster with the priming documents and playbooks than they did without them. The absence of frustration — the declining frequency of “why did the AI do that?” — is often the most reliable indicator. I would not recommend building a dashboard. I would recommend paying attention.

Calibration

This practice matters most for teams that have already established the foundational infrastructure from the earlier articles and want to move from “we use AI” to “we get better at using AI.” For teams still in initial adoption, the priority is building that infrastructure first. The feedback loop that improves it comes after.

The trade-off is discipline without bureaucracy, a narrow path. Too formal, and the practice becomes overhead that gets abandoned within a quarter. Too informal, and it is indistinguishable from not doing it at all. The after-session question, the retrospective agenda item, the periodic review — these are deliberately minimal. The rhythm matters more than the rigor. A team that asks “what should we update?” every two weeks and acts on the answer will improve faster than a team that designs an elaborate harvesting process and abandons it when deadlines tighten.

There is an urgency to this that is structural. The AI ecosystem (models, tools, capabilities) evolves on a cadence that makes traditional documentation decay look glacial. A priming document written when the team adopted one model version may actively misguide when a newer version handles context windows differently. A command designed around one tool's strengths may miss capabilities introduced in the next release. This is the same dynamic teams already understand with dependency management: a lockfile that is never updated does not stay stable, it becomes a liability. These artifacts deserve the same treatment: reviewed periodically, maintained with the same discipline as test suites, not written once and filed alongside onboarding checklists. The teams that treat them as living infrastructure will compound. The teams that treat them as setup documentation will plateau, not because they started wrong, but because they stopped maintaining.

The feedback loop has nowhere to go without the artifacts it improves — start with those.

Conclusion

What distinguishes a team that merely uses AI from one that gets better with it is not the model. It is whether the team has a way to turn each interaction into a small improvement in its shared artifacts. That is the role of the feedback loop. It takes what would otherwise remain personal intuition - a prompt that worked, a failure that recurred, a missing convention, a review gap - and makes it part of the team's infrastructure.

This is why I see the feedback flywheel not as an extra practice layered on top of the others, but as the maintenance mechanism for all of them. Knowledge Priming drifts unless someone updates it. Design-First Collaboration improves only when teams notice what structure helped. Context Anchoring gets better when teams see what they failed to capture. Encoding Team Standards> sharpen when failures expose missing checks. The infrastructure compounds only if practice feeds back into it.

Taken together, these techniques describe a way of working with AI that mirrors how good teams work with each other: share context early, think before coding, make standards explicit, externalize decisions, and learn from each session. The tools will keep changing. The teams that continue learning through shared artifacts and lightweight rituals will be the ones that get more value from them over time.

I would not begin with all of this at once. I would begin with one shared artifact and one habit: at the end of a session, ask what should change for the next one. Then make that change while the lesson is still fresh. That is small enough to sustain, and small steps are what make the flywheel turn.