Feature flag

Without a flag, shipping a feature and releasing it to every user are the same event. A problem found afterwards can only be fixed by shipping again, often in a hurry. A flag separates the two. The code goes live quietly and is tried on a small group. It is switched on for everyone once it proves itself, or switched straight back off if something goes wrong. A risky release becomes a controlled one, and a rollback becomes a switch flip.

For people building with AI tools, where changes arrive fast, a flag also limits the harm from one that misbehaves.

• Put any risky or customer-facing change behind a flag before it reaches production, not after a problem appears.
• Release to internal accounts first, then a small percentage, and watch real numbers before widening.
• Give every flag an owner and a removal date.
• Remove the flag and the old code once the decision is final.

A feature flag is a condition wrapped around new behaviour: if the flag is on for this user, show the new version, otherwise show the old one. The flag's value lives in a settings screen or service, not in the code, so changing it takes seconds and needs no new release. It can be on for everyone, off for everyone, or on for chosen accounts or a percentage of users.

• Leaving flags in the code for months. Each one doubles the paths that need testing, and old flags become technical debt.
• Treating a flag as a security control. Hiding a button is not the same as blocking access.