The Productivity Paradox
Over Christmas break 2025, I built a personal knowledge base. I wrote about
that. What I didn't write about was what happened next.
I got faster. A lot faster. Context that used to take twenty minutes to reconstruct was available in seconds. Release notes
that took an hour to draft took fifteen minutes. Meeting prep that required digging through Slack, email, and three
different wikis became a single search. Voice transcripts from meetings captured into a dozen indexed points in the
knowledge base, ready for retrieval whenever I needed them.
So of course I did more.
Not because anyone asked me to. Not because my job required it. Because doing more suddenly felt cheap. The cost of starting
something new had dropped to almost nothing, and my brain (which has always been good at juggling contexts) noticed
immediately. By January I was running four or five Claude Code sessions across multiple virtual desktops. One reviewing the
team's current roadmap and priorities, one drafting release notes, one analyzing PR changes for the weekly release, one
building a new feature for the knowledge base itself. All of them working in parallel while I bounced between them.
Former colleagues used to call me the Duracell bunny. I took pride in that. Still do, actually.
The Familiar Pattern
But here's the thing. This isn't new. I've been cycling through this pattern since my first real job at UIQ almost two
decades ago. Overextend, hit the wall, pull back, find a balance, feel good about it. Then slowly ramp up again until the
next wall. I just used to be younger and have what felt like infinite stamina, and on the rare occasion I overextended I'd
bounce back after a night's sleep.
You could track it by my task management. Easy periods meant task lists on paper. Ramping up meant digital to-do lists in
text files. And whenever it peaked I was usually at something like color coded spreadsheets in Excel to juggle and keep
track of everything. It's been the rhythm of my entire professional life.
The knowledge base surfaced the receipts. 2024: "Stop working long hours, need better discipline logging off." 2025:
"Sometimes I might be too much all over the place." The system I built to make me more productive had become a witness to a
pattern I keep repeating. And now in 2026, with the PKB making everything faster and cheaper, the cycle didn't slow down. It
accelerated.
Earlier I had told my therapist I was going to take the productivity gains and produce the same with less, cash in, take it
easier, coast a little, this time it would work. I saw that while lying in bed at 10pm, tired and happy, researching this
exact topic on my phone using claude.ai's phone app that I had hooked up to my PKB MCP server downstairs on my main
computer.
I'm failing badly at that.
Why can't I just stop?
This is the question that keeps coming back. I'm a grown adult with years of experience managing projects, teams, and
deadlines. I know what sustainable looks like. I've coached others on it.
And yet.
The feedback loop is constant. You open a Claude Code session, describe what you want, and watch it work. Iterate on the
results, produce quality work faster than ever, without the cognitive load of loading and storing context between sessions.
There's something deeply satisfying about seeing three terminals producing results in parallel while you start a fourth.
Marking a task DONE feels good. Seeing 5 out of 7 completed at the end of the day feels better. The reward is immediate,
visible, and always available.
It doesn't help that I work from home full-time. Amazing office downstairs, multiple screens, comfy chair. The commute is
fourteen steps.
And the knowledge base made it worse. Or better, depending on how you look at it. I built a system that reduces the cost of
context-switching to nearly zero. Research from Tuesday is retrievable on Friday without losing anything. A project I set
down for a week picks up right where I left off. The activation energy for starting new work dropped so low that the only
brake left was sleep.
Brakes turns out to be important.
The self-awareness was never missing. I've known about this pattern for my entire career. Every time I pulled back and found
balance, I thought I'd learned the lesson. I hadn't. I'd just run out of fuel temporarily. The PKB didn't create the
problem, but it removed the last natural brake. What I've never had is infrastructure to act on what I already know. Knowing
you should stop and having a system that helps you stop are very different things.
What I built to fight back
So I did what I always do when I hit a problem. I built something. But with the same principle I apply to every AI system I
design: the AI proposes, the human decides. No autonomous action without explicit approval.
The core is a daily planning routine. My personal assistant (a separate system that handles email triage, health checks, and
morning context gathering) prepares a structured summary every morning: today's calendar, the weekly work cadence, what's
urgent, what's overdue, and crucially, yesterday's activity stats. That last part matters more than everything else. If the
diary shows 54 Claude Code sessions and nearly 3,000 audit events from yesterday, the planner knows it was a heavy day and
biases toward a lighter one today.
Then I sit down with Claude Code and we negotiate. It proposes a bounded list. I push back or agree. Must-do items first
(work comes first, always), should-do items if there's room, and maybe one want-to-do if the day genuinely allows it. The
total effort can't exceed available hours, and there's always a slack buffer for the unplanned Slack messages and support
cases that inevitably show up.
The critical rule: if something new comes in, something else moves to tomorrow. No stacking.
When I confirm the plan, it gets written to my task file. During the day I check things off as I go. Next morning, the cycle
repeats. Archive what's done, return what isn't to the inbox, start fresh.
It's not complicated. The daily planner, the weekly planner, the activity diary, the audit logger that captures every tool
call and context switch. They're all just tools feeding off the same context infrastructure. The interesting part isn't the
tools.
It's why I needed them at all.
The crown jewel problem
None of this would work without the personal knowledge base. And that's the pattern I keep running into, across every tool
I've built.
I've been trying to push LLMs into practical daily work since ChatGPT launched in November 2021. Over the years I've had
them draft release notes, write Slack replies, prepare meeting agendas. The results got more impressive as models improved,
but they always fell short. The release notes lacked my voice and institutional context. The Slack replies were plausible
but generic. Not me.
The problem was never model intelligence. It was always lack of data and context.
The PKB changed that. It pulls in Slack conversations, GitHub PRs, emails, calendar events. All the institutional knowledge
that used to live scattered across a dozen tools. I had Claude Code retroactively analyze over 200 release notes I'd written
across four years to build a writing guide that captures my language, my style, my tone of voice, what to avoid. And
suddenly the output felt right. Not perfect, but recognizably mine. After four years of trying, that was the first time it
actually worked.
But even then: I review everything. Claude Code writes, suggests, proposes. I approve, reject, tweak. Always. The personal
assistant can read the knowledge base but cannot write back to it. If it could, one bad classification poisons future
decisions. I'm the gatekeeper. That's the boring design principle compared to "fully autonomous AI assistant."
That's what makes it trustworthy.
Is it working?
Honestly? Too early to tell.
The first day the planner ran, it told me I had zero free hours. I immediately added a new implementation task anyway.
Within minutes. The bunny lives.
But I'm collecting data now. Every day the diary logs what I actually did versus what I planned. The audit logger captures
every session, every context switch, every tool call. All of it local, on my hardware, for my eyes only. I have a
retrospective scheduled where Claude Code will analyze the patterns: am I actually stopping when the list is done? Is scope
creep measurable? Are heavy days followed by lighter ones, or am I just bulldozing through?
The honest answer might be that I've built a more sophisticated to-do list and spreadsheet and the Duracell bunny is now
wearing a watch. But even that would be something. At least I'd know.
What I do know is this: the tools that make knowledge work faster are also the tools that make it harder to stop. The
friction that used to force natural breaks (the blank page, the context rebuild, the slow feedback loop) is disappearing.
For people wired like me, that's a superpower and a trap in the same package.
I built the system that removed the friction. Now I'm building the system that puts some brakes back.
The bunny is still running. But at least now it knows what time it is.
Top comments (0)