The bug is fixed. The next change brings it back.
The change is small. Remove a check, simplify the path, make the code faster. Then a retry creates the same order twice, and someone remembers why the check existed.
Your engineers should be able to improve the service and help colleagues understand it. Instead, the person who remembers the incident has to explain why the proposed change would bring it back.
Korium in this storyMemory + Code + Skills + WorkflowsAn illustrative story, not a customer result. No customer is depicted.
Follow the work01What keeps happening
The guard looks unnecessary to someone who never saw the failure.
You lead a software team maintaining an order-processing service. An earlier incident showed that a retried request could create a duplicate order. The team added a check and a regression test.
The incident explanation lives in a review discussion and a closed ticket. Months later, a developer asks a different coding agent to improve the path.
The agent sees an extra check but does not have the history. It proposes removing it. A senior engineer catches the risk in review and has to reconstruct the incident to explain the objection.
- Team fixes duplicate orders
- Reason stays in a closed discussion
- Agent proposes removing the guard
- Reviewer rebuilds the history
02Where we would start
We’d give the agent the reason before it proposes the change.
We’d begin with one incident and the guard it produced. What failed, why was this fix chosen and which test proves the behavior the team wants to preserve?
The first useful improvement is to make that explanation retrievable at the start of the task. More code context alone does not tell the agent why a particular line matters.
03What Korium would keep
Save the failure, the decision and the test that belongs with it.
A connected agent could store this lesson in Korium with references to the incident and reviewed change:
“Retried requests previously created duplicate orders. Preserve the duplicate-prevention behavior when changing this path. Review the incident, the accepted fix and the regression test before proposing a replacement; a faster path still needs to handle retries correctly.”
Source: The incident review, the accepted change and the regression test reference.
04The next person, the next task
The agent can improve the code without treating the old failure as a surprise.
At the start of the task, the connected agent searches Korium memory for earlier decisions. It can also use the code index to locate the relevant implementation in the indexed commit, then verify it against the current checkout.
With the reason and the code in view, it can propose a plan that preserves the behavior, instead of discovering the requirement during review.
A plan based on the saved explanation
- Read the incident and confirm which retry behavior must remain.
- Find the current implementation and the existing regression test.
- Make the change, test duplicate prevention and flag anything still unproven.
05Memory + Code + Skills + Workflows
Which parts of Korium help here?
Memory explains why the guard exists. Code lookup finds the implementation, skills guide the change and tests, and a workflow takes the work through review and saves what the team learned.
- MemoryKorium:mem
Explain why a retry must not create a second order.
Korium:mem keeps the incident, the accepted fix and the reason duplicate prevention must survive the change. It gives the coding agent the history that reading a function alone may not reveal.
- CodeKorium:code
Find the code that implements the guard.
Korium:code points the agent to relevant symbols, files and line ranges in the indexed commit. The agent then checks those locations against the current checkout and reads the implementation before changing it.
- SkillsKorium:skills
Give the agent a repeatable way to change and test the behavior.
We’d load the relevant coding and testing skills, adapted to the team’s standards. Those instructions guide how the agent preserves retry behavior, checks the regression test and reports anything it has not proved.
- WorkflowsKorium:workflows
Connect the investigation, change, review and learning.
The workflow would order the work: read the incident memory, locate the code, use the skills, make and test the change, then bring it to human review. After acceptance, it includes saving the result and why this implementation replaced the earlier one.
06What the team can do next
Experienced engineers can help with the next challenge.
When the team accepts a new implementation, save why it replaced the old one and which tests were run. Keep the original incident linked to that history.
The next agent can distinguish the requirement that still matters from an implementation the team has replaced. It starts from the latest reviewed understanding, not from whichever chat someone remembered to paste.
When the change plan already accounts for the incident, review can focus on whether the new approach is any good. A newer developer can learn from the reason and the test; an experienced engineer can help them make a better change instead of retelling the failure.
How we would check whether it helped
- Review whether change plans account for known failure modes.
- Check whether reviews spend less time reconstructing incidents and more time evaluating the proposed change.
- Check that saved implementation decisions point to tests and identify what remains unverified.
One problem. A useful place to start.
Bring the bug your team never wants to fix twice.
We’d trace it from the incident to the code and the next proposed change. Then we’d connect memory, code lookup and the checks your team already relies on.