How to Prompt AI for Building (Not Just Chatting)

I've watched hundreds of people try to build software with AI. The first attempt usually looks like this: they open ChatGPT, type "build me a todo app," and expect magic.

What they get instead is a pile of code that almost works. The login form has no validation. The database schema is missing indexes. The app breaks if you refresh the page. Then they're stuck. Unable to explain what's wrong because they don't know, and the AI can't fix what it can't see.

The problem isn't the AI. It's that prompting for building is fundamentally different from prompting for conversation.

The Difference

When you chat with AI, ambiguity is fine. "Write me a poem about nature" works because there are infinite valid outputs. The AI picks one, you like it or you don't, done.

Building software is different. There's only one correct behavior for a login form. Either it validates email formats or it doesn't. Either it handles edge cases or it breaks in production. Ambiguity isn't creative freedom. It's bugs.

This means you need to prompt differently. Not with more words, but with more structure.

What Structure Actually Means

Example: Someone wants to build a customer portal. Here's what doesn't work:

"Build me a customer portal where users can log in and see their orders."

Seems clear, right? It's not. The AI has to guess:

- What fields does a user have? (Email? Username? Phone number?)
- How do they authenticate? (Password? Magic link? OAuth?)
- What's an "order"? (Physical products? Services? Subscriptions?)
- What details do they see? (Order status? Tracking? History?)
- What can they do with orders? (Cancel? Return? Download invoices?)

Each ambiguity is a decision point where the AI picks something, and you probably wanted something else.

Here's what works better:

"Build a customer portal with email/password login. Users table needs: email, password_hash, name, created_at. Orders table needs: order_id, user_id, status, total, created_at. The portal shows a list of orders with status and total. Users can click an order to see line items. No order modifications, read-only view."

Now the AI has constraints. It knows what to build and, more importantly, what not to build.

The Three Layers of Good Prompts

Layer 1: Data structure. What are you storing? If you're building a booking system, define what a booking is. If it's a dashboard, define what data you're displaying. The AI can't infer your data model from vibes.

Layer 2: User actions. What can users actually do? "Manage their account" is vague. "Users can update their email, change password, and upload a profile photo" is specific.

Layer 3: Edge cases. This is what separates working demos from production software. What happens if a user enters an invalid email? What if they upload a 50MB photo? What if two users book the same time slot simultaneously?

You don't need to specify everything. Just the things that matter for your use case.

The Constraint Paradox

Here's what's counterintuitive: more constraints don't limit the AI. They focus it.

When you say "build a todo app," the AI has infinite choices. It picks something generic. When you say "build a todo app where tasks have priorities, due dates, and can be grouped into projects," now it knows what matters to you.

The best builders I've seen treat AI like a really fast junior developer. You wouldn't tell a junior dev "build a customer portal" and walk away. You'd spec it out. Same with AI.

Examples That Work

Bad: "Create a form for collecting user feedback."

Good: "Create a feedback form with fields: email (required, validated), feedback type (dropdown: bug/feature/other), message (textarea, max 500 chars). On submit, save to a 'feedback' table with timestamp and display a success message. No authentication needed."

Bad: "Build a dashboard for tracking metrics."

Good: "Build a dashboard showing: total users (from users table), revenue this month (sum of orders where created_at is current month), average order value. Display as cards with the number large and label small. Auto-refresh every 60 seconds."

Notice the pattern: specific data, specific behavior, specific constraints.

When to Be Vague

Counterintuitively, there are times to be vague: styling and layout.

If you say "make it look modern," the AI usually does fine. If you specify "use #3B82F6 blue with 8px border radius and 16px padding," you're micromanaging pixels. Unless you have brand guidelines, let the AI handle aesthetics.

Be specific about logic and data. Be loose about aesthetics. That's the split.

The Real Skill

The real skill isn't writing longer prompts. It's knowing what to specify and what to leave open.

Specify data structure: always.
Specify user actions: always.
Specify edge cases: when they matter.
Specify styling: rarely.

This takes practice. But once you internalize it, AI stops feeling like a gamble. You ask for specific things, you get specific things, and what you get actually works.

The difference between chatting and building is the difference between "write me something interesting" and "solve this specific problem with these specific constraints." Both use AI. Only one ships.