Rahul Garg at Thoughtworks talks about the Feedback Flywheel, a practice that encourages paying attention to signals in AI engineering that can be used to continuously improve the AI engineering setup and workflows to get better outcomes. Not at a personal level but at the team level.
Every AI interaction generates signal: prompts that worked, context that was missing, patterns that succeeded, failures worth preventing. Most teams discard this signal. I propose a structured feedback practice that harvests learnings from AI sessions and feeds them back into the team's shared artifacts, turning individual experience into collective improvement.
Anyone who has used AI when building software has felt all kinds of frustration when it's not doing what you expect, and what seemingly should be obvious.
Every interaction like this is a signal that the LLM hasn't been primed sufficiently with the right information or instruction for the task or workflow. At this point one could start instructing and steering the LLM right there and then with prompts to get a better result. But it will likely need to be repeated again later.
The idea with the Feedback Flywheel is to pay attention to these, ask what went wrong and what can be improved so next time it works better. Not just for yourself but for anyone on the team working on the project. And then taking steps to bake these in so the next encounter of that situation works better, and broadly for everyone.
Adopting AI practices can plateau once everyone gets comfortable.
With AI coding assistants, most teams reach a plateau. They adopt the tools, develop some fluency, and then stay there. The same prompting habits, the same frustrations, the same results month after month. Not because the tools stop improving, but because the team's practices around the tools stop improving
Worse than this, when every developer on the team is encountering their own flavours of these issues, and each has their own level of skills, prompting style, local setup and even different AI tools, what you can and likely will quickly end up with is snowflake pull requests of wildly varying style and quality.
All of this is signal that should be used to continuously make adjustments to the context and knowledge the LLM is primed with. These can be done in various ways, like adding specific content to the agent specific files (AGENTS.md, CLAUDE.md etc), well structured and discoverable context in additional markdown files, agent skills and custom commands.
These benefits will quickly start to compound and result in better outcomes across the team and improve the quality of the codebase and the pace at which things can be delivered with a high level of quality.