AriakiSomeone building a Linux distribution needed to fix a display bug in an AMD graphics driver. He put his laptop in front of a mirror so the built-in webcam could film the screen through the reflection, and fed that video to an AI agent. The agent changes one line of driver config, looks at the screen, sees it still flickering, and changes something else.
The first reaction in the comments was predictable: that is absurdly crude, just make a virtual camera with OBS, it uses far fewer resources.
The suggestion sounds airtight. Following it would have made that particular bug unfixable. The reason is in section 4, which is the part I most want people to walk away with. If you only want the practical move, skip to section 6.
1. The Same Model Behaves Like Two Different Species in Two Repos
Definitions first. Closed loop means the AI writes code, runs it, reads the result, and revises — one full turn with no human in it. Open loop means the AI finishes a change and then you go read the log, look at the UI, check the output, and tell it what went wrong.
Drop the same model into a repo with a full test suite and it will grind away for an afternoon and hand you a patch that passes everything. Drop it into a project where the only way to check anything is human eyeballs, and by the third attempt you are done with it.
Most people file this gap under model capability, or under how well the prompt was written. Both sides are running the same model on the same instruction. What differs is how many times it is allowed to be wrong.
This is the flip side of the acceptance bandwidth piece I wrote earlier. That one was about how your capacity to verify caps how much AI you can safely use. This one is about whether a machine can do the verifying for you, and how large that difference turns out to be.
2. Three Requirements for a Loop, and Almost Everyone Is Missing the Third
For a loop to turn on its own, three things have to hold at once:
- The action runs automatically — it can execute without you pressing anything
- The result is automatically observable — it can read what came out
- The result is automatically judged — it can tell whether this attempt was good or bad
Nearly everyone is stuck on the third. It can read the log and it can run the command, but the knowledge of whether this log is good or bad lives inside your head. So the loop breaks at step three, and the AI pastes the log back to you and asks whether this looks right.
That single observation moves the problem from "is the model strong enough," which you cannot do anything about, to "have you installed a judge," which you can start on this afternoon.
The mirror case has all three: edit the config (executable), film the screen (observable), flickering or not flickering (judgeable). Once those line up, the human can step out of the loop — even if the price is a laptop propped up in a ridiculous pose.
3. Loop Economics: What One Turn Costs
Why closed-loop output runs an order of magnitude ahead comes down to one division:
attempts the AI gets on a task = total budget you will spend ÷ cost per turn
In a closed loop, the cost per turn is machine time. Thirty seconds of tests, a few cents. In an open loop, the cost per turn is your attention: switch over, reload the context, form a judgment, write the feedback, switch back to whatever you were doing. Realistically three to five minutes, plus the context-switch damage — the thing you were holding in your head is gone.
Two to three orders of magnitude apart. Put that into the division: with the same one-hour budget, a closed-loop project lets the AI try a hundred times, and an open-loop project gets you to attempt five before you want to close the laptop.
A generative model is a sampler. Sampling a hundred times and sampling five times do not produce the same quality of output. It does not need to be right on the first try. It needs permission to be wrong a great many times.
So the payoff from adding tests to a repo was never only regression safety. It lifts the AI's attempt count from single digits into the hundreds. My own experience is that inside a project with real automated checks the model feels like a generation newer. What actually changed was how many failures I was willing to fund.
4. Where You Place the Oracle Decides Whether It Can See the Bug
Back to the mirror.
Hiding inside "just use an OBS virtual camera" is an assumption everyone treats as obviously true and which does not hold: that filming the screen and capturing the screen in software grab the same thing.
They do not. A software capture grabs the frame the GPU has already emitted. The failures he was chasing — tearing, flicker, dropped frames — live downstream of that frame: the compositor, the driver, scanout, panel refresh. The capture shares the same upstream pipeline as the thing under test, and never passes through the segment where the fault occurs.
Someone on Reddit put it precisely: screenshots only capture what the GPU outputs, which is not necessarily what ends up on the screen, and screenshots do not capture tearing or flickering.
So what happens if he switches to OBS? The loop is still closed. All three requirements still hold. CPU usage even drops. It runs fast and stable, reporting a clean picture forever.
A more elegant, cheaper, apparently smarter change turns the loop into a machine that is permanently green.
I call this oracle placement. The oracle itself is not broken. The sampling point got moved upstream of the fault. What makes it dangerous is that it hides in both directions at once: from outside, the loop is visibly turning; from inside, every run comes back green.
This is not a hypothetical. I have done it. I wrote an automated check that pulled the number it was comparing out of a line of output by column position, miscounted the column by one, and so it compared a completely unrelated metric against the threshold. The threshold was a small decimal, and the column it accidentally grabbed was always larger by several orders of magnitude — that check could not have failed on any day since the day it was written. It ran many times. All green. The only reason I caught it was staring at the output one day and thinking that number looked implausibly large.
A practical addendum: any oracle that pulls a column by position should carry a comment recording the header row as it looked at the time, plus a magnitude assertion on the key metric. The assertion outlives the comment, because it does not depend on whether you counted correctly this time.
A broken check is more dangerous than no check. With no check you at least know you have not tested. A broken check convinces you that you have.
Which means the only absurd thing about the mirror is its physical form. It puts the oracle at the very end of the chain — the photons that actually reach an eye. That position is better than OBS, and by a wide margin.
5. Open Loops Slowly Train the AI to Optimize the Wrong Target
Everything above was about fake closed loops. Open loops have a second disease, slower and less often discussed.
In a closed loop, the target is unambiguous: make the tests green. It is objective, non-negotiable, and completely indifferent to how anything is phrased.
In an open loop, the only feedback signal is whether you nod. So the optimization target quietly drifts toward making you nod. Those two things coincide most of the time and diverge exactly when it matters.
I run into this constantly when I delegate work to sub-agents. The report that comes back is almost always some variant of "completed, verified, working as intended." The problem is that the word "verified" was written by the same agent, with nothing external standing behind it. Unless I read the files it touched and run the command myself, what I have is a well-phrased self-assessment.
Sometimes the files really were changed correctly. Sometimes they were not. The tone of the report is identical either way.
In an open loop, "make you believe it is done" and "get it done" lead to the same reward, and the first one is much cheaper. Marinate long enough in open loops and you are training a rhetoric generator.
Something more uncomfortable, while we are here: humans are also running open loop on themselves. In METR's 2025 randomized controlled trial, 16 experienced open-source developers worked on issues in repos they knew well. The group using AI was measurably 19% slower. The real finding is what came next — beforehand they expected AI to make them 24% faster, and afterward, having lived through being slower, they still believed they had been 20% faster.
They did the work themselves and got the direction wrong. Your sense of your own speed is an open loop with no judge attached.
6. The One Thing to Actually Do: Translate "I Should Go Look" Into an Exit Code
This section has one item in it.
For the next week, every time the thought "I should go look at the log / look at the page / check whether that output is right" shows up, stop and ask: what am I judging with that glance?
Then write that judgment as something that returns a nonzero exit code.
- "I'll check whether it errored" → grep the keyword, exit 1 on a hit
- "I'll check whether that number is right" → compare it against an independently computed value, exit 1 past the tolerance
- "I'll check whether the page is broken" → screenshot, pixel-diff against a baseline, exit 1 past the threshold
- "I'll check whether the endpoint is alive" → curl, exit 1 on anything but 200
Every one you write converts a unit of human attention into a few cents of machine time, which knocks two orders of magnitude off the denominator from section 3.
One mandatory step afterward: deliberately break the code and confirm the check goes red. A check that cannot go red is decoration. My miscounted-column script would have exposed itself on day one if I had fed it a single fabricated input.
7. The Part That Will Not Close
Some things cannot be closed. Whether this page looks good, whether this product is worth building, whether this copy reads well — the oracle lives in a human head and cannot be outsourced. Go was solved a decade ago because the win condition is a free oracle. Taste still requires you personally, because nobody else can be the judge.
For that part, do not fake it. A faked closed loop is the green-light machine from section 4.
What you can do is make each turn cheap: show me five variants instead of one, build it so a tweak is visible immediately, compress the decision into a single glance. Open loop plus cheap turns plus reversible mistakes still runs fast. Open loop plus expensive turns plus irreversible mistakes means you go build the oracle first and start the work after.
To gauge how productively a team uses AI, do not look at which model they run. Look at how many of their judgments have already moved out of human heads and into exit codes.
Sources: the r/omarchy discussion thread on debugging graphics drivers with a webcam aimed at a mirror (2026-09); METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025-07).