Concepts You'll Bump Into

What it is: the saved, versioned home for a project's code — usually on GitHub. Think shared drive with a built-in undo history.

Why you'll meet it: every serious AI coding tool assumes your project lives in one, and it's how you share, back up, and recover work.

One thing to do: create a repo for your project today, even if you're the only person on it. The GitHub website is enough — no command line required.

What it is: git records snapshots (“commits”) of your project over time, so any earlier state can be recovered.

Why you'll meet it: AI generates a lot of code quickly — and sometimes a change makes things worse. Commits are how you experiment fearlessly.

One thing to do: commit at every working checkpoint. If you're unsure how, ask your AI assistant to walk you through it — they're excellent git tutors.

What it is: a branch is a parallel copy of your project for working on one change; a pull request (PR) proposes merging it back, with a place for review.

Why you'll meet it: our best practices call for one branch (and one AI chat) per feature or fix, and PRs are where humans review AI-assisted work.

One thing to do: next change you make, do it on a branch and open a PR to yourself. It's good practice before you ever have collaborators.

What it is: the same app running in different places — your machine for development, a test copy, the real (“production”) one people use. Configuration that differs between them lives in environment variables.

Why you'll meet it: the moment you have real users, “it works on my machine” stops being enough — and secrets belong in environment variables, never in code.

One thing to do: keep a .env file for settings and secrets, excluded from your repo.

What it is: other people's code your project builds on — packages pulled in from registries like npm or PyPI.

Why you'll meet it: AI-generated projects arrive with dependencies you didn't consciously choose, and outdated ones are a leading source of security problems.

One thing to do: let GitHub's dependency alerts run on your repo, and when one fires, paste it into a fresh AI chat and ask what it means for your project.

What it is: the way programs talk to each other — your app calling a weather service, a database, or an AI model over the network.

Why you'll meet it: most useful apps call at least one API, and API access is controlled by keys — which are secrets (see above).

One thing to do: know which external services your app talks to and what data it sends them. Ask the AI to list them from your code.

What it is: turning your source code into the running thing (build) and putting it where it runs (deploy).

Why you'll meet it: a failed deploy is often a beginner's first cryptic error wall. The log usually says exactly what's wrong — in its own dialect.

One thing to do: when a deploy fails, copy the log into your AI chat and ask for a translation and a fix. That's a normal workflow, not a workaround.

What it is: localhost is your app running privately on your own machine; hosted means it runs on a server where others can reach it.

Why you'll meet it: the jump from localhost to hosted is the jump from experiment to service — with real users, real data, and real responsibility.

One thing to do: before you host anything for others, read Ownership & responsibilities. It's a short read and worth doing first.