What is a variable? (the names your code remembers things by)

What it actually is

A variable is a name your program attaches to a value so that later lines of code can use the value, and change it, by referring to the name. userEmail might hold "sam@example.com". retryCount might hold 0 now and 3 after a flaky network call. The name stays fixed while the value behind it can move.

Think of a contact card in your phone. You save a number once under “Mom”, and from then on you call and text by name. If she switches carriers, you update the number in one place and every use of “Mom” points at the new one. Variables work the same way: the program stores a value under a name, and every line that mentions the name gets whatever the value is at that moment.

Here are two lines the way you’d see them in your agent’s output:

const userEmail = formData.get("email");
let retryCount = 0;

The first takes whatever your visitor typed into the email field of a form and names it, so the rest of the code can say userEmail instead of digging into the form again. The second starts a counter at zero. In JavaScript, const declares a name that won’t be pointed at a new value, and let declares one that will; modern style defaults to const and reaches for let only when the value has to change, which is why most lines your agent writes start with const. A variable can hold more than one small thing, too. A whole JSON-shaped object with a user’s name and plan can sit behind a single name like currentUser.

Why your AI just did this

Your agent creates variables in almost every edit, because naming in-between values is how code stays readable. When it says it “stored the response in a variable” or “extracted that into a variable”, it means it gave a value a name so that several later lines can share it instead of repeating the same lookup.

This matters most when you read your own diffs. A green line that says const d = t * 0.2 tells you nothing. A green line that says const salesTax = subtotal * 0.2 reads like a sentence, and you can approve it with real confidence. The variable names in a diff are the main handle a non-developer has on what changed, which is why “rename these variables so they say what they hold” is one of the highest-value review requests you can make.

Two neighbors share the idea. State is a variable your UI framework watches, so the screen updates when the value changes. And TypeScript exists mostly to track what kind of value each variable is allowed to hold, so userEmail can’t quietly turn into a number halfway through your app.

When you’ll run into it

The classic error is ReferenceError: userEmail is not defined in the browser console or your terminal. It means a line used a name that was never declared where that line can see it. Often the cause is a spelling or capitalization mismatch: userEmail and useremail are two different names, and the language will not guess which one you meant.

The sneakier one is Cannot read properties of undefined. Here the variable exists but holds nothing, usually because the value it was supposed to receive (a form field, an API response) never arrived. Your editor may also gray out a name and warn 'total' is declared but its value is never read, which means a leftover variable is sitting there unused and is safe to delete.

You’ll meet the same idea outside your code files. The STRIPE_SECRET_KEY=... lines in .env are environment variables: names for values that live outside the code, so secrets and settings stay out of your source files.

What to check

• Read the variable names in a diff before you approve it; if you can’t guess what res2 or temp holds, ask your agent to rename it first
• Match spelling exactly when you hit ReferenceError: x is not defined; names are case-sensitive, so look for a userEmail vs useremail mismatch before anything else
• Log the value when behavior looks wrong: console.log(userEmail) placed right before the failing line shows you what the name holds at that moment
• Keep secrets out of ordinary variables; const apiKey = "sk_live_..." in a code file ends up in git, while the same value in .env stays out, provided .env is in your .gitignore
• Ask for a rename pass once a feature works (“rename the vague variables in this file so they say what they hold”); it takes your agent a minute and pays off in every future diff

Say it like a dev

Instead of: “the email thing isn’t saving” Say: “Log the value of userEmail right before the save call. I want to see whether it’s undefined at that point.”

Instead of: “it says something is not defined” Say: “I’m getting ReferenceError: userEmail is not defined in the console. Find where that variable is declared and check that the name matches exactly.”

Instead of: “can you make this code clearer” Say: “Rename the vague variables in this file. data and res should say what they hold, like invoiceList or stripeResponse.”