Main idea

When a coding assistant proposes an architecture too complicated for the need, skips the tests or puts the business logic in the endpoints, the reflex is to fix it and move on. The fix treats the symptom and leaves its cause intact: nothing had told the tool what the team expected on that precise point.

These failures have a property that makes them exploitable: they are reproducible. Unlike a human error, which comes down to tiredness or one day's inattention, a failed output will replay the same flaw as long as the missing instruction goes unwritten. So every fix that isn't capitalized on gets paid for as many times as it recurs.

The complete gesture has three steps: fix, identify the signal you failed to give, adjust the guidelines. A post-mortem on a botched generation is worth here what a post-mortem on an incident is worth in operations.

Why it matters

This turns a cost centre into a learning mechanism. The energy spent correcting an assistant is spent either way; whether it produces a durable practice depends only on what you do after the fix.

It also restores a trial-and-error loop where the tool had cut it: it is no longer the developer who errs and learns, it is the team gradually making explicit what it considers well done — and that explicitness benefits the team as much as the tool.

Nuances and limits

Not every failed output can be fixed by a guideline. Some come from context you couldn't supply, from a limit of the model, or from a need that wasn't clear on the human side — and writing an instruction in those cases moves the problem without addressing it.

And the guideline file has its own cost: too many accumulated additions make it contradictory, and a team can spend more time maintaining its instructions than it gains from them.

Open questions

• Which failures deserve a permanent guideline, and which are better handled by a one-off fix you accept having to repeat?