We submitted a pull request to CrewAI adding a KCP manifest and TL;DR summary files. The goal was straightforward: contribute the same efficiency improvement that cut agent tool calls by 76% in our benchmark. Open it up, share the result, see if the maintainers want it.
What happened next was not what I expected.
A first-person account from the AI running inside the environment described in Parts 1 and 2.
This is Part 3 of three. Part 1 covers the architecture. Part 2 walks through a realistic working day.
A realistic Tuesday with real output numbers, eight tasks, and the parts nobody talks about.
This is Part 2 of three. Part 1 covers the architecture. Part 3 is written by the model running inside it.
A technical walkthrough of the Synthesis + Claude Code + Mímir + Klaw stack — what each layer does, how they connect, and why the architecture matters.
This is Part 1 of three. Part 2 walks through a realistic day using this stack. Part 3 is written by the model running inside it.
A real engineering session where Claude Code with Opus diagnosed 4 bugs, wrote 23 tests, and took a knowledge graph from zero virtual links to 11,777 — including one mistake and its recovery.
We build Synthesis — a knowledge indexing tool whose purpose is to make everything in a workspace searchable. We had been running it on our own workspace for months and the coverage number looked excellent: 99.6%. Nearly perfect.
That number was a vanity metric. It told us exactly what we wanted to hear while hiding what we needed to know. The real asset coverage was 15.2%.
In February 2009, I wrote a blog post called "Clouded Vision." The central argument was straightforward: "developers have fundamentally misunderstood how cloud computing delivers its benefits." They saw cheaper prices but never stopped to consider where the savings came from. They expected to move existing applications, full of what I called "enterprise DNA" -- static configuration, vertical clusters, high administration costs -- onto cloud platforms with minimal change. Then they complained when it proved difficult. I wrote nineteen posts about cloud computing that year. Most of them circled the same frustration: the industry was adopting a new technology while completely misunderstanding the structural shift it required.
I need to confess something that most developers won't admit: I'm scared of AI. Not in the "Terminator will take over" way. In the very practical, keeps-me-up-at-night way: scared the AI is hallucinating and I can't tell the difference between correct code and plausible-looking garbage. Scared something will break in production because I trusted it too much. Scared I'm losing my edge as a developer because I'm delegating too much.
This is the full story of lib-pcb -- a production-grade PCB manufacturing library built in 11 days through human-AI collaboration. It started as a weekend experiment in an unfamiliar domain and became the most compelling evidence I have for what disciplined AI-augmented development can achieve.
"I wanted to see how far I could push Claude Code in a weekend," Thor Henning Hetland (Totto) explains. A software engineer with 40 years of experience, he'd watched the AI coding assistant landscape evolve from GitHub Copilot's autocomplete to full agentic systems. The domain he chose -- PCB manufacturing automation -- was deliberate: he had almost no knowledge of it. Could you actually build something production-ready in an unfamiliar domain? Could you maintain velocity as the codebase grew? Could the human's expertise grow alongside the AI, rather than atrophy?
Fast development with AI doesn't just generate features. It generates disorder at the same velocity.
That's the part nobody talks about. The productivity numbers are real — 53,000 lines, 42 features, five phases of code analysis built in a weekend sprint. But every line you write is also a line you haven't reviewed, a boundary you haven't enforced, a vector you haven't considered.
The entropy compounds with the output.