Making the agents cheaper to run

The audits had made the code cheaper to trust. They had not touched the cost of the agents themselves: what they read, ran and waited on. That week it showed, first as a few kilobytes, then as hours.

Kilobytes and milliseconds

Early on the agents had set themselves limits: how much JavaScript each part of the game could download, and how long a frame could take. By October the download ceilings were stopping work at the merge. On 5 October an agent offered to trim the chapel to squeeze under. "Raised JS limit is fine, don't cut the chapel 0.7kb."

Then I asked the question I should have asked earlier: "In terms of ms limits / ceilings we've set. Have we made these up or are they reasonable to make gameplay feel smooth, based on real world scenarios?" And a minute later: "Let's keep the ms as is for now. Let's relax on the initial Kb download, I don't mind this being raised a little."

The ruling went into the handoff that day: ceilings may rise "when a feature needs it; no piece trims or contorts code to fit." A piece reports its growth and the orchestrator raises the ceiling with a reason. Straight after, it was widened to model and texture downloads, "Meshy models above all". The milliseconds stood.

Under the hood The JS ceilings changed ten times in two days. On 6 October one check failed because the runtime bundle was 0.02 KiB over its line, a fortieth of a kilobyte.

Three days later I said it more plainly: "Don't worry about JS ceilings. I'm happy for our file size to grow and take longer to load up the initial game... It's just performance in the game that I care more about than the actual asset download size." And that afternoon: "So don't have that as a blocker."

Where is the time going?

On 5 October I ran out of Claude usage and Codex took over orchestration for two days. I set it up as I liked: "an orchestrator loading up individual sub agents to work through these, maximum 3 at a time... with a maximum of 3 review rounds." It worked, but it was heavy: sources frozen and hashed before tests, and every batch growing a spec, a ledger, a report and a review file.

On 7 October I asked Codex to critique the whole app and the way we built it. Then: "In agentic development, where is the most of our time going? I'm wary of this game taking a long time to build, and am wondering if we can speed up the development by trimming tests, running tests less often, ensuring agents can quickly work etc."

The report was blunt: "The development weakness is excessive precision and administration in the wrong places." Byte-tight ceilings were on its list.

"Let's do this." The first batch cut what every agent reads at start-up by over a third, and performance reports that had passed when a world failed to load now failed loudly. Then I noticed something I had stopped noticing: "Why are we producing before and after shots? I never look at them? Is it for an agent to review or me? Is it necessary or can we remove some of that step?" They became opt-in.

Under the hood The four start-up documents went from 60,522 bytes to 38,481, with the displaced history kept in three snapshots.

Paper cuts

I kept going, four passes that day. "There must be other things that happen... AI agents have to digest and figure out or produce or do a lot that we are over doing." The second pass found that a change to a Markdown file still launched every unit test.

The third went deeper: "I want to investigate deeply and make paper cuts here that will pay off with long term development. Think through how this will be produced moving forward, so that as we build things out, we don't introduce more slowness over time." It found one test waiting ten real seconds for a failure it could have stepped to, a combat test loading a whole maze just to borrow its scene, and 160 generated adventures that were exact repeats of ones already generated. I had suggested a skill that runs after every merge; the agent added a few cost questions to the existing health check instead.

Under the hood 160 fewer generated adventures and no real-time wait in the failure test. In the fourth pass, on a quiet machine, two village slope checks went from 10.1 seconds to 0.7, with every sample and threshold kept.

The pass was honest about its numbers. One of my other projects was running its tests on the same Mac, so the agent called its after-timings invalid rather than claim a saving, and added a rule: check the machine before starting anything broad.

The agents that undid it

"Where else are we stalling using agentic development. We spin up sub agents from an orchestrator, they do review rounds etc, we know our process, is there any other cost savings here?"

This was the most useful finding of the day. The helper agents had their own instructions, and those quietly undid the cheaper workflow. The test-runner always rebuilt, even when the owner already had the results. The architecture reviewer was told to spawn a fresh reviewer of its own and write a separate report. Fixing the entry points mattered more than any new rule.

What came out: one owner and one independent review for anything consequential, briefs instead of the whole conversation, corrections back to the same owner. Reviewers got a bounded brief too, after two had each searched the whole repo for instruction files before starting. That afternoon the same trim went into my global instructions for every project.

Later that afternoon, in another session: "So if I'm building with agents, what are the time bandits?" And then, a step behind: "Didn't we do 2 rounds of performance." Yes. "Let's do these speed ups."

Too many at once

The next day I went the other way. "Can we load up to five sub-agents...", and in another session, "maybe up to seven so we can start to be more performant and get through this backlog quicker."

Within half an hour: "I'm worried about them sharing heavy playwright tests and competing and reloading each other's work." Then: "they often move my mouse when I'm in the middle of doing something else... my mouse just suddenly jumps around the screen." And: "It's absolutely killing my CPU." I did not want to referee it: "I don't really want to be in charge of doing all this. Can you tell the parent agents of these subagents to orchestrate what gets what resources and wind down all the ones appropriately?" We settled on a shape: "I think I like the 3 owners + 1 reviewer, that seems sensible, let's keep that."

Named specs only

On 9 October a sound agent finished its work and started the whole browser suite. "Sound sub agent is done. I stopped it running a full 2 hour test suite, we can't let that happen... 2 hours running a test suite is not what we need to do!"

A minute later the test selector refused to run the full suite without --full, which only the orchestrator or I can ask for. A piece names the specs that exercise its change and records why they cover it. The review of that change caught one gap at once: the unit tests now run before the refusal, so nothing slips through.

Under the hood The full browser suite took about two hours on one worker. A piece's browser run now aims for under about 15 minutes.

That afternoon: "Are we over-testing with Playwright here?... it just seems like it's probably over-testing things too often, and that's going to be a time bandit on us." I picked three changes: every browser run takes a slot, one check per piece rerunning only a failed step, and merges that rerun only affected tests. "I want to progress things a little bit quicker than we are."

Earlier that day I had turned the same thinking on players: "Let's default the game to 'medium' not 'high'." Detection never picks High now; it is the player's choice.

What I took from it

• Milliseconds are the player's; kilobytes are mine. Guard what the player feels and let the rest bend.
• Ask what each step is for. Nobody looked at the screenshots.
• Fix the entry points. Helper agents follow their own instructions, not the policy page.
• Name the tests. A piece proves its change, not the whole game. And more agents is not more speed on one machine.

This post is about how I build the game rather than the game itself. I build Brackenmere with a team of AI helpers, and one week in October they started getting slower and fussier. I asked where all the time was going, and most of the answer was: do less.

Rules I never needed

Early on, the helpers had set themselves strict limits, like how big each part of the game was allowed to be to download. By October those limits were stopping good work. At one point a helper offered to trim a tiny bit off the chapel just to squeeze under a line.

So I asked whether the limits were real or made up. What matters to me is that the game plays smoothly once you are in it. If it takes a little longer to load at the start, I do not mind. So the limits on smooth play stayed, and the download limits stopped being a blocker.

Where is the time going?

I asked one helper to look at the whole way we worked and tell me honestly where the time went. Its answer was blunt: too much precision and paperwork in the wrong places.

So we cut back:

• Each helper had a pile of instructions to read before starting. That pile shrank by over a third.
• They took before and after screenshots for everything. I asked who those were for. I never looked at them, so they stopped.
• Some checks were slow for no reason, like one that waited ten real seconds for something it could just skip to.

The helpers undoing it

The most useful find was sneaky. Some helpers had their own instruction sheets, and those quietly undid the new, simpler way of working. One always redid checks that had already been done. Another was told to hire its own extra inspector and write a separate report.

Think of a building firm that changes its policy, but the old instructions are still pinned up in every van. Fixing those instructions mattered more than any new rule. What we settled on: one person owns each job, one other person checks it, and they get a short brief, not the whole history.

Too many at once

Then I went the other way and asked for five or seven helpers working at once to clear the backlog faster. Within half an hour my computer was struggling, and my mouse kept jumping around the screen while I was trying to work. We settled on three helpers building and one checking. On one machine, more helpers is not more speed.

Two hours of checks

Near the end of the week, a helper that had finished some sound work started running every single check in the whole game, which takes about two hours. I stopped it. Now each helper has to name the checks that actually cover its own change and say why. Only I, or the lead helper, can ask for the full two hours.

I applied the same idea to players too. The game now starts on a medium picture quality setting rather than the highest one, and you can choose to turn it up.

What I took from it

• Guard what the player feels, and let the rest bend.
• Ask what each step is for. Nobody was looking at those screenshots.
• Fix the instructions people actually read, not just the policy.
• Check the change you made, not the whole game every time.