Agentic development: how this site was built by a team of one

The site you are reading was designed and built with coding agents doing most of the typing while I did the deciding, and that sentence hides the interesting part, because the agents did not make the work disappear so much as move it. Specification, review and verification became the whole job, and the parts of engineering I used to think of as the work itself, the typing, the wiring, the tests, became something I supervised rather than performed. I want to describe honestly what that felt like, because most of what is written about agentic development is either breathless or dismissive, and the truth I found was neither.

How the work actually ran

Every piece of this site began in plan mode rather than in code. I described what I wanted, the agent asked questions until it could state the job back to me in its own words, and only then did it propose a plan broken into milestones, each with a verification step attached, whether a test to pass, a build to complete or a screenshot to look at. It wrote the tests before the code and then had to make its own tests pass, which sounds like a trick until you have watched it work, because it turns "done" from an opinion into a check the agent cannot argue with, and when a test failed the agent fixed the code rather than the test and had to say so out loud whenever it wanted to change one.

My part was deciding: which direction, which trade-off, when to stop polishing. Those decisions took minutes each and there were hundreds of them, and the typing that would once have taken me days took the agent minutes too, so the shape of a working day changed completely. I spent it reading and choosing rather than writing, and by the end I understood the codebase better than I understand most codebases I have typed myself, because I had read every line of it with the specific intent of finding what was wrong.

Where the look came from

The design was not typed by hand either, and it was not left to a model's defaults, which is the part people find hardest to believe. I used Impeccable, a design skill for Claude Code that treats the visual work as a decision process rather than a prompt. It started by interviewing me about the product, who the reader is, what they must do and what proof exists, and wrote that down before a single colour was chosen. It then derived several visual directions from the world of the reader rather than from the category, rolled a die to choose which one to build so that it could not simply pick the safest, and put the result in front of me on a decision page with the alternatives beside it and a plain "the category standard" option as an exit. I chose the week-to-view diary you are looking at, and the tooling then held me to it: a reviewer agent that had never seen the build conversation audited the pages against the chosen direction and sent back a list of what fell short, and a documenter recorded the finished system so that later changes stay inside it.

I mention this because it is the same discipline as the rest of the workflow applied to a domain where most people assume judgement cannot be structured. It can. The decisions were still mine, but they arrived as choices between real options with the consequences spelled out, which is a better way to make design decisions than most humans manage unaided.

What the console is a worked example of

The Agent Console on this site is a deterministic simulation of an agentic runtime, walking through plan, tool calls, observations and render, and it is scripted rather than model-driven on purpose, because the point is the shape of the loop rather than the cleverness of the thing inside it.

for await (const event of runtime.run(input, ctx, signal)) {
  await pacer.beat(event); // theatre timing, skippable
  dispatch({ type: 'run/event', event }); // reducer records it
}

The tools the console calls, the profile, the CV, the essays, are each defined once behind a typed interface with a name, a schema for the arguments and a function that runs, and the scripted runtime you see today simply walks a pre-written plan through them. A model-driven runtime would choose the plan itself and call the same tools through the same interface, and that is deliberate, because the expensive part of an agentic system is not the model but the contract between the model and the things it is allowed to do. Get that contract right and swapping the brain becomes a small change; get it wrong and no amount of intelligence will save you.

What changes for the people who run engineering

Four things changed in my view, and none of them is "we need fewer engineers", which is the conclusion people reach when they have watched a demo rather than shipped something.

You hire for judgement, because once the typing is cheap the scarce skill is knowing what to build, spotting when the output is subtly wrong and deciding what good looks like, all of which are senior skills, and a team of agents directed by someone without them produces confident rubbish at speed. Review becomes a first-class skill rather than a chore, since reading code, tests and evidence critically is now the job, and teams that treat review as a rubber stamp will ship whatever the agent produced. "Done" comes to include evidence, so that a change is finished when the tests exist and pass, the build is green, the behaviour has been seen working and the record of all that is attached, and because the agent makes producing that evidence cheap there is no longer any excuse for skipping it. And teams get smaller and more senior, not because people are replaced but because the ratio shifts: one person who can specify, review and verify can now direct work that used to need several people to type, which changes how you structure teams, how you grow the people who are not yet senior, and what you are really paying for.

What did not change at all

Taste did not change, because the agent will happily build the wrong thing beautifully, and it took a person to say which of several good-looking options was right for this site and this audience. Architecture did not change, because the decisions about how the pieces fit, where the boundaries sit and what is typed were mine, and they were the decisions that made the agent's work composable rather than a pile of clever fragments. Product sense did not change either, since knowing that a fractional CTO's site should sell an outcome rather than a job title is not something an agent proposes but something you tell it. And accountability did not move by an inch: if this site is wrong, I am wrong, the agent does not own the outcome, and any leader who lets a team believe otherwise has misunderstood what was delegated.

The guardrails that paid for themselves

Plan first, always, with no code until the plan is written and agreed, caught more mistakes than every test combined because it caught them before they existed. Typed contracts between components, with the console's tools, render payloads and state all typed and checked in the build, meant that whenever the agent changed one side of a contract the compiler told it about the other, which is about as cheap and boring a guardrail as exists and one of the most decisive. Table-driven tests, with the console's intent matching specified as a table of inputs and expected intents to which adding a case is one line, grew into the clearest description of what the console understands, because the agent added dozens of rows as it went. And a green build as the definition of done, with lint, types, unit tests, a production build and browser tests running before anything is called finished, both locally and in continuous integration, meant the agent could not declare victory over a red pipeline, and neither could I.

None of those guardrails is new. What is new is that they are now the whole job, and that they cost almost nothing to enforce once the typing is free.