Prompting for Code & Building Products

Slogan: "Vibe coding without context is just gambling with semicolons."

The builder's prompt structure

When you're using AI to write or modify code, your prompt needs 4 things:

1. What the app is (1-2 sentences)
2. What you're trying to do (the user-facing outcome)
3. The constraints (stack, files to touch, what NOT to break)
4. How you'll know it worked (the acceptance test)

App: NAX Academy — a docs site built with TanStack Start + Tailwind v4.

Goal: Add a "copy code" button to every code block in lesson pages.

Constraints:
- Use existing design tokens (no hardcoded colors).
- Only modify src/components/markdown-lite.tsx.
- Must work on mobile (44px tap target).
- No new dependencies.

Done when: clicking the button copies the code text and briefly shows a "Copied" label.

That prompt gets you a working PR. "Add copy buttons" gets you a 4-hour rabbit hole.

The "explain before you change" rule

Before any non-trivial change, ask:

"Before writing code, explain in 3 bullets what you'll change, which files, and what could break. Wait for me to say 'go'."

This catches 80% of "wait, that's not what I meant" moments.

Give AI the code it needs (not the whole repo)

Models work best with 200-1000 lines of relevant context. Don't dump your whole project.

Good: "Here is the component I want to change: [paste]. Here is the parent that uses it: [paste]. Touch only these two files."

Bad: "Here are 47 files."

The "review your own diff" pattern

After AI writes code:

"Now review your own changes as a senior engineer. What edge cases did you miss? What would break in production? Fix them."

You'll be shocked how often it catches its own bugs.

Coding prompt cheats

"Make it minimal"

"Use the smallest possible change. Don't refactor anything unrelated. Don't add comments unless the logic is genuinely tricky."

"Match the existing style"

"Match the formatting, naming, and patterns of the surrounding code. If you see a convention used 3 times, follow it."

"Plan, then execute"

"1. Plan the changes. 2. List the files. 3. Wait for my approval. 4. Then write the code."

"Show me the test"

"Before fixing the bug, write a failing test that reproduces it. Then fix it. Then confirm the test passes."

When using AI builders (Lovable, v0, Cursor)

• One feature per prompt. Don't say "add auth, dark mode, and a payment page" in one message. You'll get half of each.
• Describe the user, not the code. "When a new user signs up, they land on an onboarding screen with 3 steps." That's a brief. "Make a useState for currentStep" is not.
• Show, don't describe, the design. Screenshots > 500 words. Paste a reference and say "match this layout, but use our brand color".
• Read the diff. Always. Two minutes of reading saves two hours of un-breaking.

The honest truth about AI coding

AI is incredible at:

• Boilerplate (forms, CRUD, layouts)
• Translating between languages/frameworks
• Explaining error messages
• Refactoring small functions
• Writing tests for existing code

AI is still weak at:

• Anything that requires understanding your specific business logic across 20 files
• Subtle race conditions and timing bugs
• Knowing what not to build
• Tasteful design decisions (it defaults to generic SaaS)

Your job hasn't disappeared. It moved up the stack — from typing code to judging code.

Funny truth: The best AI users aren't the best prompters. They're the best reviewers. They smell BS in a diff before the AI finishes streaming it.

Learning objectives

By the end of this lesson you should be able to:

• Explain the core idea of Prompting for Code & Building Products in your own words to a non-technical friend.
• Recognise where this concept shows up in real projects and tools you already use.
• Apply at least one specific technique from this lesson to something you're building this week.

Practical exercise (10–15 min)

1. Open a new note (Notion, Apple Notes, whatever) titled "Lesson 8.6 — my notes".
2. Write 3 sentences answering: "If I had to teach this lesson to myself yesterday, what are the 3 things I'd absolutely say?"
3. Now do the smallest possible version of it — one prompt, one file, one setting change — and paste the result into your note.
4. Add one honest sentence: "Where I got stuck / what surprised me."

Ship the note to yourself. That's the loop we'll repeat every lesson.

Estimated time

• Reading: ~12 min
• Exercise: ~10–15 min
• Total: ~26 min

Remember: Reading is not learning. The exercise is where the neurons actually wire up.

Deep dive — the long version

You already have the short version above. This section is the hour-long, sit-down version — the kind of walkthrough you'd get from a mentor over coffee. Skim it the first time, then come back and read it slowly once you've done the exercise. That's where the real learning happens.

1. Why this lesson exists at all

Prompting for Code & Building Products is one of those topics that seems obvious after you know it and completely opaque before. Almost every learner we've watched trip on this ends up tripping in the same 3 places:

1. They memorise the vocabulary but not the mechanics. They can say the word, but if you ask them to draw what's happening, they freeze.
2. They jump to tools too fast. They pick a framework or an AI product before they understand what problem it actually solves.
3. They confuse "reading" with "learning". Reading gives you recognition. Doing gives you recall. Only recall counts when you're building.

The point of this deep dive is to hit all three of those failure modes head-on, in slow motion, with plenty of examples.

2. A story to anchor the idea

Imagine you're teaching a curious 10-year-old about prompting for code & building products. They don't care about your credentials. They just want a picture in their head that makes sense. Here's the story we'd tell them:

A long time ago, before phones and Wi-Fi, if you wanted to know something you had to walk to the library and ask a librarian. The librarian would find a card in a little wooden drawer, walk to a shelf, pull down a book, and hand it to you. You'd sit at a desk and read it.

>

Everything in this lesson is that same story — just with the librarian replaced by a computer, the shelf replaced by a hard drive, and the walk replaced by the internet.

That story is the mental scaffold. Every technical detail you'll learn from here onwards hangs off it.

3. The mechanics, one step at a time

Let's slow the whole thing down. Pretend we're watching a replay in slow motion.

Step 1 — The request. Something (a person, a script, another computer) says "I would like this thing." In a browser, that's typing a URL. In an AI app, that's typing a prompt. In a bank app, that's tapping a button.

Step 2 — The middleman. A layer of software takes the request, tidies it up, and forwards it. In a browser this is called the network stack. In an AI app it's an API client. You almost never see this middleman, but it's always there.

Step 3 — The doer. A computer far away receives the request, does some work (looks something up, generates something, calculates something), and produces a result.

Step 4 — The reply. The result travels back the same way it came. Middleman receives it, tidies it, hands it to whoever asked.

Step 5 — The rendering. Whatever asked for it now shows the result on a screen, plays a sound, or takes an action.

That five-step loop is literally every interaction on every website, every app, every AI tool. Once you can spot the five steps, nothing in tech is truly mysterious again — it's just variations on the loop.

4. Three worked examples (from easy to less easy)

Example A — Reading a news article. Steps: click a link (request) → your browser asks a server (middleman) → the server sends back HTML (doer + reply) → the browser paints text on your screen (rendering).

Example B — Asking ChatGPT for a limerick. Steps: type the prompt (request) → the ChatGPT client bundles it with your session token (middleman) → OpenAI's servers run the model (doer) → text tokens stream back (reply) → the client paints them one word at a time (rendering).

Example C — Ordering food on an app. Steps: tap "order" (request) → the app opens an authenticated connection (middleman) → the restaurant's system receives the order and prints a ticket (doer) → a confirmation comes back (reply) → the app shows "Order placed" and starts a progress bar (rendering).

Different domains, exact same loop. This is why one skill (understanding requests and responses) transfers everywhere.

5. Common mistakes and how to avoid them

• Mistake 1: Skipping the exercise. Reading feels productive but the neurons only wire up when you produce something. Do the exercise. It's 10 minutes.
• Mistake 2: Learning the buzzword first. "What's LLM? What's RAG? What's SSR?" You don't need those words yet. Master the 5-step loop first, then the buzzwords slot in.
• Mistake 3: Comparing yourself to people 2 years ahead. They started too. They also felt lost. The only useful comparison is you today vs you last week.
• Mistake 4: Watching tutorials as entertainment. Tutorials are training wheels, not the destination. If you're not typing along, you're watching TV.
• Mistake 5: Believing "AI will just do it". AI is a very fast intern with amnesia. If you can't describe what you want in plain sentences, no model on earth will get you to a good result.

6. A checklist you can actually use

Before you leave this lesson, tick these off honestly:

• [ ] I can explain prompting for code & building products in 3 sentences without notes.
• [ ] I can point at something in real life that uses this idea.
• [ ] I finished the practical exercise, not just read it.
• [ ] I wrote 1 question I still don't know the answer to.
• [ ] I know which lesson comes next (see the "Next up" card at the bottom of the page).

If any of those are unticked, don't move on. Loop back and close them. The learners who ship are the ones who don't skip.

7. Where this lesson connects

Every future chapter will assume you internalised this idea. Specifically:

• *When we talk about prompts*** — a prompt is a request in step 1.
• *When we talk about tools*** — a tool is a specialised doer in step 3.
• *When we talk about building your own product*** — you're going to design your own version of the loop, end to end.

That's why we made you sit through the story. Everything else in the handbook is a variation on it.

8. Bonus: three questions to journal on

If you want to really lock this in, spend 5 minutes writing (not typing — actually writing) answers to these:

1. What part of prompting for code & building products was I secretly avoiding thinking about?
2. If I had to teach this to my past self one year ago, what would I say first?
3. What is the smallest possible project I could build this week that uses this idea?

Those three prompts, repeated across every lesson in the handbook, are the single highest-leverage habit we've seen in learners who go from zero to shipping in under 6 months.

Next up

If this lesson clicked, keep the momentum going — hit the Next → card at the bottom of this page. If you struggled, do this instead:

1. Re-read sections 3 and 5 slowly.
2. Redo the practical exercise from scratch.
3. Re-read your notes again in 24 hours. Sleep genuinely helps memory consolidate — it's not folk wisdom, it's biology.

Progress is not a straight line. Circling back is how mastery is built.