Vibe Coding with Replit -- May 1, 2026

How to Describe What I Want to Build So Claude Understands It

By Arjita SethiMay 1, 20265 min read
Direct Answer

Describe what you want to build to Claude using three components: input (what data the user provides or what triggers the app), process (what the app does with that data), and output (what the user sees or receives). The more specific each component, the better the code on the first attempt. "A form that captures emails" is vague. "A form that captures first name, email, and biggest challenge; stores the submission in a PostgreSQL table called leads; and redirects the user to /thank-you" is buildable.

Why Most Build Descriptions Fail

Most people describe what they want to build the way they would describe it to a friend: "I want a website where people can sign up and get access to my content." A friend would ask follow-up questions. Claude will attempt to build something reasonable based on that description and produce something that is technically functional but not quite what you had in mind.

The problem is ambiguity. "Sign up" could mean email only, email plus name, full account creation, or Stripe payment. "Access to my content" could mean a PDF download link, a private page, a member portal, or an email sequence. Every ambiguous element in your description produces a reasonable but potentially wrong assumption in the code.

The fix: eliminate ambiguity before asking Claude to write code. Use the input-process-output framework to describe exactly what should happen at each stage. Zero ambiguous elements = zero wrong assumptions = fewer rounds of correction.

The Input-Process-Output Framework

Input: What does the user do or provide? What fields are on the form? What does a button do? What triggers the app to do something? Be specific about every field name, every trigger, every user action.

Process: What happens to that input? Does it get stored in a database? Does it send an email? Does it call an external API? Does it generate something? Name the specific action and the specific tool or service involved.

Output: What does the user see when the process is complete? A thank-you page? A file download? A redirect to another page? An email in their inbox? An updated display? Describe the exact result.

Example: Vague vs Specific

Vague: "Build a lead magnet page where people can download my free guide."

Specific: "Build a landing page with two fields: first name and email address. When the user submits the form, store their information in a Replit database table called leads with columns first_name, email, and created_at. Then redirect them to /download where they see a button that opens this PDF link: [URL]. The page should have a headline, a three-bullet value prop, and the form."

The specific version builds correctly on the first attempt. The vague version requires three rounds of correction.

Frequently Asked Questions

How do I describe what I want to build to Claude?
Use the input-process-output framework: describe exactly what the user provides (input), what the app does with it (process), and what the user sees as a result (output). Eliminate all ambiguity -- every vague element produces a wrong assumption in the code.
What level of detail does Claude need to write good code?
Every specific element: all field names in a form, all database columns, all API calls with their specific services, all redirect URLs, all page content. If you have not specified it, Claude will assume something reasonable -- which may not be what you want.
What is the input-process-output framework?
A description structure with three parts: input (what the user provides or what triggers the app), process (what the app does with that input), and output (what the user sees or receives). Completing all three with no ambiguity produces buildable app descriptions.
How do I know if my description is specific enough?
Read it and ask: could this build in two ways that would be different from each other? If yes, it is not specific enough. A good description builds in exactly one way.
Should I include design details in my build description?
Include structural design details -- layout, sections, what appears where -- but not visual styling. For styling, tell Claude your brand colors and let it apply them. Structural specificity matters more than visual specificity at the description stage.
Build With AI

Learn Vibe Coding

The Vibe Coding with Replit track at Build with AI covers the complete build process.

Explore the University