Making real things

Here’s the whole method. Walk until the idea starts coming out — what it is, who it’s for, why you care, the bit you can’t figure out. Keep talking past the point where you feel finished; the good stuff often turns up there. Then get the transcript (most recorder apps make one) and paste the entire mess to the AI with one line: “Here’s my idea — help me shape it.”

The transcript is the prompt. It’ll be richer than anything you’d have typed, because you think differently on your feet — looser, quicker, more honest. Twenty minutes of rambling from a walk gives the machine far more to work with than two tidy sentences composed at a desk.

The order matters more than it looks. Start at the keyboard and the AI’s first suggestion quietly becomes the plan — it’s fluent, it’s instant, and before you notice, you’re building its idea instead of yours. Start outside and you arrive already knowing what you want, with something to defend when the machine suggests otherwise. It still does the shaping and the building. It didn’t do the choosing.

There’s a plainer reason too: your body is part of how you think. Moving shakes ideas loose in a way sitting doesn’t — it’s why answers turn up in the shower and on bike rides, never on demand. Watch who builds the best things this week. It’ll be whoever keeps leaving the desk and coming back with something.

Here’s what most grown-ups haven’t clocked yet: the thing that used to take a team, a pile of money, and months — a real app, a website people can visit — you can make in an afternoon. One curious kid and a good AI.

Getting from “I have an idea” to “the idea is real and my friends can use it” used to be the hard part. For basically everyone, forever. Now it mostly isn’t. So the thing between you and building something isn’t money, and it isn’t being some genius. It’s whether you actually sit down and try.

The shape changes the job. A website needs navigation and working controls. A deck needs a sequence. A data tool needs clean fields and correct calculations. An image needs composition, light, and a clear subject.

Once the shape is clear, tool choice gets much easier. You are no longer asking which AI is best. You are asking which tool can make this kind of thing and still let you test it.

Every container also changes what counts as proof. A document can be checked sentence by sentence. A calculator needs test cases. A diagram must show the relationship accurately. A website has to survive real clicks on a real device. Choose the proof when you choose the shape.

• Paste — Fast for a small table. Keep the headers, do not paste thousands of rows, and check that columns did not slide out of place.
• CSV — Best for many clean rows. A CSV is plain text that preserves rows and columns; one clear header row makes it much easier to read.
• Screenshot — Useful when copying is impossible. The AI has to read pixels first, so a cropped label or blurry number can quietly change the data.
• The gate — Ask it to recreate the table, count the rows, and answer two questions whose answers you already know. Only then ask for patterns or conclusions.

Two AI systems giving the same answer is useful, but it is not proof. They can rely on the same bad source, make the same assumption, or copy the same calculation mistake. For an important claim, return to the original data, calculate it independently, and look for evidence that did not come from either model.

Asking a model to explain its steps can help you inspect an answer. It does not reveal a guaranteed record of the model's hidden reasoning, and a neat explanation can still defend the wrong result. Check the numbers, not the confidence of the explanation.

• The Planner — Names the goal, audience, facts, examples, limits, output shape, and test before asking the machine to make anything.
• The Explorer — Reads what arrived, notices what feels wrong, asks why, changes one thing, runs a test, and stays willing to revise the original plan.

Strong builders switch modes on purpose. Planning forever becomes fear dressed as preparation. Exploring without a plan becomes endless random generation. Send is the pivot: decide enough before it, then let evidence teach you after it.

• 1. Talk it out — Walk around and describe the idea out loud, to a friend or a recorder — the walk from the start of this chapter is this step. What is it? Who’s it for? What should it do? Don’t build yet. Get it clear in words first.
• 2. Shape it into a plan — Have the AI turn your rambling into a proper plan — sometimes called a PRD, a product requirements document. A short, ordered list of what gets built. This is where vague becomes buildable.
• 3. Build — Hand the plan to a building tool and let it make the first version. This part is faster than you’d believe. Minutes, often.
• 4. Verify — Actually try it. Click every button. Find what’s broken or wrong or ugly. The AI will not tell you what it got wrong — that part is your job, and it’s the part that matters.
• 5. Ship and show — Put it somewhere real and show it to a person. A live link beats a perfect idea that never left your head. Then loop back: fix, improve, repeat.

The loop never really ends — you just go round it faster and with better taste each time. The first lap is clumsy. By the tenth, you’re shaping the plan more sharply, catching problems earlier, knowing what “done” actually feels like. And the loop transfers — a song, a site, a business, a school project all go round the same five steps.

• Artifact style guide — Controls the whole page, deck, document, or dashboard: color roles, typography, spacing, layout rules, and repeated components.
• Image guide — Controls the pictures inside it: subject, framing, light, materials, mood, realism, and anything that should never appear.
• Reference examples — Show two or three things that feel right and explain why. The explanation matters more than the brand name or screenshot.
• Reverse engineer — When a result surprises you in a good way, ask what visual rules produced it. Save those rules, test them on a second image or page, and revise the guide.

A visual guide is not a taste machine. It makes some decisions repeatable so you can spend your attention on the choices that still need a human eye. If every result follows the guide but feels dead, the guide is incomplete—or you followed it too literally.

Code is just very precise instructions for a computer, written in a language a computer understands. It used to be that you had to learn that language yourself, character by character, semicolons and all. Now you can describe what you want — “a page with my photos and a button that shuffles them” — and the AI writes the code that makes it real.

That doesn’t make the code unimportant or make you helpless without the AI. The opposite: the more you understand what it’s building, the better you can steer it, spot when it’s gone wrong, and ask for the right fix. Vibe coding gets you started. Actually wanting to know what the AI just built is what makes you good at it.

Good debugging is mostly good describing. Don’t just say “it’s broken.” Say what you expected, what actually happened, and paste the exact error message if there is one. The error message looks like gibberish; paste it anyway — to the AI it’s a precise clue, often the whole answer.

Then go one fix at a time. Change one thing, test, see if it helped. If you change five things at once and it works, you’ll never know which one mattered — and if it still breaks, you’ve made a bigger mess. Patience is genuinely rare here — most people quit at the first error message. The ones who don’t are the ones who ship.

• Fix one thing — Use this when one part is broken and the rest works. Name the exact element or behavior, protect everything else, change one cause, and test again.
• Restart clean — Use this when several systems are tangled or the conversation has become confused. Save the working pieces, write a shorter plan, and begin from a clean state.
• Ask for help — Use this when the same failure survives three careful attempts. Ask a person, read the official documentation, or show another tool the exact error and the smallest example that still fails.

• Save the state — Write down what works, what is broken, and the next test. Do not make your brain hold the whole project.
• Leave the screen — Stand up, drink water, look far away, and let your eyes and attention reset. Five honest minutes can beat thirty foggy ones.
• Return with one test — Do not reopen every possibility. Start with the single check you wrote before the break.

This is not a motivational extra. Verification depends on attention. When attention drops, you accept defaults, skip strange cases, and mistake smoothness for correctness. The human is part of the system, so the human needs maintenance too.

• It’s finished — Not 80 percent. Finished. The last 20 percent — the rough edges, the broken link, the bit you kept meaning to fix — is exactly the part most people skip, and exactly the part that separates a real thing from a demo.
• It actually works — Every button does what it says. Nothing crashes when a friend pokes at it. A thing that breaks the moment someone else touches it isn’t finished, however clever the idea was.
• It has taste — Someone made choices. It looks considered, reads cleanly, feels like it was cared about. Taste is the one thing the AI can’t do for you. That part’s yours — and it’s the part people notice.

Here’s the quiet part: the AI can crank out endless stuff that’s fine. Competent. Forgettable. What it can’t do is decide what’s worth making, when it’s actually good, or what to throw away. That’s all you. And the better these tools get at the making part, the more your taste and your calls are what count. You’re the one driving.

• Frontend — Everything you see and touch — the buttons, the colours, the layout, the words on screen. The part of the building you actually walk around in.
• Backend — The machinery you don’t see — where information is stored, accounts are checked, the real work happens. The engine room below deck. A simple site might have almost none; anything that remembers things needs one.
• A repo — Short for repository. The folder that holds all your project’s code, with a full history of every change — so you can always see what you did and go back if you break something. A save system for builders.
• Deploy — To put your project on the internet so it has a real address and anyone can visit. The moment it stops being yours-only and becomes a thing that exists in the world. Going from your workshop to a shop with an open door.

Once you’re comfortable with the loop, the next leap is building with agents — handing the AI a goal and letting it run several steps of the loop on its own. You describe the feature; it plans, writes the code, tests it, fixes its own mistakes, and comes back when it’s done or stuck.

This is powerful and it has a catch: an agent moving fast can build the wrong thing fast. So you stop typing and start directing — say clearly what you want, check what it actually did, keep your taste in the loop. You’re less the builder now and more the person deciding what gets built, and whether it’s any good.