A field guide to dead code, shadowed names, ghost deps, and duplicate logic— caught with Go’s stdlib
Let’s start with something we’ve all felt. You ask an AI to write you a function, it hands you something that compiles, and you drop it into the codebase. It works. The tests pass. You move on.
But here’s the thing about AI-generated code: it’s rarely wrong — it’s just unreviewed. The model doesn’t have a mental model of your codebase. It doesn’t know that os is already imported, that applyTax is a near-copy of applyDiscount, or that it left a deadCode function behind because it generated three versions of a helper and forgot to delete the other two.
None of that stops the code from compiling. None of it fails a test. It just quietly accumulates — until the next human who touches the codebase has to untangle it.
The good news is that Go gives us an unusual advantage here. The standard library ships a full compiler front-end as ordinary packages. go/ast, go/parser, and go/token let us parse Go source and inspect it the way a careful reviewer would — without installing a single third-party tool.
So in this post, we’re going to build a small audit tool that walks an AI-written codebase and checks for the five most common kinds of cruft: unused dependencies, unused imports, shadowed names, duplicated logic, and dead code. We’ll take it piece by…