Essay · Practice
A Tool,Not a Solution
How I'm using AI in my design process — the tools, the handoffs, and what I still don't have figured out.
Most writing about AI and design picks a side. Either the tools are about to replace the craft, or they're a novelty that produces slop and wastes everyone's time. Both positions are comfortable. Neither is much use if you're actually trying to ship something.
The distinction I keep coming back to is between using AI as a tool and expecting it to be a solution. A solution is something you hand a problem to and wait for an answer. A tool is something you operate — you decide what's being made, you hold the standard, you're accountable for the result. Every useful thing I've built in the last stretch came from staying firmly on the tool side of that line, and most of the ways I've wasted time came from drifting toward the other one.
What follows is the method as it stands: refined in the sense that it's been through real work, experimental in the sense that I expect half of it to be wrong within a year.
It's also, deliberately, a map. If you're a designer who wants to start actually making things rather than describing them, the fundamentals are all here.
Three phases, roughly
Using them to go faster. Early on it was substitution. Copy, variants, boilerplate, the tedious middle of a task. Real time savings, no change in how I worked. The ceiling showed up fast: output quality tracked exactly with how much context I could hold in my own head and retype every session.
Using them to gain context. The shift was bringing them into the ambiguous part of the work instead of the mechanical part — interrogating a problem, pressure-testing my own framing, doing landscape research, working out what I actually meant by “good” before anything got made. Still tools. But pointed at judgment rather than execution, and better used the more I brought to them.
Using them to build. The current phase, and the one I find genuinely interesting. Design has always ended at the handoff — you describe the thing, someone else makes it real, and a lot gets lost in the translation. These tools move that line. I can take an idea all the way to working software myself: real code, a real database, deployed to a URL. Not because the tools design anything, but because they cover the distance between knowing what should exist and having it exist.
That's the whole argument. With these tools in hand, the output of design work can live in code rather than beside it. Not a picture of a thing. The thing.
With these tools in hand, the output of design work can live in code rather than beside it.
That distinction matters more the further out you look. What I'm working toward is a version where what a designer produces translates directly into production code, and a whole category of back-and-forth goes away with it: the requirement juggling, the long reconciliation between what a user needs and what the system can actually do. The familiar version of that is a designer saying here's what I think it should do and running into resistance from engineering partners on technical feasibility — a conversation they usually can't participate in on the merits.
What's changed for me is that I now have that context, and I got it by building. Every time I use these tools to make something real, I learn how real things are made — what's cheap to change and what isn't, where the constraints actually sit, what a system can and can't be asked to do. That understanding doesn't limit the ideation. It sharpens it. I can produce solutions that land much closer to production-ready than they used to, because I'm working from an understanding of how things get built rather than a guess at it.
The tools didn't give me the ideas. They gave me the reach to build them, and building them taught me the rest.
The stack, and what each thing is for
None of this is exotic, and none of it does the job for you. The leverage is in knowing which tool is holding which part of the work — and staying the person who decides what's being made.
Chat models — ChatGPT and Claude — for context.
This is where the ambiguous work happens, and it runs in two passes. The first is a brain dump. I get everything I know about the thing out of my head and into the conversation, unstructured and unfiltered — what I think the problem is, who it's for, half-formed ideas about how it works, constraints I'm assuming, the parts I'm unsure about. Then I use the model to interrogate it: what's actually the problem here, what's out of scope, what am I taking for granted. The point isn't answers. It's framing and scope. Most of what I dump gets cut, and knowing what to cut is the output. Only once the thing is scoped do I go looking. Research after framing is targeted — how have others solved this specific problem, what's the landscape, what should the architecture be, what am I going to run into. Doing it in the other order is how you end up with a pile of interesting reading and no clearer idea of what you're making.
Component libraries — shadcn and equivalents — as the shortcut past visual design.
This is the part that surprised me most. Grabbing an off-the-shelf library means the first version of a thing can be functional without being designed in the traditional sense — no branding, no visual refinement, no fussing with spacing. Just competent, unremarkable components wired up so a person can actually do the thing. That's the point. Build the practical version first, put it in front of someone, and let what it needs to be emerge from what it actually has to do. It's form following function, taken literally — function gets established, proven, and put on a pedestal, and the finish comes after, in service of it. Refinement applied to a thing whose function is still unsettled is decoration, however good it looks.
Codex and Claude Code as technical contributors.
This is the reframe that changed how much I could actually ship. They're not autocomplete, and they're not a solution you hand a problem to — they're contributors you brief. They read a repo, hold a codebase in context, run commands, install dependencies, and push work back. You give them a spec and review the result the way you'd review any collaborator's: closely, and with opinions. Claude Code lives in my terminal against a real repo; Codex handles plugin and tooling work on my work machine. Same posture either way — brief clearly, review honestly, don't accept output you don't understand.
GitHub as the substrate.
Version control is the unglamorous prerequisite for everything above. It's what lets an agent work on a branch without endangering anything, what makes a bad generation reversible, and what turns “I made a thing” into “the thing exists somewhere other than my laptop.” If you're starting from zero, start here.
Supabase for data.
When a prototype needs to remember something between sessions — accounts, saved state, real records — this is the shortest distance to a real database without becoming a backend engineer. Most design prototypes die at the point where they'd need persistence. This is how you get past it.
Vercel for hosting.
The final step, and the one that matters more than it looks. Deployment turns a demo into a URL you can send to a person. The difference between those two things is the difference between a prototype you talk about and one you learn from.
Markdown is the handoff
A useful practice I've picked up: research and plan in one model, package the output as a markdown file, hand that file to another model to build from. The file is the steering wheel — it's how you stay the one deciding what gets built. A markdown file gives you more agency into the intelligence.
Chat context is disposable. It doesn't survive the session, it doesn't move between tools, and it slowly degrades as a conversation gets long. Every time it resets, the model fills the blanks with its own defaults — and you inherit whatever it assumed. A markdown document survives all three. It's the artifact that carries your judgment across the gap, so the intelligence works from your intent instead of its guesses.
In practice: I'll spend real time in a chat model working a problem — the use case, the constraints, the architecture, the edge cases, what “good” means for this specific thing. Then I ask for it as a spec. Not a summary. A document precise enough that something with no memory of the conversation could build correctly from it. That file goes into the repo, and Codex or Claude Code builds against it.
Three things this buys you. First, portability — the same spec runs in any tool, this week or next month. Second, control — every decision you write down is one the model no longer gets to make for you, which is the whole game as these things get more capable. Third, and less obvious: writing the spec is where you find out whether you actually understand the problem. A model will happily build from a vague document and hand you something vaguely wrong. The gaps in the markdown are the gaps in your thinking, exposed early and cheaply.
Takeaways
A tool, not a solution. The moment you're waiting for an answer instead of operating toward one, the quality drops and you stop learning anything. Stay the operator.
Make new things, not better versions of old ones. The reflex is to point these tools at work that already exists — remake the dashboard, redo the form, rebuild something that works fine already. But the cost of building falling should change what gets built, not just how fast the same things ship. The interesting version is the thing that wasn't worth making before: too small to staff, too strange to justify, too specific to one person's problem. Those are buildable now.
The designer owns the definition of good. The model can produce a hundred options. It cannot tell you which one is right, because “right” is a claim about people, and it has no stake in them.
Encode judgment; don't repeat it. A correction you make twice is a rule you haven't written yet.
Structured inputs beat clever prompts. Prompt craft has a low ceiling. Real constraints — a written spec, explicit patterns, an actual codebase to work against — raise the floor for everything you make, permanently.
If it can't deploy, it isn't finished. The gap between something running on your machine and something a real person can open in a browser is where most of this work quietly dies.
Speed is only useful if evaluation keeps up. Generating faster than you can judge just means producing more of what you haven't checked.
Open questions
I'd rather leave the open questions open than pretend I've closed them.
Where the role ends. If I can carry an idea to working software, I'm doing work that used to belong to someone else. That's useful right up until it isn't — I'm not an engineer, what I build isn't production-grade, and I don't always know where that line falls until I've crossed it. The version of this I trust involves engineers earlier, not less. I haven't worked out the shape of that yet.
How deep the technical understanding needs to go. Enough to build has turned out to be enough to design better. Whether enough to build is enough to design responsibly — at real scale, with real constraints I've never had to live with — is a different question, and I don't think I can answer it from where I'm standing.
When finish starts to matter. Building the practical version first is right. But shipping the practical version and calling it done is a failure mode, and the tools make it an easy one — everything works, nothing is wrong, and the thing is somehow lifeless. I don't have a rule for when function is proven enough to start pushing on form. Right now it's a judgment call every time.
Where I think this goes
Honestly, nobody knows. Not even the brightest people at the orgs actually building these tools — let alone little ol' me. It's early enough that the landscape six months out is a guess, and a couple of years out is barely worth speculating about.
Which is the reason to be in it rather than a reason to wait. The only clearly wrong move right now is to write it off — to decide from the outside what these tools are and aren't good for, and never find out. Everything I understand about this came from using them badly first.
Things worth your time
A few of the pieces that have shaped how I think about this: