The AI Harness Is Moving Into the Environment: Anthropic's Source Control, a Game Built as a Harness, and OpenAI's Codex Repo

On October 13, Anthropic’s engineering blog published “Redesigning source control at Anthropic,” an account of moving the company monorepo off git and onto an in-house version control system called Scion in five months. The reason is in the second paragraph. In May 2026 Anthropic merged about 2,500 code changes a day. By September it merged more than 30,000. Source control, builds, and CI, all designed for human scale, had become the biggest bottleneck.^[1] By October 19 the Hacker News thread had 894 points and over a thousand comments.^[2] The same day, a much smaller post reached the HN front page: game developer Kyle Kukshtel’s “Your Game Is A Harness,” a write-up of his talk on making a game something an agent can read and drive.^[8][9]

One side is an AI lab merging tens of thousands of changes a day. The other is an independent game developer. OpenAI’s “Harness engineering” post from February sits at a third scale: a handful of engineers and a product built from an empty repository, every line written by Codex.^[16] Read together, the three say the same thing. Once writing code is cheap, what limits an agent is whether its environment can be queried, reproduced, measured, and enforced. The word “harness” is moving with them, out of the loop that wraps the model and down into the repository, the engine, and CI.

The short version

• The harness is moving down a layer. The Claude Code, Strands, and DeepSeek harnesses we covered earlier manage the agent loop. These three cases spend most of their effort on the environment the agent touches.
• Four shared properties: queryable, reproducible, measurable, enforceable. Scion turns repository questions into server APIs. The game pins state with seeds and commands. The Codex repo exposes logs, metrics, and UI directly to the agent.
• Merge and review rules are being rewritten. Anthropic dropped the merge queue with its global lock for post-merge and pre-deploy testing, and humans review intent instead of reading every line. OpenAI also runs with few blocking merge gates.
• Scale decides which layer to invest in. Almost nobody needs a custom version control system. Almost everybody benefits from tests that run headless and print text and numbers.

What “harness” means is drifting

Our earlier posts on the Agent Harness pattern, Strands Harness, DeepSeek Harness, and Growing Harness all treat the harness as the runtime that wraps the model and drives its tool calls.

Kukshtel uses the same word for something wider. A harness, in his telling, is a set of actions an agent takes in response to some kind of input. Claude Code is one, and it can be extended, distilled, and reshaped to fit your work. The trouble is that no existing harness talks to your game. To the agent, the game is a black box, and the only thing it sees is the code as written.^[8] OpenAI says it more bluntly. The engineering team’s main job became designing environments, specifying intent, and building feedback loops so Codex can do reliable work. When the agent got stuck, the question was “what capability is missing, and how do we make it both legible and enforceable for the agent?”^[16]

I don’t think this is just loose vocabulary. Main loops are converging across vendors, and the differences now show up outside the loop. The same Claude Code behaves very differently in a repository where one command reproduces a bug and in a game project where only a human watching the screen can tell if anything worked.

Scion: when nearly every repository client is an agent

Screenshot: the opening of Anthropic’s post, updated once on October 15^[1]

Anthropic admits its workload is unusual: a main branch history near 100 GB, about 25 million CI checkouts a day, and more than 600 PB of git traffic a day if fetched naively.^[1] The team used every standard tool, from shallow and sparse clones to several hundred internal git mirrors. As merge rates climbed, snapshots fell behind main and blame on partial clones got harder to keep working.

Stepping back, they saw the mismatch. Git assumes every copy can work offline. Anthropic was really using git as a centralized system with one authoritative copy, and nearly all of its clients were agents and CI jobs that are online by definition. So the question became: if you design source control assuming clients are always online, what does it look like?^[1]

Figure: git mirrors versus Scion’s tiered caches. All numbers are Anthropic’s own^[1]

The answer is a deliberate asymmetry between server and client. The Scion server answers file history and blame questions, creates commits, and performs merges and rebases. The client keeps a bounded local object cache, fetches trees and blobs on demand, and computes very little itself.^[1] The unit of work is a changeset, a write-ahead log entry that stores only the changed files and pointers into blob storage. Blame indexes and path history are “derived data,” computed from each changeset’s parents, eagerly or on demand. Refs are discouraged, and moving one is a compare-and-swap on a single Spanner row.

For agents, the key change is that the repository stops being something you download first and becomes a service you can ask questions. A CI job that needs the diff between a commit and its merge base asks the server and needs no working copy. Many writes also work entirely through the API. Anthropic says its automated bisect and revert pipelines would not be practical at scale without that cheap programmatic access.^[1] Asked on HN why the client can’t buffer commits offline, author Nick G. said it could, but the client would then need to learn everything the server does and still couldn’t answer full-graph questions like blame. Claude, Scion’s heaviest user, is necessarily online.^[3]

After the merge queue gives out

For most teams, the second half of the post matters more than the storage layer.

Screenshot: Anthropic says a proper merge queue “doesn’t make much sense at agent scale”^[1]

A merge queue with a global repository lock is the industry standard. It stops working when hundreds or thousands of changes can merge while tests are still running. Anthropic moved its checks to after the merge and before deployment. The cost is that concurrent changes can conflict, and Anthropic says Claude typically fixes those conflicts faster than humans can identify them.^[1] In the comments, the author added that one human driving several orchestrator agents, each managing a team of agents, is now a common pattern, and that they are still exploring how to stop those agents from needlessly conflicting with each other.^[4]

Figure: a conventional merge queue versus Anthropic’s current flow. OpenAI’s approach is covered below^[1][16]

Without the lock, the safety net is made of other things. Scion supports permissions on individual directories. Antique, the code review tool, can express semantic approval rules that tell a comment-only change from a sensitive logic change, so human reviewers spend attention where consequences are highest.^[1] Each component also has a Claude “superfan” in its own Slack channel, watching telemetry and logs like an experienced engineer with nothing better to do than refresh charts. Traditional alerts stay in place.

The post is plain about the human role. Every engineer on the project now rates Claude as better at writing code than they are, and very often their job was to tell Claude “no.”

Screenshot: Anthropic on how the engineers’ work changed^[1]

The examples are concrete. Several systems tried to find when a change merged by scanning the commit log instead of asking the review tool. One adversarial review was so wary of an internal service that Claude added layers of needless validation. Humans still review every change request, but for intent, not line by line.^[1]

Here I side with the top-voted skeptic on HN. duttish wrote that every time he stops reviewing Claude’s code, he later finds junk, so he can’t stop.^[21] Reviewing intent works only when everything else is in place: hermetic simulations, fuzzing, directory permissions, superfans on the telemetry, and automated revert ready to go. A team without those that copies “review intent only” has simply removed review. Our earlier piece, Coding agents produce more code, not more software, points the same way: when writing gets wider, review gets longer, and skipping review does not buy delivery.

Read the five months together with the prior art

Scion’s post now opens with an italic line: updated October 15 to include more detail on the projects that pioneered many of its techniques. The update followed an October 14 post by Rain (sunshowers), a former engineer on Meta’s source control team. She pointed out that Scion’s “derived data” closely matches Meta’s Mononoke server, while the original post credited Sapling only for “hard-won lessons” and did not mention Mononoke.^[5] A day later she wrote that Scion’s changeset is the same data model as Mononoke’s Bonsai changeset, that the server-side query API is similar too, and that there was overlap in personnel.^[6]

Screenshot: sunshowers’ follow-up, with an update saying sufficient attribution has been added^[6]

Anthropic’s footnote now says the Sapling reference means its server component, Mononoke, which pioneered many of the techniques Scion uses, in particular the Bonsai data model.^[1] Mononoke’s public docs match: it stores commits internally as Bonsai changesets and converts them for Mercurial-format clients.^[7] Rain’s own update says the attribution is now sufficient.

The two updates settle the attribution question well enough. The bigger effect is on how to read “seven people built a version control system in five months.” Rain herself says that rebuilding an existing system this fast is still stunning.^[6] For ordinary teams, that is also the useful reading. Agents are good at implementing quickly on top of mature prior art, and Mononoke is open source and, in Rain’s words, in every model’s training set.^[5] That is not the same as having an agent invent a distributed system from scratch. On HN, the author also said the point isn’t to vibe-code your own VCS, and that many of the ideas apply directly to git.^[2]

Games: opening the black box

Kukshtel starts from something many game developers say: “LLMs are bad at games.” His explanation is that in a web app almost everything is code, which the model can read and change. In a game, a lot isn’t code. Scenes, assets, and runtime state are opaque to the model, and a game that depends on puppeting that opaque stuff makes an agent fall over. So he treats it as a context problem, not something intrinsic to games or to models.^[8]

Screenshot: Kukshtel’s post is based on his September 12 talk at Indie Rodeo in Calgary^[8]

His fix is a chain of architecture decisions that depend on each other, and determinism is the core. Create one seeded source of randomness at the start and route every non-deterministic call through it, so the 30th random call is the same every time. Build save and load from day one, and use a single object type, Thing, with an enum for its kind. Serialization then has one way in and one way out, and the model never has to guess which of a hundred classes to extend. Route state changes through the command pattern with serializable commands. A player’s actions can then be replayed exactly, and an agent can write a list of commands in a text editor and send it to a running game with no compile step. Keep data outside the build so changing a walk speed doesn’t need a new build.

The last step is to pull the simulation out of the engine into its own library. The engine sends commands and renders whatever state the simulation returns, without second-guessing it. The network, an agent, and tests can all send commands to the core, and the tests run as plain C# projects with no engine at all.^[8]

Figure: Kukshtel’s game-as-harness structure. The prerequisites are cheapest when done first^[8]

On the measurement side, he warns that screenshots pollute context. Hand a multimodal model a before and an after screenshot, and it struggles to see what changed or whether it got closer to the goal. He uses odiff to diff images, which yields a diff image and a number like “85% similar,” a stable baseline the agent can track across turns. For performance he uses tools like samply that dump captures as text, because graphical profilers built for human eyes are not legible to an agent.^[8][19][20]

He isn’t alone. The Vectarine engine’s “Working with agents” page says it is written mainly for the agent. Tests are TOML files that run the game without a window, take screenshots, simulate keys, and run Luau inside the game, with an exact 1/60 s frame step and a seeded random generator. If a rerun isn’t at 0% pixel difference, something isn’t deterministic.^[15] Since a test launch costs seconds and a logic update microseconds, it recommends helpers that run many attempts in one step.

Screenshot: Vectarine’s agent guide lines up with Kukshtel almost point for point^[15]

Practitioners on HN offered simpler versions. TeMPOraL said his most valuable prompt was “please figure out how to run the game headlessly, so I can use my PC while you muck around.” The agent did, and since then it runs several instances in parallel whenever it needs to check an assumption.^[10] Simon Willison built a small RTS with replays that worked in Chrome and broke in Safari. The model fixed it by replacing Math.sin() and Math.cos() with its own deterministic functions.^[11]

Screenshot: one prompt that bought parallel verification^[10]

The objections deserve a hearing

The pushback on the game material is strong, and most of it comes from developers with years of shipping experience.

Screenshot: avaer argues the advice mainly fits small indie titles^[12]

avaer says the Thing approach is fine for a small game, but in a mid-sized 3D game, copying dozens of subsystems of thousands of Things won’t fit in a frame, which is why ECS and SOA exist. Art needs its own harness, and samply won’t diagnose overdraw.^[12] A former MMO developer goes further: models want to make everything deterministic, but outside simulators, games aren’t verifiable simulators, and bending the code to suit a verifier creates churn and rigidity.^[13] Cross-platform determinism isn’t free either. A fixed-point math library won’t fix shader and graphics differences.

Kukshtel admits in his postscript that the small project he is shipping uses none of this. The ideas are aimed at larger projects.^[8] I think that postscript matters more than the main text. Each technique has a cost, and the cost is lowest early and highest late. The payoff scales with how many times an agent iterates and how much it relies on checking its own work. A weekend prototype does not need a standalone simulation core.

One more comment I agree with comes from drusepth. Don’t ask an LLM to tune turn radius or freeze frames. Ask it to build the tools that let a person tune them faster. His team has about a hundred such tools for one Steam game, all written by LLMs.^[14] Making the environment legible is the same investment for people and for agents.

The Codex repo: move knowledge and rules into the repository

OpenAI’s case sits in the middle. Instead of tens of thousands of merges a day, it is five months from an empty repository to about a million lines of code and roughly 1,500 merged pull requests. The team grew from three engineers to seven, averaging 3.5 PRs per engineer per day, and estimates the work took about a tenth of the time it would have taken by hand.^[16]

Screenshot: OpenAI made the app’s UI, logs, and metrics directly legible to Codex^[16]

The first bottleneck was human QA capacity. So the app boots per git worktree, one instance per change, with the Chrome DevTools Protocol wired into the agent runtime. Logs, metrics, and traces come from a local observability stack that lives and dies with each worktree, queried with LogQL and PromQL. With that in place, a prompt like “ensure service startup completes in under 800ms” becomes something an agent can actually work on.^[16] It is the same move as “run headless and print numbers” in the game world, applied to a web service.

On knowledge, the “one big AGENTS.md” approach failed. It crowded out the task, rotted quickly, and couldn’t be checked mechanically. Today’s AGENTS.md is about a hundred lines and works as a table of contents. The real knowledge lives in a structured docs/ directory that linters and CI check for freshness and cross-links, and a recurring agent looks for stale docs and opens fix-up PRs.^[16] Our post on progressive disclosure looks at the same layered-loading problem.

On rules, one detail is worth copying. Architecture constraints are enforced by custom lints and structural tests, and the lint error messages are written for the agent, with the fix included.^[16] Human taste gets written down once and then applies to every line. The cost: Codex replicates existing patterns, bad ones included. The team once spent every Friday cleaning up “AI slop,” then encoded “golden principles” and set background tasks to open small refactoring PRs. On merging, OpenAI landed where Anthropic did: few blocking merge gates, short-lived PRs, flaky tests often handled with a rerun. The post itself says this would be irresponsible in a low-throughput environment.^[16]

Four shared properties

Put the three cases side by side, and the environment work sorts into four properties.

Property	Scion (Anthropic)	Game harness (Kukshtel, Vectarine)	Codex repo (OpenAI)
Queryable	blame, history, and diffs are server APIs, so jobs need no local repo	state is a list of Things that tests read directly	UI, logs, and metrics exposed through CDP, LogQL, PromQL
Reproducible	immutable, content-addressed changesets, so a commit hash works everywhere	one seed, command replay, an exact frame step	one app and observability stack per worktree
Measurable	cache hit rates per tier, superfans watching telemetry	odiff similarity, samply text profiles, pixel thresholds	assertable metrics such as startup time and span latency
Enforceable	directory permissions, semantic approvals, intent review	the simulation core owns state, the engine doesn’t decide	layered dependency rules, lints that explain the fix

Nothing in the table is new. Determinism, the command pattern, and blackbox game architecture have been discussed in game development for years. Server-side version control has Piper and Mononoke before it. Layering and lint rules are old news. One HN commenter joked that it took inventing AI for people to care about debuggability and iteration speed.^[9] I don’t read that as a dig. What changed is the leverage. These practices used to save human time. Now they also decide whether each agent iteration takes seconds or minutes, and whether the agent can tell on its own that a change worked.

Decide what to build by scale

Here is the order I would give a team, starting with what nearly everyone should do.

1. Make verification run headless and print text and numbers. Web service or game, the agent should know whether a change worked without looking at a screen. Tests run from the command line, failures explain why, and visual checks report a difference percentage. This step is cheapest and pays off most directly.
2. Pull nondeterminism into one place. Seed all randomness, pass time in from outside, and replace cross-platform math functions with deterministic ones. The test: the same test run twice gives identical results.
3. Give each change an isolated environment. Boot the app and its observability stack per worktree, so the agent can run instances in parallel and throw them away.
4. Turn rules into code that fails. Write architecture boundaries, naming, and file-size limits as lints and structural tests, and put the fix in the error message. Keep AGENTS.md as a table of contents.
5. Change merging and version control last. If pre-merge checks really are the bottleneck, move some of them after the merge, but only once automated revert, monitoring, and permissions are in place. If the repository genuinely outgrows git, look first at options that speak the git protocol over different storage, such as ERSC, and at jj’s multiple backends. Building your own comes last.^[17][18]

Most teams that reach step 3 are in good shape. Anthropic itself says Scion only makes sense for truly enormous monorepos, and that its token budget for internal use is far beyond what other businesses would want to spend.^[1]

Traps to watch for

• The agent bypasses the right interface. Anthropic’s example is scanning the commit log instead of asking the review tool. Make the right interface the cheapest path, then block the wrong one with a lint or a permission.
• Adversarial review makes the system heavy. Agents critiquing each other over-defend against hypothetical risks. Write the trust boundaries into the review rules.
• Screenshots as evidence. Give a model a full screenshot and unrelated regions pull it off course. Turn off irrelevant layers or crop first, then let the diff number decide.
• Half-done determinism. The simulation is deterministic, but GPU output and cross-platform graphics still differ. If rendering feeds back into logic, handle that part separately.
• Docs turn into a junkyard. A rules file that keeps growing soon has no owner. Split it, add mechanical checks, and have an agent clean it on a schedule.
• Treating someone else’s throughput as the goal. Thirty thousand merges a day is Anthropic’s workload, not an industry benchmark.^[2]

Closing

Each post has weak spots: Scion’s attribution fell short at first, the game advice hits performance and art walls on big projects, and OpenAI says its setup may not generalize. The direction is the same, though. The main loop is becoming standard, and the gap opens in the environment around the agent. Next time an agent keeps failing in your project, hold off on switching models and ask the question from OpenAI’s post: what capability is missing, and how do we make it both legible and enforceable for the agent?

References

1. Anthropic. Redesigning source control at Anthropic (2026-10-13, updated 10-15): https://www.anthropic.com/engineering/redesigning-source-control ↩
2. Hacker News. “Redesigning source control at Anthropic” thread: https://news.ycombinator.com/item?id=50073633 ↩
3. Hacker News. nickg-anthropic on why there is no offline commit buffering: https://news.ycombinator.com/item?id=50079495 ↩
4. Hacker News. nickg-anthropic on layered orchestrator agents and conflicts: https://news.ycombinator.com/item?id=50078031 ↩
5. sunshowers. Anthropic’s Scion is heavily inspired by Mononoke (2026-10-14): https://sunshowers.io/posts/anthropic-mononoke/ ↩
6. sunshowers. More on Anthropic’s Scion ripping off Mononoke (2026-10-15): https://sunshowers.io/posts/anthropic-mononoke-2/ ↩
7. facebook/sapling. Mononoke docs: Mercurial and Sapling Support: https://github.com/facebook/sapling/blob/main/eden/mononoke/docs/5.2-mercurial-sapling-support.md ↩
8. Kyle Kukshtel. Your Game Is A Harness (2026-10-10): https://kylekukshtel.com/ai-harness-engineering-game-development-claude-code ↩
9. Hacker News. “How to engineer an AI harness for game development” thread: https://news.ycombinator.com/item?id=50072120 ↩
10. Hacker News. TeMPOraL on running the game headlessly: https://news.ycombinator.com/item?id=50080720 ↩
11. Hacker News. simonw on Safari replays and deterministic trig: https://news.ycombinator.com/item?id=50074610 ↩
12. Hacker News. avaer on Thing, ECS, and art harnesses: https://news.ycombinator.com/item?id=50075724 ↩
13. Hacker News. dudeinhawaii on determinism and verifiability in games: https://news.ycombinator.com/item?id=50078115 ↩
14. Hacker News. drusepth on having LLMs build tuning tools: https://news.ycombinator.com/item?id=50078259 ↩
15. Vectarine. Working with agents: https://vectarineengine.com/guides/working-with-agents/ ↩
16. OpenAI. Harness engineering: leveraging Codex in an agent-first world (2026-02-11): https://openai.com/index/harness-engineering/ ↩
17. East River Source Control. What comes after git (2026-09-10): https://ersc.io/blog/what-comes-after-git ↩
18. Hacker News. steveklabnik on ERSC’s git compatibility layer: https://news.ycombinator.com/item?id=50075405 ↩
19. dmtrKovalenko/odiff: https://github.com/dmtrKovalenko/odiff ↩
20. mstange/samply: https://github.com/mstange/samply ↩
21. Hacker News. duttish on always finding problems after skipping review: https://news.ycombinator.com/item?id=50082912 ↩