The Code Checked Whether a Row Existed, Then Inserted One Just So the Delete Would Not Fail.

Early in my career, I inherited a codebase from a developer who was exiting the company. He was a genuinely smart guy, well liked, with a wall of certifications behind his name. A few days into reading his code, I found a pattern I had never seen before and have rarely seen since: before a delete statement, he checked whether the row existed. If it did not, he inserted it first, so the delete that followed would not fail.

A delete statement does not fail against a row that is not there. It affects zero rows and moves on. There was nothing to guard against. He had written the extra code, tested it, and shipped it, to prevent a failure that could not happen, and it was not a one-off. It turned out to be a precursor. The same pattern showed up again and again through the codebase I was taking over.

What stayed with me was not that he had made a mistake. It was disbelief, because he was genuinely capable. He had studied for and passed exams most developers never bothered to attempt. The only explanation that ever made sense to me is that he was overthinking, defending against failures he had never learned to tell apart from the ones that were actually possible. Every certification he held had tested whether he knew the material. None of them had ever tested whether he knew when a risk was real.

The comfortable version of hiring runs on the idea that a credential is a reliable proxy: if someone invested the time to get certified, that investment is evidence of real competence, and paying for the signal is simply rational pricing under uncertainty. Most technical leaders who have ever hired against a resume full of credentials have leaned on that logic at some point, because testing real judgment in an interview is hard, and a certification is already sitting there, scored.

A certification measures whether you know the material: facts, syntax, and patterns that can be studied and tested on a fixed date. It cannot measure whether you know when the material does not apply, because that judgment only shows up in situations the test was never built to anticipate. He had not failed to learn anything a certification exam would have checked. He had never developed the separate skill of knowing which risks were real, so he defended against all of them equally, and the result was code that looked careful and was actually less trustworthy, because every extra check hid failure surface of its own.

This is the same gap a 56 percent pay premium for "AI-fluent" CTOs is pricing right now, if the figure holds up to scrutiny at all. An AI-fluency credential tests whether someone can operate the tool and follow the prompting pattern. It does not test whether they know when to override what the tool produced, or when using it at all is the wrong move. That is a certification measuring instruction-following and calling it judgment, the same substitution my developer's transcript was making decades earlier, just with different material behind it.

The leaders who get this right are not the ones who stopped trusting certifications entirely. They are the ones who stopped treating a certification as the last question instead of the first one. What actually needs testing after that is what I call Bearing Capacity: what a specific person can carry, proven against a real situation rather than inferred from a title or a transcript. His Bearing Capacity was never tested by any exam he passed. Neither is an AI-fluency badge holder's, by the badge alone. And if you are the one holding that badge yourself, the same audit runs on you: has it become permission to stop building the judgment the badge itself never checked?

Pull up the last hire, or your own last review, marketed as AI-fluent. Ask for one specific decision where the person overrode what the AI produced, or chose not to use it at all, and why. No real example means the fluency you paid for is instruction-following, not judgment.

The Structural CTO walks through how to test Bearing Capacity against a real seat's Design Load instead of inferring it from a title or a transcript: http://TheStructuralCTOBook.com