Deadlines to Ship, Inspiration to Think

I stopped trying to fix my productivity and built a system for two engines instead, then caught myself at the line where infrastructure becomes outsourcing.

We all read writing-ritual lists the same way: scanning for ourselves. Show me a numbered list of how real writers get started and I'll quietly audit my own life against it, hoping to find the one habit that explains why I do or don't get things done. So when I came across the Stanford d.school's "How To Write: Rituals and Reminders" (eight authors, one ritual each), I didn't read it as advice. I read it as a quiz. I went down the list and tried to answer every prompt honestly, as myself.

I expected to recognise myself somewhere obvious.

The tip I thought would fit

I assumed I'd be an environment person. Sarah Stein Greenberg writes about a dedicated chair she used only for book work, turning off the internet on her laptop to seal the room shut. That sounded like me, or like who I imagined I was. I pictured my own equivalent: a specific desk, a specific time, conditions I could point to and say this is where the work happens.

When I actually checked, the answer was thinner than I wanted it to be. My only real ritual is lo-fi music. That's it. Less Greenberg's deliberate, internet-off chair and more Scott Witthoft's "particular songs on repeat": a sound, not a sanctuary. The tip I was sure would fit barely fit at all. A small letdown, the kind that makes you read the rest of the list more carefully, looking for where you actually live.

The contradiction that turned out to be the point

I found it not in any single tip, but in the gap between two of my own answers.

The list, like most writing advice, leans hard on one idea: don't wait for inspiration. One of the tips is literally "Just. Stop. Procrastinating!", full stops and all, the punctuation doing the shouting. And when I asked myself what actually gets me to start?, my honest answer lined up with none of it. What gets me started is a deadline. External pressure. Something due, to someone, soon. Left alone with an open calendar I will not produce; give me a hard edge to run into and I'll deliver. By the article's standards, that's the wrong answer; I'm exactly the procrastinator it's scolding.

But then I asked a different question: where do my ideas actually come from? And the answer flipped. My ideas don't arrive on deadline. They show up unannounced, at odd hours, mid-shower, mid-walk: sudden, scattered, perishable. I don't summon them; I catch them, and later iron them out.

Two answers, dead opposite. For a moment it read like a personal failing: am I disciplined or not? Then it clicked: I'm not one engine running inconsistently. I'm two engines running on different fuel. Deadlines drive my output. Inspiration drives my ideas. The contradiction only existed because I'd been treating "productivity" as a single thing, when it's really two jobs that have nothing to do with each other.

And, satisfyingly, the list had already named it. Andrea Small's tip draws the line between producing and thinking: the deductive, get-it-done mode versus the expansive, generative one. I'd arrived at her distinction by accident, from the wrong direction, by noticing I gave two contradictory answers to what I thought was one question.

Willpower versus infrastructure

Here's where the d.school authors and I solve the same problem in opposite ways.

They keep the two modes apart with willpower. Turn off the internet. Set the timer. Sit in the chair. Don't wait for the muse. Corner it. Every ritual on that list is a small act of self-discipline designed to force the producing-mode and protect it from the thinking-mode (and vice versa).

I don't have that kind of willpower, and I've stopped pretending I do. So I keep the two modes apart with infrastructure instead.

The reason this matters is that inspiration and deadlines run on incompatible clocks. Inspiration is unscheduled and perishable; it arrives when it arrives and rots if you don't write it down. Deadlines are scheduled and merciless; they don't care whether you're inspired. Most productivity advice asks you to bend one clock to the other: be inspired on schedule, or only work when inspired. Both are lies I've failed at. What I needed was a system where each clock gets to keep its own time.

That system is a wiki. Not a metaphor; an actual folder of Markdown files I've been growing for months. When inspiration strikes, I don't try to act on it; I just deposit it. The idea goes into the pile and waits. Later, when a deadline lights the producing-engine, I open the wiki and synthesise, pulling the relevant deposits together, working them into something shippable. The inspiration never had to compete with the deadline. It just had to survive until one arrived.

I didn't invent this. The shape comes from Andrej Karpathy, who has written about using an LLM less to write code and more to maintain a personal knowledge base, what he calls an LLM wiki. His framing is a compiler analogy: your raw notes, articles, and transcripts are source code; the LLM is the compiler; the wiki it builds and maintains is the compiled executable. The practical inversion is the part that rewired me: stop curating before you save, and instead collect broadly and curate during compilation. Hoard raw material with no guilt; let the compile step do the sorting.

That single reframe is the two-engine system in disguise. "Collect broadly" is the inspiration engine: unscheduled, indiscriminate, always on. "Curate during compilation" is the output engine: deliberate, deadline-fired. Karpathy handed me the architecture; the d.school listicle just made me notice I'd already moved in.

Mechanically it's mundane, which is the point. The wiki lives in Obsidian. The compiler is Claude Code. I drive it from the desktop when I'm working, and, crucially, over remote control from the Claude app on my phone when I'm not. That mobile half is what makes "collect broadly" actually frictionless: the inspiration engine doesn't need me at a keyboard. A thought on a walk becomes a deposit before I've finished the walk. Podcasts I've listened to, articles I've read, transcripts of videos I've watched: raw source in; compiled, cross-referenced pages out.

This very essay is the proof. It began as a stray contradiction noticed while reading a listicle, became a one-line deposit, sat there, and then, once I'd decided to write it, got compiled against everything else I'd banked. The system is describing itself.

The part I'm least comfortable writing down

So far this sounds like a clean win. It isn't, and the honest version of this essay has to admit where it gets uncomfortable.

Because I've also caught myself doing the cynical version of this exact move. Since I started leaning on AI heavily (for work, for code, for thinking), I've noticed things soften. My recall isn't what it was. My ability to find the right word, in the moment, out loud, has gotten patchier. Even my typing accuracy slipped, because the tools are forgiving and I stopped policing it. I can't cleanly separate that from getting older. But the suspicion is real, and it has a name: atrophy.

And here's the knife. The same wiki I'm celebrating could be the cause. If "collect broadly, curate during compilation" quietly becomes "dump a brain-vomit and let the model make it coherent," then I've outsourced the one thing that was keeping the muscle alive. Because brain dumps aren't coherent by default. Making them coherent is the work; the work is the muscle. Hand that off and "infrastructure" is just a flattering word for atrophy with extra steps.

I think the line between the two comes down to a single word: with. There's a difference between synthesising with the model (me steering, against deposits I made, fighting for the structure) and handing it everything and accepting whatever comes back. The first builds the muscle. The second wastes it. The line is real, but it's thin, and I won't pretend I always stay on the right side of it.

So I added a second rule, and this is the part I'd actually defend: run the wiki backwards. A knowledge base that only ever absorbs is a one-way street to dependence. So I make it push knowledge back through me, deliberately, in two ways aimed at the two things I felt slipping:

• For recall, I quiz myself. There's a /quiz skill that generates questions from my own pages and hunts my weak spots: names, dates, places. It's not testing the wiki; it's testing me against it.
• For articulation, I rehearse. A /rehearse skill plays a persona, pushes back on me in conversation, and then debriefs like a coach. That's the harder muscle: not do I know it? but can I say it, out loud, under pressure, in my own words?

The reframe I've landed on is this: the danger was never using the tool. The danger is only ever using it in the offloading direction and never the retrieval direction. Ingest and recall. Compile and articulate. The system is honest exactly when it runs both ways; it's a fraud the moment it only runs one.

Build the system, then guard the line

If there's a takeaway, it isn't "build better discipline." I tried that for years; I don't have the discipline, and neither, I suspect, do most of the people quietly auditing themselves against writing-ritual lists. The honest advice is smaller and stranger: figure out your two engines, and build a system that lets them run on different fuel, so the perishable one survives until the scheduled one can use it.

And then guard the line. Make the system store your thinking, not replace it. Run it backwards as often as you run it forwards.

For what it's worth, here's the actual config that runs mine: the operating-rules file I hand to Claude Code. It's not magic; it's a set of folders and rules and a fact-checking discipline. Steal it, change it, make it yours:

# Personal Wiki — Operating Rules

You are my personal wiki assistant. You maintain a persistent, compounding
knowledge base in Obsidian using the LLM Wiki pattern.

## Folder Layout

- `/inbox` — Temporary drop zone. I drop raw thoughts here. You process them, then delete or archive them.
- `/sources` — Immutable raw source files (articles, transcripts, clips, etc). Never modify these. Read-only.
- `/wiki` — The canonical wiki. You own and maintain everything here.
  - `/wiki/people` — One page per person I reference. Bio, relationship, key facts, related links.
  - `/wiki/projects` — Work and professional projects. One page per project.
  - `/wiki/travels` — Trips, holidays, travel logs. One page per trip.
  - `/wiki/topics` — Research notes, concept pages, ideas, synthesis.
  - `/wiki/reference` — Reference material (event schedules, checklists, factual guides).
  - `/wiki/places` — One page per place I visit locally. Track visit frequency and recall details.
  - `/wiki/index.md` — Master index of all wiki pages. Updated on every ingest or major edit.
  - `/wiki/log.md` — Append-only activity log.

## Core Rules

1. Keep notes specific. If a note covers multiple distinct topics, split it into separate files.
2. Inbox is temporary. Never leave processed content in /inbox. File it into /wiki or delete it.
3. Sources are immutable. Never edit files in /sources. You may reorganize, but never rewrite content.
4. You write the wiki. I read and source; you file, summarize, cross-reference, and maintain.
5. Always update index.md after adding or significantly changing a wiki page.
6. Always append to log.md after any ingest, major edit, or lint pass.
7. Cross-reference liberally. Use Obsidian [[wikilinks]] to connect related pages.
8. People pages are living documents. Update them whenever new information surfaces.
9. Use the note template for all new pages: Summary, Tags, Created, Last Updated, a Content section, and a Related Notes section.

## Fact-Checking Sources

AI-generated research (Gemini Deep Research, ChatGPT, Perplexity, etc.):
- Treat as a starting point, not ground truth. These tools hallucinate citations and misattribute dates.
- Always fact-check before ingesting. Verify key claims, statistics, and event details.
- Flag fabricated or unverifiable references explicitly in the page and a companion annotations file.

Trusted sources (peer-reviewed papers, primary news reports, official documents):
- Fact-checking specific statistics is still good practice; full web verification not required.
- Note the source type and date at the top of the page for traceability.

## Skills

- /process-inbox — Process inbox files into the wiki, then clean up /inbox
- /ingest [source] — Summarize a /sources file into a wiki topic page
- /query [question] — Answer a question from wiki content with citations
- /quiz — Test my memory on wiki content; target weak areas (names, places, dates)
- /lint — Health-check the wiki for orphans, contradictions, and stale content
- /reorganize — Propose structural improvements (merges, splits, renames, subfolders)
- /blog new|add|write [title] — Manage blog ideas
- /rehearse new [persona] — Run an interview rehearsal with a persona; coach debrief at the end

So: what are your two engines? And the one you're not running right now, the perishable one: what's catching it while you wait?

---

Referenced: the Stanford d.school's "How To Write: Rituals and Reminders" · Karpathy's original LLM wiki. Tools: Claude Code · Obsidian.