Chatting with an AI works for one bug, but not for a project that runs for months. Building Makers Brain, we moved the project's state out of the chat and into a note that both people and AI read, edit, and keep working from.
For most of the past year, working with AI on code looked like a chat for us. Lately we've been moving the important part out of the chat and into a note. That small shift is what Makers Brain is built around.
The chat works, until the project gets big
Tools like Claude Code and Cursor made one workflow feel natural: you type "build this," "why is this broken," "change that," and the AI does it. For a single function or a single bug, that's hard to beat.
It works less well once a project runs for weeks. We kept running into three problems.
The first was drift. A long conversation collects side questions, detours, and corrections of corrections. Somewhere in there the original goal gets diluted, and now and then the AI keeps confidently building on a direction we had dropped twenty messages earlier.
The second was that we became the relay. The AI does a step, we look, we tell it the next step, we wait. It's faster than writing everything by hand, but someone still has to sit at the terminal the whole time.
The third bothered us most: very little of the work stuck. When a session ended, the reasons behind a design choice, the list of what was fixed and what wasn't, the next step we'd agreed on all lived in a terminal's scroll-back. A week later, neither we nor the AI could reliably piece it back together.
First the AI wrote the notes. Then it started reading them.
Our first fix was modest. We asked the AI to keep records for us: a daily development log for each project, a note of the prompts we wrote, a short blueprint of what each project is and where it's going. All of it lives in a notes app of ours, in a folder we now call Makers Brain.
After a few weeks of this, an obvious question came up. If the AI can write these notes, why can't it read them before starting work and pick up from there?
A project always has a state, whether or not anyone writes it down: what we're trying to do, what's done, what's in progress, what's stuck, and what counts as finished. In a chat, that state is smeared across hundreds of messages. In a note, it's one page both of us can open.
What the loop looks like in practice
So we turned the note into the place work is driven from. Each project in Makers Brain is a folder. At the top is a goal written in plain words. Below it is a task table: the task, what it requires, how we'll check it's done, and its status. The statuses are deliberately few: to do, in progress, waiting for review, done, blocked. Every task also keeps a short log.
The loop is plan, do, check, write back, and do again.
When we write or change a goal, Claude breaks it into three to five small tasks and fills in the table. When we press run, a runner on our own machine takes the next task, works on it in the codebase, runs the acceptance check, and writes the result back to the note. If the check is something a machine can verify, the task is marked done. If it needs a human eye, like a layout or an interaction, it goes to "waiting for review" and the runner moves on. If it fails three times, or the requirement is unclear, it marks itself blocked, writes down exactly what it needs from us, and stops.
A task that starts as "build user login" ends up looking more like this:
Task: Build user login Check: a test user can log in, refresh the page, and stay logged in Status: Waiting for review Log: email/password login works; the basic flow test passed. Not handled yet: the wrong-password message and session expiry.
The part we like most is how corrections happen. If the AI got something wrong, we don't argue with it in a chat. We edit the note: change the goal, rewrite a requirement, tighten the acceptance check. The next time it picks up a task, that's what it sees. We've stopped telling the AI what to do next and started keeping a shared record that tells both of us.
What we've learned so far
As a working system this is only a few days old (we started piloting it on October 3), and it has already corrected us a few times.
Task size matters more than we expected. Code tasks work best when each one touches one to three files. Research and writing tasks need to be even smaller. On the first day we put three news events into one task, and that one task ran for the better part of half an hour. Now it's one piece of content per task.
The acceptance check has to be something you can actually run or look up. "Make it work well" gives the AI nothing to check against. "This command returns 200" does.
Some lines stay with people. In this setup the AI doesn't deploy, doesn't commit or push, doesn't change live database structures, and doesn't delete user data. Anything like that gets marked for review and waits for us. That's less about distrust than about a clear split of roles: the terminal is where things get done, the note is where we work together, and decisions about direction stay with the person who owns the project.
Why we think it's worth pursuing
AI coding tools keep getting better at writing code. Over the next few years we suspect the harder question won't be "can the AI write this function?" but "can the AI stay useful on a project that runs for months?" Requirements shift, plans change, and the people on the project forget things too. What carries a project through all that is a lasting record of where it stands. A longer context window doesn't do that.
Notes suit this well. They're plain, everyone already knows how to edit them, and they don't have to be tied to any one AI tool. If a better model shows up next year, the project's state is still sitting in the note.
Where Makers Brain stands
Makers Brain is still an experiment. We don't know yet whether it will become a product, a feature of our notes app, or simply the way we work. What we're fairly sure of is the idea underneath it: working well with AI depends less on making the AI more like a person and more on giving people and AI a better shared place to work.
Put more simply: don't let the important parts of a project live only in a chat. Put them where both of you can see them, change them, and keep building on them.