Every Ten Percent Buys Three Things

Midway through a week of building, I checked my usage and saw I had burned a third of the weekly allowance in a little over a day. Some of that had bought real progress. Some of it had bought a feature that took twice the effort it should have, and one design call the machine got backwards, which I caught only after it had been built around.

That was the day I started treating the budget as a design tool.

This is the last of three dev diaries on the new game. The first was about reading your novel as a map, the second about cutting the screen back. This one is about the meter.

The Meter Is the New Deadline

Writers know deadlines. A deadline forces scope: the scene you cannot finish by Friday gets cut or simplified, and the book is often better for it.

Building with AI agents swaps the calendar deadline for a usage allowance that resets once a week. The agents work through the night, so the allowance runs out long before the hours do, and every hour of agent work draws it down whether or not that hour produced anything worth keeping.

Once I started treating percent of the week as currency, every feature came with a price, and the useful question became whether something else on the list would give the player more for the same spend.

Once every feature has a price, the question of what to build next mostly answers itself.

The Rule

The rule I settled on is simple enough to check at a glance: every ten percent of the week should buy at least two or three significant features, each with real testing behind it. A feature that costs more than its share needs a written reason, recorded in the ledger next to what it cost.

The ledger is a small script that reads the work logs, totals what each build cost, and converts it to a share of the week, calibrated against the usage number I read off my own account. Every finished item gets a line: its estimate, its cost, the features it delivered, and whether it met the rule.

The ledger catches drift early: an item running at twice its estimate shows up while there is still time to stop it. Over time it also builds a track record, so each new estimate starts from what similar work really cost. Within a week the estimates were close, and deciding what to build next took minutes.

The Hidden Taxes

Most of the waste came from three places I did not expect.

Restarts. The machines the agents run on get recycled now and then, and a long job that had not saved its progress lost hours of work in an instant, then spent more of the allowance redoing it. The fix was a habit borrowed from writing: save after every scene. Every step now commits its work and leaves a note saying what is done and what comes next, so a restart now costs minutes.

Testing in the wrong places. A slow test run that checks everything is expensive. A fast change that skips the screens it touched is more expensive, because the bug comes back later and costs a second round. The rule that settled it: a small change runs every test of the screens it touches, and nothing more.

Reviews that never end. One careful critic and one round of fixes finds nearly everything worth fixing. Every extra round after that bought less and cost the same.

The Expensive Mistake Is a Wrong Target

The costliest error in the whole project was a balance target I had accepted without thinking hard enough about it. The machine tuned the game so that a lazy, low-skill way of playing could still win now and then, because the target said that player should have a floor.

When I looked at it, the answer was immediate. A player who refuses to use the game’s tools should lose. One sentence corrected the target, and the work tuned around the old goal had to be redone.

The machine is very good at hitting whatever target you give it, so the quality of the target decides everything. It will not stop to ask whether that target makes sense unless the task tells it to. That question belongs to the author, and it is the cheapest work in the project: a minute of judgment up front saves a day of building in the wrong direction.

Writers have a version of this. An outline that aims the book at the wrong ending gets executed faithfully by every chapter you write against it. The sentences can be beautiful and the book still fails.

A machine will hit any target you give it, which makes choosing the target the most valuable minute of your week.

Plans in Three Sizes

The budget conversation got easier once the first question was how much I could spend. Before a week with an uncertain allowance, I asked for three plans, at five, ten, and fifteen percent, each one building on the last and priced from the ledger’s record.

That turned an open question into a menu. The smallest plan contained the one change that mattered most to how the game feels, and each larger plan added work that mattered less. I could pick a size once I knew what the week allowed, and the work started within minutes.

Every plan comes with a hard cap. Each stage of the work checks the meter and stops itself before the line, leaving the project working and saved. A run that hits the cap delivers less, and everything it delivers works.

For Your Own Allowance

You do not need AI agents to use this. Every writer works against an allowance of hours, energy, or money, and most of us spend it without pricing anything first.

Write down what a project should cost before you start, record what it took, and let the gap teach your next estimate. Save after every scene so an interruption costs minutes. Keep one round of revision and one critic, and stop there. Above all, spend a minute checking the target before you spend a month hitting it.

The allowance runs out either way. The difference is whether it ran out on the right things.