How Do Successful Teams Name Their Feature Flags?

Apr 1, 2026

The Discovery

When I looked through the leaked Anthropic codebase, I found something unexpected: a project internally codenamed “tengu” (Japanese folklore: long-nosed goblin). Every telemetry event and feature flag carried this prefix. But what caught my attention was the naming pattern for the feature flags themselves:

tengu_cobalt_frost: true      # voice mode
tengu_amber_quartz: false     # voice kill switch
tengu_kairos: false           # autonomous agent
tengu_ultraplan: false        # 30-min Opus sessions
tengu_coordinator: false      # multi-agent swarm

Gemstone codenames. Voice mode is cobalt_frost. The voice kill switch is amber_quartz. The Reddit community reaction was surprisingly positive: “i kind of love it honestly.”

This made me think about how successful teams name their feature flags. There are real trade-offs between clarity and creativity.

Three Naming Strategies

I see three main approaches to feature flag naming:

1. Descriptive + Hierarchical

The most common pattern. Straightforward, self-documenting names:

voice_mode_enabled: true
checkout_new_payment_flow: false
auth_two_factor_required: true
api_rate_limit_v2: false

This works well for larger teams because anyone can understand what the flag does. The hierarchy (checkout_, auth_, api_) prevents collisions across services.

2. Creative Codenames (Anthropic Style)

Anthropic’s approach uses project prefixes plus gemstone-themed codenames:

tengu_cobalt_frost: true    # voice mode
tengu_amber_quartz: false   # voice kill switch
tengu_kairos: false         # autonomous agent

I think the key insight here is that this becomes internal team lore. “Is cobalt_frost enabled?” means something specific to the team. It also adds a layer of obfuscation - if someone sees these names in logs, they won’t immediately know what features are in development.

3. Ticket-Referenced

Some teams tie flags directly to their issue tracker:

JIRA-1234_new_checkout: false
GH-567_add_dark_mode: true
NOTICE-891_rate_limit: false

This provides traceability but creates verbose names.

When Creative Naming Works

Creative codenames make sense in these situations:

Tight-knit teams where everyone knows the project context
Research features that may never ship publicly
Internal tools not exposed to customers
Security-sensitive features where obfuscation helps

The Anthropic example works because they’re a focused AI research team. The naming becomes part of their internal culture.

When Descriptive Naming is Required

I would not recommend creative naming for:

Multiple teams sharing a codebase
Customer-facing features with stakeholder visibility
Audit requirements where clarity matters
Long-lived flags that new team members need to understand

For these cases, clarity wins over creativity.

Common Mistakes

I’ve seen these naming anti-patterns cause problems:

Mistake	Example	Problem
Boolean names	`is_enabled`	Redundant - all flags are booleans
Generic names	`new_feature`	No context about what it controls
No ownership	`dark_mode`	Who owns this?
Forever flags	`temp_fix`	Never gets cleaned up
Collision risk	`enabled`	Same name in different services
Over-abbreviation	`usr_auth_2fa`	Hard to read

The worst offender: generic names like new_feature or test_flag. Six months later, no one remembers what they do.

Recommendations by Team Size

Based on what I’ve seen work:

Small teams (<10 people):

Creative codenames are fine
Keep a simple mapping document
Use project prefix for namespace

Medium teams (10-50 people):

Hybrid approach: descriptive names with optional codename alias
Team prefix for namespace
Ticket reference in documentation

Large teams (50+ people):

Descriptive names mandatory
Hierarchical naming: team_feature_action
Central registry with ownership tracking

Practical Example

Here’s how I would structure flags for a hypothetical checkout redesign:

# Good: descriptive, namespaced, clear ownership
checkout_redesign_enabled: false
checkout_address_autocomplete: true
checkout_apple_pay_v2: false
checkout_remove_guest_checkout: false

# With a cleanup signal
checkout_remove_guest_checkout_remove_after: "2026-06-01"

The last line is important: include a removal signal. Feature flags should not live forever.

What I Found in the Wild

Going back to the Anthropic leak, here’s what I noticed about their naming:

Flag Name	Feature	Status
`tengu_cobalt_frost`	Voice mode	Active
`tengu_amber_quartz`	Voice kill switch	Safety toggle
`tengu_kairos`	Autonomous agent	Unreleased
`tengu_ultraplan`	30-min Opus sessions	Unreleased
`tengu_coordinator`	Multi-agent swarm	Unreleased

The gemstone pattern (cobalt_frost, amber_quartz) is consistent. The tengu_ prefix prevents collisions with other projects. The unreleased features use the same pattern, which suggests they standardize on this approach internally.

Summary

In this post, I explored feature flag naming conventions through the lens of Anthropic’s leaked “tengu” codebase. The key point is that naming encodes team communication. Anthropic’s gemstone approach works because they’re a focused team with shared context. For most organizations, descriptive hierarchical names provide better clarity. The important things: define your convention upfront, add project prefixes, document codenames if you use them, include a removal signal, and audit flags quarterly.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Feature Flags 101: Best Practices - LaunchDarkly
👨‍💻 Effective Patterns for Feature Flags - Microsoft DevOps
👨‍💻 Reddit Discussion: Claude Code Leaked Source

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!