Skip to main content

Clean Up Feature Flags Post-Release

Schedule a one-time Devin session to strip out a feature flag and its dead code after your release stabilizes.
AuthorCognition
CategoryAutomations
FeaturesSchedules
1

Schedule the cleanup when you ship the flag

You just deployed a new checkout flow behind enable_new_checkout. It’s enabled in production, but you want a week of monitoring before you commit to removing the old code. Instead of creating a ticket you’ll forget about, schedule a one-time Devin session right now — while the context is fresh.Open the schedule creation page and set the type to One-time. Pick a date after your monitoring window (e.g., next Friday at 9 AM). Select a Slack channel so your team gets notified when the session runs and the PR is ready. Then paste your prompt:
2

Make the prompt thorough

Feature flags hide in unexpected places — config files, test fixtures, comments, environment variables. The more context you put in the prompt, the cleaner the result. Include:
  • How your flags work — where they’re defined and how they’re checked (e.g., useFeatureFlag('name') in React, isEnabled('name') in backend services)
  • What not to touch — the flag framework itself vs. the specific flag (e.g., “don’t modify src/lib/featureFlags/ — that’s the framework”)
  • Where the old and new code live — e.g., “the old checkout is in src/pages/checkout/legacy/, the new flow is in src/pages/checkout/v2/”
  • Cleanup scope — comments, docs, .env files, and CI configs that reference the flag should also be cleaned up
A prompt with this level of detail lets Devin trace every reference in one pass — no follow-up sweep needed.
3

Review the PR when it lands

When the scheduled session fires, Devin traces every usage of the flag across your codebase, keeps the enabled code path, strips the disabled path and dead code, cleans up tests, and opens a PR. You’ll get an email notification when it’s ready.A typical PR looks like this:
Removed feature flag: enable_new_checkout

- Deleted flag from src/config/featureFlags.ts (1 file)
- Removed 12 conditional branches across 7 files
- Deleted src/pages/checkout/legacy/ (4 files, 380 lines)
- Updated 3 test files — removed flag mocking, deleted old-path tests
- All 1,204 tests passing
Before merging, double-check that no business logic from the old path should have been preserved — error handling, analytics events, or edge-case fallbacks sometimes live inside the “disabled” branch.