I Told My Team I Was Not Checking the Code. Saying It Out Loud Changed Nothing.

There was a stretch in my career when I approved code changes I had not really reviewed. Not carelessly. I read what could be read quickly, confirmed the documentation existed, the compliance items were satisfied, the ticket was linked, the format was right. Then I put my name on it and moved to the next thing, because the next thing had dollars attached to it and this one did not.

I was carrying two roles. The software development manager seat under me was open and I had not filled it, so the work of that seat arrived on my desk anyway. What I was actually doing when I approved something was reconciling BitBucket against Jira: confirming the ticket matched the branch, that the trail was clean, that the compliance story held. The code review itself lived in BitBucket, and I was not the one performing it. The senior engineers were, and I told them so directly: I said out loud that I was relying on them to check the code closely because I could not.

Telling them was not enough, and that is the part I did not understand at the time. When the work came back wrong, they had not done the thing I had explicitly asked them to do, and I could not be angry about it with a straight face. I had said the words once, in a room, and then built nothing underneath them. Nothing in the system made the careful version of their review the thing that happened during a week when everyone was short on time. Guilt would imply I could have chosen differently on some particular Tuesday; what I felt was flatter than that, because there was no version of next time where I did more and the hours were not going to appear.

Almost every technical leader who has been good at this job has approved something on those terms. Very few of them have said so to another leader.

The advice for this is always about rigor. Add a second required approver. Put an AI reviewer in the loop. Slow down and read the diff properly. Every one of those treats review as a discipline problem, and every one assumes the reviewer has the time and is simply spending it badly.

Here is what the system is actually doing. A review gate is built to answer one question: is this change correct, and should it ship. The gate is then staffed by whoever is available rather than whoever is qualified, so when a layer of the organization sits vacant, the person one level up inherits that gate on top of everything their own seat already demands. They cannot answer the correctness question in the time they have, so they answer the one they can. That is triage, and given a vacant seat and a dollar-weighted alternative, it is the correct local decision.

The failure is in what the approval emits. My approval was honest: it certified exactly what I had done, which was reconcile two systems and confirm the paperwork held. What it could not do was say so, because it sent the same signal a full correctness review would have sent: same name, same field, same green mark. That is a One-Bit Approval, a yes carrying no information about its own basis, and everyone downstream reads it and infers the thorough version because the thin version looks identical. Confidence at that gate is a ritual your system performs, not a judgment it makes.

Run that long enough and the gate develops Depth Loss: it can no longer express the difference between careful scrutiny and a fast pass. Nothing appears to degrade, which is the dangerous part. Approvals clear at the same rate, cycle time looks healthy, the dashboard stays green. The cost surfaces later as rework, incident recovery, and instability on the main branch, measured in a completely different system than the one reporting that everything is fine. Your Culture layer is meanwhile learning what review means under pressure by watching what actually happens under pressure, which is the only lesson it ever absorbs.

AI did not create this; it removed the slack that was hiding it. CloudBees surveyed two hundred thirteen enterprise technology leaders this year and found that sixty-one percent of the average enterprise codebase is now AI-generated or AI-assisted. In that same survey, ninety-two percent reported confidence in the production readiness of AI-generated code, and eighty-one percent reported a rise in production issues caused by it. Sonar put a related question to more than eleven hundred developers and found that just over half do not always check AI-assisted code before committing it. The gate was always thin, and it is now thin at a volume that will not absorb it.

The leaders who get out of this read diffs no faster than you do. They stopped trying to solve it at the gate.

The gate is asking a question the available reviewer cannot answer. Replace it with one they can: what was the recorded intent behind this change, and does the reasoning hold. What was this trying to do, what was considered and rejected, what would make it wrong. Reading intent is cheap where reading a diff is expensive, which is exactly why it survives a vacant seat, and it is the only version capable of asking whether the change should have been written at all.

So stop treating your signature as a report on the code. Treat it as a report on your own basis. Record what you actually checked, and let the thin ones look thin. Saying it in a room does not count, which I learned the expensive way. Put it in the working agreement: name what this gate covers, name what it does not, and name who holds the correctness call.

What finally resolved it for me was none of that. I hired the software development manager and made the code review call explicitly his, because the empty seat had been the problem the entire time. Fill it if you can. If you cannot fill it this quarter, write the agreement, because a spoken arrangement is the one thing you cannot hold anybody to.

Take your most recent production incident. Ask two people about the approval that let it through, separately. Ask the approver what they actually verified. Ask the author what they assumed that approval covered. If those two answers do not match, your gate was never the thing that failed.

The LeadershipOS™ Scorecard finds which layer your review gate is actually failing in, whether that is Communication, Culture, or a seat nobody has filled: https://theleadershiposbook.com/scorecard

---

I write about structural leadership for technical leaders in high-stakes operating environments. If you want to see where your system is load-bearing on you personally, the LeadershipOS™ Scorecard maps it: https://theleadershiposbook.com/scorecard