Using AI for larger projects

When you first start using AI it feels like magic. You type, it types back, and paragraphs that would have taken you an hour to write arrive in four seconds. With smaller works it never stops feeling like that.

But then you try something big. A book, a business plan, a year of family history. Day one is great. Day two is fine. Somewhere on day four the model forgets what you told it at the start, contradicts decisions you already made, and quietly rewrites a section you liked.

The model didn't get worse. You kept filling the jug until it overfilled.

It rarely looks dramatic. People refine inside the chat window, ask for new markdown files in the chat, and stack revision on revision until neither they nor the model can tell which plan is the current one.

An AI model has no memory. Every time you hit send, the entire conversation so far goes to it again: your first message, its first reply, the PDF you pasted on Tuesday. That bundle is the context window, measured in tokens, about three-quarters of a word each.

So 104,000 / 200,000 is not a tally of what you've spent. It's the size of the bundle right now, and every turn re-sends it.

Most chat apps hide this. You never see a token count, you just see the conversation get compacted, or you get told to start a new one. Caching makes the re-sending cheap for about five minutes, then it's full price again.

Compaction is worth understanding, because it's the thing that quietly costs you the day's work. There's a hard ceiling on how much can be sent, so when you approach it the app summarises the conversation and carries the summary forward instead of the transcript. That summary is written by a model, not by you, and it keeps roughly what looks important in the abstract. The five minutes you spent explaining why your aunt's version of the story is the unreliable one becomes a line that says you discussed family sources. From that point the model is working from a description of your project rather than your project, and it gets thinner every time it happens.

Not every tool does this. Coding agents compact and keep going, because they can open your files again afterwards — the summary is thin, but the files it points at aren't. Most consumer chat apps don't even offer that: you get told the conversation has reached its maximum length and to start a new one. Same ending, less ceremony.

Memory features don't cover the gap either. They carry a few facts about you, not the state of your work.

So stop trying to hold the project in the conversation. It cannot be held there: it compacts, it degrades, and then it's gone. Use the conversation to produce something instead. You talk something through, and before that chat closes, the understanding you arrived at is written to a file: a note, a section, a line added to the reference doc, a decision recorded with its reason. Folders of files are the context. The chat is where they get made.

That reframes what a good session looks like. Not a long conversation you keep alive, but a short one that leaves something on disk. If a chat ends and nothing on your computer changed, that chat was a loss — the work was real and it went into a buffer that gets thrown away.

Before this chat gets any longer: everything we worked out here that isn't written down yet, put it in files. For each one, tell me the file, whether it's new or an edit, and what you're adding. Include decisions and the reasons behind them, not just the finished prose. If something we discussed doesn't belong in any existing file, say so and suggest where it should go.

Running out of room is the obvious failure. The quieter one costs more: quality drops long before the window is full.

It isn't the volume, it's that nothing is sorted. An open-book exam with one textbook is fine. The same number of pages shuffled across every subject is not.

The model's own replies count too, and in a long chat they're the bulk of it. Ask for "the whole thing again but shorter" and the pile now holds both versions.

There's a worse version of this. The model gets a fact wrong — invents a name, uses a date you'd already corrected, reverses a decision you made on day one — and you tell it so. Your correction doesn't delete the wrong answer. Both versions are in the pile now, and every turn after that re-sends both. It behaves for a while, then reaches for the wrong one again, because from inside the context the mistake looks exactly as authoritative as the fix.

Polluted context stays polluted. There's no undo inside a conversation. The only thing that actually clears it is a new chat.

Which is why arguing with the model is the wrong move. You're correcting something temporary. Nobody writes a book in one shot — it's months of passes, and the model isn't carrying any of it between them.

Correct the file instead. Whichever file owns that fact: the reference note it came from, the timeline, the chapter that's already using it. The model is what edits the file quickly, and it's what you think out loud with while you work out the wording — but the fact now lives somewhere that doesn't evaporate, and the next twenty chats read it from there.

You've got a fact wrong: [the mistake]. The correct version is [the fact]. Don't just rewrite it in this chat. Tell me which file that fact belongs in, edit that file, and quote the lines before and after so I can check. Then list anything else in the project that repeats the mistake, so I can fix those too.

1. Your work lives in files on your computer. The chat is disposable.
2. One conversation does one job. When it's done, the output goes in a file and you close the chat.

Control is why it works. In one endless chat the model reads everything, always. Once the work is in files, you choose what it reads. These three files, nothing else.

The chat is scratch paper. It's where you think out loud, try a wording, push an idea around until it's prose, and it's meant to be thrown out at the end. The model isn't remembering your project between sessions, it's reading it. The files are the memory. The model is the engine you point at them — it changes them fast, it expands a bullet into three paragraphs, it finds the bit you contradicted yourself on. What it doesn't do is hold the project. Which is what makes a bad turn survivable: you fix the file and bin the paper.

A biography, but swap in your own project. The shape doesn't change.

biography/
├── CONTEXT.md      ← the facts and the rules. Goes in every chat.
├── outline.md      ← the plan
├── raw/            ← unedited dumps. Messy on purpose.
├── notes/          ← raw material, cleaned up and compressed
└── chapters/       ← the actual book

Click a task and watch what it needs:

CONTEXT.md goes in every conversation. Under two pages: who's who, what the project is, the rules on voice and format, and the names spelled how you want them. Without the names the model invents one in chapter two, keeps using it, and you catch it in chapter nine.

raw/ is where you dump. Talk for twenty minutes and save it without editing a word. Repetitive and out of order is fine. The mess is where the detail is.

notes/ is where the mess becomes usable, and it's the step everybody skips. One chat, one raw file, cleaned up. What comes back is a fifth the length.

It runs the other direction too. Don't only compress what you wrote. Point a chat at the broad source, a book, a PDF, a folder of research, and ask it about one topic. Talk it through, then save what came out as a new note.

That note is narrower than the book, and it's what your later chats read instead of the book. Ask a sub-question against the note and you get something narrower again. Each pass is a smaller thing to carry and it's aimed at what you actually need, rather than everything the source happened to cover.

Compress once, and every later conversation gets the compressed version. Never feed the broad thing to a working chat. Feed it to a distilling chat first.

What that looks like on one file:

raw/kitchen.md          1,900 words, spoken, unedited
  "...and she had that yellow pot, the big one, I think it was her
   mother's, no wait, it was from the shop on Dundas, and every
   Sunday she'd..."

notes/kitchen.md        380 words, sorted, dated
  Yellow enamel pot. Bought at the Dundas Street shop, not inherited.
  Sunday roast, every week, 1961 to 1974.
  OPEN: what year did the shop close?

Read this raw dump. Pull out the distinct events, people, dates and details, put them in order, and cut the repetition. Do not add anything I didn't say, and do not smooth over gaps. If something's missing or unclear, list it at the bottom as an open question.

Here is [the book, PDF or folder of research]. I only care about [topic]. Pull out everything relevant to it and leave the rest. Keep the specifics: names, numbers, dates, and direct quotes where the wording matters. Tell me what looked thin or missing. Write it as a standalone note that makes sense without the source, because the source isn't coming with it.

chapters/ is the output, one file each. Writing chapter four, the model gets CONTEXT.md, outline.md, and the two or three notes it draws on. Not the other chapters. Not raw/. If chapter six needs something from chapter two, paste the two paragraphs, not the chapter.

Read only these files: [list the files]. Write [what you want] to [the file it should go in]. Don't read anything else in the folder, and don't change any file except that one.

None of this needs a programmer's setup. The same model reaches you through three shapes of tool, and most people have only used the first:

The middle one is the surprise. If your output is documents, that's where you stop. All three read the same plain files, which matters more than the choice: a folder of markdown opens in any of them, in Obsidian, in a text editor from 1995, and in whatever replaces them in two years.

Once an agent can edit your disk, you ask it to tidy chapter four and it rewrites the ending you spent an evening on. There's no Ctrl-Z across a folder.

Git is that undo. It photographs every file in the folder at once, and you can walk back to any photograph later. That's the whole idea. A photograph is called a commit, the stack of them is your history, and nothing is ever thrown away, so going back costs you nothing.

GitHub is where that history lives when your laptop doesn't. Email, password, done in three minutes, and private folders are free. After that a dead drive is an inconvenience instead of a loss.

You don't have to learn a single command. Every tool in the ladder above already knows git, so ask in English: "save a checkpoint", "what changed since yesterday", "put chapter four back the way it was this morning". Ask it to connect GitHub too. It will do the work and hand you the one browser step it can't click itself.

The order is the habit: save point first, then turn the agent loose.

Set up git for this folder if it isn't already, then commit everything with a message describing what changed in this session. Explain in one line what I'd type to get back to this exact point later.

All of it, as something you can paste. It doesn't build anything first. It interviews you, because your answers are what CONTEXT.md is made of.

I want to use you on a long project: What you're working on. It will outlast this conversation, so set it up to live in files instead of in the chat.

Start by asking me questions. What the project is, who it's for, what finished looks like, the voice and format I want, and the names, terms and spellings you have to get right. Ask a few at a time and wait for my answers. Don't start building until you have enough.

Then make the folder: CONTEXT.md with the facts and rules you just learned, outline.md with the plan, and empty raw, notes and chapters folders. Keep CONTEXT.md under two pages and keep it to facts.

Set up git in that folder and commit. From then on, commit before any change that touches more than one file, and tell me the one command that undoes it.

For every task after this, name the files you're about to read before you read them, and read nothing else. If a task seems to need the whole project at once, say so and split it instead.

Finish by telling me what you're still unsure about, and what I should dump into raw first.

Nothing in it is clever. Each paragraph is one thing from this post:

• Ask me questions. Left alone a model starts writing. Interviewing you first produces the facts a fresh chat would otherwise guess at.
• Make the folder. Sections 4 and 5, handed over as an instruction.
• Commit before multi-file changes. Section 7. Save points arrive before you need them, which is the only time they work.
• Name the files first. Section 3. This is the line that keeps context small once you're twenty chats in.
• Say what you're unsure about. A model will paper over a gap silently if nobody asks.

Read it again and notice what it mostly is. Constraints. Not "help me write a book" but which files, in what order, and what to do when it doesn't know. That's the difference between an assistant and a very fast way to make a mess.

Short projects don't need any of it. One long chat is fine for an afternoon. Folders and save points are overhead. Overhead pays off when a project outlives a single sitting.

Compression loses things. A cleaned-up note drops the odd phrasing, the tangent, the thing you said sideways that was the best line in the dump. That's why raw/ is permanent.

Context windows keep getting bigger. True, and it doesn't change the advice. A bigger desk with everything on it is still a desk with everything on it. The files-on-disk half was never about tokens.

The folder is yours. The chat isn't.