Hay una confusión cara en software: creer que desplegar una función es lo mismo que encenderla. No lo es —o no debería serlo. Esta semana lo volvimos regla con código: estrenamos Cortex, nuestro sistema de feature-flags, y la decisión de diseño más importante no fue una pantalla ni un endpoint, fue un default.
Cada bandera nace apagada. En cada ambiente. Una función nueva puede estar desplegada en producción y, aun así, no hacer absolutamente nada hasta que alguien entra y la prende —a propósito, ambiente por ambiente. El estado por defecto no es 'encendido y a ver qué pasa’; es inerte.
El default más peligroso es el que hace algo sin que se lo pidas. Por eso cada función nace apagada: para que prenderla sea una decisión con nombre y fecha, no un efecto secundario de un deploy.
Alrededor de ese default está lo que lo vuelve usable: reglas de segmentación (prende para estos, no para aquellos), interruptores de emergencia permanentes que no se pueden borrar por accidente, y un registro de auditoría de quién prendió o apagó qué. Y una decisión que para nosotros no es decorado: la bandera se consulta desde el código (API + SDK) y también desde un agente, por un endpoint MCP. O sea que el mismo copiloto con el que construimos puede leer y mover una bandera sin pedirle un deploy a nadie —la palanca queda al alcance del operador, sea humano o IA.
Lo contamos porque 'tenemos feature-flags’ suena a checkbox de madurez, y el valor real está en la dirección del default: separar 'está en producción’ de 'está prendido’ te deja desplegar a oscuras, soltar de a poco y apagar sin volver a compilar. Receipts > adjectives: el recibo es una sola línea —t.boolean :enabled, default: false— en la migración que crea los ambientes de cada bandera, y es esa línea la que decide, por nosotros, que lo nuevo empiece sin hacer ruido.