Vibe coding replaces syntax with plain language, which makes the words a builder types the closest thing the project has to source code. Vague descriptions leave gaps, and AI tools fill every gap with their own assumptions; the result can be technically impressive and contextually wrong. Specific descriptions, by contrast, produce output that starts to resemble the work of a professional team.

This lesson introduces the lightweight spec: a few plain sentences that capture who a tool is for, what it must do, and what done looks like. It draws on Nielsen Norman Group's testing of AI prototyping tools, borrows a sentence format professional teams have used for decades, and shows why a rough sketch can communicate what a paragraph can't.

None of it requires technical vocabulary. Describing software well is a writing skill, and the spec that comes out of it becomes the opening move of the build conversations ahead.

Description quality is code quality

In early 2023, Andrej Karpathy wrote that "the hottest new programming language is English" [1]. The line reframes what programming means: when an AI turns plain language into working software, describing what to build becomes the act of programming itself. The description is the source code, and its quality sets the ceiling on everything the AI produces.

That shift moves the skill, but doesn't remove it. As Ethan Mollick puts it, "you have to know what you want to create; be able to judge whether the results are good or bad; and give appropriate feedback" [2]. A builder who can't say what good looks like won't get it, no matter how capable the tool.

The practical upshot: time spent sharpening a description now pays off the way time spent debugging code once did. Fuzzy words produce fuzzy software, and precise words are the cheapest quality lever a non-coder has.

What is a lightweight spec?

A lightweight spec is a short, plain-language description that tells an AI 4 things: who the tool is for, what it must do, what done looks like, and any rules or examples that pin down taste. It's written in sentences, not documents, and it's written to be revised, not obeyed.

The word spec carries heavyweight baggage from older software processes, but the modern version has shed it. Product teams now routinely write a small plain-language requirements document before prompting, and beginner guides to AI coding put that step first [3]. Nothing about the format requires engineering vocabulary.

For a project scoped to a single task, the whole spec might run 5 or 6 sentences. That's the point: short enough to write in minutes, specific enough that the AI doesn't have to guess.

Detail beats brevity

In October 2025, Nielsen Norman Group tested AI design tools, vibe-coding tools, and general chatbots against a real redesign project, giving each a broad prompt, a detailed prompt, and a prompt with reference files attached. The evaluation showed that longer prompts with clear, detailed requirements "consistently yield better results" [4]. With the detailed prompt alone, tools produced work resembling human-made designs, some even adding brand elements the prompt never requested; with the broad prompt, outputs varied wildly.

The mechanism is gap filling. Whatever a prompt leaves unsaid, the tool decides on its own, and its guesses rarely match the picture in the builder's head. A detailed prompt doesn't make the AI smarter; it just removes the guessing.

One honest caveat keeps the rule from becoming dogma: the same study found vague prompts genuinely useful for early exploration, since they can surface directions a builder hadn't considered. Detail beats brevity as the default once the goal is known; before that, looseness has its uses, a nuance the final practice returns to.

Context, Ask, Rules, Examples (CARE)

Kate Moran of Nielsen Norman Group condensed prompt completeness into a 4-part structure called CARE [5]. Each letter names a kind of information the AI can't invent on its own.

The 4 parts of CARE:

  • Context: the situation, the audience, and the background the tool can't guess
  • Ask: the specific action or output wanted
  • Rules: constraints the output must respect
  • Examples: demonstrations of tone, format, or quality

Moran is explicit that CARE is a completeness checklist, not a template: the parts needn't appear in order, and not every interaction needs all 4. Its value is in catching what a hurried prompt leaves out, which is usually context and rules.

Requirements as sentences

Long before AI, software teams learned to compress a requirement into one plain sentence. The user story format, devised by a London team in the early 2000s and later popularized by Mike Cohn, follows a fixed shape: "As a [role], I want [capability] so that [benefit]" [6]. One line forces the who, the what, and the why to all show up, with zero technical vocabulary.

The same move works in vibe coding without any template. Simon Willison publishes the real prompts behind his small tools, like this one: "Build an artifact (no react) that lets me paste in a QR code and displays the decoded information, with a hyperlink if necessary" [7]. It's a requirement written as a sentence: an input, an output, and one conditional behavior.

Every sentence in a lightweight spec can face the same bar: a concrete actor, a concrete capability, and a reason it matters. Sentences that pass are hard for an AI to misread.

Pro Tip! Reading each requirement sentence aloud is a quick test: a line that sounds ambiguous out loud will read ambiguous to an AI.

What is a promptframe?

What is a promptframe?

Evan Sunwall of Nielsen Norman Group coined the term in 2024: "A promptframe is a design deliverable that documents content goals and requirements for generative-AI prompts based on a wireframe's layout and functionality" [8]. It sits between the wireframe and the prototype, pairing each element of a layout with a prompt describing the content that belongs there.

Sunwall introduced it to retire lorem ipsum. Placeholder text derails testing because, in his words, "the content inspires feedback, not the container." His per-prompt checklist transfers directly to non-coders: state the objective (why the content exists), the desired outcome (what people should do or think after seeing it), and an example.

For a vibe coder, the promptframe shows that a spec can attach to a picture. A rough layout with a sentence pinned to each region is a promptframe in miniature, and it often says more than a page of prose.

Showing beats telling

Words carry intent; references carry taste. In Nielsen Norman Group's evaluation, prompts that included attached design artifacts "resulted in more streamlined outputs," and the higher the fidelity of the reference, the more accurately tools translated it [9]. A screenshot of an admired site, a rough sketch, or an existing page pins down layout and tone that prose struggles to specify.

The same study noted an honest irony: "by providing these references, you've already completed much of the design work yourself." For a non-coder, that's a feature, not a flaw. Vision was never the bottleneck; construction was, and a clear reference plus a fast AI covers both.

References don't need polish to work. Current tools accept sketches, screenshots, and design files alike, so showing what a thing should look like is now a normal part of describing it.

Pro Tip! A phone photo of a hand-drawn sketch counts as a design reference.

The ambiguity tax

Every undefined word in a spec gets defined by the AI instead, and the AI answers the words, not the intent. Nielsen Norman Group's evaluation showed the cost: asked for a "profile page" for a course attendee, several tools shipped a social-media-style profile with a banner and prominent contact details, technically responsive and contextually wrong [10].

Category words like profile, feed, and dashboard feel precise because professionals use them, but each maps to several competing patterns. Disambiguation is cheap: "a private dashboard for one person, not a public profile" costs a single clause and saves a rebuild. Anthropic's prompting guidance suggests treating the model like a talented new hire with no context on local norms, which is exactly the reader a spec should be written for.

The same guidance offers a calibration test: a spec that would confuse a colleague reading it cold will confuse the AI too. Confusion in a human reader is the cheapest early warning a builder can get.

Specs are living, not perfect

A lightweight spec is the first turn in a conversation, not a contract. Sunwall's promptframe process loops from prompt to output to critique to revised prompt [11], and Ethan Mollick grew a working 3D game through 4 short prompts, the first of which contained spelling and grammar errors and still worked [12]. Precision of intent matters more than polish of prose.

This is also where detail beats brevity earns its caveat. The Nielsen Norman Group study behind that rule found that vague prompts "might surface unexpected directions you might not have considered" [13], making loose prompts a legitimate opening move during exploration. Detail is the strong default once the destination is known; before that, a rough prompt and an open mind do real work.

The failure mode isn't the imperfect spec; it's the absent one. A builder who writes 5 honest sentences, sends them, and revises after seeing the output will outrun one who keeps polishing a document that never gets sent.