So, I finally got around to trying Claude Code on a real project, hoping it would be the magic bullet for clearing out our tech debt backlog. The promise of "intelligent refactoring" sounded great. Spoiler alert: it wasn't.
The core issue? It's blissfully, naively unaware of licensing. Our CI pipeline has a mandatory check that runs `license-checker` or similar tools to ensure all dependencies (and their transitive dependencies) are compliant with our corporate policy. No GPL, strict copyleft, etc. You know the drill.
Claude, in its infinite wisdom, keeps suggesting changes that swap one perfectly fine, MIT-licensed package for a "more modern" or "better maintained" alternative... which happens to pull in a viral license. Last week, it decided our perfectly functional HTTP client was "legacy" and proposed switching to a different library. The new library itself was Apache 2.0, fine. But its *dependency tree* introduced a package with a LGPL license. Our CI immediately redlined.
This isn't a one-off. It's happened with:
* Database drivers
* Logging utilities
* Even date formatting libraries
The suggestions look clean and clever from a pure code perspective, but they completely ignore the legal and compliance landscape. It's like having a brilliant architect who designs a beautiful house... on top of a toxic waste dump.
Has anyone else run into this? Is there a way to configure the thing to at least *consider* licensing, or do we have to treat every single suggestion with manual, paranoid scrutiny? Feels like it defeats the whole "automation" angle if we have to manually audit the entire dependency chain of every proposed change. 🤦♂️
Just my 2 cents
Trust but verify.
This is a critical, often overlooked gap in automated refactoring tools. They optimize for code metrics while treating the dependency graph as a secondary concern, if at all. You've hit on the exact reason our team manually reviews every suggested package swap, no matter how trivial.
The date formatting example is particularly telling, because that's a domain where the license risk seems low but the ecosystem is surprisingly fragmented. A tool might flag `moment` as "heavy" and suggest `date-fns`, but miss that you're pulling in a polyfill with ambiguous licensing.
Have you considered building a denylist into your CI that fails the build if a suggested change introduces packages from known problematic license families? It's a band-aid, but it creates a feedback loop the tool might eventually learn from.
That manual review step is so important. It's where we actually caught a license issue last month, right after a similar automated suggestion.
The denylist idea is a good one, but I worry it's a moving target. The license of a transitive dependency three levels down can change with a patch version, and our denylist would need constant updating. It feels like we're trying to automate a solution to automated problems.
Has your team found a tool that can evaluate the *full* proposed dependency tree before a commit, not just the immediate change? That seems like the real need here.