Design, build, prove

Part of my methodology series. If you have not read the overview, start there. This piece goes deep on one part of it: the three steps that do the work on a slice.

Once the memory exists and the conductor has picked the next slice, three steps do the real work on that slice: design it, build it, prove it. I did not build these three. I adopted them from a set of skills by JS Mastery Pro, and I lean on them every day. A good toolbox is not a monument to things you made yourself. It is whatever gets the work done well, and knowing the difference is part of the method.

Design it first

The first step is architect, and its whole job is to stop me building before I have decided. For anything with a real decision in it, a data model, a provider, a pattern, the decision gets settled and written to a small spec before any code is written. So the build has something to build to, instead of inventing as it goes.

The value is not the document, it is the forcing. architect asks the deep questions I would have skipped, weighs the options, and recommends an answer rather than handing me a neutral menu. A decision made in prose, on purpose, with its reasoning next to it, is a decision that survives to the next session. A decision made implicitly, in the middle of a build, is a decision that gets quietly remade the next time someone touches the file.

Review it, every time

Between designing and building there is a step people skip when they are moving fast: read the design again before you act on it. Every time, not just when it feels risky. A second read, ideally on a different model than wrote it, catches the confident mistake the first one is blind to. The model that wrote a spec is the worst judge of it, for the same reason you cannot proofread your own writing well: you read what you meant, not what is there. A fresh reader, or a fresh model, reads what is there.

This has paid for itself more than once. On more than one spec, a review on a second model found a real problem the first model was sure did not exist, and the fix went in before a line of code was built on the mistake.

Build only what was designed

Then develop builds it, to the spec, and nothing more. That last clause is the discipline. An agent given a spec and left alone will help, and helping is the problem: it adds the field you did not ask for, the abstraction you did not need, the extra endpoint that felt tidy. develop builds the decided thing and stops. The spec is the fence, and staying inside it is what keeps a slice small enough to actually finish and verify.

If something load bearing turns out to be undecided partway through, the honest move is not to invent it, it is to stop and route back to the design step. Building a real decision without noticing you made it is the failure mode the whole pipeline exists to prevent.

Prove it by running it

Last is check, and it proves the slice works by running the real thing, not by trusting green tests. Tests pass for reasons that have nothing to do with the feature being right. A test can be green because it asserts the wrong thing, or mocks away the exact part that breaks. So check drives the actual application against the spec’s acceptance criteria, the observable outcomes the design promised, and a failure stops the ship. Proof is a thing you watch happen, not a checkmark you trust.

Why three, not one

You could ask one clever agent to design, build, and verify in a single pass. I have tried. It is worse, for the same reason a good kitchen has stations: nobody is holding the entire order in their head, so nobody drops half of it. A narrow, well briefed step beats one generalist juggling everything, because each step reads the same shared memory and does one job to completion before the next begins.

These three are the middle of the loop. The conductor runs them in order and handles the seams, and the thing they all build against is the memory outside the chat. Design, build, prove: settle it, make it, watch it work.