Skip to content

AI-Augmented Development

Two Architectures for Claude Code: What 19,700 Stars Got Right and What They Missed

A repository called claude-code-best-practice hit #1 trending on GitHub this week. 19,700 stars in days. Eighty-four tips from Boris Cherny, who created Claude Code, along with contributions from Thariq, Cat Wu, and the broader Anthropic team. It is the most comprehensive public document on how to get serious results from Claude Code, and it deserves the attention it is getting.

The reason it caught my eye is that the ExoCortex -- the eight-layer stack running my Claude Code setup for ten-plus weeks now -- solves many of the same problems from a fundamentally different direction. Same tool, same class of problem, different architectural assumptions. Comparing the two reveals something neither setup has articulated on its own: there are two distinct philosophies for extending Claude Code, and both have blind spots the other has solved.

We Cancelled a 45-Minute Architecture Review. A KCP Query Answered It in 1.2 Seconds.

When the AI Agent Knows Your Architecture — organisational knowledge becomes queryable rather than assembled in meetings

Last week someone asked the question that usually triggers a meeting: "If we change the payment service API contract, what else breaks?" In any enterprise system older than a few years, nobody has the full picture. The payment service team knows their side. The downstream consumers know theirs. The platform team knows the deployment topology. But the blast radius of a contract change lives in the intersection of what three or four people carry in their heads, and the only way to assemble that intersection has always been to put those people in a room.

We didn't put them in a room. We ran a query.

The Squash Merge Murders

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.

The Investigator had other plans.

The KCP Ecosystem: How Five Tools Turn Claude Code Into a Persistent Intelligence Platform

The KCP Ecosystem — Turning Claude Code into a Persistent Intelligence Platform

The Problem

Every session with Claude Code starts from zero.

Every AI session starts from zero — the Start-From-Zero Loop

You open a new session, and the model has no idea what you were doing yesterday. Which services are running. What you decided about the database schema last Thursday. Why you chose the library you chose. You re-explain it. Claude asks clarifying questions you answered two sessions ago. You paste the same background context you always paste. Then the work begins.

And when the work does begin, there's a different problem: output flooding the context window. Run mvn package and you get 400 lines of Maven lifecycle noise. Run terraform plan and the diff buries the actual changes in scaffolding. Run kubectl get pods cluster-wide and you've spent 8,000 tokens on status rows you didn't need.

Context flooding destroys working memory — 33.7% of a 200K context is recovery overhead

The context window is your working memory. Filling it with boilerplate and re-explaining the same setup repeatedly is waste — not just inconvenient, but structurally limiting. A 200K token context sounds vast until a third of it is recovery overhead.

What's missing is infrastructure. Not smarter prompting. Not longer context. Infrastructure — a persistent layer that handles memory, filters noise, and gives the model the right knowledge at the right moment without you having to manage it manually.

That infrastructure is KCP.

kcp-dashboard: Observability for the KCP Ecosystem

The KCP toolchain has been running in the background for weeks. kcp-commands injects manifests before Bash calls. kcp-memory indexes sessions and tool events. Events accumulate in ~/.kcp/usage.db and ~/.kcp/memory.db. The machinery works. But until today, the only way to know whether it was working well was to grep through databases and trust the numbers.

Trust is not observability. You cannot improve what you cannot see.

Today we are releasing kcp-dashboard v0.22.0 -- a terminal UI that reads both KCP databases and shows you what the guidance layer is actually doing: which commands are guided, how often manifests leave the agent needing more help, what sessions look like, and where the gaps are.

The Faster Pencil

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.

Peter Naur Was Right in 1985, and AI Just Proved It

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.

I haven't typed apt install in three months

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.

The Code Was Never the Moat

Bruce Perens says the entire economics of software development are dead. He said this in response to a story about a developer using Claude to rewrite a Python library from LGPL to MIT in a few hours. 130 million monthly downloads. 1.3% textual similarity to the original. A clean room implementation, or close enough that the legal distinction barely matters anymore. The whole thing took roughly five days.

Perens is half right. The economics of code as artifact are dying. The economics of knowing what to build are stronger than ever.

Skill-Driven Development vs Spec-Driven Development

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.