A reviewer writes: we do not use raw SQL here, use the repository pattern. The change gets made, the pull request merges, and everyone moves on. Next week a similar task produces the same mistake, and someone writes the same comment.
That is not a model problem. It is a memory problem, and for a while it was ours too. We reflected on what a run had learned about a codebase, but only on the first attempt. When a human sent work back, the correction was applied and then discarded.
Why the review is the valuable signal
A failing test tells you something broke. A reviewer telling you the approach is wrong for this codebase tells you a rule, and rules generalise. That is the difference between fixing one pull request and not making the mistake again.
So we now distil reviewer comments into durable rules attached to the project. The next task starts already knowing them.
Only when a person actually spoke
The obvious mistake would be learning from every iteration. A flaky test or a lint nit teaches nothing durable, and storing it would dilute the rules that matter until none of them carry weight.
So the learning step runs only when a human left a comment. A continuous-integration failure is fixed and forgotten, which is the correct outcome for it.
What we deliberately do not do
We do not let the model rewrite its own rules unattended. The distilled rules are visible in the project, and you can edit or remove any of them. A rule learned from a misunderstanding would otherwise steer every future task, quietly, and nobody would know where it came from.
The test of it
The question is not whether the tool writes good code today. It is whether the second month is better than the first. If your team is still leaving the same review comments in week eight, the tool is not learning and no amount of model capability fixes that.