The Arthive Autopsy: When 'LGTM' Becomes a Post-Mortem

In code review, 'Looks Good To Me' (LGTM) is supposed to be the final stamp of approval—a signal that the code is ready for merge. But all too often, it becomes a rubber stamp, a hollow checkbox that bypasses genuine scrutiny. When that happens, LGTM doesn't mean 'I reviewed this carefully'; it means 'I want this out of my queue.' The result? Bugs, technical debt, and eventually a post-mortem where everyone wonders how the issue slipped through.

This guide is for developers, team leads, and engineering managers who have seen LGTM lose its meaning. We'll dissect the anti-patterns that turn approvals into liabilities, explain why they happen, and offer concrete fixes. By the end, you'll have a framework to restore LGTM as a trust signal—not a trap.

Where LGTM Goes Wrong: The Field Context

The LGTM anti-pattern doesn't appear in a vacuum. It thrives in environments where review culture is weak, deadlines are tight, or the process feels like overhead. Consider a typical scenario: a developer submits a large pull request late on a Friday. The assigned reviewer, already overloaded, skims the diff, sees tests pass, and types 'LGTM' without examining the logic. The code merges, and weeks later a subtle bug surfaces in production. The post-mortem reveals that the review missed a race condition or an edge case. Everyone nods—but the same pattern repeats next sprint.

This is not an isolated case. In many teams, LGTM becomes a social signal: 'I trust you, so I approve.' Trust is valuable, but it shouldn't replace verification. The problem is compounded when review assignments are static—the same reviewers always paired with the same authors—leading to familiarity that breeds complacency. Other contributing factors include lack of clear review criteria, pressure to reduce cycle time, and tools that treat LGTM as a binary pass/fail rather than a nuanced assessment.

We see this most often in fast-moving startups where 'move fast and break things' is taken literally, but it also appears in regulated environments where reviews are mandatory but performed perfunctorily. The common thread is that the process is optimized for throughput, not depth. The result is a review culture that produces LGTM at scale—but with diminishing returns.

The Human Factor

Reviewers are not machines. Cognitive fatigue, context switching, and social pressure all affect the quality of a review. A reviewer who has just finished a complex task is less likely to dig into a 500-line diff. The LGTM anti-pattern often reflects systemic issues: too few reviewers, too many pull requests, or a culture that values speed over quality. Recognizing these pressures is the first step to fixing them.

When LGTM Masks Deeper Problems

Sometimes LGTM is a symptom of a team that has lost the habit of critical reading. New hires quickly learn that thorough reviews are discouraged because they slow down delivery. The result is a normalization of superficial approval. Over time, the team's code quality degrades, and the cost of fixing bugs after release skyrockets. The LGTM post-mortem then becomes a recurring event.

Foundations Readers Confuse

Many teams conflate LGTM with a guarantee of correctness. It is not. LGTM is a statement of opinion: the reviewer believes the code meets the project's standards and is unlikely to cause problems. But that opinion is only as good as the review that produced it. Another common confusion is equating LGTM with a thorough review. A reviewer can say LGTM after a 30-second glance, and the system treats it the same as a 30-minute deep dive. This is a design flaw in how we measure review quality.

Some teams also misunderstand the role of automated checks. They think that if CI passes and linters are green, LGTM is a formality. But automated tools catch only a fraction of issues—they miss logic errors, design flaws, and non-functional concerns like security or performance. Relying on automation to justify a shallow review is a dangerous shortcut.

Another foundation that trips up teams is the belief that LGTM is reversible. In practice, once a pull request is merged, the cost of reversal is high. Even if you revert, the damage is done: the bug is in the history, and other branches may have merged on top. The assumption that 'we can fix it later' encourages lax reviews. Finally, some teams confuse LGTM with consensus. A single LGTM from one reviewer does not mean the whole team agrees. This is especially problematic in complex changes that affect multiple components.

What LGTM Actually Means

In a healthy review culture, LGTM means: 'I have read the code, understand its purpose, verified that it meets our standards, and I see no issues that would prevent merging.' It implies a certain level of effort. When that effort is absent, LGTM becomes noise. Teams should define what a proper review entails—checklists, time expectations, and required checks—so that LGTM is backed by substance.

The Myth of the 'Quick Review'

Some advocates argue that small changes can be reviewed quickly without losing quality. While that's true for trivial fixes (a typo, a comment), most changes are not trivial. Even a one-line change can have wide implications. The habit of quick LGTM on small diffs trains reviewers to be less careful. It's better to treat every review with the same baseline of attention, adjusting depth based on risk, not diff size.

Patterns That Usually Work

What does a good LGTM look like? In teams that avoid the anti-pattern, LGTM is earned through a structured process. One effective pattern is the 'review checklist'—a shared document that lists what the reviewer should check: correctness, test coverage, style, security, performance, and documentation. The reviewer uses the checklist and comments on each item, even if only to say 'looks fine.' This raises the bar for what LGTM means.

Another working pattern is the 'two-LGTM rule' for critical changes. In this model, a pull request requires approval from two independent reviewers before merging. This reduces the chance that a single reviewer's fatigue or blind spot leads to a bad merge. It also encourages authors to write clearer descriptions because they know two people will read them.

Rotating reviewers is another proven approach. By pairing different people together, the team avoids the familiarity that breeds complacency. A fresh set of eyes is more likely to spot assumptions and hidden issues. Some teams also use 'time-boxed reviews' where the reviewer spends a fixed amount of time (say, 30 minutes) on a review, then either approves or asks for changes. This imposes a minimum effort.

Finally, post-merge reviews can complement pre-merge LGTM. In this pattern, a change is merged quickly (e.g., for urgent fixes) but then reviewed afterward. If issues are found, they are fixed in a follow-up. This balances speed with quality, but it only works if the team actually does the follow-up review—not just postpones it indefinitely.

Checklist-Driven Reviews

A concrete example: a team working on a payment system adopted a checklist that included 'verify rounding logic,' 'check for SQL injection,' and 'confirm idempotency.' Each item had to be ticked before LGTM could be given. The result was a dramatic drop in payment-related bugs. The checklist didn't add much time—maybe five minutes per review—but it forced reviewers to think about specific risks.

Reviewer Rotation in Practice

Another team rotated reviewers every two weeks. Each developer reviewed code from a different area of the system. This cross-pollination spread knowledge and caught issues that domain experts might overlook. The team reported that the quality of reviews improved, and LGTM became a more reliable signal. The cost was a slight learning curve, but it paid off in fewer production incidents.

Anti-Patterns and Why Teams Revert

The most common anti-pattern is the 'drive-by LGTM'—a review that consists of a single comment or emoji with no substantive feedback. This often happens when the reviewer is in a meeting or on a mobile device. The change is approved, but no one has truly engaged with the code. Another anti-pattern is the 'rubber stamp reviewer'—a person who always approves, regardless of the change. This is often a senior developer who is too busy or too confident in the author's skills.

Then there is the 'I'll fix it later' LGTM, where the reviewer spots a problem but approves anyway, expecting the author to fix it in a follow-up. In practice, the follow-up often never happens, or the fix introduces new issues. This pattern undermines the review as a quality gate. A related anti-pattern is the 'conditional LGTM'—approval given with a list of requested changes, but the author merges without making all of them. The review system doesn't enforce that the changes are actually made.

Why do teams revert to these anti-patterns? The main driver is time pressure. When the team is measured on throughput, reviews become a bottleneck. The path of least resistance is to approve quickly. Another reason is lack of accountability. If no one tracks review quality, there is no incentive to improve. Some teams also lack a shared definition of what a good review looks like, so everyone defaults to their own standard—often a low one.

Finally, social dynamics play a role. Junior reviewers may feel uncomfortable rejecting a senior's code. The LGTM becomes a way to avoid conflict. Over time, this erodes the entire review process, as everyone learns that LGTM is meaningless.

The Bystander Effect in Reviews

When multiple reviewers are assigned, each may assume someone else will catch issues. This is the bystander effect. Studies (though not named here) suggest that increasing the number of reviewers can actually reduce individual accountability. The result is that no one does a thorough review, and the LGTM comes from the first person who skims the diff.

How to Break the Cycle

To revert from these anti-patterns, teams need structural changes. One is to require reviewers to leave at least one comment—even if it's just 'I checked the logic and it looks correct.' This forces engagement. Another is to track review depth metrics, like time spent or number of comments, and use them in retrospectives. But beware of gaming: time spent doesn't guarantee quality. The goal is to create a culture where LGTM is earned, not given.

Maintenance, Drift, or Long-Term Costs

The long-term cost of shallow LGTM is technical debt. Every bug that slips through is a future fix, and every missed design flaw leads to rework. Over months, the codebase becomes brittle. New features take longer because developers must navigate around hidden issues. The team's velocity drops, and morale suffers as 'unexpected' bugs become routine.

There is also a knowledge cost. When reviews are superficial, knowledge doesn't spread. Junior developers don't learn from seniors, and the team becomes dependent on a few experts. If those experts leave, the knowledge gap becomes critical. A good review process is a knowledge transfer mechanism. LGTM without discussion loses that benefit.

Another hidden cost is the erosion of trust. When developers realize that LGTM is meaningless, they stop trusting the review process. They may start bypassing it or merging without waiting for approval. The process becomes a formality that everyone resents. Rebuilding trust takes time and deliberate effort.

Finally, there is the cost of post-mortems themselves. Every incident that could have been caught in review consumes engineering time in investigation, root cause analysis, and remediation. The cumulative effect is significant. Investing in better reviews upfront saves far more than it costs.

Case Study: The Slippery Slope

Consider a team that started with thorough reviews. Over time, as deadlines tightened, they began accepting quick LGTMs. Initially, the impact was small. But after six months, the defect rate doubled. The team spent 20% of their time fixing bugs. They eventually realized that the cost of thorough reviews was less than the cost of debugging. They reverted to stricter standards, but it took three months to clear the backlog of issues.

Measuring the Cost

Teams can estimate the cost of shallow reviews by tracking defect escape rate—bugs found in production that should have been caught in review. If that rate is high, it's a sign that LGTM is failing. Another metric is review time: if most reviews take less than five minutes for non-trivial changes, quality is likely low. These metrics are not perfect, but they provide a starting point for discussion.

When Not to Use This Approach

The structured, checklist-driven review approach is not suitable for every situation. For example, in a prototyping phase where code is experimental, thorough reviews may be overkill. The cost of review outweighs the benefit because the code might be thrown away. In such cases, a lightweight LGTM (or even no review) is acceptable, as long as everyone understands the context.

Similarly, for emergency fixes (hotfixes for production outages), speed is critical. A full review process can delay the fix and cause more damage. In those cases, a post-merge review is appropriate. The key is to treat emergency exceptions as exactly that—exceptions—and not let them become the norm.

Another scenario is when the change is truly trivial: a comment typo, a variable rename that doesn't affect logic. In such cases, a quick LGTM is fine. But teams should define what 'trivial' means. A one-line change that fixes a null pointer exception is not trivial—it could have been the tip of an iceberg. The rule of thumb: if you can't explain the change in one sentence, it's not trivial.

Finally, in highly regulated industries (medical, aviation), the review process is often mandated by external standards. In those environments, LGTM is not a matter of choice—it must follow a defined procedure. The anti-patterns described here still apply, but the fix may require formal audits rather than cultural changes.

Balancing Rigor and Speed

The challenge is to find the right balance for your team. A good heuristic is to vary review depth based on risk. High-risk changes (affecting security, payments, data integrity) get the full checklist treatment. Low-risk changes (internal tools, cosmetic updates) can be lighter. The important thing is that the team agrees on the classification and applies it consistently.

When the Team Is Too Small

In a two-person team, a two-LGTM rule is impossible. In that case, external reviews (from another team or a contractor) can provide a fresh perspective. Alternatively, the team can use automated tools to catch as much as possible, and then treat the single LGTM as the final gate. The key is to be aware of the limitations and compensate where possible.

Open Questions / FAQ

Q: How do I convince my team to adopt a more rigorous review process?
A: Start by presenting data from your own projects. Track bugs that escaped review and estimate the time spent fixing them. Show that the cost of review is lower. Then propose a small experiment: try a checklist for one sprint and measure the impact. If it reduces bugs without slowing down delivery, the team will be more open to change.

Q: What if the team is distributed across time zones?
A: Asynchronous reviews work well with checklists and clear expectations. Use tools that require explicit sign-off on each item. Consider setting a minimum review time (e.g., 30 minutes) to prevent rushed approvals. Overlapping working hours can be used for synchronous discussions on complex changes.

Q: How do I handle a senior developer who always gives LGTM without reading?
A: This is a culture issue. Have a private conversation to understand their perspective—maybe they feel overburdened or think the code is always good. Offer to pair them with a junior reviewer to share the load. If the behavior persists, escalate to the team lead and discuss review expectations in a retrospective.

Q: Should we require two LGTMs for all changes?
A: Not necessarily. Two LGTMs are beneficial for high-risk changes, but they can slow down trivial fixes. A tiered approach works better: one LGTM for low-risk, two for medium-risk, and three (or a design review) for high-risk. Define risk levels and communicate them to the team.

Q: Can automation replace human review?
A: No. Automation catches syntax errors, style issues, and some security vulnerabilities, but it cannot evaluate design decisions, understand business logic, or assess trade-offs. Automated checks should complement human review, not replace it. Treat them as a first pass that filters out easy issues, leaving the reviewer free to focus on deeper concerns.

Q: What do I do if a reviewer consistently gives detailed feedback but the author ignores it?
A: The review process should block merging until all comments are resolved. Use a tool that requires explicit acknowledgment of each comment. If the author still ignores feedback, it's a team norm issue that needs to be addressed in a one-on-one or team meeting. The goal is not to create friction but to ensure that reviews are taken seriously.

Q: How do I measure review quality without making it a bureaucratic burden?
A: Keep it simple. Track the number of comments per review, time spent (if available), and defect escape rate. Use these metrics in retrospectives to identify trends, not to blame individuals. The aim is to improve the process, not to punish reviewers.