What does LGTM mean? Code review shorthand, decoded
Othman Shareef · October 12, 2026 · 4 min read · Code Review Glossary
LGTM means looks good to me. In code review it is shorthand for approval: the reviewer has read the change, found nothing blocking, and is happy for it to merge.
Where does LGTM come from?
The acronym predates modern tooling; it grew up on open source mailing lists and early review threads as a compact way to say the patch passes. What made it a term of art is that big engineering cultures formalized it. At Google, the internal review tool Critique makes LGTM a literal, named approval state that reviewers grant, as described in Modern Code Review: A Case Study at Google. From there the word leaked into the general vocabulary: GitHub reviewers write it in approval comments, bots print it, and stickers exist. The mechanics differ by platform, but the meaning has stayed stable for decades: a named human is signing off.
What does LGTM mean in practice?
An approval asserts more than most people think. When you approve, you are telling your team three things: the change does what its description claims, you looked hard enough to catch the problems you are qualified to catch, and you are comfortable with this code running in production with your name in the review log. That is why the flip side matters too: knowing when to request changes instead is what keeps the approval meaningful. A reviewer who never blocks anything is not agreeable; they are absent. LGTM only carries information if it was possible for you to say something else.
When is a bare LGTM fine, and when is it rubber-stamping?
A bare LGTM is perfectly good feedback when the change is small, the behavior is easy to verify, and the author is trusted on this part of the codebase. A dependency bump with green CI, a typo fix, a config value change you double-checked: adding paragraphs of commentary there is ceremony for its own sake. The trouble starts when LGTM becomes the default response to everything, including changes nobody could have read in the time between request and approval. We wrote a whole piece on LGTM culture and code review theater: the short version is that the acronym is not the problem, the missing reading is. A useful self-test: if you cannot name one specific thing you checked, you did not review it, you witnessed it.
Related shorthand: PTAL, nit, WIP
LGTM lives in a small family of review abbreviations worth knowing:
- PTAL: please take a look. A request for review, or for re-review after fixes have been pushed.
- nit: short for nitpick. Prefixes a minor, non-blocking comment; we cover the etiquette in our piece on review nitpicks.
- WIP: work in progress. Marks a pull request that is not ready for formal review; on GitHub this is now usually a draft PR instead.
- ACK / NACK: acknowledge or reject, an older sibling of LGTM from mailing list review culture.
All of this shorthand exists to keep review fast without making it empty. LGTM is the smallest possible review comment, and that is exactly why it deserves the discipline: it should compress a real judgment, not replace one. If your team wants the compression without the emptiness, make the convention explicit: a bare LGTM is reserved for trivial changes, everything else gets one line about what was checked, and an LGTM you feel pressured into giving is really a signal to slow down. Shorthand works best when everyone knows exactly how much weight it carries.