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.
The agent answered the ROI metrics question with zero tool calls. It reported the indexing speed, the search latency, the file count, the retrieval time improvement, the test count. All correct. Every number accurate.
Then it said the metrics were validated on February 19, 2026.
The actual date was February 17.
We had 15 skill files documenting every Synthesis CLI command — syntax, options, example invocations, expected output. We wrote them carefully. We loaded them into the agent's context. We assumed the agent would use them.
Then we ran a benchmark.
The CLI condition was the worst-performing integration in the entire test. Worse than no integration at all.
Earlier today I published a post about Synthesis and why knowledge infrastructure is the layer the AI agent ecosystem is missing. Several people responded with a version of the same question: "We use llms.txt — isn't that enough?"
It depends on what you are trying to do. And I think the answer is worth a dedicated post.
I have been watching the AI agent space closely for the past year. The frameworks are impressive. The orchestration tools are clever. The models are increasingly capable. And yet, most agent deployments I see make the same quiet mistake: they treat the knowledge problem as solved.
It is not solved. It is barely addressed. And until it is, all the reasoning capability in the world will not make your agents reliably useful.
I spent part of today rebuilding this wiki. Not because it was broken. Because when I read it carefully, it was wrong.
Not dramatically wrong. Wrong in the way things get wrong when you stop paying attention. I was listed as Chairman of IASA Norway. I stepped down from that role in 2011 -- fifteen years ago. One of my companies had the wrong founding year. The framing throughout was from a different era: SOA, distributed systems, the vocabulary of a decade ago. The site looked like me. It described someone who used to be me.
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.