Addable Labs — Blog

Ashlands: what one prompt built

Tue, 22 Sep 2026 00:00:00 +0000

On 31 July 2026 we gave Claude Code one prompt: build an action role-playing game at the level of Morrowind, in Three.js, fan out sub-agents, have a separate harsh critic compare each piece against the real game side by side, and don't stop until every critic is wowed. No architecture, no task list, no definition of done. The build ran for three days; on 10 August, at our request, the agent wrote an evaluation of its own run. Both are public: Ashlands is MIT-licensed, and its evaluation report is deliberately weighted toward what went wrong — and is the agent's own account of its own run, worth remembering for every number below.

The prompt follows the Gauntlet Loop, the method Matt Shumer described in How to Run a Gauntlet Loop: run it inside an agentic system rather than a chat, state the goal without prescribing the implementation, give the critic a concrete reference to compare against, let the lead agent split the work into pieces that can be judged separately, and never let a builder grade its own work. Others have run it since; the games they built are collected on his site, several of them very good.

What came out

About 94,000 lines of TypeScript across 160 files; sixteen subsystems, each behind a named contract; eighteen quests with dialogue, factions, crime and a journal; zero binary assets — terrain, materials, sky, flora, architecture, creatures, music and sound all generated from code. The agent also built the machinery that judges it: 32 gate checks and 17 end-to-end checks driving a real browser. At the close the gate was failing 1 of 32, end-to-end passed 16 of 16, and the game ran at 20 to 35 frames per second at capture resolution on a MacBook Air.

And it plays: you can walk the world, use skills and finish all eighteen quests — a script drives every one to its final stage without sticking. What is open is art direction and frame rate: a palette check failing on one vantage, stair-stepping where water meets terrain, mottling at distance. Not a game that falls over — an unfinished one.

What the method got right

Contracts first: one named interface per subsystem, communicating only through an event bus, which let sub-agents write terrain, sky, combat and audio at once with almost no integration conflicts — the report calls it the decision most responsible for the codebase existing. Builders kept away from critics: agents grading their own work declared success, independent critics did not. And negatives as the most valuable output — four of the six rounds in the closing phase ended with an agent making a change, measuring it, finding it worse and reverting, keeping the measurement, and each closed a line of investigation for good.

What went wrong

The brief's terminal condition, a blind side-by-side against the real game, never happened: no reference screenshots were ever obtained, so every "beats Morrowind" score was an agent comparing a frame against its own recollection — a deviation from the method, whose third principle is to give the critic something concrete to inspect.

The most expensive failure was not bad code but confident wrong diagnosis. One vantage rendered as a flat terracotta wash, and three rounds of sub-agents were sent to the terrain material, the lighting and the atmosphere; all three measured correctly, found nothing and reverted. The cause was one missing distance term in the camera-placement search, which had climbed to the nearest high shoulder and aimed point-blank at the peak: no shader change can fix a frame with no depth in it. A second multi-round hunt was the same bug class.

Where the corrections came from

The report is the agent's voice, and it is thin exactly where the human was decisive: we played the game as it was built and steered it. The first-person arms took about eleven rounds. On 1 August: "Those are really bad arms! Fingers go the wrong way and arms look like pipes rather that real arms." Later that day: "The hand looks like a left hand, but the player is holding the sword in its right hand." That evening we compared it to early image generation, where horses had five legs, and asked for the arm to be started over from a picture rather than patched. On 2 August, with a screenshot: "the knockles should be on the right side of the hand, not the left", then "if you dont get the hand right this time, i want you to research how others do it". The agent's own summary of 3 August is blunter than the report: "User feedback each time was correct and mine was not."

The frame rate went the same way: every sub-agent wanted 60 frames per second on a fanless laptop, none got near it, and we worked out why — several agents were testing at once, each driving its own browser and GPU, so what each measured was not what a player would see. "We are doing all development on a MacBook Air. FPS will not become perfect. Also some other agents are working too. Keep going," we wrote on 1 August. The report records that collision as a finding of its own — a load average of 37 on eight cores — and credits "the user" in one clause.

Then we asked for the two things the run was missing: "Build the regression gate, and think about how we can transition from random walk workflow to a highly structured and intentional map of steps you need sub-agents to take." Both are in the repository now: the gate nothing merges without, and a pipeline that serialises verification to one browser and allows one change to the global look per round — a factory, arriving from inside a single-prompt run, two days in.

What it cost

Over three days the run spawned 242 sub-agents across 34 workflow launches — at most seven alive at once, and never ten. They are short-lived, a median of forty minutes, so the total climbed while the number running together stayed small: five or more for seventeen of the seventy-two hours, the crowd behind that load average of 37.

The last six of those 242 ran in the closing phase and five completed: about 1.32 million tokens and 654 tool calls over roughly 3.8 hours, for one shipped visual fix and four closed investigations. The sixth died before reading a file when the account hit its weekly token limit — the ceiling on this method is quota, and quota arrives without warning. About a million of those tokens went into the one vantage whose cause was that missing distance term.

Where the loop fits

The report's closing argument, which it marks as opinion rather than measurement, is that the cost of the loop is set by the critic and not the builder. The builder side worked; judging the work is what consumed the tokens, and this run had close to a worst-case critic on every axis. Two questions predict the outcome better than anything else: is there an executable oracle that answers yes or no without a model's opinion, and does a failing check name the thing to fix? Porting a library, implementing a spec, optimising for speed, balancing a card game over a hundred thousand simulated matches — all yes. A renderer with no reference imagery: no on both counts.

What we take into the factory

We run agents the other way round — stages, gates, a ledger and a founder review before anything is published, which is how this site was built and what the factory article describes. This run was steered, and the steers are in the repository: the arms, the frame-rate diagnosis, the gate and the map of steps. The instruments were built during the loop by the agent whose work they judged, and were wrong seven times. So, for our own runs: build the instrument first and calibrate it against a known defect, put the reference in the critic's hands before the first round, and keep a person where an agent cannot tell you it is wrong. Contract-first decomposition, builders kept away from critics and a clean negative treated as a complete answer — those we take as they are.

The method is what got 94,000 lines running at all, and the report closes by adding to it: a revised starting prompt for anyone rerunning this, whose addition is how the work is to be verified — name the reference, name the instrument, say what a pass looks like before the first agent starts. Run it that way and this run would have ended further along.

Morrowind is named here only as the design target the experiment measured itself against; Ashlands contains no assets from those games. The Elder Scrolls and Morrowind are trademarks of ZeniMax Media.

Why we run an agent-run software factory

Mon, 21 Sep 2026 00:00:00 +0000

Addable Labs builds software largely with AI agents, and since September 2026 this website has been built and maintained by what we call the factory: a small team of coding agents organised like a company, coordinating through a shared issue tracker, with one person in charge. The article How this site was built by agents told the story of one build; this series describes the setup itself, one layer at a time, starting with the obvious question: why run something like this at all, and what is it built on?

What one agent and one person could not do

nivå was built the other way round: one coding agent and one person, 480 commits in 26 days, every one co-authored by the agent. That setup does not start from nothing. A file of working agreements, four written routines — review, gates, deploys and content changes — eighteen notes the agent keeps for itself, ten of them things we have corrected, a progress log with an entry per session and 105 recorded decisions carry the work from one session to the next.

What that setup cannot do is talk to anyone but us. On 12 September, with four agents on one computer, each on its own project, we had the nivå agent write a message we could carry to the other three by hand, and pasted it into the rules file every agent on the machine reads first. Every task starts with us, and when two sessions need to know about each other, we carry the message. That does not scale to agents that plan, build, review and publish while we do something else, and it keeps us in details we do not want to be in.

Three things had to change: the work had to sit in a shared ledger that any session could claim from, not in one project's notes; sessions had to hand work to each other and follow it up without a person in between; and the person in charge had to be involved at a few known points — a plan to approve, a branch to read before it is pushed — instead of all the time.

Steve Yegge's iterations

The setup we run is built on open-source work that Steve Yegge started in October 2025 with Beads, an issue tracker he describes as memory for coding agents rather than a to-do list for people. In January 2026 came Gas Town, his orchestrator: up to thirty agent sessions coordinating through Beads, a dozen or so active at a time, with a fixed cast of roles and a thesis we have adopted wholesale, in his words: "an agent is not a session" — sessions are disposable, the work is persistent. In April 2026 Gas City arrived: in his words, "Gas Town, but torn apart and rewritten from the ground up as an SDK for building your own dark factories". He is careful to say that he did not write it — Julian Knutsen and Chris Sells did. Then in August 2026, "Fences, not Sandboxes" described the organisation of fifty to sixty agents he runs, governed by written rules rather than by containment.

We went through all of that on 20 September 2026 and found that nearly everything we wanted — a factory per project, a coordinator you can talk to, delegation with follow-up, one shared ledger — already existed, was actively maintained and MIT-licensed. We built on it rather than build another orchestrator, and ran the first build the same afternoon.

Gas City and Beads, briefly

Beads is a command-line issue tracker backed by a version-controlled database. Every unit of work is a bead — a task, a message between agents, the record of a session — with dependencies between them. A bead blocked by another is not offered to any agent, which is how order is kept without a central scheduler. An agent claims a bead, works, writes down what it did and closes it; if its session dies halfway, the bead stays open for the next one.

Gas City is the orchestrator around that ledger and hard-codes no roles. An agent is configuration: a name, a prompt, a scope. A formula is a workflow written as steps and dependencies; applied, it becomes a graph of beads that the orchestrator drives to completion, restarting sessions that crash. Packs bundle agents and formulas so that a methodology can be pinned like a dependency. The maintainers' own rule for the framework is that it "moves work; it doesn't reason about it" — the judgement lives in the prompts.

What we took, and what we changed

We took the principles as they are. Work persists, sessions do not. Roles are configuration, not code. Planner, builder and reviewer are different agents, and review runs in several lanes. Rules are written in the files every session reads first. And, from the "Fences" essay, governance by refusal rather than by cage — a fence, in the definition he quotes, is "any mechanism that turns you away if you aren't supposed to be there".

Yegge runs fifty to sixty agents; we run a handful of sessions at a time on one computer and mean to run one factory per project — so far there is one, for this site. The org chart is small: one mayor, and a floor of roles taken as they are from the upstream starter pack — requirements, plan, plan review, decomposition, implementation, three review lanes, a publisher — each started as a session when a build step needs it and retired afterwards. Our own contribution so far is the mayor's prompt, limits on how many sessions one computer runs at once and the rules of a shared machine. The founder's gate sits at the plan, since the second build. No agent pushes on its own: publishing means a branch we read locally, and nothing reaches GitHub until we say so. We talk to the mayor over Discord.

One build, in numbers

The redesign of this site was the factory's second build, and the documents it wrote are in the repository. It began on 20 September 2026 at 17:34 UTC with a short brief, and the review report was finalised at 00:14 the next morning: six hours and forty minutes of wall-clock time. In between, the requirements step produced 31 requirements with acceptance criteria; the plan step rendered three design directions as real pages — we were already looking at them on the preview server and picked one within two minutes of being asked — and approved the reviewed plan at 19:45; the decomposition produced ten work items; one implementation worker, in four sessions, worked through them in 22 commits; and three review lanes found two required fixes, made by a fix lane before the report was written. The branch ended at 39 commits touching 90 source files, passing ten automated gates, 101 tests and Lighthouse scores of 97 to 100 on all seven pages it checks. Our part was six short messages while the run was on — the pick, our corrections, the plan-gate answers — and, next morning, our verdict on the finished page. The run itself was 112 beads, 17 agent sessions in ten roles and ten mails between the mayor and the floor that we never had to carry; nothing went public on the agents' own say-so.

The first build, earlier the same day, took about four hours for 27 requirements and ten work items, needed one required fix and had no gate before the end: we saw the result when it was done and did not like the look of it. Neither run was flawless. In the first, a session claimed a bookkeeping record instead of its task and needed fourteen minutes to work around it; it wrote the fix into its notes, and when the second build's first session hit the same race, it was on its task within a minute. Both runs left us a list of open items; we consider those lists part of the product.

Thanks

None of this would exist without Steve Yegge's willingness to build in public and to release Beads and Gas Town under a licence that let us build on them, nor without Julian Knutsen, Chris Sells and the community around the Gas Town Hall organisation, who made Gas City. Thank you. The code is on GitHub — Gas City, Beads and the packs registry — and the essays are on Yegge's site: Welcome to Gas Town, Welcome to Gas City, Fences, not Sandboxes and Beads Best Practices.

What comes next

The next articles take the setup one layer at a time — the roles, the beads the agents communicate through, the life of a request, the rules a change has to pass, what the founder sees and decides, what went wrong and what it costs.

How this site was built by agents

Sun, 20 Sep 2026 00:00:00 +0000

Addable Labs builds software largely with AI agents, and this website is the first thing an agent-run software factory produced for the company from start to finish, in two builds. This article describes the stages, what we looked at and the checks that stand between an agent's change and a published page.

The stages

Each run moved through a fixed sequence, and every stage wrote a document the next one had to read: requirements, a plan, a review of that plan, a decomposition into work items, the implementation, a review of the result and publication. The requirements turned a short brief into numbered statements with acceptance criteria. In the first build the plan chose the stack and fixed the URL structure, the article schema and the colour palette, with the alternatives it rejected; in the second it chose the design system. The decomposition cut the plan into work items, each with its own proof command, and an agent implemented them one at a time on a local branch.

What the founder reviews

Nothing on this site goes public on an agent's say-so. But the first build ran without a gate: requirements, plan and ten work items went through in four hours, and the founder's verdict on the finished site was "a page from the 90s". The second build put our gate at the plan: we picked one of three rendered directions, answered the plan's open questions and judged the result on the preview next morning. We own the parts no agent can settle: the wording about the company, the Swedish text, which private projects may be mentioned and the steps that touch the domain and hosting.

The gates

One command runs every check, and the same command is set to run on each pull request. It builds the site, checks that every internal link resolves, validates the HTML, checks every page's structure — landmarks, one main heading, a skip link, alt text — measures the contrast of every colour pair in both schemes, confirms that every English page has a Swedish counterpart and both sets of interface strings have the same keys, validates the feeds and greps the output for the facts the pages must state. Each gate has a test proving that it fails when something is deliberately broken.

Two honest observations

Most of what the agents wrote was not code: in the first build, 6,900 lines of requirements, plans, summaries and reviews against 3,700 of site, gates and tests. Precision in the documents mattered more than cleverness in the code: the one fix the review required was a gate that hard-coded a placeholder we are meant to replace.

The gates catch mechanical mistakes, not untruths: a missing Swedish page or a colour that fails contrast is caught automatically; whether a sentence about a product is true is not. So the facts about the apps trace to a source — the README each was taken from and the date it was read — and we still read all of it. Agents also made mistakes: one session claimed a bookkeeping record instead of its task and needed fourteen minutes to work around it.

The site is plain: static HTML and CSS, two small scripts (an appearance toggle and a scroll-reveal effect; the page works without both), one self-hosted typeface and no third-party requests or analytics. That was a decision, and the part that matters — nothing loaded from anyone else's servers — is verified by a gate on every build.