Calyntro

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

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

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

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