The hardest part of building something large on your own is holding the whole thing in your head. And while you're vibing, it's hard to keep track of what you did yesterday, let alone last week. What's left on the big feature I'm halfway through. Did I already handle the login case or just mean to. A team spreads that load across people and standups. On your own it all sits with you, and it leaks out the moment you step away for a few days.
You don't fix that by remembering harder. You fix it by having the agent keep two documents current as it works, so the memory lives in files instead of your head.
The running changelog
A changelog is a dated list of what changed, written for the person using the thing. Most people meet it as release notes on someone else's software and don't think to keep one themselves. That's the part I want to change your mind about. A changelog isn't a publishing chore you do at release time. It's a work log that happens to double as release notes, and the agent can keep it current for free while it builds.
The rule is simple. Every time the agent finishes something you'd actually notice, it adds one plain line under an Unreleased heading. Here's what that looks like in practice, straight from a project of mine:
## [Unreleased]
### Added
- Reach your Mac from anywhere, not just the same Wi-Fi. Your phone can now
connect to the Koda running at home over the internet through a private,
encrypted tunnel, so you can check on and steer a session from the road.
### Fixed
- Images in a document now show up in the document view. A picture you
reference by its file used to come up blank; now it renders inline.
### Changed
- Sub-folders in the Documents list now nest and indent under their parent,
so a folder inside a folder reads as a tidy tree instead of one long path.
Two things make this worth the habit. The first is that it drafts itself. When you're ready to cut a version, you're editing a list that's already written instead of trying to reconstruct a week of 12-hour vibe sessions from memory and commit messages. The Unreleased block becomes the release notes.
The second is more useful day to day as the plain-language answer to "what has this project actually done lately," and you can read it in ten seconds after a week away. Code and commits tell you what changed in the code. The changelog tells you what changed for the person using it, which is the version you think in when you're deciding what to do next.
The one rule that keeps it honest: write each line for the user, in what they see or do, and leave pure internal work out. "Refactored the sync module" helps nobody. "Your changes save back on their own when you tap Done" is a line you and your users both understand. If a change has no visible effect, it doesn't earn a line.
The ship checklist, for the big ones
The changelog handles the steady stream of small stuff. A large feature needs its own document, because a large feature is where holding it in your head fails hardest. There are ten moving parts, three of them are decisions you haven't made yet, and two of them are gotchas you'll only remember at the worst moment.
So before starting something big, have the agent write a ship checklist: what "done" actually means, broken into a list you can check off, with the open decisions called out separately from the mechanical work. Here's the real one I'm using to ship an iPhone companion app, lightly trimmed:
# iPhone App — Ship Checklist (Phased)
Ships in two increments, not one release:
| Increment 1 | Native app over same-WiFi control | Free | later this week |
| Increment 2 | Cloud / from-anywhere, the paid tier | Paid (IAP) | later this month |
| Cross-cutting | App Store distribution + review | — | start now |
## Decisions (settled + open)
- [x] Billing = in-app purchase on iOS, Stripe on Mac/web, one shared
entitlement. Once remote access is a feature inside the iOS app, Apple
guideline 3.1.1 makes IAP the correct mechanism. Qualifies for the Small
Business Program at 15%, not 30%.
- [x] Transport ships as BOTH the cloud relay and the WireGuard tunnel,
not one or the other. Decided; do not re-open.
- [ ] Turn the paid tier on: both transports enabled in the shipped build,
no longer behind the testing flag.
## Increment 1 — Native app over LAN (free)
- [x] Scan the Mac's QR on the same Wi-Fi, pair, go. No account.
- [x] Device-verified on a real phone. Increment 1 is code-complete.
- [x] No purchase surface yet — audited: no paywall, no price, no gate.
## Cross-cutting — App Store (gates both public releases)
- [ ] App Store Connect record, metadata, screenshots, privacy labels.
- [ ] Network Extension review form (WireGuard needs Apple's justification).
- [ ] The reviewer can't run your Mac. A companion app is inert without a
paired, awake Mac, and Apple rejects apps that look non-functional.
Needs review notes, a demo video of the full loop, and a reviewer path.
- [x] Support inbox (hello@kodahq.io) resolves.
What this buys you is the ability to put the feature down. You come back in three days, open the checklist, and the boxes tell you exactly where you stopped and what's next. No re-reading code to reconstruct your own plan.
That last unchecked item is the kind of thing a checklist exists for. "The reviewer can't run your Mac" is not a task, it's a trap I'd have walked straight into at submission time, weeks from now, with everything else already done. Writing it down the day I understood it means it's waiting for me instead of ambushing me.
The part people skip is separating decisions from tasks, and it's the part that matters most. Tasks are things the agent can just do. Decisions are things only you can make, and a big feature usually stalls on one unmade decision while a pile of doable work waits behind it. Listing them apart means you can see, at a glance, "the whole thing is blocked on me picking a payment provider," instead of feeling vaguely stuck. A checkbox next to a decision is a nudge that it's your move.
Keep the checklist honest the same way you keep the changelog honest. When a decision gets made, write down what you chose and one line of why, right there in the list. When something ships, check the box. A checklist you don't update is worse than none, because it lies to you with confidence.
Why this works when you're on your own
Both documents do the same job from different ends. The changelog is the rear-view: what this project has already become. The ship checklist is the windshield: what this one big thing still needs. Between them, the state of the work lives in files the agent maintains, not in your memory, and that's the whole trick. You can step away for a week, come back, read two short documents, and be caught up on a codebase too large to hold in your head. A team gets that from each other. Solo, you get it from writing it down, and the agent does the writing.
Neither of these is a tool you install. A changelog is a markdown file. A checklist is a markdown file. The only thing you're adding is the habit of telling the agent to keep them current as part of finishing the work, instead of treating documentation as a thing you'll do later. Later is when you've already forgotten the part worth writing down.
I build Koda, a Mac app where the agent keeps a changelog and working docs like this for every project by default. But nothing above needs it. It's markdown in a folder, and any agent tool can run it today.
Give your agent this prompt:
From now on, keep a CHANGELOG.md at the root of this project. Whenever you finish a change that I would notice as the user, add a plain-language line to an "Unreleased" section at the top, grouped under Added, Changed, or Fixed. Write it for a non-technical reader in terms of what they see or do, not how the code works. Skip pure internal refactors. Do this as part of finishing the work, not as a separate step I have to ask for. Start by reading the recent history of this project and drafting the Unreleased section for everything already done that belongs in it.