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, and 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.