Close the Loop

The Step Almost Nobody Adds

Here is how most people use AI to write code. Ask the model for a
change, get the diff, and then review it by hand to find where it went
wrong. The AI produces, the human inspects. That is the whole loop, and
it puts every piece of the model's output in front of a person.

There is one step almost nobody adds, and it changes the economics
completely: give the AI the pipeline's own report and let it fix its
mistakes before a human ever looks. The model wrote the code, the CI
tells it exactly what is broken, and the model corrects itself on the
feature branch. By the time you open the merge request, the obvious
garbage is already gone, because the thing that produced it also
cleaned it up.

The Loop

The shape is simple and it is worth stating plainly, because the value
is entirely in closing a loop most workflows leave open.

The AI writes code on a feature branch, the same as always. The
pipeline runs and produces its usual output: the failing tests, the
linter warnings, the type errors, the security scan findings, the
coverage drop. That report already exists. Every CI run generates it.
In the normal workflow it sits there waiting for a human to read.

Instead, you hand that report back to the AI. It reads its own failures
against the code it just wrote, sees concretely what does not compile,
what test it broke, what the scanner flagged, and it revises. The
branch updates. The pipeline runs again. This repeats until the report
is clean or the model stops making progress, and only then does a human
get involved.

The connection that makes this practical is a way for the model to
actually reach the report, which is what an MCP server or an equivalent
tool integration provides: the model can pull the pipeline results the
same way a developer would open the CI page. Without that link the loop
stays open and you are back to copy-pasting error logs into a chat by
hand.

Why It Works

The reason this is worth building is that a huge fraction of the
mistakes AI makes on code are exactly the mistakes CI is designed to
catch.

A model will confidently write code that does not compile. It will
break an existing test it did not think to run. It will import
something that is not installed, call a function with the wrong
signature, leave a variable unused, trip a linter rule, or introduce
the kind of pattern a security scanner flags on sight. These are not
subtle. They are mechanical, and the pipeline detects every one of them
without a human involved.

In the open-loop workflow, all of those land in your review queue. You
open the diff, you spot the broken import, you leave a comment, the
model fixes it, you review again. You are doing the pipeline's job by
hand, acting as the messenger between the CI that found the problem and
the model that can fix it. Closing the loop deletes you from that path.
The report goes straight to the model, and the mechanical mistakes get
fixed without ever consuming your attention.

What reaches your review, then, is different in kind. It is code that
compiles, passes its tests, satisfies the linter, and clears the
scanner. The remaining problems are the ones that actually need a human:
is this the right approach, does it fit the architecture, is the logic
correct in the ways a test cannot check. That is the review worth your
time. The mechanical review was never worth your time, and now you are
not doing it.

The Honest Limits

This is not a machine that reviews itself into correctness, and
believing that is how you ship confident nonsense.

The loop is only as good as the pipeline behind it. The AI fixes what
the report tells it is wrong. If your tests are thin, your linter is
lax, and you have no scanner, the report is quiet and the model has
nothing to correct against. A green pipeline means the code passed the
checks you have, not that the code is good. Closing the loop raises the
floor to the quality of your CI. It does not raise it any higher, which
is one more reason the CI itself is worth investing in.

It can also loop without converging. A model handed a failure it does
not understand will sometimes thrash, changing things and rerunning
without getting closer, burning pipeline minutes and tokens. The loop
needs a limit: a few iterations, and if the report is not clean by
then, it stops and a human looks. Left unbounded it is a way to spend
money going in circles.

And a passing pipeline is not a merge. The whole point is to move the
human review to where it matters, not to remove it. The model clearing
its own mechanical mistakes means your review is about design and
correctness instead of broken imports. It does not mean the code merges
itself. A human still decides.

The Point

Most AI coding workflows leave a loop open: the model produces, the
pipeline judges, and a human stands in the middle carrying error
messages from one to the other. Close it. Let the model read the CI
report and fix its own mechanical mistakes on the branch before you
look. You review far less AI code, because the model catches its own
garbage first, and what survives to your queue is the code worth a
human's attention.

Build the loop, bound it so it cannot spin forever, and keep your CI
strong, because the loop is only ever as good as the report it feeds
on. The AI wrote the code. Let it read the verdict too.