Skip to content

AI-Augmented Development

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.

The Front Door and the Filing Cabinet: A2A Agent Cards Meet KCP

The Front Door and the Filing Cabinet: Composing A2A and KCP in Multi-Agent Systems

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.

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.

Six Weeks After the Sprint

The sprint story is easy to tell.

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.

The sprint — 11 days, 197,831 lines of Java, PCB design library built from nothing to manufacturing-ready

That was January 27. Six weeks ago.

Nobody asked what happened after. Which is the point.

Same Engine, Different Transmission

Most AI productivity discussion asks the wrong question. "How much faster?" assumes the difference is speed. It is not. Two developers using the same model, the same IDE integration, the same subscription tier -- one of them starts every session cold and the other does not. The gap between them is not the engine. It is the transmission. But the transmission alone is not the full story either. There is a third variable: how the driver was trained.

Same Engine, Different Transmission: The 4-Gear AI Memory Architecture -- standard 1-gear setup vs four gears, honest productivity numbers

kcp-commands: Save 33% of Claude Code's Context Window

Every token Claude Code's context window can hold is an opportunity — a tool call result that stays in scope, a file that does not need to be re-read, a decision that does not need to be recapped. Wasting those tokens on noise is a quiet tax on every session.

Today we are releasing kcp-commands: a Claude Code hook that recovers 33.7% of a 200K context window in a typical agentic coding session by intercepting Bash tool calls at two critical points.

The full number across our benchmark session: 67,352 tokens saved.

Update (March 3, 2026 — v0.9.0): kcp-commands now writes a JSON event to ~/.kcp/events.jsonl on every Phase A Bash hook call. kcp-memory v0.4.0 ingests that stream to provide tool-level episodic memory — kcp-memory events search "kubectl apply" returns every time Claude ran that command across all your projects. Phase A gives Claude vocabulary. Phase B cleans output. Phase C remembers what ran.