Calyntro Blog

A pattern keeps showing up in teams that have adopted AI-assisted development. The reasoning sounds compelling at first: “The AI writes the code. Why do I still need to spend time on tests? Surely the AI can handle that too.” This is a misunderstanding of what tests are for. Software failure modes are properties of the system — not of the author. Whether a function was written by a junior developer, a principal engineer, or a language model, the same class of bugs is possible: boundary conditions missed, edge cases unhandled, implicit assumptions unexamined. The mechanism of authorship is irrelevant. The failure modes are not. ...

Big Spec Up Front failed. Not because the people who practiced it were careless — many of them were meticulous. It failed because of something structural: the act of implementation always reveals things that specification missed. Users cannot fully articulate what they want before they see it. Complexity defeats even complete knowledge. External requirements shift before the system ships. Agile was the response. Short loops. Working software over comprehensive documentation. Iterate toward understanding instead of specifying toward it. ...

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. ...

There’s a recurring debate in agile circles about why teams miss deadlines. The usual suspects: bad estimates, too many columns in Jira, missing WIP limits, the wrong metrics. The fixes that follow are predictable. Reconfigure the board. Add a Cycle Time chart. Apply Little’s Law. Run a retrospective about why the sprint went sideways — again. These interventions aren’t wrong. But they’re downstream of the actual problem. The Board Shows What Refinement Produced A Scrum board is a mirror. It reflects the quality of the decisions made before the sprint started. If those decisions were vague, the board will look chaotic — not because of how the columns are arranged, but because the work itself was never properly understood. ...

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. ...

Ein Team plant eine größere Umstrukturierung. Drei Module sollen einem neuen Team übergeben werden, zwei weitere zusammengeführt. Der Engineering Manager ist zuversichtlich — die Architektur ist klar dokumentiert, die Übergabe sollte in zwei Sprints erledigt sein. Vier Monate später ist das Projekt noch nicht abgeschlossen. Was niemand vorher gesehen hatte: Eines der übergebenen Module hatte in den letzten 18 Monaten exklusiv einen einzigen Entwickler als Ansprechpartner — der inzwischen das Unternehmen verlassen hatte. Ein anderes Modulpaar änderte sich faktisch immer gemeinsam, obwohl im Architekturdiagramm keine Verbindung eingezeichnet war. Und ein dritter Bereich zeigte seit Monaten stetig steigende Komplexität — unbemerkt, weil niemand den Trend über Sprints hinweg verfolgt hatte. ...

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. ...