Data vs code: the world lives in a file.

The problem with hardcoding

Ask yourself: if you wanted a fifth computer in the lab, what would you do? Right now the answer is "prompt Claude to edit the game code," because the computers — their names, their colors, how many exist — are woven into the code. Programmers call this hardcoding, and they say it the way you'd say "load-bearing wallpaper."

The fix is one of the oldest, best ideas in software: separate what the app is from what the app shows. The code should know how to draw a computer. Which computers exist — that belongs in a plain file the code reads when it starts.

Step 1 — the extraction

That last paragraph is you preventing a booby trap, and it deserves a word. Browsers block pages opened from a plain file from fetching other files — a security rule you'd otherwise discover as a mysteriously empty room and a cryptic console error. By saying how you run the game, you let Claude pick a loading approach that works (it'll likely make the data a lab-data.js file the page includes directly — same idea, same editability, zero drama).

Step 2 — open the data file and just look at it

Ask Claude to show you the file, or open it in any text editor. It'll look something like:

const LAB_DATA = [
  {
    "name": "Computer 1",
    "summary": "Placeholder — a real project goes here soon.",
    "path": "~/somewhere",
    "screenColor": "#38e1ff"
  },
  ...
];

Braces, quotes, commas — this format is called JSON, and it's how most of the software world writes down structured facts. You don't need to memorize its rules. You just need to see what it is: not code. No logic, no instructions. A list of facts, sitting in a file, waiting to be read. State, at rest.

Step 3 — the moment

Now, in that text editor, by hand, without Claude:

1. Change one computer's name to "Franklin". Save. Refresh the game.
2. Copy an entire entry (from { to }, mind the comma between entries), paste it below, change its name. Save. Refresh.

A computer named Franklin. A fifth desk that didn't exist a minute ago. You changed an app by editing a text file. No prompts, no code, no permission from anyone. If it feels almost too easy — that's the point. The hard part (code that reads data and draws accordingly) is done and never needs touching again; the living part (the data) is now in the easiest possible format to change.

Why this is the most transferable idea in the course

Look around and you'll see this pattern absolutely everywhere:

• A restaurant's online menu: the site is code; today's dishes and prices are data someone edits.
• A store's product pages: one page design, a thousand products of data.
• This very website: the AI Radar page is a fixed page that reads a data file of headlines and model prices; I refresh the data, never the page. You now know its whole secret.

And for you, practically: when you build things from now on — a menu, a price list, a portfolio — tell Claude Code from the start: "keep the content in a separate data file so I can edit it myself." You'll be able to update your own projects forever, in a text editor, for free, without needing anyone. That sentence is a superpower disguised as a chore.