Ready, Set, Create! (Using AI)

Here’s the part most “build an app with AI” tutorials skip: before the magic happens, you have to install a small pile of tools and get them talking to each other.

So this post is the unglamorous, deeply important half — the setup. By the end you’ll have everything a non-developer needs to sit down and vibe code a real, publishable blog: accounts, tools, a working command line, and an AI assistant wired up with the right agents and skills. Part 2 picks up where this leaves off and actually builds the site.

This is written for the technical-adjacent — you can follow instructions and you’re not scared of a terminal, but you’re not a career developer. That’s exactly who vibe coding is for.

One thing worth saying up front: there are many tools you can use to vibe code, and no single one is “correct.” Whichever tool you’re most comfortable with that gets the job done is the best one to use. This series leans on VS Code and Copilot, but I’d also recommend installing and trying out the GitHub Copilot CLI and the GitHub Copilot app to find what fits the way you work.

Why?Do I need to read this if I already have a blog?

No. If you already have a working project and dev environment, skip straight to the agent and skills scaffolding section near the end — that part is project-agnostic and worth doing regardless of what you’re building. Everything before it is for people starting from a blank machine.

What “vibe coding” is (and isn’t)

Vibe coding means describing what you want in plain language and steering an AI until the thing actually works — not typing a single prompt and walking away with a finished app. It’s a conversation: you set the direction, the AI proposes, you push back, and you converge on something real.

I go deep on the mindset — plan mode, picking a model, knowing when the AI has wandered off — in Coding with AI: A Neurodivergent Non-Coder’s Guide to Building Real Apps. Read that for the why. This post is the how do I even get started.

Before you install anything: the plan

You’re going to set up six things, in this order, because each one builds on the last:

A GitHub account — your home base for code, history, and hosting.
Git — the tool that actually tracks your changes locally.
The GitHub Copilot app — vibe coding from anywhere, no editor required.
VS Code Insiders — the editor where the deeper vibe coding happens.
Node LTS + npm — the engine that runs a modern website.
GitHub Copilot — the AI you’ll be steering inside the editor.

Then you’ll scaffold a home for your agents and skills so the AI works with you instead of guessing. Let’s go.

A note on operating systems: I’m writing the commands Windows-first, since that’s what most first-timers are on. Where macOS or Linux differ, I’ll call it out inline.

Step 1: Create a GitHub account

Head to github.com and sign up. Pick a username you won’t be embarrassed by later — it shows up in your project URLs.

Why?Why do I need GitHub for a blog?

Three reasons. First, it’s a backup — your writing and code live safely in the cloud, not just on one laptop. Second, it’s a time machine — every change is versioned, so you can undo anything, even a week later. Third, it’s free hosting and the front door for AI tools — Copilot and the agents you’ll use authenticate through your GitHub identity. One account unlocks all of it.

While you’re there, enable two-factor authentication in your account settings. GitHub requires it for most contributors now, and you don’t want to hit that wall mid-project.

Step 2: Install Git (this is not the same as a GitHub account)

This trips people up constantly: your GitHub account lives on the web, but Git is a separate program that runs on your computer and does the actual work of tracking changes.

Windows: download and run the installer from git-scm.com. Accept the defaults — they’re sensible.
macOS: run git --version in Terminal; if Git isn’t installed, macOS offers to install it for you. Or use Homebrew: brew install git.
Linux: sudo apt install git (Debian/Ubuntu) or your distro’s equivalent.

Once installed, tell Git who you are — this stamps your name on every change you save:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Why?Why does Git need my name and email?

Every saved change (a “commit”) records who made it. Use the same email as your GitHub account so your work is properly attributed. It’s not a login — just a label on your history.

Step 3: Install the GitHub Copilot app

Before you install a full editor, install the GitHub Copilot app. It’s the piece that changed how much of my work happens outside VS Code. The app lets you steer Copilot’s coding agent from wherever you are — the web, your phone, or GitHub itself — so you can kick off changes, review what the AI proposes, and approve pull requests without opening a code editor at all.

Windows / macOS / Linux / mobile: install the app from github.com/features/ai/github-app and sign in with the GitHub account you just created.

Why?Why install this before the editor?

Because it genuinely reduces how much you need the editor. A huge share of my vibe coding now starts as a plain-language request to the Copilot agent — from a browser tab or my phone — which then does the work on a branch and opens a pull request for me to review. VS Code is still where I go for hands-on, line-by-line work, but the app handles “describe it, let the agent build it, review the PR” without me sitting in front of an editor at all. Installing it now means you have that option from day one.

Step 4: Install VS Code Insiders

VS Code is the editor. Insiders is the daily-updated version that gets the newest Copilot and AI-agent features before anyone else. Download it from code.visualstudio.com/insiders.

Why?Why Insiders instead of regular VS Code?

The AI agent features move fast, and Insiders gets them first — often weeks ahead of the stable release. The tradeoff: it updates every day and can occasionally be a little rough. For vibe coding, being on the newest features is worth it. If you ever hit a bad build, regular VS Code is always there as a fallback — your projects work in both.

When you first open it, sign in with the same GitHub account (bottom-left account icon). This connects the editor to your identity and, in a moment, to Copilot.

Step 5: Install Node.js (LTS) and confirm npm works

A modern blog is built and previewed by Node.js, and Node ships with npm, the tool that installs the building blocks your site depends on.

Install the LTS version — not “Current” — from nodejs.org.

Why?Why LTS and not the newest 'Current' version?

LTS stands for “Long-Term Support.” It’s the stable, boring, widely-compatible version that every tutorial and tool expects. “Current” is the bleeding edge — newer, but more likely to surface bugs you won’t yet know how to debug. As a beginner, boring is your friend.

After installing, close and reopen your terminal, then verify both tools are found:

node --version
npm --version

You should see version numbers (for example, v22.x.x and 10.x.x). If instead you see something like 'npm' is not recognized or command not found, your PATH isn’t picking up Node yet.

Why?What is PATH, and why would npm 'not be found'?

PATH is the list of folders your terminal searches when you type a command. If node and npm aren’t found, it means the terminal doesn’t know where the installer put them. The fix is almost never manual PATH surgery.

The reliable fix for a “not found” error:

Fully quit and reopen your terminal (and VS Code) — the installer updates PATH, but only new terminal sessions see it.
Restart your computer if step 1 doesn’t do it.
If it still fails, don’t hand-edit PATH. Instead, uninstall Node and reinstall it with a version manager, which handles PATH for you: fnm or nvm-windows on Windows; nvm on macOS/Linux.

Why?Why a version manager is the better long-term answer

A version manager installs Node in a predictable place, wires up your PATH automatically, and lets you switch Node versions per project later. It removes the entire class of “npm not found” problems instead of patching one instance.

Verify everything before you build

Run this quick checklist in a fresh terminal. Each command should print a version or a success message — no errors:

git --version          # e.g. git version 2.4x.x
node --version         # e.g. v24.x.x
npm --version          # e.g. 10.x.x
code --version         # VS Code version (use 'code-insiders' if 'code' isn't found)
gh --version           # e.g. gh version 2.x.x (see below)

If any line errors out, fix that tool before moving on — every later step assumes these all work.

Why?What's 'gh' and do I need it?

gh is GitHub’s official command-line tool, and this series relies on it. It’s the easiest way to log in to GitHub from the terminal (gh auth login) and later to create your repository without leaving VS Code. Install it now from cli.github.com and confirm gh --version prints a version before you continue — Part 2 assumes it’s set up.

Where to do the work: local vs. GitHub Codespaces

Everything above installs your tools locally, on your own machine. That’s a perfectly good way to work — but it’s not the only one, and it comes with a gotcha I learned the hard way.

After spinning up project after project, I ran my hard drive out of space. Here’s the thing that took me too long to realize: once your code is committed and pushed to a GitHub repo, you don’t need to keep a local copy forever. The repo is the source of truth. When you’re done working on a project for a while and you’re tight on disk, delete the local folder — you can always clone it back down the moment you want to pick it up again.

Better yet, skip the local-disk problem entirely with GitHub Codespaces, which lets you work on and test your code in the cloud. Your editor, terminal, tools, and running preview all live on a container GitHub spins up for you — you just open it in the browser or connect VS Code to it.

Why?What actually is a Codespace?

A Codespace is a full development environment — VS Code, a terminal, Node, Git, your project files, everything — running on a machine in the cloud instead of on your laptop. You reach it from a browser or from VS Code on your machine, but the work happens remotely. Nothing takes up space on your local drive, and you can spin one up or throw it away per project.

Why?Which should I pick as a beginner?

Either works, and you can switch anytime — the project is identical in both. Go local if you want the simplest mental model and reliable offline access. Go Codespaces if you’re low on disk space, jump between machines, or just want a clean environment you can delete without a second thought. Many people do both: local for daily work, a Codespace when they’re on a different computer.

Using source control in VS Code

Git is the safety net under everything you vibe code, and the best part is you rarely need to touch the command line to use it. VS Code has a built-in Source Control view that turns commits, branches, and syncing into a few clicks. This is worth learning early — it’s your undo button, your backup, and your history all in one. The official Source Control docs and the quickstart go deeper; here are the parts you’ll actually use every day.

Open the Source Control view from the Activity Bar on the left (the icon that looks like a branching graph) or with Ctrl+Shift+G (Cmd+Shift+G on macOS). Everything below lives here.

The core loop is stage → commit → sync:

See what changed. Every file you’ve edited shows up under Changes. Click one to open a side-by-side diff — old version on the left, your new version on the right — so you can review exactly what you (or the AI) changed before saving it.
Stage the changes you want to keep. Hover a file and click the + to stage it, or stage everything at once. Staging lets you commit some changes now and leave others for later.
Write a commit message and commit. Type a short description in the message box at the top, then click the ✓ Commit button (or press Ctrl+Enter). A commit is a labeled snapshot you can always come back to.
Sync to GitHub. Click Sync Changes (or Push) to send your commits to your repo in the cloud. Now it’s backed up and safe.

Why?What's the difference between staging and committing?

Staging is choosing which changes go into the next snapshot; committing actually takes the snapshot. The two-step exists so you can commit a focused set of related changes — say, just the changes to one post — while leaving unrelated edits for a separate commit. If that feels like overkill at first, VS Code lets you commit everything at once: with nothing staged, hitting Commit offers to stage all changes for you.

Work on branches for anything risky. A branch is a parallel copy of your project where you can experiment without touching your known-good version. Click the branch name in the bottom-left status bar to create a new branch or switch between existing ones. If the experiment works, you merge it back; if it doesn’t, you just switch away and delete it — your main version was never touched.

Read your history two ways. The Source Control Graph (in the Source Control view) shows the timeline of commits and branches so you can see how the project evolved. The Timeline view (in the Explorer, at the bottom) shows the history of a single file — handy for seeing every change to one blog post and restoring an earlier version if you need to.

Why?What are those colored bars in the editor margin?

As you edit, VS Code shows gutter indicators — small colored marks next to the line numbers. A green bar means a new line, blue means a modified line, and a little triangle means deleted lines. Click one to preview the change inline, revert just that block, or stage it. It’s a live, at-a-glance view of everything that’s different since your last commit.

Why?What happens if I hit a merge conflict?

A conflict happens when two changes touch the same lines and Git can’t decide which to keep — common when you edit on two machines or branches. VS Code flags the file and opens a merge editor that shows both versions side by side with buttons to accept one, the other, or both. Pick what’s right, save, and commit the resolution. It sounds scary the first time; the visual editor makes it far less so.

Between the AI writing code and VS Code making commits a two-click habit, source control stops being a chore and becomes what it should be: a constant, low-effort safety net you’ll be glad exists the first time something breaks.

Scaffold a home for your agents and skills

This is the step that separates “AI autocomplete” from actually vibe coding. Skills and agents are reusable instructions you give the AI so it stops guessing and starts working the way you want. You’ll want two homes for them.

1. Per-project customization lives inside each repository, in a .github folder. This travels with the project, so anyone who clones it (including future you) gets the same AI behavior:

your-blog/
└── .github/
    ├── copilot-instructions.md   # always-on context about THIS project
    ├── instructions/             # rules scoped to certain files
    ├── prompts/                  # reusable /slash-command prompts
    ├── agents/                   # custom agents (*.agent.md)
    └── skills/                   # project-specific skills (SKILL.md)

2. Your personal, portable library lives in your home folder and follows you across every project:

~/.agents/
└── skills/
    └── my-skill/
        └── SKILL.md

Why?What does `~` mean?

~ is shorthand for your user home directory. On macOS and Linux that’s something like /home/yourname. On Windows it’s C:\Users\yourname, where yourname is typically your Entra ID (work or school account) without the @domain.com part — so russ@contoso.com becomes C:\Users\russ. So ~/.agents/skills just means the .agents\skills folder inside your home directory.

Why?Why two separate locations?

The .github folder is team- and project-scoped — it ships with the repo so the customization is guaranteed to be there. Your ~/.agents/skills folder is personal and portable — reusable skills you want on hand no matter what you’re building. VS Code Copilot reads both, so you get project-specific rules and your own toolkit at the same time.

You don’t need to author anything elaborate yet — and you don’t need to create the folders by hand either. This is a perfect first taste of vibe coding: let the AI scaffold it for you. Open Copilot Chat in VS Code (the chat panel), make sure it’s in Agent mode so it’s allowed to run commands, and paste a prompt like this:

Create my portable skills library at ~/.agents/skills. Just create the
empty folder structure — don't add any files yet. Show me the command
before you run it so I can approve it.

The AI will propose a command (it’ll be something like mkdir -p ~/.agents/skills), wait for you to approve it, and then run it in the terminal. Reading and approving that command before it runs is exactly the safe habit you’ll rely on for the rest of this series.

Why?What's 'Agent mode'?

Copilot Chat has a few modes. Agent mode lets the AI take actions on your behalf — running terminal commands, creating files, editing code — pausing to ask for your approval along the way. It’s the mode that turns chat into actual vibe coding. Look for the mode picker at the bottom of the chat panel.

That’s the portable library ready. The project-scoped .github files come to life in Part 2, once your blog repository actually exists — there’s no point writing project instructions before there’s a project to describe.

Why?Where do NEW skills go later?

Author your own skills under ~/.agents/skills/<name>/SKILL.md (portable) or a project’s .github/skills/ (ships with that repo). Avoid editing any tool-managed or “bundled” skill folders — those get overwritten when the tool updates.

If you want to go deeper on plan mode, picking a model, and how skills change the way you work, that’s all in the vibe coding lessons post.

Vibe coding safely (read this before Part 2)

AI will happily run terminal commands and rewrite files for you. That’s powerful and occasionally dangerous. A few habits keep you out of trouble:

Commit early and often. Every time something works, save it to Git. It’s your undo button for the whole project.
Work on a branch for anything risky. Branches let you experiment without touching your known-good version.
Read commands before you approve them. If the AI wants to delete files or run something you don’t recognize, slow down and ask it to explain first.
Never put secrets in your code. API keys and passwords belong in environment variables or a secrets store — never committed to the repo, which may become public.

Why?Why does this matter for a simple blog?

Because the habits you build now carry into everything you vibe code later. A blog is low-stakes — the perfect place to learn to commit often, use branches, and review what the AI does before it matters on a real project.

Make security the AI’s default, not an afterthought

The habits above keep you safe. The next step is making sure the code the AI writes is safe too — because an AI left to its own devices will happily reach for whatever pattern was most common in its training data, and “most common” is very often “least secure.” Hard-coded connection strings, public storage accounts, keys in config files, wide-open CORS. It’s not malicious; it just doesn’t know your bar unless you set it.

You set that bar by grounding the AI in real security guidance and making that guidance the highest priority in every instruction, skill, and agent you use. Three levers do most of the work:

Wire up the Azure MCP and use its Azure best-practices tool. The Azure MCP server ships a built-in Azure best-practices capability the AI can call before it writes or deploys anything that touches Azure. It returns secure, production-grade guidance — managed identities instead of connection strings, Key Vault for secrets, least-privilege role assignments, private networking, and secure defaults — grounded in current Microsoft recommendations rather than whatever the model half-remembers. Ask the AI to “check Azure best practices first” and it’ll pull that guidance in before generating code.
Pair it with the Microsoft Learn MCP so security and identity guidance comes straight from the current official docs — Entra ID, Defender, and Azure security baselines — instead of stale training data.
Lead with security in your own instructions, skills, and agents. When you scaffold the .github files in Part 2, put security first in copilot-instructions.md — least privilege, no secrets in code, managed identities, input validation, secure defaults. A short, explicit “security comes first” rule at the top of your instructions steers every response after it.

Why?What's a 'security-focused skill or agent'?

It’s a reusable instruction set whose whole job is to hold the AI to a security bar. You can create a security-review skill that runs a checklist before you ship — secrets scanning, dependency risk, auth and access review, input validation — or a dedicated security-review agent you hand a diff to for a second opinion. The point is the same as any skill: promote your best “did we do this securely?” prompts into a permanent capability the AI applies every time, instead of hoping you remember to ask.

Why?Why put security at the *top* of my instructions?

Instructions are read top to bottom, and earlier rules carry more weight when the AI has to make a trade-off. If “ship it fast” sits above “do it securely,” guess which one wins under pressure. Leading with least privilege, no hard-coded secrets, and secure-by-default patterns makes security the lens everything else is filtered through — not a box you check at the end.

The vibe-coding-specific risks worth knowing

Classic web vulnerabilities still apply, but AI-generated code adds a few failure modes of its own. These are the ones I’d burn into your habits from day one:

Never ship code you don’t understand. Keep a human in the loop. The AI optimizes for “this runs,” not “this is safe.” If you can’t explain what a block does, don’t merge it — ask the AI to walk you through it first.
Verify every dependency before you install it. Models hallucinate package names, and attackers register those made-up names with malware inside (“slopsquatting”). Before you npm install anything the AI suggests, confirm the package is real, actively maintained, and spelled exactly right — then pin the version and commit your lockfile.
Ask for security explicitly in the prompt. Don’t assume the AI will validate input, apply least privilege, or avoid hard-coded secrets on its own. Say so. “Follow secure coding practices, validate all input server-side, no secrets in code” costs you one sentence and changes what you get back.
Let a scanner watch your back. Turn on secret scanning and dependency alerts (GitHub gives you both for free), and run them automatically — not just when you remember. A scanner catches the leaked key or vulnerable package you’ll eventually miss by eye.
Treat tool and web output as untrusted. Content the AI pulls from a webpage, a file, or an API can carry hidden instructions (prompt injection). Never let something the AI read trigger something risky it then does without you confirming it.

Why?What's 'slopsquatting' and why should I care for a blog?

When an AI invents a package name that doesn’t exist, an attacker can register that exact name and fill it with malicious code — so the next person who trusts the AI’s suggestion installs malware. It’s a real, growing supply-chain attack. The fix is cheap: don’t install anything you haven’t confirmed is the genuine, maintained package. Building that reflex on a low-stakes blog means you’ll have it when the stakes are real.

Steal a ready-made security skill

Everything above is easier to enforce when it’s written down as a skill the AI pulls in automatically. This repo ships one you can copy: a vibesec-skill under .github/skills/ that captures secure-coding practices across access control, XSS, CSRF, secrets, SSRF, file uploads, SQL injection, JWTs, and the AI-specific risks above — and tells the AI to treat security as the highest priority and fail closed when it’s unsure.

Drop a copy into your own project’s .github/skills/ (or your portable ~/.agents/skills/), and the AI will apply it whenever you’re building a web app or ask for a security review — no re-explaining required.

Why?Do I have to write that skill myself?

No. That’s the whole point of skills being portable files: grab an existing one, drop it in, and it just works. Refine it over time as you learn your own bar. When you catch a security lesson the skill doesn’t cover yet, add a line — future you (and the AI) inherit it automatically.

Writing posts without touching code: the built-in CMS

Editing MDX files by hand is fine once you’re comfortable, but you don’t have to. This blog ships with a lightweight content management system (CMS) called Keystatic — a friendly admin UI for creating and editing posts, filling in titles, dates, tags, and hero images, and writing the body in a rich editor. It reads and writes the same MDX files in your repo, so there’s no database and no separate service to host.

Why?What's a CMS, and why would I want one?

A CMS is the dashboard you write and manage content in instead of hand-editing files. Keystatic is a git-based CMS: every change it makes is just an edit to a file in your repo that you commit like any other. You get the comfort of a visual editor and the version history of Git — no trade-off.

You don’t install it separately — it comes bundled as a dependency when your project is scaffolded in Part 2. To keep the live site fast, the admin UI only loads when you explicitly start it in CMS mode. Once your project exists, the whole loop is:

npm run cms

Then open http://localhost:4321/keystatic in your browser. You’ll see collections for Blog Posts and Projects. Click one to edit it, or use + Create to start a new post — fill in the fields, write the body, and save. Keystatic writes the .mdx file into src/content/ for you.

Why?Why a separate `npm run cms` instead of the normal dev server?

The everyday npm run dev server stays a pure, fast static site with no admin code shipped to visitors. npm run cms sets a flag that mounts the Keystatic editor at /keystatic only on your machine. It never gets deployed to the public site, so there’s no login to secure and no admin surface exposed to the internet.

Because every save is just a file change, your workflow stays the same as the rest of this series: write in the CMS, review the change, commit it to Git, and push. The AI can still help — ask it to draft a post, then polish it in the Keystatic editor, or vice versa. Use whichever feels natural for the piece you’re writing.

Why?Do I have to use the CMS?

Not at all. Some people prefer writing MDX directly in VS Code with the AI right there; others like the structured fields and preview of the CMS. They edit the exact same files, so you can switch between them post to post — or even mid-post.

What you should have right now

Before moving on, make sure all of this is true — Part 2 assumes every one of them:

✅ A GitHub account with 2FA enabled, and you’re signed in inside VS Code.
✅ Git installed and configured with your name and email.
✅ VS Code Insiders open, with the Copilot extension active and responding.
✅ node, npm, and git all return versions in a fresh terminal.
✅ A ~/.agents/skills folder ready for your portable skills.
✅ You understand the safety basics: commit often, branch for risk, no secrets.
✅ You know how to make security the AI’s default — ground it in the Azure and MS Learn MCPs, and lead every instruction, skill, and agent with security first.
✅ You’ve internalized the vibe-coding risks: review what you can’t explain, verify every dependency before installing, and let a scanner watch your back.

If any box is unchecked, sort it now. A shaky foundation turns Part 2 into a frustrating detour hunt instead of the fun part.

Next: actually building the thing

That’s the setup — the part nobody warns you about, now behind you. In Part 2, we put it all to work: scaffolding the blog with Astro, writing a copilot-instructions.md so the AI understands your project, steering it through your first real feature with plan mode, and deploying the finished site to the internet with a live URL to share.

Your homework before Part 2: run the verification checklist one more time and make sure every command comes back clean. Then subscribe so you don’t miss the build — or if you get stuck on setup, the contact page is the fastest way to reach me.

Ready, Set, Create!(Using AI)