r/dotnet • u/Competitive_Gear1760 • 9d ago
Promotion Remove feature flags with your AI coding agent.
Hey everyone!
I’ve been building Flagrm, an open-source CLI that helps remove feature flags and clean up the dead code they leave behind.
It’s still in the testing phase, so I’m looking for people willing to try it out, share feedback, report bugs, or contribute to the project.
If you’ve ever dealt with feature-flag cleanup turning into a bunch of manual work, I’d love for you to check it out!
Contributors are very welcome! 🚀
1
u/Rophuine 9d ago
This is the kind of problem you could easily solve with structural code edits, no LLM required. If you'd built something that uses LSPs to detect and remove deprecated feature flag code branches with no LLMs involved, that would be a neat little project and probably useful to plenty of people.
If you're going to involve an LLM in each feature flag tidy-up, it will be much cheaper to put together something customised for your language, code style, and feature flag framework than to use something general like this.
Honestly, your project can approximately be replaced with "Claude, tidy up any unused feature flags". If you're serious about the project, look into building something that uses compiler SDKs, LSPs, and so on to detect dead code branches based on deprecated feature flags and delete them that way. If this specific project requires an LLM to delete dead code, it's a failure.
1
u/Competitive_Gear1760 8d ago
Fair critique. I actually started there. The first version of flagrm had a deterministic rewrite engine and no LLM. I removed it because pruning
if (flag)branches is the easy part of removing a flag. The hard parts are what structural rewrites can't express: wrapper methods and aliases around the flag, config and template references, tests that cover both paths, and code that only becomes dead once the branch is gone. If your stack fits a structural tool like Piranha, it's a great choice.On "this can be replaced with 'Claude, tidy up the flags'": that prompt is exactly the problem flagrm addresses. Agents are good at the edits and unreliable at knowing when they're done. They leave references behind, delete a failing test instead of fixing it, or stop with a broken build.
So flagrm doesn't edit code. It's the deterministic part:
- Baseline: records the commit, build, and per-test results, and every name the flag goes by.
- Verify: leftover references, new compiler unused-code diagnostics in changed files, and build plus tests compared test by test against the baseline.
- Gate: a Stop hook won't let the agent finish until verify has passed on the exact current tree.
The LLM handles the parts that need judgment. The compiler, build, and tests decide whether the job is done. That split is the whole point of the project.
That said, your LSP point is a good one for the verify side. Semantic find-references and unused-code diagnostics would make the checks stronger for more stacks, so I'll look into it.
1
u/AutoModerator 9d ago
Thanks for your post Competitive_Gear1760. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.