The agent fixed the change. But what did the next agent get from that feedback?
Coding agents learn from review feedback when a useful correction becomes something the team can reuse. A missing relationship goes into shared context. A missed failure becomes a test. A repeated way of checking work becomes a skill. Then we need to see whether the next relevant run uses it.
This does not require retraining the model. It means improving the setup around it.
What happens after the reviewer catches the issue?
Consider an illustrative change to an invoice export. The API sends a new payload, but the background worker still expects the old one. The tests in the API repo pass. The export fails when the services run together.
The reviewer points out that the worker was missed. The implementation agent fixes the payload, and QA runs the flow again.
That solves the current change.
But if we stop there, the next session can miss the same worker. Someone has to explain the relationship again.
I described a similar boundary failure in my earlier software-factory account. One service emitted created_at, while the consumer expected createdAt. The integration check caught the mismatch. Local checks had not exercised the shared boundary.
The useful learning is what we retain after catching it.
Put the correction where it belongs
For the export example, we should first understand why the worker was missed.
If the agent did not know the worker consumed the event, correct that relationship in the shared context, with a source and owner. If the relationship was already there but never reached the agent, look at retrieval.
If the agent knew about the worker but skipped the check, improve how it plans verification. A skill for event changes can tell it to find producers and consumers, check their contracts and verify the affected interaction. A contract test can catch the known mismatch.
If the check was planned but the worker could not start, fix the sandbox setup.
The same feedback can point to different problems. Adding “always check downstream services” to the prompt will not repair a broken environment.
The change impact guide explains how to connect those dependencies to the checks a change needs.
Shared context and skills should improve together
The context tells the agent which worker consumes the event. The skill tells it how to handle that kind of change.
Both need to be available to the relevant agents. If the implementation agent learns something but QA still works from an older contract, we have moved the problem into the handoff.
This is why I think learning belongs in the delivery system around the agents. Humans and agents need a common place for the decisions, relationships and practices they will reuse.
That does not mean saving every conversation as a permanent instruction.
I have written before about instruction bloat. Every issue adds another rule, and soon nobody knows which file owns what. Some corrections should replace old guidance. Others belong in a test or a specific skill. A one-off reviewer preference may need clarification before it becomes a team rule.
For the code itself, review responsibilities and integration boundaries so repeated corrections improve the structure the next engineer will work with.
Keep the source and scope with the lesson, and have the responsible owner review it. When the contract changes, the old guidance needs to change too.
Did the next run need the same correction?
For the export example, I would look at the next change that touches the same event.
Did the agent find the worker? Did it include the contract check? Could QA run it? Did the reviewer have to explain the relationship again?
If it failed again, ask where the loop broke. Was the retained fact wrong, was it never supplied, or did the agent receive it and still miss the check?
One successful run does not prove the setup will always work. But it gives us something concrete to inspect. Over comparable changes, we should look for fewer repeated interventions and less rework, while still checking the quality of the result.
This is the learning loop I want from Prinevo. Feedback should improve the shared context, skills and verification around the agent team, so the next change needs less repeated explanation.
Take one correction your team keeps making. Follow it into the next relevant run. The real-change scorecard can help you assess the human effort and evidence together. That is more useful than counting how many notes the agents saved.