Every time Claude does something wrong, that is data. Most people sigh, fix it manually, and move on. They absorb the friction. The same mistake happens tomorrow, and the day after, and the day after that.
The method is different: capture that friction immediately, at the moment it happens. Five seconds of effort now saves hours over the lifetime of a project.
The /feedback pattern
Here is the pattern I use. Claude makes a mistake — uses a default export where my project uses named exports, or imports from a deep path instead of the package's public API. Instead of just correcting it, I type something like:
remember: this project never uses default exports for utility functions. Always use named exports.
Claude saves this to its memory. Next session, next week, next month — it remembers. The friction never happens again.
This is the /feedback pattern. Every friction point becomes a correction. Every correction becomes persistent knowledge. The system gets smarter every time something goes wrong.
Why "as it happens" matters
Timing is everything here.
If you wait until the end of the session to write down what went wrong, you will forget half the issues. The small ones — the slightly wrong import path, the unnecessary type assertion — those slip away. They felt minor in the moment but they compound.
If you batch feedback into a weekly review, you will forget 90%. You will remember the one major issue that broke the build but not the dozen small frictions that slowed you down all week.
Capture in the moment. The friction is fresh. The context is right there. You know exactly what went wrong and exactly how to phrase the correction. It takes five seconds. Do it now or lose it forever.
The three feedback channels
Not all feedback belongs in the same place. There are three channels, and each serves a different scope.
Immediate correction
Tell Claude right now, in the conversation. "No, use X instead of Y." This fixes the current session but does not persist. Use this for one-time corrections that are specific to the task at hand.
Memory
Save to Claude's auto-memory for future sessions. "Remember: this project uses Tailwind v4 with the new CSS-based config." This persists across sessions for you personally. Use this for personal preferences and project-specific knowledge.
CLAUDE.md update
Add a permanent rule to the project's CLAUDE.md. This persists for everyone who works on the project — including other developers and CI pipelines. Use this for project rules and anti-patterns.
Which channel for which feedback
The decision is straightforward:
Personal preference — use memory. "I prefer functional components over class components." This is about you, not the project.
Project rule — use CLAUDE.md. "Never import @jd/db/server in client components." This is about the codebase. Anyone working on this project needs to know it.
One-time correction — just say it. "That function already exists in utils, don't create a duplicate." This is about the current task. It does not need to be remembered.
The mistake I see most often: people put everything in CLAUDE.md. Personal preferences, one-time corrections, things that are obvious from the code. CLAUDE.md is expensive — every line costs context budget every session. Be selective.
Continuous learning: the instinct pattern
There is an advanced version of this pattern that I want you to know about, even if you do not implement it immediately.
Instead of manually capturing every friction point, you can set up a system where Claude evaluates each session for extractable patterns. At the end of a session, a Stop hook parses what happened — what errors occurred, what corrections you made, what workarounds were needed — and extracts observations.
These observations become "instincts" with confidence scoring. A new instinct starts at 0.3 — tentative, maybe a coincidence. Each time the same pattern is confirmed, the confidence increases. At 0.6 it is probable. At 0.9 it is near-certain.
The system is project-scoped. An instinct learned in one project does not bleed into another. But if the same instinct appears in two or more projects with confidence above 0.8, it auto-promotes to global. That is how personal knowledge evolves organically.
Observation: "User corrected default export to named export" -> Pattern detected: "This project prefers named exports" -> Instinct created: confidence 0.3 (tentative) -> Confirmed 3 more times: confidence 0.8 (established) -> Same pattern in second project: promoted to global instinct
The pipeline flows: observations lead to pattern detection, pattern detection leads to instinct creation, and instincts evolve into concrete artifacts — skills, commands, or even dedicated agents.
Advanced implementations store instincts in a structured format — YAML with the pattern name, confidence score, project scope, and the correction that should be applied. This makes instincts searchable, mergeable, and exportable. You can share instincts between projects, promote high-confidence instincts to global scope, and even version them alongside your code.
You do not need to build this today. But understand the direction: feedback is not a one-time action. It is a system that compounds.
The feedback loop is the difference
Without a feedback loop, you have a static tool. You correct the same mistakes every session. The agent never learns. Your workflow plateaus after week one.
With a feedback loop, you have an evolving system. Every mistake makes the system smarter. Every friction point you capture is a friction point that disappears forever. After three months, the agent knows your codebase, your preferences, and your anti-patterns better than a new team member would.
This is what separates people who think AI coding tools are "neat but limited" from people who ship entire features with them. The tool is the same. The feedback loop is the difference.
Start capturing friction today. Not tomorrow. Not in a weekly review. Right now, the next time Claude does something slightly wrong. Five seconds. That is all it takes.