AI Coding Agents
Maintenance
Removing stale feature flags with coding agents
September 24, 2026 - 2 minute read
Feature flag cleanup looks simple after a rollout reaches 100 percent. The flag still appears in configuration, evaluation calls, tests, analytics, documentation, and sometimes several repositories. Removing only the conditional leaves dead behavior behind. Removing the wrong branch can restore behavior that users no longer see.
Martin Fowler's feature toggle guidance separates toggles by purpose and expected lifetime. Release toggles should usually disappear after rollout, while permission and experiment toggles follow different ownership rules. Coding agents can handle the mechanical search and coordinated edits, but the task must begin with proof that a specific flag is safe to retire.
Prove the feature flag is stale
Record the flag key, owner, creation purpose, current production value, environments, and last known evaluation. Confirm whether any customer, tenant, region, or service still receives the old path. Check server-side and client-side systems because the same key can have different defaults.
Search beyond exact string matches. Wrappers, typed flag constants, generated clients, environment variables, dashboards, and runbooks may refer to an alias. The agent should produce an inventory before editing and identify which branch is the permanent behavior. If the rollout state or ownership record is missing, stop and resolve that uncertainty rather than infer it from code.
Factory's Droid Exec can run a non-interactive maintenance task in a named working directory or isolated Git worktree. That keeps the proposed removal separate from other work and preserves dirty worktrees for review when a run cannot finish cleanly.
Remove the flag as one bounded change
Delete the evaluation call, the obsolete branch, and configuration entries together. Simplify tests so they assert the permanent behavior directly instead of setting a flag that no longer exists. Remove mocks, fixtures, metrics, and comments that existed only for the transition.
Keep the patch narrow. A stale flag often sits next to code that could be refactored, but combining cleanup with a redesign makes regressions harder to diagnose. For cross-repository flags, create an explicit order. Consumers should stop reading the key before the control-plane definition disappears, unless the flag system guarantees harmless reads of unknown keys.
The OpenFeature specification provides a common model for flag evaluation, including default values, targeting context, and evaluation details. Those details help define what must remain stable while the call site is removed. They do not prove that a rollout is complete, which still depends on the organization's own telemetry and release record.
Validate behavior without the toggle
Run tests for the permanent branch and for adjacent failure paths. Build production artifacts to catch references that development transforms may hide. Search the repository again for the key and its aliases after the change. A zero-result search is evidence only when the original inventory was complete.
Exercise the user-visible flow when the flag affected a UI or API. Factory's Automated QA maps a diff to affected applications, drives relevant flows, and captures evidence for review. The final pull request should list the retired key, the retained behavior, all repositories checked, and the verification performed.
Teams with many short-lived flags can schedule a candidate report through Factory Custom Automations. Keep deletion behind human review. Age and evaluation counts can identify candidates, but rollout intent and customer exceptions still determine whether removal is safe.
