You volunteered to build the running-club site you have pitched at every weekend run: members post routes and RSVP without digging through the group chat. Tonight the club's co-organizer is watching your screen over a video call, because you promised a first look. You type the idea into an AI coding tool, and for a minute it delivers everything the demos promised. Then it stops and prints a plan: a language you have heard of, a company name you have not, a list of files it will create, a line about something called secrets. It ends with one question: approve this plan? The co-organizer asks if it looks right, and you cannot judge a single line, so "looks fine" would be a guess said out loud.
The plan on your screen, printed in full
Here is the plan, close to what a current AI coding tool proposes for a small site idea.
Plan: running-club site
Build with: JavaScript, using the Next.js framework
Host on: Vercel
Files to create:
app/page.js the home page
app/routes/page.js post and browse routes
app/rsvp/page.js RSVP for the weekend run
data/runs.json where routes and RSVPs are stored
Also create: a .env file to hold secrets
Approve this plan?
You read it twice and half the names mean nothing, so you feel tested on vocabulary nobody ever taught you. Maybe you close the tab, or maybe you type yes and feel like a passenger in your own project. Your ability was never the problem; the unfamiliar words were.
When you are stuck like this, not knowing the words feels exactly the same as not being capable, but the two are different problems: becoming a capable builder takes years, while learning a word takes minutes.
Read it like a contractor's quote
Read the plan again the way you would a contractor's quote for your house: you will never pour the foundation, but you can approve the quote, question the odd line item, and notice when it drifts from what you asked for.
Build with: JavaScript, using the Next.js framework. JavaScript is a programming language, and Next.js is a framework, a pre-built structure that lets the tool assemble your site from proven parts instead of from scratch. Both are among the most common choices on the web; Languages and frameworks: approve the pick decodes this line fully.
Host on: Vercel. The finished site is a folder of files, and those files need to sit on a computer that stays on and stays connected to the internet, or nobody but you can ever visit it. Hosting is the business of renting out that kind of computer; Vercel and Cloudflare both do it well. While your build is this small, the differences between them are fine print; the choice is between two parking spots outside the same building. Occasionally a tool asks the bare either-or, Vercel or Cloudflare?, with no recommendation; ask which it recommends and why, then take that. Where software lives and hosting, renting a computer on the internet make this line concrete.
Files to create. Each page of your site lives in a file: app/routes/page.js is the page where members browse routes. The line worth a second look is data/runs.json, which settles how the product remembers routes and RSVPs between visits: a simple file rather than a database, a program built for storing and searching information.
Also create: a .env file to hold secrets. Secrets here means private values your site uses behind the scenes, like passwords and access codes for other services, which must work without ever being shown to visitors. The plan is setting aside a locked drawer for them; the .env file is that drawer.
Approve this plan? The tool did not quiz you line by line; it made its choices and asked for one signature. Before you sign, write down what you approved: a note as short as "hosting is Vercel, the tool's default, accepted for now" turns a yes you could not explain into a decision you can revisit once the vocabulary arrives.
Nobody is asking you to write the code. Your job is reading the proposal, closely enough to question the odd line item and notice when the plan drifts from what you asked for.
Every question in the plan unwraps the same way
Each line of that plan pre-answered what used to be a research project, and most questions a tool asks just check whether a default suits you. The hosting line is one instance of a pattern you will meet constantly.
Every jargon question an AI tool asks is a small decision wrapped in unfamiliar names, and the wrapper is almost always thicker than the decision inside.
You unwrap it with the same moves every time.
- Ask what it is really asking. Set the product names aside and look for the plain decision underneath. It is nearly always about where something runs, where something is kept, or who is allowed to do what.
- Ask why it is smaller than it sounds. The famous options got famous by being good enough for almost everyone, and while your build is small, most decisions can be changed later at a price you can pay.
- Make the move. Take the default, note what you took, and keep building; the note separates approving from sleepwalking and leaves you a list of decisions to revisit later.
Run the moves on the decision the file list carried past you, which sometimes arrives bare: should this be a database or a file? It is really asking how your product should remember information between visits, either option handles a first build, and the move is the same approve-and-note. Data, where information lives fills in what you approved.
The obvious objection: the AI can explain every word
You could paste any line of the plan into a second chat and get a patient explanation in seconds; nothing here asks you to give that up. As a substitute for a map of your own, though, it breaks down.
You cannot judge an explanation you have no map for. An explanation of Vercel only lands if you already know what hosting is and why a site needs one; without that, the answer arrives carrying new words, and the freeze moves down one level.
You cannot tell a flavor question from a money question. The paragraph explaining a host reads exactly as calm as the paragraph explaining where your users' passwords will live, yet one is cheap to change later and the other can cost money or trust if you wave it through. Telling them apart takes a working picture of the whole system.
That is the promise of this level: a working picture of what software is, where it runs, and what happens when somebody uses your product, then a walk through the stack, the name for the set of parts every product stands on, and finally a build of your own, approved decision by decision.
Try it now
This drill takes about ten minutes and spends nothing on either path.
No setup: Open any AI chat you already use and paste one line: "I want to build [your idea]. Before you write anything, show me the plan you would propose, with the language, the host, the files, and one short reason for each." A chat cannot build it, but it will print a plan much like the one above. Pick the line that intimidates you most and decode it on paper: what it is really asking, why it is smaller than it sounds, and which default you would take.
With your tools: Give Claude Code the same idea and read the plan it proposes before approving anything; notice that it offers options with reasons instead of quizzing you, then pauses for your yes. Approve one default you can explain back. Same move in Codex or Cursor: paste the idea, read the plan, approve the default you can explain. If nothing is installed yet, The Setup Clinic gets you running.
Either way, leave with the artifact. Start a plain note and call it your idea file. Give it two lines: the decision you just decoded ("hosting is Vercel, the tool's default, accepted for now") and the idea you keep circling, the build you keep describing to friends. Later drills add lines to it, and when you pick your first real build, you will look here first.
Chapter Summary
- Today, an AI coding tool's first answer to your idea is usually a full plan, a proposed language, host, and file list, waiting for your approval.
- Freezing at that plan is almost always a vocabulary gap, not a capability gap, and learning the missing words takes minutes, not years.
- Read the plan like a contractor's quote: approve it, question the odd line item, and notice when it drifts from what you asked for. Your job is reading the proposal, not writing the code.
- Every jargon question inside a plan is a small decision wrapped in unfamiliar names, nearly always about where something runs, where information is kept, or who is allowed to do what.
- Unwrap any such question the same way every time: ask what it is really asking, ask why it is smaller than it sounds, then take the default and write down what you took.
- A second chat can explain any term, but you cannot judge an explanation without a map, or tell a flavor question from a money question, and this level builds you that map.
- Stop and decode fully, rather than approving on autopilot, whenever a line touches money, passwords, API keys, or user data.
- Your artifact from this chapter is your idea file: the first decoded decision plus the idea you are circling, a note the drills ahead keep adding to.
- Next, What software actually is makes the most overloaded word underneath all these questions concrete.
Sources
- Vercel documentation (last verified July 2026).
- Cloudflare developer documentation (last verified July 2026).
- Next.js documentation (last verified July 2026).
- Anthropic Claude Code documentation (last verified July 2026).