It Was Never Protected. It Was Just Unlucky Enough Nobody Had Tried Yet.

Years ago, at a company I worked with, the engineering team decided to use open source software wherever it reasonably could. That is a sound default. Inside the product we were building, we planned to use CKEditor, an open source rich text editor, somewhere it would be absolutely critical: the tool an army of paid writers and consultants depended on every day to do the work our customers were paying for.

A support contract for CKEditor ran about ten thousand dollars a year at the time. Someone wanted to skip it: open source is free, and ten thousand dollars is real money. What we were actually weighing was a Boundary Bearing, a risk sitting entirely outside our control, in whatever an open source community could or could not do for us on any given day. I made the case that if the editor broke and we had nobody to call, an army of paid users would stop working on a system our own customers were paying for, and I won. What stayed with me was not winning. It was that the case had to be made at all: that risking a mission-critical system to save ten thousand dollars was ever a live question in a room, requiring an argument and a vote rather than being settled before anyone raised it.

That was years before AI made code cheap. I am watching the exact same mentality show up again right now, just faster and with better PR. A manager vibe-codes an application over a weekend and posts about it. A team replaces a paid SaaS vendor with something built in-house over a few sprints. It gets celebrated as exactly the kind of hands-on leadership AI finally makes possible again: proof the manager stayed sharp, saved the company money, moved faster than a committee ever could.

Here is what nobody is asking in the celebration. Who reviews that manager's pull request? Self-review is not review. A direct report reviewing their own manager's code is structurally unlikely to push back hard. If the manager is prompting an AI to generate the code rather than typing it themselves, the gap doubles: the prompt, which is where the actual judgment lives, goes unreviewed too. The same unchecked judgment shows up twice, in the request and in the output, both approved by the person who wrote them both.

This would matter less if writing code were what made a manager valuable. It has not been, for a long time, well before AI made code itself cheap. What makes a manager valuable is judgment: knowing whether the weekend project solves the right problem, knowing what happens when a system that quietly replaced a paid vendor goes down, knowing how to develop and align people who are themselves valued for their judgment. None of that requires personally shipping code, and shipping code does not build or protect any of it.

The cost shows up later, compounded. A team replaces a SaaS billing vendor to save money and move fast, and it works right up until the self-built system breaks and nobody can bill customers, and the people who should be building the actual differentiator are instead firefighting the thing they built to save time, losing exactly the race they thought they were winning.

None of this means staying hands-off is the fix, case by case, argument by argument. I won the case for that support contract once. Winning was not the win. A system that has to be argued for and protected every time a cost-saving idea shows up has never actually been classified as critical. It is being re-litigated from scratch, under the pressure of whatever idea is exciting this month. What actually holds is classifying what is mission-critical before the next exciting idea arrives, so the question of whether to risk it never gets a hearing at all.

Pick the one system that would stop paid work cold if it failed for a day. Now ask honestly: could you, personally, replace a piece of it this weekend with something you vibe-coded, and ship it, with nobody stopping you? If the honest answer is nobody would stop you, the system was never actually protected. It was just unlucky enough that nobody had tried yet.

The Edge Case walks through how to name a Boundary Bearing before it becomes a live argument, not just win the argument once it does: http://TheEdgeCaseBook.com