A build loop only moves as fast as the feedback inside it. When an AI tool generates the code, the human's main quality lever shifts from making to directing: holding a vision, judging each take, and saying what's wrong in terms the tool can act on. Ethan Mollick described vibe coding as working like a creative director, and NN/g's evaluations back the instinct: detailed, precise direction consistently produced better results than broad requests.

The good news is that directing isn't a mysterious talent. It's substantially the same skill as giving critique to a human design team, and it decomposes into structure anyone can learn and practice.

This lesson breaks down what separates a note an AI can act on from a complaint it can't, dissects a real feedback exchange line by line, and settles two worries that stop beginners cold: whether iterating means the first prompt failed, and whether specifying everything amounts to doing the work anyway.

The director stance

Iterating like a director means treating each round of the build loop as direction: specific, actionable feedback toward a vision the builder owns. The director doesn't operate the camera. The director knows exactly what the shot should be and can say what's wrong with this take.

Ethan Mollick, describing his own AI-assisted building, put it this way: "Sometimes I found myself acting as a creative director, other times as a troubleshooter, and yet other times as a domain expert validating results" [1]. He also named the three duties the role carries: knowing what to create, judging whether the results are good or bad, and giving appropriate feedback.

None of those duties requires writing code. They require vision, judgment, and articulation, which is why designers and other non-coders often step into the stance more naturally than they expect.

Detail beats vagueness

NN/g's evaluation of AI prototyping tools ran the same real project, a course-attendee profile page, through three tiers of prompts: a broad text prompt, a detailed text prompt specifying components, design language, and interaction states, and prompts with attached design artifacts [2]. The detailed prompts consistently produced better results, generating outputs similar to human-produced designs even without visual references. Broad prompts produced outputs that varied widely, because the tools had to make assumptions about the requirements and fill in the gaps themselves.

The evaluation was an expert heuristic review of one real project across many tools, not a controlled experiment, so it reports a direction rather than a number. The direction held across every tool tested, though: the more a prompt specified, the closer the output landed to what a designer would've made. Attached references pushed further still; the higher the fidelity of an attached sketch, mockup, or Figma file, the more accurately tools translated it.

Precision over verbosity

Precision over verbosity

Detail means precision, not word count. NN/g's follow-up analysis found that "verbosity without precision hurts clarity," and that a concise, well-chosen keyword can beat a long but vague description [3]. Its documented example is a three-rung ladder: asking for a "trendy" conference landing page produced generic output, listing features such as high contrast, blocky layouts, and bold colors did better, and naming the style outright, "in a neobrutalist style," did best. A named style is compressed direction; one recognized term carries dozens of requirements.

Generic adjectives fail for the opposite reason. Words like simple, clean, and modern appear on every marketing site the model trained on, so they select for nothing. NN/g's advice is to point to established design styles or frameworks instead. And because frontier models now follow instructions closely, imprecise words cost more than they used to; the model executes exactly the vague thing that was said.

Pro Tip! A general-purpose chatbot can critique a draft prompt, flag missing context, and suggest improvements before it ever reaches the build tool.

Care in prompting (CARE)

Kate Moran's CARE framework, published by NN/g, decomposes an actionable request into four parts [4].

The four components:

  • Context: the background the AI needs about the project, audience, and situation
  • Ask: the specific request, stated directly
  • Rules: constraints and requirements the output must respect
  • Examples: references that show what good looks like

The framework also builds in a phase Moran calls iterate, refine, and combine outputs, which means revision is part of the plan rather than a sign the plan failed. Moran is candid about the cost: "If this seems like it's a lot of work, that's because it is." The payoff is that good feedback stops being an innate talent and becomes learnable structure, much like the critique skills designers already practice with human teams.

Observations, not verdicts

A verdict declares quality: "it's bad, fix it." An observation reports evidence: what appeared, where it appeared, and what was expected instead. Human collaborators can decode verdicts because they share context and can ask follow-ups. AI tools struggle with that ambiguity; NN/g found they can't deliver thoughtful results from broad, judgment-only input [5].

Anthropic's debugging guidance offers the template: instead of "fix the login bug," describe the symptom, point to the likely location, and define what fixed looks like [6]. The same shape works for design notes. "The pricing section feels cramped" becomes "the pricing cards on the plans page have almost no padding, and the three tiers should breathe like the hero section does." Frustration after a bad take is natural; the discipline is converting it into observations before hitting send.

Saying what to keep

Feedback that only lists changes leaves everything else unprotected. Humans assume incremental edits, but generative tools may regenerate broadly, and instruction-following is leaky even on good prompts. Moran notes that the more detailed the instructions, the more likely the AI overlooks one or more of them, which is why her iteration checklist opens with checking whether the AI actually followed the instructions [7].

The fix is cheap: name what worked alongside what should change. A note like "keep the header and the color palette exactly as they are; the spacing between sections needs to double" fences off the good parts before the revision starts. Directors do the same thing on set, locking the takes they like before asking for another.

Pro Tip! When a revision drops a detail that was already working, ask the AI to try again without missing any details.

Anatomy of a great note

Ethan Mollick's public fire-truck game session shows what a great note looks like in the wild. His second message read: "hmmm its all a little boring (also sometimes the larger buildings don't place properly). Maybe I control a firetruck and I need to put out fires in buildings? We could add traffic and stuff" [8]. One casual message carries three ingredients: a felt problem (boring), a reproducible bug (buildings don't place properly), and a creative direction (firetruck, fires, and traffic).

A later turn ended with "make it all so much better," the weakest clause in the whole exchange. It worked only because the specific observations before it did the directing. Anthropic's before-and-after pairs show the same anatomy from the engineering side: "make the dashboard look better" fails where pasting a screenshot and asking the tool to implement it, compare the result, and fix the differences succeeds [9]. A great note bundles reaction, evidence, and direction; polish is optional.

Does iterating mean failure?

Tool demos sell a fantasy: one prompt, finished app. That sets up the worry that needing a second round means the first prompt failed. Moran, writing from inside NN/g's own practice, says the opposite: "I find it's very rare that I can just accept genAI's output exactly as it's returned to me" [10]. Iteration is the working method of the most sophisticated users, not the fallback of beginners. Anthropic agrees from the tool-maker's side: the best results come from tight feedback loops, and correcting quickly generally produces better solutions faster [11].

Correction does have a failure mode, though. Anthropic's guidance draws the line at roughly two attempts: when the same issue survives two corrections, the session itself is the problem, its context cluttered with failed approaches. At that point "a clean session with a better prompt almost always outperforms a long session with accumulated corrections." Iterating isn't failure; refusing to restart is.

Specifying vs. doing the work

NN/g raises the sharpest objection against its own findings: by providing detailed requirements and references, "you've already completed much of the design work yourself" [12]. Moran concedes the related cost, noting that careful prompting can take significant time, sometimes more than doing the task the old-fashioned way [13]. For a professional designer prototyping by hand, that math can genuinely favor skipping the AI.

For a non-coder, the math flips. Specifying is the accessible half of the work; working code is the half they couldn't produce at any speed. Trading a skill they have for an output they can't make otherwise is a favorable deal, which is exactly the trade vibe coding offers.

There's one more nuance: NN/g and Anthropic both note that vague prompts have a place in early exploration, where unexpected directions are the point. Directors run improv takes too. The move is choosing looseness deliberately rather than defaulting to it.