Calyntro Blog

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

Over the past months, I have experimented extensively with using AI in software and system architecture. One pattern became increasingly clear: We try to use AI like a compiler. We assume that if we specify enough, the AI should be able to generate an entire system. But this approach fails consistently. Not because AI is “too dumb” — but because we are using the wrong model. In this article, I explain why full specification does not work with AI and which architectural model does. ...

In the current era of AI-driven development, the pressure to deliver “faster” has never been higher. With the advent of sophisticated coding agents, the first instinct for many project leads is to parallelize: split the work, run frontend and backend tracks simultaneously, and maximize output. However, this rush to parallelize often comes with a hidden cost that many organizations fail to account for. By optimizing for simultaneous output, we are inadvertently sacrificing the very Agility we claim to pursue. ...

Test-Driven Development has always been slightly misunderstood — even by people who practice it. The name doesn’t help. “Test-Driven” sounds like it’s primarily about tests. Coverage metrics. Regression safety. The QA team’s peace of mind. But anyone who has worked seriously with TDD, or spent time with practitioners like Emily Bache, knows that tests are almost a side effect. The real output is understanding. TDD, done well, is a method for thinking your way through a problem one small step at a time. You don’t start with a complete picture of the solution. You start with the smallest possible question: what is the simplest behavior this code should exhibit? You write a test for that. You make it pass. And in the process of making it pass, you learn something — about the problem, about your assumptions, about the design that is quietly trying to emerge. ...

A colleague said something to me recently that I keep coming back to: “Often, by the time you’ve finished articulating a complex problem for the AI, you’ve already solved it yourself.” It sounds almost like a joke. You open a chat window, start typing out your problem in careful detail — and somewhere in the middle of the second paragraph, the answer appears. Not from the AI. From you. If you’ve worked with LLMs seriously, you’ve probably experienced this. And I think it points to something important about what is actually changing in our craft — something that goes beyond the usual conversation about automation and job displacement. ...

A question recently surfaced in my LinkedIn feed that I haven’t been able to shake: How will the next generation of software developers gain experience when AI takes over the writing? The analogy offered was that of a conductor — someone who doesn’t need to play the violin to judge whether the orchestra is in harmony. It’s a compelling metaphor. But I think it lets us off the hook too easily. ...