Six PRs. Two TypeScript felonies. One rebase cascade that broke the laws of git. And then the twist.
Case file opened: Week 14, April 2026
There is a week every year when Norway simply stops. The parliament empties. The highways fill with Volvos heading north. The cabin doors open to air that hasn't been breathed since February. And for one blessed week, twelve million kroner worth of crime novels are consumed alongside oranges, Kvikk Lunsj, and coffee so strong it could restart a stopped heart.
Påskekrim — Easter crime. It's a national tradition. You're supposed to read about murders. You're not supposed to commit them.
AI does not remove the hard part of any job. It moves it — and makes it harder to ignore.
Based on a conversation between two software developers, March 2026.
Two developers were talking late one night about what AI had actually changed in their work. They had both been using it for years. They were good at it. And what they kept coming back to was something that surprised them: the more capable the tool got, the more it demanded of them — not less.
This essay is built on that conversation. But the idea they landed on has nothing to do with software. It applies to any job where thinking is the work.
In 1985, the Danish computer scientist Peter Naur published a short paper called "Programming as Theory Building." His argument was simple and radical: a program is not its source code. A program is a theory — a coherent mental model of what the system does, how its parts relate to each other, and why it was built the way it was. The source code is a byproduct of that theory. A trace. Not the thing itself.
Something caught my attention this week. JJHub launched a version control platform built on Jujutsu instead of Git, designed specifically for agentic engineering teams. The premise: Git's data model breaks under the commit volume that agents produce.
That observation is narrowly about version control. But the pattern it reveals is much broader.
Tim O'Reilly posted something this week about craftsmanship in the AI age. The question he was circling: how do you maintain quality standards when agents are doing the work?
The default answer in the industry is: keep the human in the loop. For every meaningful decision, have a human review before proceeding.
I'd been using the Task tool heavily — delegating research tasks to Claude subagents, letting them explore codebases, map dependencies, surface patterns. The results coming back were good. But when I'd start a new session and ask about the same topic, there was no trace of that prior investigation. The context window had reset, and the episodic memory layer — kcp-memory — wasn't helping.
Here's what that looked like in practice: I'd asked a subagent to map the co-events repository ecosystem earlier this week. It came back with a clear picture — co-events is the CatalystOne HRIS event-sourcing platform, seven repos, with a dependency chain running from co-event-typelib through co-event-sdk into co-analytics-vanilla (which, by the way, uses Neo4j with APOC, not SQL — a non-obvious choice). Two days later, I started a new session, asked about co-events architecture, and got a blank stare. The agent had no idea any of this had been mapped. It treated the question as entirely novel.
My first hypothesis was handover loss. Maybe something was being compressed or summarized too aggressively when agents returned their findings. Maybe the model transition (often Opus for the delegated tasks, Sonnet for the orchestrating session) was dropping context. That felt plausible, and a little unsettling.
The real cause was more concrete — and more fixable.
Last Tuesday I needed a file-watch service on my workstation. The kind of thing that monitors a directory and triggers a reindex when something changes. Normally that means ten minutes of reading systemd docs I've read fifty times before, copying a unit file from somewhere, adjusting paths, running systemctl --user enable, checking journalctl for the inevitable typo in ExecStart.
Instead I described what I wanted. Claude Code found an existing service on the machine, used it as a template, wrote the unit file, enabled it, started it, checked the logs, confirmed it was running, and updated the knowledge manifest so future sessions know the service exists. I approved three actions. The whole thing took about ninety seconds.
I haven't typed apt install in three months. Not because I stopped installing software — I install more than ever. But the person typing the commands isn't me anymore.
Multi-agent systems need two kinds of identity. The first answers "who is this agent and how do I call it." The second answers "what knowledge does this agent have and who is allowed to see each piece of it." Google's A2A protocol handles the first. KCP handles the second. They are not competitors. They are different layers of the same stack.
This post started as that explanation. Then, the same day it was published, we built four simulators and 150 adversarial tests against the spec. The tests found 8 concrete gaps. Those gaps are now driving KCP v0.7. The full story follows.
Most teams using AI for development have settled on a workflow that looks roughly like this: write a detailed specification, feed it to the agent, review the output, iterate. It is disciplined. It is responsible. It works. And after six months of watching it in practice, I believe it has a structural limitation that becomes more expensive the longer you use it.
The limitation is not quality. Spec-driven development produces good output. The limitation is that every session starts from zero. The spec carries the knowledge. The agent carries nothing.
Eleven days. 197,831 lines of Java. A PCB design library built from nothing to manufacturing-ready. Clean numbers, clear arc, dramatic compression of time.
That was January 27. Six weeks ago.
Nobody asked what happened after. Which is the point.
