April 25, 2026
Green checks, red flags
Commenting and Approving Pull Requests
Approve now, nitpick later: trust-fueled speed or messy shortcut
TLDR: The author argues for approving code changes while leaving minor comments, relying on trust and fast tests to keep things moving. Commenters split between speed-loving “approve-with-notes” fans and skeptics worried about unread feedback, lost context, and people abusing the green check—making this a culture-and-tools test for every team.
Jake Worth just dropped a spicy take: leave your suggestions, questions, and tiny fixes, then hit approve. Simple: move fast, trust teammates to follow up, and let continuous integration (automatic tests) and linters catch the boring stuff. The crowd? Loud. Fans like quxbar cheer it as anti-gatekeeping, saying reviews become about ideas, not power moves. singron backs the speed, arguing the true cost is waiting: a two-hour review beats a two-day stall every time. eterm points out Azure DevOps even has an “Approve with suggestions” button, then side-eyes aftermath: do people read comments after the green check?
Skeptics clap back. embedding-shape says parking drive-by wisdom in a pull request is like leaving Post-its on a moving train—put it in the code. Groxx agrees it works “more than half” the time, but warns “some routinely abuse it” to sneak big changes that deserve a real review. And repo settings add drama: approvals that reset on new commits and auto-merge bots can turn a good-faith approve into a YOLO merge. Jake leans on Conventional Comments labels like nitpick and suggestion to signal intent, plus emojis for spice. The vibe: with high trust and clear tooling, approve-and-comment is slick; without it, it’s chaos.
Key Points
- •Default practice: leave non‑blocking comments and approve the pull request simultaneously.
- •Rationale: comments demonstrate thought and can surface misunderstandings; approval relies on team trust and fast CI to implement suggestions quickly.
- •Effectiveness depends on repository settings (e.g., approvals resetting on new commits, auto‑merge rules) and should be considered before using this approach.
- •Tooling (linters, auto‑formatters, type checkers, security scanners) reduces trivial nitpicks; feedback is labeled using Conventional Comments.
- •Blocking issues are handled case‑by‑case; frequent blocking feedback suggests upstream misalignment. Aim for high alignment so most feedback is non‑blocking.