Don’t Learn to Vibe-Code. Learn to Build.
What fumbling around with AI taught me about thinking, context, systems, and the increasingly important role of judgment.
Recently, I had the opportunity to give a talk at the IxDF San Francisco Vibe Coding Hackathon about how AI has changed the way I think, design, and build.
Since then, I’ve been genuinely surprised, inspired, and humbled by how many people have told me that the talk resonated with them. Some said it helped them make sense of their own experience. Others said it gave them a clearer way to begin building with AI.
That was exactly what I hoped it might do.
I didn’t arrive at this way of working through some carefully designed master plan. I fumbled my way here.
I started by trying to write better prompts. Then bigger prompts. Then extremely detailed prompts containing enough headings, rules, and exceptions to qualify as minor international treaties.
I built too quickly. I let AI fill important gaps with assumptions. I changed five things at once and then had to figure out which one broke everything. I trusted the word “fixed” more often than I should have.
Slowly, all those mistakes began to resemble a process.
Building as an Extension of Designing
AI has not turned me into an engineer. Not even close.
What it has done is extend my reach as a designer and builder. It has removed a tremendous amount of the distance between something I can imagine and something I can actually make.
I can now carry an idea much farther through research, strategy, product definition, experience design, prototyping, and implementation. That doesn’t eliminate the need for engineers or teams. It lets me explore and prove more of an idea before I need them.
The Wyze Never Wonder project became a particularly good example. I began with an ambiguous job description, a Wall Street Journal article, the existing Wyze experience, public research, and a hypothesis.
From there, I developed a point of view, wrote a PR/FAQ, defined the product, designed the system beneath it, established the visual and interaction rules, planned the build, and created a working prototype.
The prototype was interesting.
The compression of that entire process was much more interesting.
Three Things I’ve Learned
Looking back at that work, and a lot of other things I’ve built, I’ve distilled my current approach into three “Doon-isms.”
Plan Before You Prompt
The blank prompt box isn’t the starting line. Thinking is.
Get clear about the problem, the objective, your assumptions, and what good looks like before asking AI to make anything.
You don’t need to know the solution before you begin. But you should understand what you’re trying to accomplish well enough to recognize whether the work is moving toward it.
Think Systems Before Surfaces
AI can make something that looks pretty good remarkably quickly.
Without the right context and guardrails, however, “pretty good” can become inconsistent, incoherent, or structurally shaky just as quickly.
Give AI the requirements. The brand. The information architecture. The conceptual model. The screenshots and sketches. The references, constraints, and design rules that should remain true as the product evolves.
Don’t merely describe the surface. Give AI the system that should govern it.
That’s how you avoid AI drift.
Think Future Before Feature
AI is very good at working locally.
Ask it to build a feature, and it will focus intently on that feature. It is less likely to step back and ask how the feature belongs within the greater system.
Will we need this capability again? Should it become a reusable component? What data, services, permissions, or workflows should be shared? Are we creating a foundation or another one-off thing we’ll have to untangle later?
AI can help build the pieces. We still need to think about how the pieces become a system.
Judgment Is Still Our Job
This brings me to what I believe is the designer’s most important role throughout all of this: judgment.
- Are we solving a real problem—or starting with a solution and looking for one?
- Are we solving it for the right person?
- Did we identify and prioritize the most important use cases?
- Does each feature earn the complexity it introduces?
- Can this be simpler?
Those aren’t coding questions. They’re design questions.
AI made building easy, but it also made judgment critically important.
The tools will change. They may have changed by the time you finish reading this. But learning how to define an idea, provide meaningful context, think beyond the immediate feature, and judge the work honestly will remain valuable.
Vibe-coding might get you started. Building is what gets you somewhere.
View “Don’t Learn to Vibe-Code. Learn to Build.”
If this talk would be useful to your team, class, design community, or organization, I’d be happy to share it again.
Reach out and let’s talk!
Turning complexity into clarity, alignment, and action.