khairold
← Back to Systems

Work on the system, not in the system

The operating principle behind everything I build — and why most engineers are doing it backwards.

·
PhilosophyLeverageAISystems Thinking

There’s a feeling I keep having. It’s the feeling of doing the same thing for the third time and knowing I’ll do it again next week.

Processing tickets manually. Re-explaining context to a new session. Copying data between systems. Organizing notes. These aren’t hard tasks. They’re easy tasks that eat your life through repetition.

The instinct most people have is to do them faster. Get better at the busywork. My instinct is different: build a system that makes the busywork disappear.

The principle

Work on the system, not in the system.

This isn’t a productivity hack. It’s a leverage question. Every hour spent doing repetitive work has a return of one hour. Every hour spent building a system that automates repetitive work has a return that compounds.

The math is simple but people ignore it because building systems feels like procrastination. “I should be doing the actual work, not building tools.” But the “actual work” is often the thing that shouldn’t require a human at all.

Three systems, one principle

Everything I’ve built recently follows this pattern.

The note-taking problem

I had notes everywhere. Notion pages, Apple Notes, random text files. I’d capture something and never see it again. The standard solution: be more disciplined. Create a better folder structure. Use tags.

That’s working in the system. More effort on the same broken process.

Instead, I built a Second Brain where my only job is to talk — text or voice, from my terminal or WhatsApp — and AI handles filing, connecting, and surfacing. The system extracts people, projects, ideas, and tasks automatically. It sends me daily digests of what needs attention. It flags when projects go stale.

I capture 5–10x more than I did with any note app. Not because I’m more disciplined — because the system removed the discipline requirement.

The context transfer problem

AI sessions start fresh. Every time you open a new conversation, you re-explain your project, your decisions, your constraints. Most people accept this as the cost of working with AI.

That’s working in the system. Re-doing the same setup every session.

Instead, I built the .plan/ protocol — four markdown files that give any AI session full context in seconds. PLAN.md shows where we are. MEMORY.md holds every decision and its rationale. The AI reads these files, orients itself, and starts working. Zero re-explanation.

I built a full website in 4 sessions. Each session picked up exactly where the last left off. The time spent creating the protocol was repaid by the second session.

The data pipeline problem

Singapore publishes 10,000+ court judgments on a clunky government site. Lawyers struggle to find relevant cases. The standard approach: hire people to manually curate and summarize cases.

That’s working in the system. Throwing human labor at a data problem.

Instead, I built a scraping and AI pipeline that pulls cases automatically, extracts summaries and entities with Claude, and publishes them to a fast, searchable website. 640 cases processed in one run. Entity extraction across all of them. The pipeline can process the remaining 9,800+ cases without me touching it.

The system does in minutes what would take a team weeks.

Why this is hard

The principle is obvious. The execution is hard for three reasons:

1. Building systems feels like not working. When you have 50 unprocessed tickets, spending a day building an AI categorization pipeline feels irresponsible. Your manager sees zero tickets closed. The pressure to “just do the work” is real.

But the day after the pipeline is built, those 50 tickets get categorized in minutes. And next week’s 50 tickets. And the week after that.

2. You have to see the repetition first. Systems thinking requires pattern recognition. You need to notice that you’re doing the same thing repeatedly before you can abstract it away. Most people are too deep in execution to notice the pattern.

This is actually why brain dumps matter. When I capture “processed tickets again, same manual categorization” three times in a week, the Second Brain surfaces that repetition. The system helps me see where I need systems.

3. The first version is slower. Building a system to automate a 10-minute task takes hours. The breakeven is somewhere around the 30th repetition. If you’re not honest about how often you repeat something, you’ll misjudge the investment.

But here’s the thing: in 2026, building systems is dramatically faster than it was. AI compresses the build time. The breakeven point has shifted from months to days. The .plan/ protocol took one session to design. The Second Brain’s Cloudflare Worker API took one session to build. These aren’t large investments anymore.

The meta-layer

There’s a recursive quality to this principle. The tools I use to build systems are themselves systems I’ve built:

  • The Second Brain captures the thoughts that lead to new systems
  • The .plan/ protocol manages the multi-session builds of those systems
  • The agent design (SOUL.md, HUMAN.md, TENSIONS.md) ensures the AI collaborator gets better over time
  • TENSIONS.md watches for friction in the systems themselves, feeding the next round of system-building

Each system creates leverage for building the next one. The Second Brain makes me better at noticing where I need automation. The .plan/ protocol makes me faster at building it. The agent’s self-observation surfaces issues I wouldn’t catch on my own.

This is the real compounding: not just automating tasks, but automating the process of discovering what to automate.

The honest version

I still do busywork. I still manually process things I should have automated by now. The principle isn’t “never do manual work” — it’s “every time you do manual work, ask whether a system should be doing it instead.”

Sometimes the answer is no. Some tasks are genuinely one-off. Some are too complex to automate reliably. Some aren’t worth the investment.

But most of the time, the answer is “yes, and I’ve been avoiding it because building the system feels like procrastination.”

It’s not procrastination. It’s the highest-leverage work you can do.