How I build with AI
For most of my career the loop was: design something, hand it off, wait weeks, get back something that wasn't what I meant. That step is going away. I build the thing myself, in code, with agentic AI tools, so nothing gets lost in translation. This page is the actual method, not the pitch.
Interrogate the problem first
Before any pixels, I use the model to pressure test the brief: edge cases, failure states, who the user really is. It is the cheapest place in the whole process to be wrong.
Build the flow, not the frame
Working screens in code from the start. One small flow at a time, adjusted and pushed until it is right, then the next one. If it can't be clicked end to end without narration, it isn't done.
Refine by hand
The tools get it to eighty percent. Spacing, motion, copy and hierarchy are still my job, and closing that gap is where design judgment lives now.
Keep the system honest
Every new pattern gets written back into the project's design conventions, so the next session inherits it instead of reinventing it.
One file keeps it consistent
Agentic coding drifts. Ask for twenty screens over a month and you get twenty dialects: different spacing, different button language, different voice.
So every project I run keeps one conventions file holding design tokens, component patterns and product voice. Every working session loads it, obeys it, and updates it when a convention changes. That single file is why the Search Atlas build reads as one product instead of thirty prompts. It even drives a runtime theming layer in the shipped prototype: light and dark presets, density modes, and motion that respects reduced-motion settings, all from the same tokens.
This site runs on the same mechanism. Its conventions file is in the repository.
# CONVENTIONS ## Tokens color, type, spacing, radius: defined once, referenced everywhere ## Component rules every image opens full screen every state is real: loading, empty, error destructive actions confirm inline ## Voice plain, direct, no jargon buttons say what happens
Three working rules
Field notes from the writing series.
Small prompts, not perfect ones
I used to hunt for the perfect prompt: one giant seed, one perfect result. But a perfect prompt is just another handoff, polished upfront and hoped about. What works is smaller. Set the big picture, then prompt for one flow at a time. A few flows in, the system knows the product, the prompts get shorter, and the results land closer.
Record it, don't describe it
Some interactions defy words: a flow across several screens, a behavior that is timing and motion more than layout. So I record the interaction and upload the file. The model processes the frames and sees the whole interaction play out. Ten seconds of recording beats three paragraphs.
The prototype is not the codebase
A working prototype earns better feedback, but somebody still has to build it for real. I treat the prototype as a live reference held against the production repo, and I am deliberate about where AI-generated patterns become system components and where they stay disposable.
The toolkit
Tools change monthly. The method is what stays.
Proof beats description. Open the Search Atlas prototype and click around, orread how it was built.