Beginning applied AI: Git checkpoints, then Claude Code

There is a version of “getting into AI” that means maths, papers, and training models — I've written a map of that separately. This page is about the other version, the one almost nobody should skip: actually building things with AI. Not watching demos, not reading hot takes — sitting down and making working software with an AI doing the heavy lifting.

The honest pitch: the barrier has collapsed. You need exactly two things — a way to checkpoint your work so nothing can ever really break (that's Git, and you'll use a friendly free app for it, not the command line), and an AI that writes and manages the code while you direct it (that's Claude Code). And when you want what you've built live on the internet, a third tool (that's Railway) turns out to be the easiest of the lot. Everything on this site — the snooker game, the economy charts, the playable MIDI keyboard, the AI chat — was built exactly this way. This page is the whole setup, end to end.

Why you should bother

For decades, having an idea for software and being able to make it were separated by years of training. That gap is now weeks of casual practice. The intimidating parts of programming — the syntax, the arcane tooling, the inscrutable error messages — are precisely the parts the AI now handles. What's left for you is the part that was always the point: deciding what to build, looking at it, and saying “closer, but make it do this instead.” That's product thinking, and you already do it every time an app annoys you.

Which is why passively sitting this out is the one clearly wrong move. You don't need to become an engineer. You need to get over a small hump of unfamiliar words — repository, commit — after which you can build more or less indefinitely. The hump is genuinely small. Here it is.

Step 1: Git, without the intimidation

Git has a fearsome reputation it does not deserve at the level you need it. Strip away the jargon and it is a save system for a folder. Like save points in a video game: every time your project is in a state you like, you save a checkpoint. If anything later goes wrong — you broke something, the AI broke something, you just liked yesterday's version better — you roll back. Nothing is ever lost.

And you don't need the command line for any of it. Use GitHub Desktop, a free app for Mac and Windows that turns Git into buttons:

1. Create a free account at github.com — the place your checkpoints get backed up online.
2. Install GitHub Desktop and sign in.
3. In the app, choose New repository. A “repository” is just a folder that Git watches — your project lives in it like any other folder on your computer.
4. When you've changed something and like the result, the app shows you exactly what changed. Type a one-line note (“added the about page”) and click Commit. That's a checkpoint.
5. Click Push now and then to copy your checkpoints up to GitHub, so they're safe even if your laptop isn't.

That is the entire Git education you need to start: repository (the watched folder), commit (a save point), push (back it up online). Git can do a great deal more — branches, merges, collaboration — and you should cheerfully ignore all of it for now. The intimidating details can wait, possibly forever; plenty of working developers use little more than this.

Step 2: Claude Code on top

Claude Code is an AI agent that works directly in your project folder. Unlike a chat window you copy code out of, it reads your files, writes new ones, edits existing ones, and runs things — while telling you what it's doing and asking before anything significant. You talk to it in plain English; it does the engineering.

First, a word about the terminal

Claude Code grew up in the terminal, and the word alone puts people off, so let's take its mystique away. The terminal is just a window where you talk to your computer by typing instead of clicking — the original interface, from before mice existed, still there under every Mac and PC. The hacker-movie aesthetic is a costume; in reality it's a polite, empty window that does absolutely nothing until you type something and press Enter. Opening it cannot harm your computer. Looking at it cannot harm your computer. It's a text box.

On a Mac it's the app called Terminal (press ⌘-space and type “terminal”); on Windows it's PowerShell (search the Start menu). Open it and you'll see something like this — and this little session is the entire amount of terminal this workflow ever needs:

The one concept that makes all of it click: a terminal is always standing in some folder, exactly like a Finder or File Explorer window is always showing some folder — it just doesn't draw it as icons. Whatever you type happens in the folder you're standing in. And that's the whole reason navigation matters here: when you start Claude Code, it adopts the folder you're standing in as your project — that's what it reads, that's where it writes. Start it in the right folder and it sees your website and nothing else; start it in the wrong one and it's politely confused. So the single job before typing claude is to be standing in your project folder, and three little commands do it:

• pwd — “print working directory”, i.e. where am I standing? The terminal replies with the full path of the current folder. When in doubt, ask.
• ls — “list”, i.e. what's in here? It prints the files and folders around you — the same things you'd see in Finder, as a list. (It works in Windows PowerShell too.)
• cd my-website — “change directory”, i.e. step into that folder. cd .. steps back out, up one level. And the best-kept secret for new users: type the first few letters of a folder's name and press Tab — the terminal finishes the name for you. Nobody types full paths by hand.

That's it. pwd to see where you are, ls to look around, cd to walk, Tab to autocomplete — then claude to start. You cannot get lost (you can always pwd), and none of these commands change anything — they only look and move.

And GitHub Desktop will even spare you the walk: with your repository selected, the Repository menu has an “Open in Terminal” item (“Command Prompt” on Windows) that opens a terminal already standing in your project folder. Click that, type claude, Enter. That's the whole ritual.

If even that feels like one step too many, you can skip the terminal altogether: Claude Code also comes as a normal desktop app for Mac and Windows, where you pick your project folder with an ordinary file dialog. Use whichever feels comfortable — they're the same brain in different clothes.

Setting up

1. Sign up at claude.ai if you haven't — a regular Claude subscription covers Claude Code.
2. Install Claude Code by following Anthropic's quickstart — either the desktop app or the terminal version. The quickstart is written for beginners; follow it line by line and it works.
3. Open it in your repository folder — via the app's folder picker, or by typing claude in a terminal opened from GitHub Desktop as above.
4. The first run walks you through signing in to your Claude account in the browser. After that it just starts.

If anything in the install snags — a confusing prompt, a message you don't recognise — paste it into regular Claude and ask what to do. Using the AI to bootstrap the AI is not cheating; it's the move.

Your first session

Open Claude Code in your repository folder and type something like:

“Create a simple personal website in this folder: a home page about me, plain HTML and CSS, no frameworks. Make it look clean and work on phones.”

It will create the files and explain what it did. Open the page in your browser and look at it — not at the code, at the thing. Then keep going: “make the heading bigger”, “add a page listing my favourite books”, “now make it look good in dark mode”. When you like where it's landed, switch to GitHub Desktop, skim the changes, and commit.

The loop you'll live in

From here on, building software is one loop, repeated:

Notice where you spend your attention: on what to ask for and on whether the result is good. The code in the middle is mostly Claude's problem. You'll absorb plenty about how it works over time — by asking, which Claude is endlessly patient about — but understanding every line was never the entry requirement people feared it was.

Step 3: Put it on the internet with Railway

Everything so far lives on your laptop, and for a while that's enough — you build, you open it in your browser, you enjoy it privately. But the moment a project is worth a text message — “look what I made” — you need a URL, and getting one used to be the second cliff after coding itself: rent a server, learn Linux, configure a web server, keep it all patched. Hosting was a profession.

Railway collapses that cliff the way Claude Code collapses the coding one. You point it at your GitHub repository — the one you've been pushing to since step 1 — and it works out for itself what kind of project it's looking at, builds it, runs it, and hands you a public web address. There is no server to rent, no configuration file to write, nothing to keep patched. And from then on it watches the repository: every push deploys the new version automatically.

The one-time setup:

1. Go to railway.com and sign up with your GitHub account — one click, since you made that account back in step 1.
2. Choose New Project → Deploy from GitHub repo and pick your repository. (The first time, GitHub asks you to confirm that Railway is allowed to see it.)
3. Wait a minute or two while Railway inspects the code, builds it, and starts it. For a plain HTML site or a small app it needs no configuration at all — the detection is automatic.
4. In the service's Settings, under Networking, click Generate Domain. That's your live URL — something like my-website.up.railway.app — ready to send to anyone on Earth. (If you later buy a proper domain of your own, you attach it in the same place.)

That's the entire setup, and you do it once per project. Afterwards, deployment stops being a step you take and becomes a thing that happens: you commit and push from GitHub Desktop exactly as before, and about a minute later the live site is the new version. Step 4 of the loop quietly gains a superpower — save and publish become the same gesture. If a deploy ever fails, Railway shows you the build log; copy it into Claude Code and say “the deploy failed with this, fix it” — same translator, same move as any other error.

Two things worth knowing before you lean on it. First, secrets: if your project ever uses an API key — say you add an AI feature — the key must never be pasted into your code, where it would be committed, pushed, and visible to anyone. Instead you put it in the service's Variables tab on Railway, and the running app reads it from there; ask Claude Code to wire that up and it will know exactly what you mean. Second, cost: Railway isn't free forever — after the trial, the hobby tier is a few dollars a month, which for something that used to be a sysadmin's salary is the cheapest line in this whole story.

And once more, proof from my own desk: the page you are reading is served by Railway in exactly this arrangement. The repository lives on GitHub; Railway watches it; the AI chat's API key sits in a Railway variable, never in the code. When I finish writing this paragraph I'll commit, push, and roughly a minute later you'll be able to read it — with no deploy step in between that I could even describe to you.

What this actually gets you

This site is the proof I can offer from my own desk. It's a few hundred pages of plain HTML — no frameworks, no build step — and essentially all of it was built in that loop: in-browser games with their own physics engines (snooker, a 3D RC car simulator), musical instruments and a drum machine, interactive economic charts, live maps, and AI experiments that talk to models through a small server. I directed; Claude built; GitHub Desktop kept the checkpoints. None of it required me to hand-write the code.

Yours doesn't have to be a website. People run this same loop to build small business tools, prototypes for ideas they want to test, scripts that automate tedious work, apps for their family. The loop doesn't care what you point it at.

Habits that make it go well

• Commit often. Every time something works, checkpoint it. Small commits are what make experiments free.
• Ask small. “Add a dark mode” beats “build the whole app”. Small asks are easier to judge and easier to roll back.
• Judge the product, not the code. Open the thing and use it. Your taste as a user is the scarce input here.
• Start with a plain website. HTML files in a folder, no frameworks. It's the gentlest on-ramp: every change is instantly visible in a browser, and there's nothing to install or configure.
• When confused, ask Claude. “What does this file do?”, “why did that break?”, “explain what a commit is again” — the tool that writes the code is also the best tutor about it.

The fears, answered

Every beginner carries the same handful of worries, so let's retire them explicitly.

• “I'll break my computer.” You won't. Everything in this workflow happens inside one project folder, and Claude Code asks before doing anything consequential. The worst realistic outcome is a project that doesn't work yet — which is also the normal state of every project, including professionals', most of the time.
• “I'll lose my work.” That's exactly what step 1 was for. Committed work is recoverable forever, and pushed work survives even a stolen laptop. Once the habit is in place, this fear simply has nowhere to live.
• “I'll hit an error I don't understand.” You will — everyone does, daily. The difference now is that the response is mechanical: copy the error, paste it to Claude, say “explain this and fix it.” Errors have stopped being walls and become messages, and you have a fluent translator sitting next to you.
• “I don't know what I don't know.” Nobody does at the start; the difference is you can now ask unlimited “stupid” questions with zero social cost. Claude doesn't sigh, doesn't judge, and never gets tired of “what's a server, again?” The embarrassment that used to tax learning is gone.
• “Real programmers will scoff at this.” Some might; meanwhile a large share of professional developers now work in almost exactly this loop, because it's faster. And your hobby project has precisely one judge: whether the thing works when you open it.
• “I'm too late.” Tools like these have existed for barely a couple of years, and they're still improving monthly. Nobody on Earth has a meaningful head start. “Too late” is the one fear on this list that's not even slightly true yet.

No reason to wait

The whole setup — GitHub account, GitHub Desktop, Claude Code, first committed project, even a live URL on Railway — is an afternoon, most of it spent watching progress bars. The skills that compound from there aren't the intimidating ones; they're describing what you want clearly and noticing what would make it better. If you've been waiting for the moment when building software stopped requiring you to become someone else first: it's here, and it arrived quietly. Don't watch it go past.

One last thing: this guide is deliberately minimal, which means it can't cover everyone. If it doesn't quite fit your situation — a different machine or setup, a different starting point, a step that didn't work the way I described, or a part you'd like taken further — email me at [email protected] (or say hello on X or LinkedIn) and I'll gladly expand the page. Questions from beginners are exactly the feedback that makes a guide like this better.