Chapter 2. Dev Uncle's Workshop

Dev Uncle is right. You don't need a computer science degree to build with AI. You need a small, solid toolkit and a mental map of how the pieces connect. That's this chapter, and it's the longest setup you'll do in the whole book.

The minimum toolkit

Here's everything you need. All of it is free except the Claude plan, and you probably have the first two already.

Ten concepts that make everything make sense

Each of these takes a minute. Together they're the difference between following Sous blindly and knowing what it's doing.

1. Files and folders

A software project is just a folder full of files. Nothing magic. When Sous says "edit src/app/page.tsx", it means "open the src folder, then app, then the file called page.tsx".

A few names you'll see in every project in this book:

2. The terminal

The terminalTerminalA text window where you type commands instead of clicking. It runs exactly what you type and prints what happened. is a window where you type commands instead of clicking. It looks scary because it's plain. It's actually the most honest part of your computer: you type, it does exactly that, and it tells you what happened.

On a Mac it's the Terminal app. On Windows, it's PowerShell or Windows Terminal. On Linux, you knew that already. Your editor also has one built in: in VS Code or Cursor, press Ctrl plus the backtick key (`, top left of the keyboard), or choose View → Terminal.

You'll get through 95% of this book with eight moves:

One more that helps when you're lost: pwd (print working directory) tells you which folder you're in. Most "it doesn't work" moments in the terminal are really "you're in the wrong folder".

3. The languages you'll see

You won't write these from scratch. You'll read them, enough to spot when something looks wrong. Four show up constantly:

• HTML is the structure: headings, buttons, lists. It's the bones of the page.
• CSS is the looks: colours, spacing, fonts. In this book you'll mostly see it as Tailwind class names like bg-orange-500 p-4.
• JavaScript, and its stricter cousin TypeScript, is the behaviour: what happens when you tap "Add to cart". TypeScript adds labels like "this is a number" so mistakes show up before customers see them. Files end in .ts or .tsx.
• SQL is how you ask a database questions: "give me every order from today". You'll meet it properly in Chapter 7.

Here's a tiny piece of a menu in the kind of code Sous writes. You can probably read it already:

<li className="flex justify-between text-lg">
  <span>Masala chai</span>
  <span>₹40</span>
</li>

A list item, laid out with the name on the left and the price on the right. That's the level of reading you need.

4. Frameworks and libraries

A libraryLibraryA box of ready-made code you call when you need it, such as a set of buttons or a date formatter. is a box of ready-made parts you call when you need them. A frameworkFrameworkA ready-made structure for an app that decides where things go; you fill in the parts. Next.js is a framework. is a whole kitchen layout: it decides where things go, and you fill in the recipes. This book uses three:

• Next.js: the framework. It handles pages, links, loading data and talking to servers. Your app is a Next.js app.
• Tailwind CSS: a way to style things with short class names right in the HTML, so you (and Sous) don't juggle separate style files.
• shadcn/ui: a set of good-looking, accessible components (buttons, dialogs, drawers) that get copied into your project, so you own them and can change them.

Why these three? Partly because they're good. Mostly because they're popular. Remember Chapter 1: the AI makes fewer mistakes with things it has seen thousands of times. Picking a rare, clever framework is like asking Sous to cook a dish from a cookbook it's never read.

5. Packages, and why a bad one is a risk

A packagePackageCode someone has published for others to install, usually from the npm registry. Your package.json lists the ones your app uses. is a library someone has published for anyone to use. You install packages with npm, the Node package manager, which downloads them from a huge public registry at npmjs.com. Your package.json lists them; npm install fetches them into node_modules/.

This is wonderful. It's also how strangers' code ends up in your app. A package can be abandoned, buggy, or deliberately harmful. And AI adds a twist: it sometimes suggests packages that don't exist, or used to exist, or have a name one letter off from a real one. Attackers know this and publish malicious packages under those invented names.

Your defence takes ten seconds. Before installing anything you didn't ask for, search its name on npmjs.com. Check it exists, it has recent updates, and lots of weekly downloads. If in doubt, ask Sous: "Is there a more popular, well-maintained package for this?"

6. Localhost, production, and secrets

When you run npm run dev, your app runs on your own computer at an address like http://localhost:3000. LocalhostLocalhostThe address of your own computer. An app at localhost:3000 is running on your machine, and only you can see it. means "this machine". Only you can see it. It's the kitchen before opening time.

ProductionProductionThe live version of your app, running on a server on the internet for real users. is the real thing: your app running on a server on the internet, at a public address, for real customers. Things that work on localhost can still break in production, usually because of a missing setting.

Those settings are often environment variablesEnvironment variableA named value, like an API key, that your app reads when it runs instead of storing it in the code. Locally it lives in .env.local; in production, in your host's settings.: named values like STRIPE_SECRET_KEY=sk_live_… that your app reads at run time. Locally they live in .env.local. In production you type them into your host's dashboard. This keeps secrets out of your code, so the code can be shared and the secrets can't.

7. Git and GitHub

GitGitA tool that records the history of your project as a series of save points (commits) you can return to at any time. keeps the history of your project. Every time you commitCommitA save point in Git: a snapshot of every file in your project, with a short message describing the change., you make a save point: a snapshot of every file, with a short message like "Add menu page". You can jump back to any save point, any time.

A timeline of four commits. The fourth, 'Sous improves it', breaks the app. Dev Uncle runs git revert and the timeline rewinds to the third commit; the menu is restored.

A few more words you'll hear:

• A repositoryRepository (repo)A project folder together with its full Git history. GitHub stores copies of repositories online. (repo) is the project folder plus its whole Git history.
• A branchBranchA parallel line of commits in Git, used to try changes without touching the main version until you're ready to merge them. is a parallel timeline. You try a risky idea on a branch; if it works, you merge it back; if not, you delete it and main never knew.
• GitHub is a website that stores a copy of your repo online. It's your backup, the way you share code, and (in a minute) the way your app gets deployed.
• Push sends your commits up to GitHub. Pull brings changes down.
• Revert creates a new commit that undoes an old one. Restore throws away changes you haven't committed yet.

Here's why this matters so much for vibe coding. Sous will sometimes make a big change that breaks five things at once. Without Git, you'd ask Sous to fix its fix, and it might make it worse. With Git, you go back to the last good save point in one command and try again with a better prompt. Git is the undo button for AI mistakes.

8. Reading errors

Errors aren't the app being rude. They're the app telling you exactly what went wrong, in a language you're about to learn to read.

When something breaks, look in two places:

• The terminal where npm run dev is running. Server-side errors show up here.
• The browser console. Right-click the page, choose Inspect, then open the Console tab. Errors from the page itself appear in red.

A typical error comes with a stack traceStack traceThe list of files and line numbers printed with an error, showing the path the code took before it failed. The first line says what went wrong; the rest say where.: a list of files and line numbers showing the path the code took before it fell over. The first line says what went wrong. The lines below say where. Look for a file in your own src/ folder; that's usually the culprit.

TypeError: Cannot read properties of undefined (reading 'price')
    at MenuItem (src/components/menu-item.tsx:12:28)
    at renderWithHooks (node_modules/react-dom/...)

Line one: something expected an item with a price, and got nothing. Line two: it happened on line 12 of menu-item.tsx. You don't need to fix it yourself. You need to hand Sous the whole thing.

9. Deployment

DeploymentDeploymentPutting your code on a server so it runs on the internet. With Vercel, every push to GitHub can deploy automatically. means taking your code and running it on a server so the world can use it. This book uses Vercel, the company that makes Next.js. You connect your GitHub repo once. After that, every time you push, Vercel builds your app and puts it live, usually in under a minute. Push to a branch and you get a private preview URL to test before it goes to everyone.

Your app gets a free address like queueless-jo.vercel.app. Later you might buy a proper domain like meerascorner.in. A domain is just a name; DNSDNSThe internet's phone book. It maps a domain name like meerascorner.in to the address of the server that hosts the site. is the internet's phone book that maps the name to the server's actual address. You buy the domain from a registrar, then add a couple of DNS records Vercel tells you to copy. It takes ten minutes of work and up to a few hours to spread around the world. That's all you need to know for now.

10. Inputs, processing, outputs

The last idea is a way of thinking, and it's the one Dev Uncle uses for everything. Every feature, every page, every bug is three questions:

1. Inputs: what comes in? (A tap on "Add", a name typed in a form, a payment confirmation.)
2. Processing: what happens to it? (Add the item to the cart, check the price, save the order.)
3. Outputs: what comes out? (The cart count goes up, a receipt email, a ticket in the kitchen.)

When you describe a feature to Sous this way, it builds the right thing more often. When something breaks, these questions tell you where to look: wrong input, wrong processing, or wrong output.

Prompting fundamentals

Now that you know the words, you can give Sous better instructions. A good prompt has six ingredients:

1. A specific outcome. Not "improve the menu" but "show each item's price right-aligned in bold".
2. The user. Who is this for? "Customers ordering on a phone while queueing" changes everything.
3. Constraints. What not to touch, which tools to use, what to keep. "Use shadcn/ui. Don't change the colours."
4. Examples. Real data, a screenshot, a site you like. Examples beat adjectives.
5. A plan before code. Ask for the plan, read it, then say go.
6. Ask it to explain. After a change, ask what it did and why. It's free tuition.

The workshop: from empty laptop to live URL

This is the big one. Make a fresh chai. Steps 1 to 4 are one-time setup. Steps 5 to 9 are the loop you'll repeat for the rest of the book.

Something broke. Here's what I did just before: [describe the last thing you did or asked for].

Here's the full error from [the terminal / the browser console / the Vercel build log]:

[paste the entire error, every line]

Explain in plain English what went wrong, then propose the smallest fix. Don't change anything else.

You suggested installing the package [package-name]. Before I install it:
1. What does it do, in one sentence?
2. Is it widely used and actively maintained? Point me to its npmjs.com page.
3. Is there a more popular alternative, or can we do this without a new package?

Explain the changes you just made, file by file, in plain English. For each file: what changed and why. Then tell me how I can check in the browser that it works.

What you've learned

• A project is a folder. src/ holds your code, package.json lists ingredients, .env.local holds secrets and never gets committed.
• Eight terminal moves cover most of what you'll do: cd, ls, mkdir, npm install, npm run dev, git status, Ctrl+C and arrow-up.
• Popular tools (Next.js, Tailwind, shadcn/ui) make the AI better. Check unfamiliar packages before installing.
• Localhost is your kitchen before opening; production is the real café. Secrets live in environment variables.
• Commit before every big AI change. git restore . undoes uncommitted mess; git revert undoes a commit.
• Paste the whole error. Ask for a plan before code.