Calyntro Blog

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

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

Most tools that claim to show code ownership answer one question: who last touched this file? It is a reasonable question. But it is the wrong one. A file can have five contributors on record — and still be fully owned by someone who left the company fourteen months ago. The commit history looks healthy. The risk is invisible. This is the gap Calyntro is built to close. The Difference: Static vs. Temporal Ownership Standard ownership tools take a snapshot. They look at the current state of the repository and assign files to whoever touched them most recently, or most often, within a fixed window. ...

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

There is a conversation happening right now in engineering circles about code reviews. The argument goes roughly like this: AI is generating code faster than humans can review it, PR volume is exploding, and we need smarter tooling to keep up. That argument is correct. And it is solving the wrong problem. The deeper issue is not that reviews don’t scale. It is that we are still treating the review as the primary quality gate — a last line of defence before code enters the codebase. In the age of AI-assisted development, that assumption needs to be challenged at its root. ...

Over the past months, a question has been making the rounds in engineering circles: Is anyone doing “triplet programming” — two humans and an AI agent? We are. Here is why. The Setup When we introduced GitHub Copilot as an agentic coding assistant, the default assumption was that each developer would work one-on-one with the agent. That is not what we ended up doing. Instead, we run sessions with two developers and one agent. ...

One developer. 161 files. The highest churn rate in the entire repository. This is not a startup with three engineers and no processes. This is MongoDB — one of the most widely used, most professionally maintained open-source codebases in the world. Thousands of contributors. Years of accumulated engineering discipline. And still: a single person holds exclusive knowledge of 161 files in a module that changes more than any other. Why MongoDB? We chose MongoDB deliberately. Not because it is a cautionary tale, but because it is the opposite: a project that does almost everything right. Structured contribution guidelines, active code review, long-term maintainers. If knowledge risk shows up here, it shows up everywhere. ...

Three months’ notice sounds like enough time. It isn’t. Not for the files nobody else has ever touched. Not for the modules where one person made every decision for the last two years. You discover those files during the handover. Or after it. We call it a knowledge transfer problem. It isn’t one. It’s a visibility problem. What bus factor actually means The term comes from a thought experiment: how many people on your team would need to be hit by a bus before the project is in serious trouble? ...