{"id":1807,"date":"2026-09-05T15:30:42","date_gmt":"2026-09-05T22:30:42","guid":{"rendered":"https:\/\/malekzadeh.net\/doon\/?page_id=1807"},"modified":"2026-09-05T15:37:35","modified_gmt":"2026-09-05T22:37:35","slug":"how-i-ai","status":"publish","type":"page","link":"https:\/\/malekzadeh.net\/doon\/how-i-ai\/","title":{"rendered":"How I AI \u2193"},"content":{"rendered":"\n

Don\u2019t Learn to Vibe-Code. Learn to Build.<\/h3>\n\n\n\n

What fumbling around with AI taught me about thinking, context, systems, and the increasingly important role of judgment.<\/h5>\n\n\n\n

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.<\/p>\n\n\n\n

Since then, I\u2019ve 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.<\/p>\n\n\n\n

That was exactly what I hoped it might do.<\/p>\n\n\n

\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
View the presentation<\/strong><\/a><\/figcaption><\/figure>\n<\/div>\n\n\n

I didn\u2019t arrive at this way of working through some carefully designed master plan. I fumbled my way here.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u201cfixed\u201d more often than I should have.<\/p>\n\n\n\n

Slowly, all those mistakes began to resemble a process.<\/p>\n\n\n\n

Building as an Extension of Designing<\/h3>\n\n\n\n

AI has not turned me into an engineer. Not even close.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

I can now carry an idea much farther through research, strategy, product definition, experience design, prototyping, and implementation. That doesn\u2019t eliminate the need for engineers or teams. It lets me explore and prove more of an idea before I need them.<\/p>\n\n\n\n

The Wyze Never Wonder project<\/a> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The prototype was interesting.<\/p>\n\n\n\n

The compression of that entire process was much more interesting.<\/p>\n\n\n\n

Three Things I\u2019ve Learned<\/h3>\n\n\n\n

Looking back at that work, and a lot of other things I\u2019ve built, I\u2019ve distilled my current approach into three \u201cDoon-isms.\u201d<\/p>\n\n\n\n

Plan Before You Prompt<\/h4>\n\n\n\n

The blank prompt box isn\u2019t the starting line. Thinking is.<\/p>\n\n\n\n

Get clear about the problem, the objective, your assumptions, and what good looks like before asking AI to make anything.<\/p>\n\n\n\n

You don\u2019t need to know the solution before you begin. But you should understand what you\u2019re trying to accomplish well enough to recognize whether the work is moving toward it.<\/p>\n\n\n\n

Think Systems Before Surfaces<\/h4>\n\n\n\n

AI can make something that looks pretty good remarkably quickly.<\/p>\n\n\n\n

Without the right context and guardrails, however, \u201cpretty good\u201d can become inconsistent, incoherent, or structurally shaky just as quickly.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Don\u2019t merely describe the surface. Give AI the system that should govern it.<\/p>\n\n\n\n

That\u2019s how you avoid AI drift.<\/p>\n\n\n\n

Think Future Before Feature<\/h4>\n\n\n\n

AI is very good at working locally.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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\u2019ll have to untangle later?<\/p>\n\n\n\n

AI can help build the pieces. We still need to think about how the pieces become a system.<\/p>\n\n\n\n

Judgment Is Still Our Job<\/h3>\n\n\n\n

This brings me to what I believe is the designer\u2019s most important role throughout all of this: judgment.<\/p>\n\n\n\n