Section 0What is agentic coding? Start here if you're new

This section is for readers who have never written software — no programming background, no familiarity with developer tools. It explains, from zero, what an AI coding agent actually is, what happens when it "builds an app," and the handful of words you need so the rest of this guide reads like a book instead of a wall of jargon. If you already work in software, skim the vocabulary cards and move on to Section 1.

Two things are true at once, and holding both is the whole trick of this section. Building software has genuinely become something a person without a technical background can direct — that isn't hype, it's the premise this guide takes seriously enough to spend fourteen sections on. And yet the words around it — repository, deploy, CI — still form a wall that makes outsiders feel the field isn't for them. The wall is thinner than it looks. Behind it sit perhaps a dozen ideas, none harder than the ones you already use to read a contract or run a household budget, and this section walks through them in order, each one standing on the previous.

Here's the bar for the next few pages: by the end you'll be able to say, in your own words, what an AI coding agent actually does when it "builds an app," follow one complete working loop from request to result, and read the rest of this guide without stopping at every third term. That's all this section attempts. Everything deeper — how to direct the work, check it, and ship it — is what Sections 1 through 14 are for.

Software is text files, run by a computer

Start with the most basic fact, because everything else builds on it: a program — a website, an app, a booking system — is a collection of plain text files. Each file contains source code: instructions written in a programming language that a computer executes. "Writing software" means writing and changing these text files; "running" the software means having a computer follow those instructions. There is no magic object behind the curtain — if you can change the right text files, you can change the program.

Those files live together in a repository (or "repo") — a project folder with a memory. A tool called Git records every change ever made to it: who changed what, when, and why. That history is what makes it safe to let anyone — human or AI — edit the files: any change can be inspected, compared against the previous state, and undone.

The salon app, once it exists, is exactly this: one repository holding a few hundred text files — the booking screen, the rules about double-booking, the list of code libraries it builds on, its own tests — plus the full Git history of every change since day one. Nothing in it is sealed away or out of reach. That's worth internalising early, because it's the reason an AI agent can work on software at all: a program that can read and write text can, in principle, do to a codebase anything a programmer can.

What a language model is — and what it isn't

An LLM (large language model) is a program trained on enormous amounts of text until it becomes very good at one job: given some text, predict what text should come next. That single skill turns out to cover a lot — answering questions, summarising, translating, and yes, writing source code, because source code is text too.

Two properties matter for everything in this guide. First, a model is not a database: it doesn't look answers up, it generates them — which means it can generate text that is fluent, confident, and wrong (a hallucination). Second, it only knows what it saw during training plus what you put in front of it right now — its context. It has no memory between conversations and no awareness of your project unless the relevant files are shown to it.

Both properties will follow us through the entire guide, so make them concrete now. Ask a model about the salon app's code and it may confidently describe a cancelBooking() function that has never existed — not because it's lying, but because that is exactly the function such an app plausibly would have, and plausible-next-text is the only game the model plays. And if you told it yesterday that "customer" means the person booking the haircut, not the salon, today's fresh conversation knows nothing of the sort until someone puts that definition in front of it again. Much of the discipline of working with these models — Sections 3 and 12 especially — is managing those two facts rather than being repeatedly surprised by them.

From chatbot to agent: give the model hands

A chatbot can only talk. An agent is a language model connected to tools — the ability to actually do things: read a file, edit a file, run a command, search the web. Wrap that in a loop — look at the situation, decide the next step, act, look at the result, decide again — and you get agentic coding: you describe an outcome in plain language, and the agent plans the work, edits the repository's files, runs the program to check its own work, reads the error messages, fixes what broke, and reports back. Tools like Claude Code are exactly this: a coding agent that operates on a real project folder on a real computer.

One loop, watched end to end

Abstractions stick better after one concrete run-through, so here is the agent loop in slow motion, on the salon app. You type a single sentence into the agent — your prompt: "Customers should be able to cancel a booking up to 24 hours before the appointment." Then you watch.

• It reads before it writes. The agent searches the repository for everything to do with bookings, opens those files, and builds a picture of how the app currently works — the same orientation a new human colleague would need, done in seconds instead of days.
• It edits the text files. A new rule in the booking logic, a "Cancel" button on the customer's booking page, a check for the 24-hour deadline. Each edit is an ordinary change to an ordinary file, and Git records all of it.
• It checks its own work. It runs the app's tests and the app itself. One test fails — the deadline check got a timezone wrong. The agent reads the error message exactly the way a person would.
• It fixes and re-checks. Edit, run, read, again — the loop — until the checks pass.
• It reports back. A short plain-language summary of what changed and why, with the full record of every edit sitting in the repository for anyone to inspect.

Minutes, start to finish. Now notice what you did during those minutes: nothing — and everything. You chose a feature worth having, you phrased what "done" means ("up to 24 hours before"), and you're about to judge whether the result is actually right — should a cancellation also notify the owner? The agent couldn't know you wanted that; deciding, framing, and judging are the job this guide trains. And notice the thing that should quietly worry you: every check in that story was a check the agent ran on itself. Building checks it can't talk its way past is the difference between a demo workflow and a professional one — it's where Section 1 picks up.

The vocabulary you actually need

Seven terms cover most of what this guide assumes. Each also has a glossary entry, and every section explains its own jargon as it goes — but these seven are the load-bearing ones:

The seven terms, run through one story

Definitions fade; stories stick. So take the cancellation feature from the loop above and follow it all the way to a real customer. The agent's edits live in the repository. It records them as a commit — a snapshot with a note: "Allow customers to cancel up to 24h before appointment." It bundles that work into a pull request: here is a proposed change; someone approve it before it joins the real project. The moment the proposal exists, CI wakes up and runs every test the project has against it — had one failed, the pull request would be blocked with no human effort spent. You review and approve. The change goes first to staging — the rehearsal copy of the salon app, where you tap through a cancellation yourself with nothing at stake — and only then is it deployed to production, where a real customer, later that evening, cancels a real Thursday appointment. Seven terms, one journey. Every chapter that follows is about doing some leg of that journey well.

Why "it works on my screen" isn't "it's done"

Here is the trap this entire guide exists to help you avoid. An agent can produce a working-looking app astonishingly fast — a real interface, real buttons, data that saves. Building that demo is maybe a fifth of the work of a real product. The other four-fifths are invisible in a demo: keeping strangers from reading your customers' data, surviving the moment a database dies, handling two people booking the same slot at the same instant, the legal documents a real business is required to have, and the ability to change the software next month without breaking it. Software that has all of that is called production-ready; software that only has the demo is what this guide calls vibe-coded.

None of this is an argument against agents — they can build the invisible four-fifths too. But they mostly won't unless someone asks, checks, and verifies. That someone is you, and you don't need a computer-science degree to do it: you need the right questions, the right checklists, and the discipline to run them. Supplying those is what the following sections — and the companion production-readiness protocol (production-readiness-protocol.md), a checklist an agent can execute against your project: download it into your repo and hand it to the agent as a checklist — are for.

What you don't need — and the three things you do

A word for the doubt you may still be carrying: "surely I need to learn to code first." You don't, and it's worth being precise about why not. You don't need to write code yourself, for the same reason a film director doesn't need to operate the camera: the operating is done by someone — something — else, and your value lies in knowing what a good result looks like. You don't need mathematics beyond arithmetic. You don't need to memorise commands — the few this guide uses run in the terminal, the plain text window where coding agents live, and Section 2 hands every one of them to you copy-and-paste ready. And you don't need expensive hardware; as noted above, the heavy machinery runs on the provider's servers, not your laptop.

Three things you do need, none of them technical. The willingness to read what comes back. Agents report in plain English; the newcomer failure mode isn't misunderstanding the reports but skipping them. The reflex of asking "how would I know if this is wrong?" — which sounds like engineering but is really the same scepticism you'd apply to a builder's quote or a used car. The checklists are supplied by this guide; the reflex to reach for them is yours to bring. Patience with a new kind of colleague — one that is astonishingly fast, never tired, occasionally confidently wrong, and entirely dependent on you for direction. Section 1 is about exactly that working relationship, which is why it comes first.

Quick check: a friend shows you an app an agent built for them in a weekend — bookings save, the calendar fills, it looks finished. They want to launch Monday. What do you tell them?

That what they're looking at is the demo — and a working demo is maybe a fifth of a real product. Everything that decides whether Monday goes well is invisible on that screen: whether a stranger can read other customers' data, what happens when the database dies, whether two people can grab the same slot at once, the legal documents, the ability to change the app next month without breaking it. None of it exists unless someone asked, checked, and verified — and the agent's own cheerful "done" is not that check. The decision: don't launch Monday; treat the weekend build as a promising start and run it through the production-readiness questions first.