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.
A few weeks ago I asked a room of developers two questions.
First: "How do you use AI in your work?"
Great answers. Specific. Confident. Everyone had a workflow.
Second: "What does your team's AI workflow look like — the shared one?"
Silence.
Two months. Two builds. Two kinds of velocity.
January: lib-pcb. 197,831 lines in 11 days. Brute force. AI executing at scale. Fast.
February: Synthesis. 84,692 lines in 7 days. The codebase fed itself context. Found its own errors. Rewrote its own understanding mid-build.
We didn't design the self-learning loop. A benchmark on day 6 revealed it.
Speed without self-correction is just faster chaos.
In February 2009, I wrote a post called "Clouded Vision" where I argued that "developers have fundamentally misunderstood how cloud computing delivers its benefits. They see the cheap prices but don't stop to consider where the cost saving comes from." The post described a specific architectural mistake: teams were taking their existing applications, full of what I called "enterprise DNA," and deploying them to cloud platforms with minimal change. Then they complained when it proved difficult and expensive.
The last post was about hallucinations, production bugs, and shipping bad code. Three fears that built three systems. This post is about the next three: money, control, and silence.
There is a narrative forming in the industry that goes something like this: AI will replace junior developers, senior developers will become more valuable, and if you have enough experience you have nothing to worry about. I think this misreads what is actually happening. The shift is real, but it is not the one most people describe.
When we finished lib-pcb, the question we got most was: "How?"
Not "what model did you use?" Not "what IDE?" Those questions miss the point entirely. The model is the least interesting variable. What made 197,831 lines of Java, 7,461 tests, and 474 commits in 11 days possible was a methodology. Specifically: six practices that we have now codified under the name Skill-Driven Development.
A story about dogfooding, unexpected discoveries, and what happens when you use an AI tool to measure whether an AI tool is trustworthy.
By Thor Henning Hetland and Claude Sonnet 4.6 — written together, February 20, 2026
This article has two voices. Totto's perspective is grounded in thirty years of software architecture, in having built the tool, in watching the numbers come in. The AI's perspective comes from a strange position: being simultaneously the researcher conducting the benchmark, the instrument being measured, and the subject whose reliability is in question.
We agreed to write this honestly. That means Totto admits when the results surprised him, and the AI admits what it's like to discover that the context it relies on might be wrong.
In January 2026, I built lib-pcb in eleven days.
197,831 lines of Java. 7,461 tests. Eight format parsers, twenty-eight validators, seventeen auto-fix types. The kind of codebase that should take ten to eighteen months by conventional timelines.
The experience was disorienting in a specific way: the AI could generate code faster than I could understand what it had generated. By day four, I had a problem I hadn't anticipated. Not a quality problem — the code was good. A navigation problem. I couldn't find things anymore.
Synthesis was my answer to that. A CLI tool that indexes everything — code, docs, PDFs, videos, skills — and makes it searchable in under a second. I built it to solve the lib-pcb output explosion. 691 files per day, and I needed to find any of them in under thirty seconds.
The question was: did it actually help? Not anecdotally — I knew it helped me. But how much? And help with what, exactly?
So I built a benchmark.