Choosing something small enough to finish

The most common first-project failure has nothing to do with AI. People pick something they cannot finish, get 60% of the way, and quietly stop.

Your first build has one job: to be finished. It exists so you run the whole loop once, end to end, including the boring parts.

The three tests

A good first project passes all three.

1. One sentence, no “and”.

Good: “A page where I paste a link and it saves to a list I can see later.”

Bad: “A page where I save links, and tag them, and search them, and it syncs to my phone.”

Each “and” is a separate thing that can break. Four features do not take four times as long to review — they take longer, because now failures interact.

2. You can see whether it works.

Something visual and immediate. You do the thing, you look at the screen, you know.

Compare that to “a script that cleans up my spreadsheet”. Did it work? You would have to check hundreds of rows to be sure. That is a fine second project. It is a terrible first one, because you cannot review it with the skills you have today.

3. One sitting.

If you cannot imagine reaching a finish line in an hour or two, cut it down. You are not measuring your ambition here — you are buying repetitions of the loop.

The project we will use

For the rest of this course, the running example is a small one:

Readlist — a single web page where you paste a link, click Save, and it appears in a list. The list survives closing the browser.

It passes all three tests. It is also honest about size: it is a page, a text box, a button, and a list.

You are welcome to build something else. Keep your own project on the same scale and everything here transfers.

Write the finish line first

Before you type a single prompt, write down what “done” looks like. Three or four lines, plain language:

Done means:
- I paste a URL, click Save, and it appears in the list
- Refreshing the page does not lose the list
- I can delete an item
- It does not look broken on my phone

This takes two minutes and does more work than any prompting trick.

It gives you something to check the agent’s output against. Without it, “done” drifts — every time you look at the thing, you see one more improvement, and you never ship.

The cut list

Everything you want that is not on the finish line goes on a separate list, called Later. It stays there until version one is actually shipped.

For Readlist, the Later list is long and that is fine: tags, search, editing an item, a nicer design, syncing, sharing, a browser extension.

Not one of those is bad. Every one of them, added now, is a way of not finishing.

Set it up now

A finish line you are holding in your head is not a finish line. Give it a folder.

Three things, two files, one folder: the one sentence and the finish line go in done.txt, the cut list goes in later.txt, and the folder they sit in is the project. No code yet — the scope exists first.

The terminal in this lesson is a simulator. Nothing you type touches your computer and nothing here can break, so type the four lines rather than reading them.

mkdir readlist
echo "Readlist: a page where I paste a link and it appears in a list." > readlist/done.txt
echo "Done means: the link shows up in the list and refreshing does not lose it." >> readlist/done.txt
echo "Later: tags, search, editing, syncing, a browser extension" > readlist/later.txt

mkdir makes a folder. The rest is one idea called redirection: > sends a line into a file and replaces whatever was there, and >> adds a line to the end instead. That is why the second line into done.txt uses >> — with > it would have wiped the first one.

Read it back with cat readlist/done.txt and you are looking at the thing you will check the agent’s work against.

Building something other than Readlist? Use your own words. The task only checks that the folder exists, that done.txt contains a Done means: line, and that later.txt is there holding what you cut.

That folder is the entire input to your first prompt, which you write in the next lesson.