Build: One Feature, on Its Own Branch

Step 4 of 7.

The specs are written and the agent has done its first read. Now it builds. This is where the AI works fastest, and where an unchecked mistake spreads fastest, so the lesson is about doing it in a way that is easy to review and easy to undo.

Our goal: build one feature from its spec, on a branch of its own, and check the result against the spec and not only against the compiler.

Here is the route:

How a developer takes a ticket: a branch of their own.
Why the AI always works on a branch too.
Building from the spec.
Checking the work against the spec.
One feature at a time, and what changes with several.

We leave out the tests and the reviews (lessons 12 and 13), and the push, which comes after a person has read the work (lesson 13).

How a developer takes a ticket

A developer picks up a ticket and does not start typing on the shared main line of the code. They make a branch: a private copy of the code where their changes live until they are ready. Everyone else keeps working on the main line, undisturbed. When the work is done and reviewed, the branch is merged back.

Three reasons a team does this. A mistake on the branch harms no one, because the branch can be thrown away. The whole change sits in one place, so a reviewer reads it as one piece. And two people can work at once without stepping on each other.

Why the AI works on a branch too

All three reasons count double for an agent.

A mistake is cheap. The agent can edit many files fast. If the result is wrong, you delete the branch, and the main line never knew. This is a wall (lesson 02) made of habit.
The review has a clear edge. The branch holds exactly this task. What the person reads in lesson 13 is the difference between the branch and the main line, and nothing else.
Several can run side by side. Each task on its own branch cannot collide with another (more on this at the end).

So the rule is: every task starts on a new branch, and the agent creates it first. The name matches the task, such as task-03-add-book. It is a good rule for a person too, and the agent follows it because the pointer file from lesson 10 says so. Pushing the branch to the shared server waits until a person has read it.

Building from the spec

Start a fresh session for each task (lesson 08). It is a new hire, so the pointer file brings it up to date. Then give it the task, in the fewest words:

Build task 03 from docs/specs/03-add-book.md. Create the branch
task-03-add-book first. Do only what the spec says. Before you change
anything, tell me your plan.

Each sentence is a habit from lesson 05. "Do only what the spec says" holds the scope. "Tell me your plan" is plan first, and it is the cheapest moment to catch a wrong reading.

An example of what comes back (yours will differ):

Plan for task 03, on branch task-03-add-book:
1. A page with a form: ISBN, title, author, price (optional).
2. A check that the ISBN is digits only and that title and author are
   not empty.
3. Save the book to SQLite and return to the list.
4. The list page, sorted by title A to Z.
I will not add editing, deleting or covers (out of scope).
Question: the spec says the same ISBN cannot be added twice. Should the
error name the existing book?

Read it as you read a spec. The plan matches. The question is a small gap in the spec, and now is the time to answer it. Say yes or no, and then let it go ahead. In Manual mode (lesson 10), it asks before each edit, and you read what it proposes.

This course does not walk through the code, and you do not need to read it to follow the process. The agent writes C#, and the interesting part is what you do around it.

💡 Task 01 first. Task 03 needs a project to exist, so task 01 (setup) is built the same way before it: a branch, a short plan, a check. It is a small feature, so we skip the walk-through.

Check it against the spec

The code compiles and the page opens. That is not the same as done. The "Done when" lines in the spec are the checks (lesson 09), so use them, in order.

Run the app and try each line. Watch for two things that compiling cannot show:

Something missing. The list should be sorted A to Z, and an unsorted list still compiles.
Something extra. A delete button the spec never asked for is more to review and maintain.

Then:

A check fails: say what is wrong in one sentence, point at the spec line, and let the agent fix the branch.
The spec is silent: that is a gap. Fix the spec first, then the code (rule 1).
All checks pass: ask the agent to commit, a save point on the branch. Nothing has left your machine.

One at a time, and then several

Do one feature at a time. Finish it and get it checked before the next. That keeps each branch small enough to read, and a mistake in one cannot hide behind the next.

Lesson 09 said several agents can build at once. They can, when the specs do not overlap, each on its own branch. Task 02 (login) and task 05 (search) touch different things, so they could be built side by side. The catch is at the end of the picture: every branch still needs a person to read it. Speed in building makes the reading the slow part, which is why lesson 13 is about reading well. Start with one, and add a second when reviewing the first feels easy.

Where we ended

The project now has code, on a branch, and the main line is untouched.

Before (the end of lesson 10):

bookshop-backoffice/
├── README.md
├── CLAUDE.md
├── .claude/settings.json
└── docs/ ...                  tasks and specs

After, on the branch task-03-add-book:

bookshop-backoffice/
├── README.md
├── CLAUDE.md
├── .claude/settings.json
├── docs/ ...                  unchanged
└── src/                       <- NEW  the C# web app (from task 01)
    ├── the add-book page      <- NEW  the form and the save (task 03)
    └── the book list page     <- NEW  the sorted list (task 03)

Recap

A developer takes a ticket on a branch, so the main line stays safe and the change sits in one place.
The agent does the same: every task starts on a new branch, created first. A mistake is cheap, the review has a clear edge, and branches cannot collide.
Build from the spec, in a fresh session, in few words: do only what the spec says, and tell me your plan first.
Check the work against the "Done when" lines, not only the compiler. Look for what is missing and what is extra.
A gap in the spec is fixed in the spec first (rule 1). Then commit on the branch. Nothing is pushed yet.
One feature at a time. Several can build in parallel when they do not overlap, and then reading is the slow part.

Questions to think about

The answers are left out on purpose. Try them in your own words first.

Why does a developer work on a branch, and not on the main line?
Why should an AI agent always work on a branch?
Why is "it compiles" not the same as "it is done"?
What do you do when a check cannot be answered because the spec is silent?
Why does building in parallel make review the bottleneck?

Next lesson: step 5, Test and AI review. Turn the "Done when" lines into tests, and give the work a second look.