LGTM: The Four Letters Slowly Destroying Your Production Environment

It arrives like clockwork. You open your pull request, and within four minutes — before any human being could have possibly read 847 lines of changed code — there it is. A single green checkmark. One comment. Four letters.

LGTM.

Looks Good To Me. The most optimistic statement in software engineering. A declaration of confidence so absolute, so unwavering, that it could only have been written by someone who did not read a single line.

Welcome to the theater of code review, where the performance matters more than the play.

The Anatomy of a Rubber Stamp

Let's be honest about what LGTM usually means in the wild. It does not mean I reviewed this code carefully and found no issues. It means one of approximately six things:

1. I opened the diff, saw it was long, and decided my time was better spent elsewhere.
2. We have a reciprocal review agreement and I approved yours so you'll approve mine.
3. The author is a senior engineer and questioning them feels politically inadvisable.
4. I found one small thing, mentioned it, they replied 'good point, fixed,' and I approved without checking the fix.
5. It's Friday at 4:45 PM.
6. All of the above, simultaneously.

None of these scenarios involve actually reading the code. Yet somehow, the green checkmark lands with the same institutional weight as if it had been reviewed by a panel of engineers holding clipboards and frowning professionally.

This is the magic of LGTM. It grants the appearance of due diligence while requiring approximately the effort of blinking.

The Social Contract Nobody Signed But Everyone Honors

Code review reciprocity is one of the most powerful unwritten rules in software development, and almost nobody talks about it openly. The dynamic works roughly like this: you review my code quickly and painlessly, I review yours quickly and painlessly, and together we maintain a comfortable fiction in which our team has a rigorous review process.

Disrupt this equilibrium and you become that person. The one who left fourteen comments on a two-line change. The one who asked why a particular abstraction was chosen when the PR description clearly said minor refactor. The one whose review queue mysteriously fills with the most tedious, context-free tickets imaginable.

Asking hard questions in a code review carries real social risk, and most developers — being rational humans who have to work with these people for years — quietly do the math and decide the risk isn't worth it. So they write LGTM and move on, and the codebase absorbs another small decision that nobody actually examined.

Multiply this by a thousand PRs and you've got yourself an architecture.

The Psychology of Approval

There's a deeper mechanism at work here, and it's not laziness — or at least, not only laziness. It's conflict aversion wearing an engineering hat.

Leaving substantive feedback means potentially being wrong. It means the author might push back. It means a comment thread that could spiral into a philosophical debate about naming conventions that consumes three days and resolves nothing. Approving cleanly sidesteps all of that. You become the easy reviewer, the low-friction reviewer, the reviewer people want to tag.

Meanwhile, the person who actually reads the code, spots the race condition, and asks about it in a comment is now managing a conversation that neither party particularly wanted to have. They're burning time, burning social capital, and their reward is the vague satisfaction of having done the job correctly — which, in the absence of any organizational reinforcement, feels a lot like nothing.

Systems get the behavior they incentivize. If your team celebrates shipping velocity and treats review thoroughness as a personal quirk rather than a professional expectation, you will get LGTM. Every time. Without fail.

The Incident That Could Have Been Caught

Here's where the comedy stops being funny. Every engineering team has a post-mortem in its history where someone, during the timeline reconstruction, quietly notes that the offending code did go through review. It was approved. It had a green checkmark.

Nobody says it out loud in the meeting, but everyone does the math. The review was a formality. The bug was reviewable — it was right there in the diff, doing exactly what it would later do in production, just in a context where it was slightly easier to ignore.

The LGTM culture doesn't cause catastrophic failures directly. It creates the conditions in which catastrophic failures can arrive unannounced, having cleared every checkpoint without anyone actually checking.

That's the quiet organizational rot the summary promised. It's not dramatic. It's a slow drift toward a codebase where nobody is really watching, and everyone assumes someone else is.

A Survival Guide for Teams Who Want Reviews That Mean Something

If you've read this far and recognized your team — or yourself — here's a non-judgmental set of suggestions for reversing course without blowing up your working relationships.

Make the scope explicit. A PR titled 'minor fix' and a PR titled 'rearchitecting the payment flow' should not receive the same review. Agree as a team on what level of scrutiny different change types warrant, and write it down somewhere other than a Confluence page nobody can find.

Normalize 'I don't have context here.' One of the most honest comments a reviewer can leave is I'm not familiar enough with this area to review it meaningfully — can someone else take a look? This is not a failure. This is the review process working.

Separate approval from completion. Some teams have started distinguishing between 'I approve this to merge' and 'I reviewed this thoroughly.' They're not always the same thing, and pretending they are is where the trouble starts.

Make it safe to ask dumb questions. If junior engineers see that asking a clarifying question in a review earns them a passive-aggressive response, they will stop asking clarifying questions. This is how knowledge gaps become load-bearing.

Acknowledge good catches publicly. When someone's review actually catches something before it ships, say so. Loudly. In whatever channel your team uses for announcements. Create a culture where thorough review is a contribution, not a nuisance.

The code review that consists of a single LGTM isn't always wrong. Sometimes the change really is trivially correct and the reviewer really did spot-check it appropriately. But when LGTM is the default — when it's the path of least resistance that everyone takes without thinking — you've stopped doing code review. You've started doing code acknowledgment.

And acknowledgment, unfortunately, does not catch bugs.

It just makes sure everyone felt seen before the incident ticket opened.