Skip to content

AI-Augmented Development

Building Together: An 11-Day Human-AI Collaboration Story

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.

It Started as a Weekend Experiment

"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?

Software Entropy at Speed

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.

Claude Code + Synthesis: Five Superpowers for Java Developers

A practical guide to giving your AI coding assistant an institutional memory

You've tried Claude Code. Maybe you love it. Maybe you've noticed that on your 300K-line, 20-module Maven project it spends the first five minutes figuring out where anything is.

That's not a model limitation. That's a context problem. And it's solvable.

The Seven-Day Evolution

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.

The Architecture Mistake Cloud Taught Us (That We're Making With AI)

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.

What "Senior Developer" Means When AI Can Code

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.

Six Pillars: What We Learned Building 200,000 Lines in 11 Days

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.

The Mirror Test: How Synthesis Benchmarked Itself Into Something Better

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

A Note on How This Was Written

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.

Part I: Why We Needed a Tool to Test the Tool

Totto

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.