The agent is the tool. The system is the product. The workflow is the leverage.

The codebase is the design tool. A playground branch is the artboard.

I build and iterate there until the interface, states, and edge cases are accounted for, then port the finished work to a clean branch, productionize it, and raise the PR.

A static mockup lies about the states. It shows a screen with plausible data and says nothing about the empty case, the error case, the permission state, or the edge case three months in.

Those are where a product is actually decided.

In a real codebase, they are one click away.

Every feature on the playground branch gets a floating toolbar of state controls. Loading, empty, error, success, different permissions, different data. Whatever matters is directly reachable without completing the flow to get there.

That turns a prototype from something you demonstrate into something people can actually interrogate.

A stakeholder should not need me to walk them through the happy path. They should be able to poke at the thing themselves.

It also forces the states that usually get forgotten to exist before production ever sees them.

Every feature moves through the same stages:

Brainstorm → Specify → Plan → Build → Verify

Between each one, I stop.

I review what exists, compare it against the intent, and decide whether it deserves to move forward.

That is the safety mechanism for working with agents.

Agents can produce a lot of plausible work very quickly. The dangerous failure mode is not bad code. It is a week of confident work in the wrong direction.

Reviewing between stages makes the cost of being wrong one stage instead of one week.

Before building anything new, I audit what the design system already provides.

Existing components come first. Established patterns come first. New primitives only exist when the existing system genuinely cannot express what we need.

And when something new is necessary, it is built as a reusable component from the start, not as a one-off that someone has to clean up later.

The goal is to extend the system, not turn the codebase into slop soup.

Important decisions do not live inside a conversation.

They live in written memory: worklogs, decision indexes, project context, business rules, and invariants that survive when a context window disappears.

That is what makes multi-week agentic work possible.

A decision gets argued once, recorded, and carried forward. Without persistent memory, the same decisions get re-derived across sessions, often slightly differently each time.

That is how systems quietly drift.

If a change touches an interface, I verify it through that interface.

Not through a terminal. Not through a unit test. Not by reading the diff and deciding it looks right.

Visual changes are screenshot-verified. Interactive flows are driven end to end. Risky changes are previewed in isolation so the running environment stays safe.

If I cannot prove something through the path a user would actually take, I call it unverified.

Verification is not a feeling. It is a claim you earn.

Every feature gets handed over in writing as part of building it, not when someone eventually asks for documentation.

The handover answers three things:

What is it? What was built? Why does it work this way?

Implementation detail is mostly chaff. If it does not change how someone understands or uses the feature, it probably does not belong.

The most valuable part is usually the boundary between systems: how two things connect, and especially where they do not connect even though a future engineer might reasonably assume they do.

Those are the details that cost someone a day.

And the document should state decisions, not debate them. Settled decisions are written as settled. Open questions get their own section.

A document that hedges every decision can look thorough while being completely useless.

The canteen project is the clearest example.

The first version, a payment log, was specified, built, and verified in a single day. Two and a half weeks later, it was demoed to the founder, who brought a better model for how the product should work.

So we threw it away.

The second version was rebuilt in five days.

Throwing away two and a half weeks of work should be a crisis. It was a normal Tuesday.

And that is the real return of this workflow.

Not typing faster.

Making it cheap to be wrong.

Because when being wrong is cheap, you can find out earlier, change direction faster, and end up with a better product.