For developers: remember why you built it this way

Code is the easy part. The hard part is remembering why - why this library, why that trade-off, why you ripped it out two sprints later. Meet Priya, a backend engineer on a small team.

The mess

The architecture call happened in a thread. The decision was real; the reasoning is gone. Three months on, someone asks "why are we on Postgres and not Dynamo?" and the honest answer is a shrug. So the debate happens again.

Your desk, in engineering terms

• Inbox - a stack trace you'll look at later, a snippet, a "TODO: this is a race condition."
• Ideas - a refactor you're not ready to justify yet.
• Work - the few tasks worth doing before the release.
• Memory - architecture decisions with the why attached. Your team's real ADRs, minus the ceremony.
• Slate - sketch the sequence diagram when words won't do it.
• Ship - the release, the changes, and whether it actually fixed the thing.

Moments from Priya's week

"Save it where you are." In onboarding.tsx, Priya selects Users quit while creating a workspace. Auto-create one and let them rename later. and runs Scribble Flow: Save (Ctrl+Alt+S, or Cmd+Alt+S on a Mac). She picks Decision and writes the why. The card is on the desk with the file and the branch. The same key lets the agent search and save when she asks. The steps are in From the editor.

"Paste it now, read it later." A gnarly stack trace at 6pm. Priya drops it into capture as code - language preserved - and goes home. It's in the Inbox tomorrow with a title already on it.

"Why this library?" Choosing between two queue libraries, Priya writes the call as a decision in Memory: chose the smaller one, because the team can actually read its source. Future-Priya asks Memory and gets the answer with a link.

"This bug keeps coming back." Priya keeps capturing the same flaky-test symptom. On the Desk, Connect the dots notices the pattern and nudges: you've mentioned this timeout four times. Connect these links the notes - it was never four bugs, it was one.

"Draw the flow." Before a migration, Priya opens Slate and sketches the old path vs the new one. The drawing saves as a scribble, ready to connect to the release.

A developer's week

• In the editor: one key, then Save, or one sentence to the agent.
• During the day: capture snippets, errors, and "why did that break?" the moment they happen.
• When you decide the architecture: write it in Memory with the trade-off, not just the choice.
• Before a PR/release: turn the loose scribbles into tasks in Work.
• After you ship: one line on the outcome - regression gone, or not.

FAQ

Is this architecture-decision-record software? No. Memory is where the why lives, without a markdown ritual in git. If you already keep ADRs in the repo, you can still capture the messy thread that led there.

Can I paste a stack trace? Yes. Capture as code - language preserved - and read it later in Inbox.

Does this work in VS Code and Cursor? Yes. One desk key. The editor can save a selection. The agent can search and save when you ask. Your original text stays yours.

Will AI rewrite my notes? Never. The original is untouched. Suggestions are Accept, Edit, or Dismiss.

Next

The mechanics are in From the editor (the key, Save, and the agent), Just capture (code, files, screenshots), and Make something of it (turning a scribble into a decision). For the longer take, read engineering decisions without the ceremony. Start with Start here if you want the two-minute version.