I'm a designer. My degree is in microelectronics, my graduate work is in psychology, and nothing on that list says "writes production React." Yet this site — the fluid type system, the MDX content pipeline, the interactive 3D graph on the lab page — is code I shipped. Not code I typed. Code I directed.
This is the first entry in a learning log I intend to keep adding to: periodic snapshots of what building-by-directing actually looks like as the method matures. This snapshot is about the method itself — a five-stage loop I now run every substantial feature through, and one feature that went through it three times before it earned its place.
The loop
Each stage exists because of a specific failure mode I kept hitting. The judgment came first; the tooling — a set of named, reusable AI workflows I've built up as skills — just makes the judgment repeatable.
1. Interrogate the decision. The failure mode: starting to build while half the decisions are still unmade, then making them badly, mid-implementation, under sunk-cost pressure. So before anything gets built, I have the AI interview me — a structured interrogation called grill-me that walks every open decision one at a time, each question paired with a stated recommendation and its reasoning, so I'm always reacting to a position rather than a blank page. The artifact is a decision list. Nothing downstream starts until it's complete.
2. De-risk the unknown. Some questions can't be answered in a document — "will this layout feel right?" only resolves on screen. The failure mode is treating those questions as settled because a plan paragraph says so. For these I run prototype: build the risky part live, throwaway by default, judge it with my own eyes, keep or kill. The artifact is a verdict, not code — the prototype is allowed to die.
3. Phase the work. The failure mode: handing an AI one giant ask and getting one giant, unreviewable result. plan-pipeline dismantles the work into phases, each with explicit success criteria and — because not every phase deserves the same firepower — a routing decision: which model executes it, at what level of effort. Mechanical file-shuffling gets a cheap fast model; anything a visitor will see gets the expensive one. The artifact is a plan file any future session can execute without me re-explaining the project.
4. Execute. Claude Code runs the phase — reading the plan, writing the files, running the type checker, verifying against the success criteria. My job at this stage is the one a director has on set: watch the monitors, veto, redirect. The artifact is the diff.
5. Adversarial check. The failure mode is the most dangerous one: work that looks finished. Code that renders, passes the type checker, and is still wrong in ways I don't have the engineering background to spot on read-through. So the last stage is code-review — a separate AI pass whose only job is to attack what the previous stages produced. It has caught real bugs on this site that I would have shipped: not style nitpicks, logic that would have broken quietly later. The artifact is a findings list, and the loop doesn't close until it's empty or explicitly waived.
Interview, prototype, plan, execute, review. The names are mine; the discipline is older than any of the tools — it's just a design process, pointed at code.
Three graphs, two funerals
The lab page's nebula — a 3D force graph of my actual working system: wiki, skills, automations, projects — is the loop's best worked example, because it went around the loop three times and the first two outputs are dead.
I ran prototype to iterate the nebula. Version zero was a force-cloud: physics-settled, every branch in its own color, a glowing grid floor. Technically it worked. Visually it read as chaos — my own reaction on seeing it live was that the full palette looked less like a knowledge system and more like a virus render.
Version one swung hard the other way: a deterministic radial tree, one quiet mono palette, every branch mapped faithfully to the real folder structure. Calmer — and worse in a subtler way. Folder-faithful turned out to be the wrong loyalty. Visitors don't care where my files live; they care what the system does, and a directory tree answers the wrong question.
Version two reorganized the same data by meaning instead of location: a content nucleus at the center, a ring of tools around it, projects in their own zone, with a depth cascade from light center to dark rim. That's the one that's live.
The part I want a reader to take from this isn't the graph. It's the funeral discipline. Each dead version was judged live, killed on the spot, and archived at a git tag — recoverable, citable, out of the way. Two full builds abandoned without ceremony is not waste; it's the prototype stage doing exactly its job, at a cost low enough to make killing easy. That discipline — build live, judge, kill, tag — is the thing that transfers directly to client work, where the temptation to defend a sunk cost is even stronger.
The bench
The loop is the spine, but most days also draw on a bench of narrower skills — each one, again, a piece of judgment made repeatable. A few, with the moment they earn their keep:
When a transition feels wrong but I can't say why — motion. It carries the animation judgment I'd otherwise reconstruct from scratch each time: spring curves over duration guesses, performance audits that catch layout thrash, and a library of reference patterns to adapt instead of invent. The page transitions on this site went through it.
Before any stack decision — research. The failure it prevents is deciding from a marketing page. It goes to primary sources and community signal, and returns a written brief with confidence levels — which is how this site ended up not building an auto-tweet pipeline, after the research showed the integration path had been quietly killed.
When something needs to look like a designer made it — a chain of design skills (design, frontend-design, ui-ux-pro-max) that front-load visual direction before any UI code: style, palette, and type decisions made explicitly, so the implementation stage executes a direction instead of averaging one.
When work leaves my desk — handoff and to-spec, which package a build's decisions and constraints so the next person — or the next AI session — inherits context instead of archaeology.
None of these is impressive alone. The point is the shape of the whole: a system where each hard-won piece of judgment gets a name, a home, and a way to be invoked on demand. That system is the actual thing I've built this year. The site is just its most visible output.
What this entry pins down
A year ago, "designer who codes" would have been a stretch for me. What changed isn't that I learned to type React — it's that I learned the loop: interrogate before building, prototype before committing, phase before executing, review before shipping. The typing turned out to be the fungible part.
Next entries in this log will be narrower — single features, single failures, whatever the method learns next. This one just needed to put the method on the record.