“Just add a field? It’s a 20-minute job.” We’ve all said it. And three days later, you’re still knee-deep in a labyrinthine codebase, the ticket is still open, and your motivation has evaporated somewhere between burnout and quiet resentment. It’s not just about the task. It’s about the feeling that you aren’t building anymore. You’re just… patching. ...
Two Doors, One Gate Onboarding guardrails and power-user friction look like the same problem. They aren’t. June 2026 · 7 min · Karl-Heinz Reichel Table of Contents The Setup The Category Error We Already Made Once Two Layers, Not One Document Letting the Data Set the Threshold Accountability Instead of a Badge Closing Thought A few weeks ago we wrote about why we run AI coding sessions with two developers instead of one. Triplet programming works well as a transitional structure — a way to build shared fluency while the risk of agent-driven, codebase-wide changes is still high. ...
What Your Git History Reveals About Team Alignment Your org chart says one thing. Your Git history says another. They’re rarely the same. Last week I wrote about Conway’s Law as a measurement problem — the idea that every commit records not just what changed, but how your teams coordinate. That the co-change pattern across thousands of commits is a structural artifact of who talks to whom, day by day, pull request by pull request. ...
A recent piece by Andrea Laforgia on Expectation-Driven Development (EDD) made the rounds, and it deserves serious attention. The core argument is compelling: AI agents produce code faster than humans can meaningfully review it, so we need a structured protocol for specifying intent before implementation and demanding evidence of fulfillment afterward. The human developer transitions from author to editor — from writing code to evaluating it. That framing is right. And the EDD workflow — write expectations in plain text, let the agent implement, ask the agent to prove it, challenge the evidence, iterate — is a real improvement over the current default, which is roughly “trust and hope the CI is green.” ...
Most tools that measure bus factor stop at the number. One person owns this module. Here is the percentage. Good luck. That’s useful context. It’s not useful guidance. The question a CTO or engineering manager actually needs answered isn’t how concentrated is the knowledge? — it’s what do I do about it, and where do I start? The Problem With Raw Risk Metrics Knowledge concentration exists in virtually every codebase. Run any ownership analysis on a real production repository and you’ll find modules where one person did 80% of the meaningful work. You’ll find files nobody else has touched in two years. You’ll find developers who accumulated knowledge across hundreds of commits that isn’t written down anywhere. ...
Conway’s Law was stated in 1967: any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure. Fifty-eight years later, it is still being treated as a principle to design toward — not a pattern to measure in what already exists. That’s the gap we wanted to close. From Metaphor to Measurement The usual treatment of Conway’s Law goes like this: recognize that your teams' communication structure will shape your architecture, then design your teams deliberately to get the architecture you want (this is what Team Topologies calls “inverse Conway maneuver”). That’s sound advice. ...
Bus factor is one of those concepts every engineering leader nods at and almost nobody measures. The definition is simple: how many people would need to leave — or get hit by a bus — before your project is in serious trouble? A bus factor of 1 means a single person holds knowledge that no one else has. If they leave, you’re exposed. Most teams estimate this. They name names. They have informal conversations about who knows which system. And then they file it away until someone actually leaves. ...
We have spent the last year solving the during problem in AI-assisted development. How do we work alongside AI without losing architectural coherence? How do we structure teams so that the speed of AI generation does not outrun human judgment? How do we ensure that the conceptual identity of a system — the thing only humans can define — survives contact with an LLM that has never read the architecture decision records? ...
Adam Tornhill published a piece today that I found myself nodding along to almost paragraph by paragraph. His argument: Spec-Driven Development, in its strong form, is a replay of the Model-Driven Architecture dream from the 1990s — and it will fail for the same reasons. Implementation is not the execution of a known scope. It is the discovery of scope that wasn’t known yet. He’s right. And I want to pick up where he stops. ...
In my previous post, I argued that full specification fails with AI — and that component-based architecture with clear interfaces is the right model. Since then, several readers pointed me to a similar argument by Javi Lopez, who draws a sharp parallel to the CASE tools of the late 1980s: the same promise, the same illusion, a new mask. Lopez is right. And I want to go one step further — not just to say what goes wrong, but to show what it looks like when it goes wrong, and what it takes to recover. ...