How astrand.xyz V0.3 was built by an agent team

How it started

The old site was from early 2025. I built it to win contract work, and by now it had known security holes and astrand.xyz didn't answer anymore.

I started with a project starter I built for my kit. It can take a new idea or, like here, an existing repo, and it asks for the idea in my own words first. I said I wanted my newest work on it, no more contract-work copy and a new look. Then a few picks, like the size (I said medium), and a card saying what it thinks I'm building. I said that's right, and to show my Claude Code work too.

After the card a research agent looked at the stack and at dev portfolios people and employers like. The site was on Next.js 15.1.6, open to every security advisory since March 2025. A roadmap agent split the work into releases: safe and live first, then the content, then the redesign.

A critic agent went through the roadmap and the first plan and found six musts. One was that old secrets from the mail form still worked, so I revoked them that day. The starter fixed the rest, then wrote the first plan and the project skeleton with the working notes, the check script, CI and Dependabot.

The first release, V0.1, made the site safe and put it back online. The build run's navigator, an agent on Opus at high effort, moved it to Next.js 16 and React 19.3. The crypto donations and the mail form came out, and so did every line offering contract work. It used about 13.5M tokens of a 15M budget. I merged it at 15:02 UTC and a few minutes later astrand.xyz was back on Vercel over HTTPS.

The plan

For the redesign I wanted the site to show my newest work in blockchain, full stack and sustainability, and to look modern without losing what made the old one memorable.

Before any code, a design round in its own session. A design agent on Fable at high effort wrote a brief from the research on what employers like in dev portfolios and gave me three directions. I picked the voxel garden, the cube tree you see on the home page. Then two designers on Opus at medium effort drew two layouts for each page, and around 16:10 UTC I picked the grid for home and the story beside the facts for about.

Then a planning session. A planning agent on Opus at high effort drafted the step table, I answered its open questions and stamped it ready to build. Eleven numbered steps, each with who builds it, on which model, what to check and a budget. The estimate said 38M tokens.

Every row reads like that one. A builder gets one step, the files it may touch and the check that says it's done.

The build

The navigator, again an agent on Opus at high effort, ran the release from 16:41 UTC. A builder on Sonnet at medium effort moved the site to Tailwind 4 first. Then builders on Opus at medium effort took the page-sized steps, one each: the first built the frame, with colour tokens for both themes and a sticky nav, and the second made the cube and the tree that builds itself.

Then a third Opus builder made the home page and a fourth the about page at the same time, each in its own worktree. Both were merged in by 17:09.

QA ran two agents at a time, all on Sonnet: one at 375 pixels, one on desktop, one on the toggles and the tree, and one against my taste file. An accessibility reviewer on Sonnet at high effort checked accessibility, and the design agent read the build against the design brief.

Lighthouse on mobile gave 98 for performance and 100 for accessibility, on both pages.

A reviewer on Sonnet at high effort went over the branch and found one must, cube marks that came out 18.9 pixels tall. A writer agent on Sonnet at medium effort wrote the README and the pull request. The draft was up at 17:59, an hour and 18 minutes after the navigator started.

I read the draft at 19:49 and sent eight notes, more on those below. One asked for more of the screen on wide desktops, so a designer drew two options and I picked the one with more side by side. A builder had it in by 20:00.

A wrap-up session went over the token use and what caused the rework. On my go the release merged at 20:25 UTC and went live the same evening, checked at 375 and 1024 pixels.

What went over

71.6M tokens used against 38M planned. Almost twice.

The build itself ran a bit over, 44.7M to the draft. Then I read the draft and sent eight notes: a card link on a domain that had lapsed, both climate jobs that should read as climate work, Node.js missing from my skills, and more of the screen used on wide desktops. Those notes cost 27M, and 22.4M of that was the navigator.

In total the navigator used 47.1M of the 71.6M, about two thirds, carrying the whole release in one session. By model it was 86% Opus, 14% Sonnet and 1% Fable.

The builders stayed under their budgets, all but one QA pass that went 0.1M over.

Some rework came from not looking. Links were written and never opened, and the tree painted only its bottom slab at 1024 because the browser pane the agents check in draws no frames.

What I'd change

Give the navigator less to carry. My notes on a draft now go to a fresh session, not the one that ran the build, and the navigator should hand its probing to an agent instead of reading everything itself.

The team also learns as it goes. After each release a wrap-up session goes over the run, its token use and its rework, and turns what went wrong into a lesson in the project's lessons file, which the next release reads. A link on a lapsed domain reached my read this time, so every outbound link gets opened before a commit now, and every cube size is a whole pixel. Both are checks the builders run.

It picks up my taste the same way. Every time I send a design back it becomes a rule in a taste file, with my words beside it, and the builders and QA read that file. When I asked for more of the width on desktop, the rule became that wide screens show more side by side, never the same layout scaled up.

The agents and their checks live in my Wolfpack kit (opens in a new tab), which is public on GitHub.