{
  "id": 8341789,
  "title": "Stop Rubber-Stamping \"LGTM\": Why Pull Requests Are Operational Contracts (Especially with AI Code)",
  "url": "https://urgent.news/2026/09/19/stop-rubber-stamping-lgtm-why-pull-requests-are-operational-contracts",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-19T00:20:52.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/tarikmostafa/stop-rubber-stamping-lgtm-why-pull-requests-are-operational-contracts-especially-with-ai-code-cdh"
  },
  "original_language": "en",
  "account": "Many engineers find themselves routinely approving pull requests with minimal scrutiny, especially when AI assistants quickly produce syntactically correct code. The temptation to simply click \"LGTM\" (Looks Good To Me) and merge is strong, particularly when the code appears clean and passes unit tests. However, this mentality can lead to serious problems, as a single unhandled edge case can cause a significant production outage.\n\nWhen a critical issue arises, the postmortem investigation becomes focused solely on the individual who approved the code for deployment. Senior leadership and Site Reliability Engineers (SREs) will ask, \"Who reviewed and approved this to go live?\" Every approval is a legally binding signature, as it represents a sworn claim: \"I have thoroughly examined this architecture, understand its potential failure modes, and am prepared to defend this code at any hour, including 3:00 AM.\"\n\nAI-powered code generation has made the creation of code nearly instantaneous and virtually cost-free. Therefore, the scarcity of raw code output has vanished. Consequently, code review and architectural verification have become the most critical and accountable actions in the software development process. If we continue to treat pull requests as mere rubber stamps, we risk turning our code repositories into unmanageable messes. On the other hand, if we treat them as contracts, we can ensure system integrity and foster genuine engineering trust.\n\nTo avoid falling into this trap, I recommend a simple pre-approval test for each pull request, particularly those generated by AI tools: Before clicking \"Approve,\" ask yourself aloud, \"If this code were to break production tomorrow, what would be my documented rationale for allowing it to ship?\" If you cannot provide a clear and defensible answer, you have not yet completed your review process.\n\nI have compiled a series of visual, one-page blueprints outlining blast radius, distributed boundaries, and human engineering ownership to help teams navigate this challenge. These blueprints are featured in my new book, *The Unshakeable Developer: Why AI Won't Replace True Software Engineers*. I encourage you to share your team's experiences with code reviews and any strategies you have employed to combat review fatigue in the age of AI-generated code.",
  "summary": "Be honest: when was the last time you opened a 400-line PR, scrolled through a sea of clean-looking green diffs, thought \"looks fine to me\" , typed LGTM , and hit merge? I've been guilty of it. Most of us have. Especially now, with AI coding assistants churning out syntactically plausible code in seconds, the temptation to rubber-stamp pull requests has skyrocketed. The formatting is neat, the…",
  "key_points": [
    "Many engineers routinely approve pull requests with minimal scrutiny.",
    "Clicking LGTM can lead to serious production outages.",
    "Pre-approval test recommended before approving pull requests."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}