What “LGTM” means in code review
“LGTM” stands for “Looks Good to Me,” indicating that a reviewer approves a changelist. At companies like Google, an LGTM signifies that the reviewer spent adequate time verifying the code meets team standards. This approval relies on two elements: adequate codebase context and a coherent, reviewable change structure. Google’s engineering practices define the term and tell reviewers to read every requested line and check the surrounding context.
In agent-assisted development, AI agents generate code rapidly while leaving critical context in external prompts or traces. Reviewers must deduce both the purpose and mechanism of a change, often relying on flat diff interfaces that only highlight modified lines. While LGTM retains its traditional definition, modern workflows place immense pressure on reviewer comprehension.
Why large diff presentation hampers evaluation
Review quality can decline when changes exceed reasonable limits. Drawing on a case study of 2,500 reviews at Cisco, SmartBear recommends reviewing no more than 200 to 400 lines at a time. High file counts, flat file lists, and arbitrary presentation order introduce extraneous cognitive load, forcing reviewers to spend energy piecing together context instead of assessing safety.
Research demonstrates that file sequence shapes reviewer focus:
- Reordering files by predicted review activity increased code comments by 23% and improved hotspot identification compared with standard alphanumeric lists.
- Files displayed earlier in a diff received more reviewer comments.
- In a controlled experiment from the same study, placing a defective file at the end of a long list produced 64% lower odds of detecting one of two tested defect types.
When large changes remain necessary, such as multi-service schema updates, review interfaces must highlight relationships and suggest logical reading paths.
When LGTM signals process breakdown
An isolated quick approval can represent efficiency. Patterns of instant approvals across large or multilayered pull requests reveal a systematic issue termed interface-induced approval: approving after seeing reassuring surfaces without building a full mental model of the change.
Key indicators that approval depth has degraded include:
- Pull requests cross service, data, or authorization boundaries with zero reviewer discussion about systemic impact.
- Reviewers approve complex code while explicitly describing the diff as difficult to parse.
- Critical files consistently sit at the bottom of default review sequences.
- Metrics track review speed while omitting measures of review depth.
- Team members spend subsequent sprints reconstructing past approval rationale.
Designing interfaces for comprehension
Improving code review requires interfaces that reduce initial orientation effort. Effective tools organize edits into logical cohorts, map out dependency-aware reading sequences, isolate behavioral modifications from routine updates, and embed context directly alongside code changes. Structured presentation provides a clear path through the evidence, allowing reviewers to focus on validating correctness and rendering confident approvals.
