How do you clear out the feature flags nobody uses anymore?
A cleanup AI Employee that sweeps your codebase weekly, finds feature flags that are fully rolled out or long dead, deletes the flag and the dead code branch it guards, proves the suite still passes, and opens a PR for a named human to merge, never touching a flag still mid rollout.
×
A feature flag has a natural lifecycle: ship behind it, ramp the rollout, hit 100%, delete it. The first three steps are urgent and have an owner. The fourth one isn't and doesn't. By the time a flag is fully rolled out, the team that shipped it has moved on, and removing a few lines of conditional logic loses every priority fight. So flags pile up, each one leaving an if branch, a dead else, and a config entry nobody reads anymore. The cost isn't obvious from any single flag. It's cumulative: every live flag is a branch some engineer has to reason about, a code path that might not even be tested anymore, and a source of bugs where the "off" branch silently rots. Left alone, the flag inventory only grows, and nobody wants to be the one who deletes a flag that turns out to still matter.
A weekly schedule reruns the cleanup AI Employee against a ledger it keeps between runs, tracking every flag's age, rollout state, and what it already proposed, so it treats flag cleanup as an ongoing sweep rather than a one off task. It clones your repo, inventories every feature flag, and classifies each one: fully rolled out and safe to remove, long dead with no live check left, still in partial rollout, or part of an active experiment. For the first two categories it deletes the flag and the dead branch it guards, proves the suite still passes, and opens a PR. For the rest it does nothing but note them for a named human to look at.
See exactly how the work gets done.
Runs weekly against a running ledger
A scheduled run fires once a week and picks up the ledger it keeps between runs rather than starting fresh, tracking every flag's age, rollout state, and whatever it already proposed, so it never relitigates a flag it already handled or duplicates an open PR.
Carries your classification rules
How to tell a dead flag from a live one travels with it as a skill: what "fully rolled out" looks like in your flag config, how long a flag has to go unchecked before it counts as long dead, and, just as important, what partial rollout and active experiment signals look like, so it knows exactly when to stop.
Works the codebase through GitHub
Its only system is the codebase itself, reached through GitHub with permissions you set: it clones the repo, greps for every flag definition and call site, removes the flag and the branch it guards on an isolated branch, runs the verification suite, and pushes a PR through the gh CLI. Credentials stay in memory, never written to disk or exposed to the model.
Never merges, never pushes to the default branch
Any flag still in partial rollout or part of an active experiment is reported, not touched. Every change lands on an isolated branch and becomes a PR. It never pushes to the default branch and never merges its own work.
Opens the cleanup PR
Only when the full suite is green does it push the branch and open a PR listing exactly which flags it removed and why, plus a separate note for any flag it found still in partial rollout. A named human reviews and merges; nothing lands on its own.
Runs in your environment
Every run is isolated inside your own infrastructure, reaching only the codebase through GitHub. Your data never leaves it.
Permissions you set
The GitHub credential stays in memory, injected at run time, never written to disk, never shown to the model or the logs.
Partial rollout is untouchable
Any flag still ramping, or part of an active experiment, is never removed. It's logged, and a named human decides its fate.
Proven before it's proposed, never self merged
The full suite runs on the cleanup branch inside your environment; a failing removal is dropped and logged, never pushed for a person to untangle. Every change lands as a PR, never a direct push, never a self merge.
You own the rules
The classification rules, the ledger, and the permissions are yours, versioned and changed on your terms, not in a vendor dashboard.
Flags that used to sit forgotten at 100% rollout now get deleted within a week of reaching it, with the dead branch cleaned up alongside them. The AI Employee proposes; a person still owns the merge, and anything mid rollout stays exactly where the team left it.
Weekly
Every flag rechecked against its current rollout state
PR only
Every removal lands as a reviewable PR, never a direct push
0 flags
Partial rollout flags ever touched by the AI Employee
Our free AI audit shows you where AI fits, what your security risks are, and gets your first AI employee working.
How do AI Employees keep your docs in sync with the code?
Sweeps the code merged each day, rewrites the docs those changes touched, and opens one reviewable pull request. Publishing waits for a human merge.
×How do AI Employees test every pull request before a human reviews it?
Checks out every pull request, runs the suite, exercises the change through the edge on a test deploy, and posts the result. It stays off production, leaving the merge to a person.
×How do you get a postmortem drafted the moment an incident resolves?
Reconstructs the incident timeline, correlates it against deploys and log spikes, and opens a structured postmortem as a doc PR. It drafts, and the team finalizes.
×