{
  "id": 15881863,
  "title": "Deleting 19k Lines of Dead Compiler Code Without Trusting the LLM",
  "url": "https://urgent.news/2026/10/21/deleting-19k-lines-of-dead-compiler-code-without-trusting-the-llm",
  "topic": "ai",
  "section": "AI",
  "published": "2026-10-21T11:49:41.000Z",
  "source": {
    "name": "Lobsters",
    "slug": "lobsters",
    "url": "https://thecloudlet.github.io/technical/refactor-with-ai/part-1-deletion/"
  },
  "original_language": "en",
  "account": "This report details how I removed approximately 19,000 lines of obsolete compiler code from a codebase, completing the task within a week. A month later, there were no revert commits made. The advice from a senior engineer at a previous job was to leave tangled code alone, as cleanup wasn't seen as work and refactors often ended in disaster. However, I disagreed, believing that software naturally drifts toward disorder without regular maintenance. At the company where I worked, I previously spent four days debugging a static linked list implementation with side effects. The senior engineer who named the lists used deeply nested modules to maintain abstraction barriers. This experience led me to understand the importance of periodic code cleanup.\n\nThe accumulation of code over time leads to complexity and makes maintenance more challenging. AI models can exacerbate this issue by treating retired code as valid examples, potentially introducing it into new code. However, AI also aids in the cleanup process by helping to understand dependencies before making changes. My manager assigned me the task of cleaning up tech debt after a new flow had been successfully implemented and proven stable. The flow in question, referred to as flow X, was controlled by a compiler option --XYZ and was intermingled with production code.\n\nTo tackle this task, I divided the codebase into two categories: code that depended on --XYZ, which required review, and everything else, which could be safely ignored. The first step was to precisely determine the line where --XYZ was parsed and where flow X was selected. Utilizing static analysis tools based on compile_commands.json, I traced every caller and callee from this starting point. An LLM was then used to mark each function it reached, categorizing the markings in two colors. This marking process was subsequently verified by running a second call-graph tool from the same starting point. If the tool reached the same set of functions as the marking, it confirmed the marking's accuracy, eliminating the need to trust the AI.\n\nOne limitation of this approach was that MLIR registers passes and builds pipelines from strings, which led to dynamic edges that clangd could not follow. This meant that not all new code would be marked, but the remaining code was still too large to review line by line. To manage this, each marked function or node was categorized and handled according to its risk level. Deleted whole functions required quick reviews, while other nodes needed more extensive surgery to ensure healthy code was not damaged. Some nodes required bypasses to maintain dependencies while making changes.\n\nI defined four categories for the nodes, assigning an appropriate treatment for each. The AI, using a small classifier model, categorized most nodes with minimal effort. However, I found that the AI mislabeled a few nodes, which were easily spotted and classified into riskier categories. To ensure the successful removal of flow X without altering the behavior of existing code, I implemented tests for each category. The deletion test verified the removal of the flagged elements, ensuring no dead code was left behind. The retired option was rejected, and any remaining artifacts were rejected as well. A surgical functional test checked that the observable behavior after the changes matched the behavior before the changes. Each category had a matching test, with the deletion test being the most critical and surgical tests providing the strictest checks.",
  "summary": null,
  "key_points": [
    "Removed 19,000 lines of obsolete compiler code from codebase",
    "Used AI to understand dependencies before making changes",
    "Implemented tests to ensure behavior remained unchanged"
  ],
  "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."
}