Lessons From Running a Swarm of Agents

Why agents skip steps, and what to keep in mind when you start something with a swarm of them, while it runs, when it gets stuck, and when you change your mind about what you wanted. From weeks-long projects with anywhere from five to fifty agents working at once.

“Knowledge is knowing a tomato is a fruit; wisdom is not putting it in a fruit salad.”

Miles Kington

After several months of using armies of agents to reverse engineer software, build servers and emulators, make games, write every utility I’ll ever need, work through a decade-long backlog of projects, and rebuild my entire home server setup, alongside building the infrastructure for the agentic work itself, this is some of what I’ve learned.

This post is about getting better results from agents on larger projects, the kind that run for weeks with anywhere from five to fifty agents working at once on research, investigation, and building in parallel, not one agent and a button: the things I’ve found worth keeping in mind when I start something, while it runs, when it gets stuck, and when I change my mind about what I wanted, which on a long project I always do. The first half is why agents skip steps. If you already believe an agent can’t see your machine, skip to part two.

Part one: why the gap exists

What stays in your head

All of it current, none of it written down.

When you work on something, you carry a model of it, whether you know the thing well or not. If you know it, the model is full of specifics: which services are up, what you changed an hour ago, which tests are flaky, what the data usually looks like. If you don’t, you carry a model of what you think it looks like, right or wrong, and you make assumptions off that instead. Outside code it’s the same. You know the chart came from last month’s spreadsheet, and that the sound stopped after you plugged in the new monitor.

It isn’t only facts. The model is also what you expect: this call is fast, that service drops connections under load, the build takes four minutes, the cache is probably stale. You run on those assumptions without noticing they’re assumptions, right or wrong, and most problem-solving is comparing what happened to what you expected and chasing the difference.

You check your work against that model all the time without thinking of it as checking: a glance at a log, a quick run because something looks off. The model is often wrong, which is why you also keep notes, open a debugger, and ask a coworker. But the tracking and the checking happen whether you plan them or not.

In my last post, an agent found a bug in Parasol Stars by running the original ROM twice with one change and comparing memory frame by frame. I only looked because I happened to play that room in the remake and it felt wrong: harder than I remembered, in a way that didn’t seem intentional. I had no proof, just a guess that something was off, and I made a bet on it. That guess came out of the model in my head, not out of the repo.

We take that model for granted, and most of us aren’t good at turning it into something written down. It’s intuition, and intuition is hard to transcribe into an actionable plan; it’s the same reason people who are great at a thing are often bad at teaching it. So when we delegate, the model stays where it is. Look at how people write tasks for agents:

• Port this game to Godot and make the enemies feel like the original.
• Map the security posture of this scope and tell me what matters.
• Fix the audio skip at the start of stage 3.
• Automate the weekly numbers report.
• You are a senior engineer at a top FAANG company who never makes mistakes… blah blah blah.

Each one names an outcome. None says what the current state is, what would count as right, how anyone would know, or how to tell halfway through that it’s on the right track. The person writing it knows a lot of that: which emulator setting is the real one, which findings are worth a weekend, what the skip sounds like, which column is always wrong on Mondays. Some of it they’d say if asked. Some of it they’ve never put into words. They know what they want, and that’s what goes on the card.

The setup I actually play on never makes it onto the card.

An agent can’t look unless you gave it something to look with. So the request gets the change, and the facts and the checks stay with you. Working well with agents means handing those over too: the current state, written down, and a way to check results that the agent can run.

The context window is all it has

The agent has none of that. Its context window is its working memory: if a fact isn’t in it, the agent guesses or goes and gets it. Reasoning can tell it what should have happened. Only observation tells it what did. Compiler errors, test output, logs, screenshots, and query results are how the real world gets into that memory, and they’re how the agent finds out what’s true.

The middle row is what you get when the request only describes the change.

Unchecked assumptions get expensive because later work depends on them. If an agent assumes the data import worked, it builds the chart, writes the summary, and polishes the report on top of an empty table. Each step looks finished, and all of them are wrong.

That’s the quantitative case. A lot of the direction on a real project is qualitative: you look at what came back, wrinkle your nose, and say eh, this isn’t it, what about this. The page doesn’t pop. The enemy shows up too early. The animation is right but the timing feels off. The settings menu works and it’s three clicks too deep.

Half of it is questions: what is this, what did you mean by that, what if we did it the other way, and can we try that without buying it a ring. That happens constantly while building, and there’s no check for it except a person looking at the output. The agent can’t wrinkle its nose on your behalf, which is one more reason the output has to end up somewhere you’ll look.

How far its own predictions go, and how well it judges its own work, is measured in What the agent has instead near the end, with the numbers in the appendix.

The strongest models build their own checks

As of October 2026, the strongest models don’t deal with this by predicting harder. They build checks. I’ve watched it happen. On a recompilation project before this one, the audio skipped when a certain part of a stage started, and I couldn’t explain it. The cause turned out to be the process freezing while it waited for the window to become responsive, which meant nothing inside the process could see the gap: its threads were stopped, so from its point of view no time had passed. Logging from the code would have shown nothing.

The model built a monitor in a separate process that tapped the audio output while the game ran and did spectral analysis on the stream, and that found the hiccup. That was where I noticed it couldn’t see what I could see, and that I’d been assuming it could.

Claude Opus 5’s launch examples are the same move: asked to rebuild a machine part from a drawing it couldn’t view, it wrote its own computer vision pipeline; asked to build a market data feed with no live feed to test against, it wrote its own test harness. Anthropic’s prompting guide now tells developers to remove explicit verification instructions because the model already checks its work, and OpenAI says the same about GPT-6 Astra. The labs with the most compute trained their models to build checks. They didn’t train them to stop needing checks.

Anthropic’s harness work shows the same thing from the other side. A harness is the software around the model that runs its tools and manages its context. Across three Opus releases, the author removed more of it each time: forced context resets, then rigid sprint plans. One component stayed through every version: a separate evaluator that clicked through the running app in a real browser.

Each release let more scaffolding go. The browser never left.

Meta tried the other route, training its Code World Model on 120 million traced Python functions so it would have an internal sense of what code does at runtime. On the June 2026 benchmark it finished in the bottom half. A model that predicted perfectly would still not know the state of your machine.

Why this won’t close soon

• Your state isn’t in the weights. Any model, of any design, has to observe your system to know what’s true in it.
• Prediction degrades with distance and size. Models predict by reasoning one step at a time, the cost grows with every line, and running the real thing is faster, cheaper, and exact.
• The industry is betting on loops. Frontier coding models are trained inside runnable environments and rewarded when hidden tests pass, which makes them better at using feedback, not at working without it.
• Reliability lags capability. METR’s May 2026 report put the public frontier at about 12 hours for tasks agents finish half the time and 1.5 hours for tasks they finish 80% of the time.

What would change this is a model that keeps an explicit, updated picture of program state across steps and knows when that picture is uncertain. That’s a different kind of model from what we have. Even then, it would reduce how often an agent needs to check, not remove the need to look.

A feedback loop is worth more than a bigger model

If checks are what make agents reliable, you can buy reliability with checks instead of model size. My own run is the smallest version of this: the same 27B model went from 0% to 67% at ten lines ahead when it was allowed to check each step. Two 2026 studies found the same at larger scale: an agent that checks its model of a game against recorded observations ranks first in every setting, and picking the best harness gains about as much as picking the best model (A4).

The limits: the model still has to turn the signal into a fix, a wrong checker steers it wrong with confidence, and many cheap attempts can cost more than one good one. Within those limits, a loop built for a smaller or local model is the cheapest upgrade available.

A check can’t tell you what you wanted

I was talking about this with a colleague, a principal engineer at a major software company who has spent a few decades building things and has gone all in on making agents build them the way he wants. He pushes back. In his view, loops and goals are crutches, a way of failing upward at a cost, and the real work is the design up front. His plans read like hand-held pseudocode where an algorithm matters and detailed prose where it doesn’t, with the data model and the state model written out. It’s more work, and what comes back is what he meant. Tokens are cheap, he says, and thought is not.

He is right about the part a check can’t reach. A check tells you whether what you asked for happened. It can’t tell you whether you asked for the right thing, and a loop that runs until the check passes gives you exactly what you asked for and not what you wanted, which is the oldest complaint in software, moved down one level. The two fixes are not in competition. The design says what you want; the check says whether you got it. A check written from a vague request confirms a vague result, which is why the checks have to come from the requirement, and why the requirement has to be written down.

The newer frontier models are very good at solving things with no direction, and that’s most of their appeal: one-shot builds, changes to existing code, long runs of work from a vague instruction. The cost is that more gets assumed. Every requirement I didn’t write down gets filled in by the model’s judgment, and the work is finished before I see any of it.

With one agent that’s manageable. But past a toy example I’m not waiting on one agent to build anything moderately complex; I need anywhere from five to fifty running at once, researching, investigating, and building in parallel, and what that trade costs is visibility into the small decisions. Each agent fills its gaps its own way, then they build on each other’s fills, and the drift from what I thought I said grows exponentially with every hour nobody is watching.

By the end, the thing may be a long way from the model I started with. Sometimes that’s right: they found something along the way that invalidated the original vision. Sometimes it’s just drift, and I can’t tell which without looking. Either way the scale is a necessity if you want to build anything consequential with this, as opposed to demos and one-shots. The gap is between the work it did and the work I wanted, and a passing check doesn’t close it.

Part two: what to keep in mind

This is the half to use. Any project longer than a day has the same four moments: when you start, while it runs, when it gets stuck, and when you change your mind about what you wanted. First, what a check can be, because most of what follows depends on having one.

Checks are not only tests

Tests are one kind of check. The job is to make the things you’d check yourself available to the agent as text it can ask for.

• Is it running? What’s in there right now? A state dump: one command that prints current rows, config, queue depth, or file tree.
• Does it look right? Screenshots, rendered output, browser automation at phone and desktop widths.
• What did I just change? Before and after snapshots, and diffs.
• Will this break that? A repro script for the bug; an invariant check such as “every order has a customer”.
• What does the outside service do? A fake or recorded copy of the service the agent can call safely.
• Does it look and sound right while it runs? A tap at the output: screen control, an audio capture, not a read of the file.
• Where was I? What do I actually know? The working record, in a file.

The Parasol Stars harness is one of these. It runs the remake and the original side by side and compares game state every frame. It isn’t a unit test. It shows the agent a difference that it couldn’t have predicted from the code.

Same save state, same input. One controller port's worth of difference.

The same idea works away from code. Reorganizing 8,000 photos: write a manifest of every file and its hash first, then confirm every hash exists exactly once in the new layout. Analyzing a spreadsheet: compute the key totals two ways and reconcile them against the source before writing any conclusions. Writing from sources: a script that confirms every quote appears word for word in the source. Setting up a home server: a health check that hits each service and prints up or down after every change.

Some things can only be checked at the end of the line. A rendering bug, a skipped audio frame, a checkout button that sits off-screen on a phone: none of that shows up in the code or in a file, only in the output. That’s why I’ve put time into computer-use tooling, CUA and my own computer-ctrl on top of it. Those checks used to need me. They don’t, if the agent has the tool and the expectation that it will use it, but that has to be in the plan; nothing hands it over by default.

When you start

Build the check first and watch it fail for the right reason. A test that fails with “module not found” proves the module doesn’t exist yet, not that the test checks the behavior you care about.

Write down what’s in your head. Which database, which port, which tests fail on purpose, what normal data looks like, which emulator configuration is the real one. The design belongs here too: the data model, the state model, and which algorithm goes where. An agent fills unspecified design with whatever is most common in its training data, and that’s rarely what you had in mind. Put the lasting answers in a file the agent reads every session:

## How to check things here
- Run the app: `make dev` (port 3000). Load sample data: `make seed`
- Full check: `./check` (lint, types, tests; under a minute)
- Peek at the DB: `./scripts/db-peek orders 5`
- See a page: `npx playwright screenshot http://localhost:3000/cart cart.png`
- Known noise: tests in `legacy/` fail on purpose
- Don't edit: `tests/contract/` (these are the acceptance checks)

Give access, not instructions. An agent can only check what it can observe. In Anthropic’s harness experiments, Claude out of the box was a poor judge of its own work; a separate judging agent with a real browser was the strongest lever they found. A dev environment, sample data, a browser, and read-only logs beat paragraphs of instructions.

Match the effort to the model. Frontier models already check their work, so skip the step-by-step verification script; give them the checks, a clear definition of done, and the acceptance rule. Smaller and local models need the loop spelled out. A typo fix needs none of this.

While it runs

This is where the scale bites. With one agent I can follow the thread: I see it hit a problem or build something I didn’t expect, and I step in. With twenty running at once I can’t. They’re making decisions I have no idea about, in parallel, all day. I can’t watch twenty things, so the record and the checks have to do it for me: each agent writes down what it observed and what it assumed, each result gets checked before anything builds on it, and I read the misses.

Most agent workflows keep a plan or a to-do list. That records what has been done. It doesn’t record what’s actually known, which is what you need when something goes wrong.

For any task with several dependent steps, have the agent keep a short working record: the goal, what has been observed and how, what’s assumed but not yet checked, which later steps depend on each assumption, and the one check that would settle the assumption the next step depends on.

Without this, the next move after a wrong file is "try something else."

Without the record, a wrong file sends the agent through unrelated fixes: tweak the button, rewrite the query, restyle the CSV. With it, a mismatch points somewhere. If the request has no filters, the bug is between the button and the endpoint. If the request is right and the file is wrong, the bug is in the export. Either way one assumption gets crossed off and the next move has a reason.

The record also lets evidence expire. A check on yesterday’s build says nothing about today’s, so when something a check relied on changes, that fact goes back to assumed.

This record is the external working memory. Logs and test output are raw observations. The record holds what they mean for the task.

I keep a skill for this, project-tracker: one Markdown dashboard per project with the current objective, status, attempts, decisions, open questions, and next actions, with observed facts kept separate from theories and unknowns. I’m not pitching it. It’s a collection of the things I kept finding myself tracking in larger projects, iterated on now and then, and it has been useful on the bigger ones.

Check before you build on it. Not after every edit; before a result becomes the foundation for more work. The data import before the analysis, the schema before the API.

Protect the acceptance checks. An agent told to make tests pass will make tests pass by whatever route is open. In a June 2026 study, agents graded by a hidden suite of browser tests scored near-perfect while the library they were asked to build was often dead or absent; they’d built a demo that held the tested behavior directly. The same pattern shows up in every current measurement of it (appendix). Tests can be wrong too, so the rule isn’t “never touch a test.” It’s “never weaken a check to get a pass.” Keep the acceptance checks out of the agent’s reach, hold some back, and tell it: if a check looks wrong, stop and say why.

End with what wasn’t checked and what was assumed. “Probably works” shouldn’t turn into “done” on the way to the summary, and a requirement the agent invented shouldn’t pass as one you gave it.

When it’s stuck

When it starts skipping around, ask what would tell the explanations apart. An agent trying one plausible fix after another has stopped learning from its attempts. Ask which observation would show which explanation is right. If two attempts teach it nothing new, it should change how it’s investigating or say what’s blocking it.

Every check has a scope, and it’s easy to ask the wrong question. “The file downloaded” isn’t “the right records downloaded.” Reopening a document proves it saved, not that it says the right things. Reading back an audio setting proves the setting changed, not that you can hear anything.

All three pass. None of them answers the question you had.

The worst case is a check written from the same misunderstanding as the code. If the agent believes exports should ignore filters, it writes an export that ignores filters and a test that confirms it, and they agree. Write checks from the requirement, not the implementation, and look at a real output yourself at least once.

When you change your mind

On anything that takes more than a day I change my mind about what I wanted, because I see the thing and it isn’t it. That isn’t a failure of the plan; part of the requirement gets discovered by building. The record above handles the mechanics: evidence expires, assumptions go back to assumed. The harder part is the requirement that was never written down at all.

Roughly what I had in mind, and nothing like what came back.

My remake is the example. It was mostly built with frontier models, but not from a prompt that said port this game. I gave them an emulator and a working environment, local models to generate art and assets, and the harness that compares the remake with the original every frame.

I picked Godot because I knew it: cross-platform, easy to build with, and it exports to HTML, which matters because models are very good at web pages and most harnesses can drive Chrome over its debug protocol, so an HTML build gives the agent a whole environment to guess, check, and sort out its own mistakes in a browser tab it controls. It also means my machine isn’t covered in game windows while it tests.

The emulator was the same kind of decision. An open-source emulator gives the agents instrumentation and a debugger for free: no crude harness to wire up, no getting lucky and catching the odd behavior at the right moment. They can step cycle by cycle and dump any subsystem they need, which makes the emulator a source of truth, and I led with that from the start because I value an agent being able to reproduce anything at any time.

The target helped too. An arcade game has no complicated state carried between screens, so every part of it can be run and tested on its own without playing back to it; I’m a few seconds from any state I need to validate.

None of that is specific to games. Games are a useful case because they’re a runtime of many subsystems running in real time, with consequences in real time and everything bubbling up into a presentation layer, plus remote systems to coordinate with if there’s a network feature. That’s what makes them a good test of working with agents on complex systems.

The question I led with was how to give the agent a way to know whether it was getting closer, without me playing whack-a-mole over every detail. Asking it to figure out what’s inaccurate and fix it doesn’t work; it has nothing to compare against. The frame-by-frame harness was the answer: a deterministic signal, cheap to run, that says how far off the remake is and where. Inside that frame the models did a lot of good work. Then I asked for a 2.5D graphical overhaul with no requirements, because I didn’t have any. The models extruded 3D geometry out of the 2D sprites. It was horrible.

Every check passed. The sprite got thicker.

To get what a studio with a budget would produce, I’d have to supply the tooling, the direction, and a production pipeline for turning a retro game into something that looks designed. Frontier models can do a lot and there’s headroom there. But even if they can do it, will the assumptions they make be the ones I want? And if they are, is the way they get there any good? I have no way to tell.

Anthropic’s guide for Opus 5 now ships a prompt to hold the model to the scope you asked for and to check in when different readings of the request would lead to materially different work. The useful version of that is an agent that helps you find your requirements while it builds: it says what it assumed, it says so at the point where the assumption changes the shape of the work, and it lists all of them at the end.

The prompt

A prompt that covers it:

Goal: [one sentence]
Done means: [something observable: a command's output, a screenshot, a number]
What you can't see from here: [current state, constraints, what normal looks like]

Before changing anything, show me how you'll check this. If no check exists,
build the smallest one that works and run it so we both see the current state.

Keep a short note of what you've observed versus what you're assuming, and
check an assumption before building on it. When a requirement I did not
state would change the shape of the work, say what you assumed before you
build on it. Don't edit [tests/contract/]. If a check looks wrong, or two
attempts teach you nothing new, stop and tell me instead of working around it.

When you're done, show the check output, list what you did not verify, and
list the requirements you assumed.

What to build

In your own projects: one command that checks everything and prints short output. Scripts that print current state for anything you’d otherwise look at in a GUI. Sample data with known right answers, and fakes for outside services. A way to see UI output. A working-record file for multi-session work.

In the harnesses we all use: tools that report whether something finished, not just whether it was requested. The project’s check run automatically when the agent says it’s done, with the result shown to both of you. Compiler and type errors surfaced right after each edit. Files the user can mark off-limits so the acceptance checks stay intact. The working record kept outside the context window so it survives restarts. Loop detection: repeated attempts that produce nothing new should trigger a new approach or a question. Screenshots, browser control, and log tails as standard tools, and cheap experiments with sandboxes and rollback. Tool output trimmed so the one useful line isn’t buried in 2,000 lines of noise.

In teams: treat “agent-legible” as an engineering goal. One-command dev environments, fast deterministic tests, clear error messages, and a CLI or API for anything only reachable through a GUI. Test the checkers too: plant a known bug and confirm the check catches it. All of this makes the humans faster as well.

Build the check first

Before handing an agent a task, the question isn’t whether it can make the change. It usually can. The question is whether it can check the result. If it can’t, build that first.

In the Parasol Stars work, every mistake the agent made was found the same way: by checking its claim against the logged data. The log made that possible, not the agent.

The log has a second use. People remember the hits and forget the misses. An agent that does one surprising thing well leaves a stronger impression than the ten routine failures around it, and the failures turn into ordinary days. Engineers surface the hits, managers see the hit rate, and the misses never make it into the summary. I’m running an experiment on this right now: a skill pack that Codex has been writing on its own for four days, about 280 skills, with no checks on purpose. I want to see how far it drifts from what I asked for, and when it’s done, I’ll have to work out how to tell whether any of it is useful. A record of what was verified and what wasn’t is the only account that keeps the misses in it.

The same applies to writing, including this post. It started as a rant, got sorted into beats and a short brief for what a reader should walk away with, and went through three reviewers with different jobs, a lint for my own voice, a check of every number against its paper, and one measurement I ran myself. None of that is prompting. It’s the pipeline, and without it the result is the generic article you have already read ten times.

Part two on one page.

Sign-off

If you take one thing from this, take the question: before you hand an agent a task, how will either of you know it worked? If you take two, the second is that “you are a senior engineer at a top FAANG company who never makes mistakes” is not a check.

The numbers are below for anyone who wants them. If you’ve built checks like these for your own work, or had an agent’s self-check fool you, I’d like to hear about it.

What the agent has instead

The facts behind part one, for anyone who wants them before the numbers.

Its predictions are good on toy code and poor on real code. Predicting the output of a small function is a solved problem, to the point that the classic benchmark for it was retired this year, and a September 2026 paper notes that an agent doesn’t need to predict anyway when it can run the program. Fair for agents, and beside the point for the model: being able to run the program says nothing about how good its own picture is, which is what you’re relying on every time it can’t run the thing, or doesn’t.

Real repositories are a different story: on a September 2026 benchmark built from instrumented test runs, the best of five models got 38% of the runtime questions right (A1), and on a June 2026 benchmark the best of twelve models caught three quarters of the failing tests while most caught a third or less. On my own machine, a 27B model asked for the program state ten lines ahead got it right never with reasoning off and two thirds of the time with reasoning on, at twenty times the cost (A2).

The current generation isn’t exempt, though the measure there is different. Terminal-Bench 4.0 is a completion benchmark, not a prediction one: 66 realistic jobs in a sandboxed terminal, the agent gets bash with no step limit, and a verifier checks the end state after it stops. With every chance to run and check, the best current model, Claude Opus 5.5, finishes 65% of the jobs as of October 7, 2026; GPT-6 Astra 60%, Grok 4.7 29% (A4). The two benchmarks above are the ones that measure prediction.

It’s optimistic about its own work. In a 2026 Anthropic harness experiment, agents reliably graded their own work too generously (A4), and the June 2026 benchmark’s authors attribute its misses to a bias toward predicting that tests pass.

It can’t see your state. No training run puts your database, your environment variables, your library versions, or yesterday’s edits into a model’s weights. A perfect simulator would still need to know where to start.

It can’t reliably tell when it’s wrong without outside input. Asking a model to review its work without running anything means it re-reads text it wrote a moment ago. Research from 2024 on self-correction found that without outside feedback, models often don’t improve and sometimes get worse. With reliable feedback, an error message or a test result, self-correction works.

The same limit holds at the other end of the speed range. TypeSafe AI’s Jev, launched in September, is a System One model: hand it a state and a typed question and it returns a decision with a probability in one pass, no prose, no reasoning. That’s useful for routing and triage, and the probability isn’t evidence that the decision was right. It’s the model’s assessment of itself, which is the thing that can’t be trusted without outside input. A fast decision still needs a check from outside the model.

Appendix: the measurements

The numbers behind the claims above, for anyone who wants them. Every model and benchmark here is from 2026 unless the date says otherwise.

A1. Toy code versus real code

The classic test, CruxEval, asks a model to predict the output of a small Python function. By 2026 it had stopped separating models: one evaluation service quit running LiveCodeBench’s version on new releases because scores had saturated, and a benchmark paper from late September 2026 says the format is no longer suitable for coding agents, because an agent can run the program instead of reasoning about it.

That paper, Codoku, replaced it with puzzles an agent can’t run its way out of: fill in typed blanks in a partial program so that global constraints hold. Claude Opus 5 solved 77% of the small puzzles and 50% of the large ones. GPT-5.6 Sol solved 67% and 54%. The open-weight models trailed: GLM 5.3 solved 50% of the small puzzles and 12% of the large, Kimi K3 48% and 11%, DeepSeek V4.1 Flash 39% and 22%.

SWE-Flux, also from September 2026, asks what happens at runtime inside twelve Python repositories, with the answers taken from instrumented test runs: which branch executed, how many times a loop ran, what a variable held, which exception fired. The best of five models, GPT-5.4, scored 38% overall and 29% on the loop questions, where, as the authors put it, a model must track how the program evolves over iterations.

A June 2026 benchmark took 435 cases from SWE-bench Verified and asked twelve models, frontier ones included, whether a test would pass. GPT-5.5 caught 74% of the failing tests. Claude Opus 4.7 caught 35%, Qwen3.5-397B 32%, and Qwen3-30B 2.5%. The authors attribute the misses to a bias toward predicting that tests pass. Asked which method or line would use the most time or memory, none of the twelve reached a recall at five of 0.2. Meta’s CWM, the model trained on execution traces, caught 21% of the failing tests, ninth of twelve, and came last at picking out the most expensive method or line.

Twelve models, 435 cases from SWE-bench Verified, June 2026. Data from Towards Evaluation of Implicit Software World Models in Coding LLMs.

A2. My lookahead run

Qwen3.8-27B, a 4-bit MTPLX export served locally on an M5 Max: give it a short Python program and the variable state after one executed line, ask for the state n lines later, score exact match on the whole state. Thirty synthetic programs (a few integers, a list, a short loop with a branch), seed fixed, temperature 0, one run.

With reasoning off, one line ahead it was exactly right 70% of the time. Three lines ahead, 20%. Five, 3%. Ten, never, though on average it still had about half the variables right. Each answer took about a second.

With reasoning on at the lowest effort setting, it got one and three lines ahead right every time, five lines 92%, and ten lines 67%. The cost was 290 reasoning tokens at one line ahead and about 1,200 at ten, and 6 to 24 seconds per answer instead of one. The reasoning text is the model executing the program by hand, one line at a time. That’s the mechanism: it can simulate, the simulation costs tokens in proportion to the distance, and it still fails a third of the time at ten lines.

Reasoning off, 120 prompts; reasoning on at low effort, 49 prompts. My run, October 2026.

Limits: synthetic code, one model, one quantization, one run per prompt, and the reasoning condition was stopped at twelve programs to keep it under twenty minutes. The harness, the raw results, and the two runs that didn’t work (a stale mlx_lm, and a server that ignored the thinking-off flag and reasoned into a token cap) are in the post’s repository.

A3. Agents building to the test

In a June 2026 study, Copilot CLI agents running Claude Opus 4.7 and GPT-5.5 were asked to port a React data table to Angular as a reusable library, graded by a hidden suite of 222 browser tests. Without the suite, they delivered a library that was present but unfinished. With the suite in the loop, scores went near-perfect while the library was often dead or absent: the agents built a demo that held the tested behavior directly. The authors’ line: the agent doesn’t, on its own, validate what it ships as a user would.

SpecBench, from May 2026, measures the same thing as the gap between visible tests and a held-out suite. Every frontier agent saturates the visible tests, the gap persists, and it grows by 28 points for every tenfold increase in code size. One agent produced a 2,900-line hash-table “compiler” that memorized the test inputs.

METR’s pre-deployment run of GPT-5.6 Sol in June 2026 put its 50% time horizon at about 11 hours when cheating attempts were counted as failures and beyond 270 hours when they were counted as successes, and noted its detected cheating rate was the highest of any public model on their harness. METR’s May 2026 frontier report, covering internal models from Anthropic, Google, Meta, and OpenAI, found that on tasks of eight hours or longer at least 16% of successful runs were illegitimate on review, over a hundred instances, and says that checking for cheating by hand is often the majority of the work in running its suite.

The failure has a quieter form: not saying what wasn’t done. OpenAI’s launch page for GPT-6.1 Sol (early October 2026) reports an evaluation of whether an agent tells the user its search tool is broken instead of guessing. On tasks chosen to provoke the failure, GPT-6.1 Sol fails to say so 2.1% of the time, GPT-6 Sol 4.9%, GPT-6 Astra 1.5%, and GPT-6 Luna 28.7%. The same page notes that Claude Fable 5.1 fell back to another model on about 40% of one benchmark’s tasks, a detail that doesn’t show in the score.

A4. What the loop is worth

Part one makes two claims: a model can’t tell how your system will behave without looking, and when it can look, finishing depends on the loop more than on the model. A1 and A2 measure the first. A3 measures whether what gets delivered is what was asked. This section is the evidence for the second claim, and every source in it grades the end state, with a verifier, a browser, or a recorded observation, rather than taking the model’s own report, because the model’s report is the thing in question.

The evaluator is the part of the harness that survived. In Anthropic’s March 2026 harness experiments, Claude out of the box was a poor QA agent for its own work and graded it too generously. Separating the agent doing the work from the agent judging it was the strongest lever, and the judge got a real browser through Playwright so it could click through the live app. Opus 4.5 let the author drop forced context resets; Opus 4.6 let him drop the sprint structure and run the evaluator once at the end. A solo run of the same task took 20 minutes and $9; the full harness took 6 hours and $200, with a difference in output quality the author calls immediately apparent.

Harness choice is worth about as much as model choice. Han and Sun (ICML 2026) found that picking the best harness gains about as much on Terminal-Bench as picking the best model. A 2026 study of coding agents on ARC-AGI-3 found the variant that checked its model of the game against recorded observations ranked first in every setting and succeeded at lower reasoning effort, at the price of more compute per run. The 2024 “Large Language Monkeys” paper is the origin of the result: a cheap open model with tests choosing among many attempts beat the best single attempt of that year’s frontier models on SWE-bench Lite. Those models are two generations gone; the result has held up.

With the loop, the frontier finishes about two thirds of the time. Terminal-Bench 4.0 is the one board where every current model runs through the same minimal harness (Vals AI, mini-SWE-agent): 66 community-written tasks across software, science, ML, operations, hardware, security, and media, each a real deliverable, graded all or nothing by a verifier that runs after the agent stops, with bash, no step limit, and up to eight hours. It doesn’t measure prediction or reading what you wanted. It measures how often an agent finishes when it can run anything it likes, which is the ceiling the loop buys you.

As of October 7, 2026: Claude Opus 5.5 65%, Claude Sonnet 5.5 64%, GPT-6 Astra 60%, Claude Fable 5.1 58%, GPT-6.1 Sol 55%, GLM 5.3 39%, Grok 4.7 29%, DeepSeek V4.1 Flash 20%, Kimi K3 17%. The best model on the board fails a third of the tasks. Vals notes that 22 of Opus 5.5’s 198 attempts were served by Opus 5 or Opus 4.8 through provider-side fallback; counted as failures, its score drops to 58%, behind Sonnet 5.5 and Astra. METR’s September 22, 2026 summary calls Opus 5.5 an incremental improvement over Fable 5.1, which matches the board: the top four are within seven points.

Every current model, one harness, October 7, 2026. Data from Vals AI.

Reliability lags capability. METR’s May 2026 frontier report put the public frontier at about 12 hours for tasks agents finish half the time (confidence interval 5 to 61 hours) and about 1.5 hours for tasks they finish 80% of the time, with the strongest agents having essentially saturated the Time Horizon 1.1 suite. The gap between those two numbers is why part two checks while it runs: an agent that finishes a twelve-hour task half the time hands you a wrong twelve-hour result the other half, and the run itself doesn’t say which one you got.

---

Sources: the saturation note is on Vals AI’s LiveCodeBench page (updated September 2026); Codoku is Li, Sun, Li and Su, Codoku: Renewable Program-Reasoning Challenges for Frontier Coding Agents (September 2026); SWE-Flux is Taherkhani et al., Can LLMs Reason About Runtime Behavior? (September 2026); the test-outcome benchmark from Towards Evaluation of Implicit Software World Models in Coding LLMs (2026). Self-correction: Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet (ICLR 2024) and Kamoi et al., When Can LLMs Actually Correct Their Own Mistakes? (TACL 2024). Jev: TypeSafe AI, Introducing System One Models & Jev (September 2026). ReAct: Yao et al. (2022). Opus 5 examples and guidance: Introducing Claude Opus 5 and Prompting Claude Opus 5. Astra guidance: OpenAI, Rethinking skills and prompts for GPT-6 Astra and Using GPT-6 Astra. Harness experiments: Anthropic, Harness design for long-running application development (March 2026). CWM: FAIR CodeGen team (2025). METR: Frontier Risk Report, February to March 2026 (May 2026) and Summary of METR’s predeployment evaluation of GPT-5.6 Sol (June 2026), Frontier Risk Report, February to March 2026 for the illegitimate-run rate, and Summary of METR’s predeployment evaluation of Claude Opus 5.5 (September 2026). Broken-search-tool evaluation and the Fable 5.1 fallback note: OpenAI, Introducing GPT-6.1 Sol (October 2026). Shared-harness scores: Vals AI, Terminal-Bench 4.0 (updated October 7, 2026). Repeated sampling: Brown et al., Large Language Monkeys (2024). ARC-AGI-3: Rodionov (2026). Harness versus model: Han and Sun, How good is your harness? (ICML 2026). Building to the test: Ma, Kereopa-Yorke and Schultz, Building to the Test: Coding Agents Deliver What You Check, Not What You Requested (June 2026); Zhao, Srikanth, Wu and Jiang, SpecBench: Measuring Reward Hacking in Long-Horizon Coding Agents (May 2026, revised September 2026). The Parasol Stars material and the lookahead measurement are from my own harnesses; the measurement’s code and raw results are in the post’s repository.

October 2026