Cómo las Reglas de Opinión Previenen Incidentes de Producción en Claude
Cada equipo que implementa Claude en producción eventualmente se topa con el mismo muro.
El primer prototipo funciona.
La demostración va bien.
Luego llega el tráfico real y la aplicación comienza a hacer cosas que nadie predijo: llamar a la herramienta equivocada, agotar el presupuesto, devolver una negativa sin alternativa, o filtrar un detalle del prompt del sistema que nunca debió haber dicho en voz alta.
Ninguno de estos son errores en Claude.
Son lagunas en las decisiones que el equipo nunca hizo explícitas.
Esta página expone el modelo mental detrás de ese patrón de fallo y por qué reemplazar el prompting ad hoc, caso por caso, con un pequeño conjunto de reglas de opinión, escritas, es el movimiento de mayor apalancamiento que un líder técnico puede hacer antes de lanzar una función impulsada por Claude.
Resumen
- Idea Central: Los incidentes de producción en aplicaciones de Claude rara vez son causados por fallos del modelo; son causados por decisiones que se tomaron una vez, informalmente, y nunca se convirtieron en una regla que otros pudieran seguir o aplicar.
- Por Qué Importa: El prompting ad hoc escala linealmente con el número de ingenieros que tocan la base de código y el número de casos extremos que casualmente se les ocurren; las reglas de opinión escalan con la revisión, no con la memoria.
- Conceptos Clave: prompting ad hoc, reglas de opinión, deriva de decisiones, clase de incidente, aplicabilidad de reglas.
- Cuándo Usar: Antes de que una función de Claude llegue a usuarios reales, cuando un segundo ingeniero comienza a tocar el mismo código del agente, e inmediatamente después de cualquier incidente cuya causa raíz sea "olvidamos manejar eso".
- Limitaciones / Compensaciones: Las reglas demasiado rígidas ralentizan la experimentación legítima, y una regla que nadie aplica es solo documentación que nadie lee.
- Temas Relacionados: política de selección de modelos, higiene de prompts, diseño de herramientas, gobernanza de costos, barreras de seguridad.
Fundamentos
El prompting ad hoc es lo que sucede por defecto.
Un ingeniero escribe un prompt del sistema para resolver el problema que tiene delante.
Funciona, así que se lanza.
Seis semanas después, otro ingeniero agrega una nueva llamada a una herramienta, y las suposiciones del prompt original se rompen silenciosamente, porque nada escribió esas suposiciones en ningún lugar donde una segunda persona pudiera encontrarlas.
Las reglas de opinión son la alternativa.
Una regla es una decisión que ya se ha tomado, declarada de forma clara para que cualquiera en el equipo pueda aplicarla sin redescubrir el razonamiento desde cero.
"Usar Haiku para tareas de clasificación con menos de 500 tokens de entrada" es una regla.
"Usar el modelo que parezca adecuado para la tarea" no es una regla; es una invitación para que cada ingeniero tome una decisión diferente, localmente razonable, globalmente inconsistente.
La distinción importa porque Claude, como cualquier modelo de lenguaje grande, es extremadamente bueno haciendo exactamente lo que se le pide y solo moderadamente bueno adivinando lo que se suponía que se le pedía cuando el prompt es vago.
Un prompt vago no falla ruidosamente.
Falla silenciosamente, de maneras que solo se manifiestan como un patrón agregado a través de miles de solicitudes de producción: un tono ligeramente incorrecto aquí, una llamada a herramienta innecesaria allá, un pico de costos que nadie rastrea hasta su origen durante semanas.
Una analogía simple: el prompting ad hoc es como un equipo sin una guía de estilo de codificación.
Cada archivo se ve razonable localmente, y la base de código en su conjunto no es revisable, porque no hay un estándar compartido contra el cual verificar ninguna decisión individual.
Las reglas de opinión son la guía de estilo, no porque la creatividad sea mala, sino porque la consistencia es lo que hace posible la revisión, la depuración y la incorporación en primer lugar.
Mecánicas e Interacciones
Los incidentes de producción en aplicaciones de Claude tienden a caer en un pequeño número de clases de incidentes recurrentes, y cada clase se remonta a la ausencia de una regla específica:
- Desajustes de nivel de modelo. Un punto final de clasificación sensible a la latencia se enruta silenciosamente a través de Opus porque nadie escribió para qué complejidad de tarea se mapea a qué nivel de modelo, por lo que el ingeniero de guardia que agregó el punto final eligió lo que parecía seguro.
- Hinchazón de contexto. El prompt de un agente conversacional crece cada sprint a medida que los ingenieros agregan "una instrucción más", hasta que el contexto acumulado degrada la calidad de la respuesta y nadie puede decir qué instrucción sigue siendo fundamental.
- Herramientas sin alcance. A una herramienta destinada a buscar saldos de cuentas se le da acceso amplio a la base de datos "por si acaso", y una secuencia de entrada inesperada utiliza ese acceso de una manera que el autor original nunca pretendió.
- Gasto no rastreado. Nadie estableció un presupuesto de tokens por equipo, por lo que un bucle de agente excesivamente entusiasta agota el presupuesto de inferencia de un mes en un fin de semana antes de que alguien note la factura.
- Lagunas silenciosas en las barreras de seguridad. Una llamada a herramienta que escribe en un sistema de producción nunca fue explícitamente controlada con confirmación, porque el prototipo original solo se ejecutó contra un entorno de staging.
Cada uno de estos es prevenible, y cada uno es prevenible por el mismo mecanismo: escribir la decisión como una regla antes del incidente, no como un elemento de acción retrospectivo después de él.
Aquí es donde entra la deriva de decisiones: la divergencia gradual entre lo que un equipo cree que hace su aplicación Claude y lo que realmente hace, acumulada una decisión local no revisada a la vez.
La deriva de decisiones es invisible desde dentro de una sola solicitud de extracción (pull request).
Cada cambio individual parece una adición pequeña y sensata.
Solo se vuelve visible en agregado, generalmente durante la revisión de un incidente, cuando alguien reconstruye la línea de tiempo y se da cuenta de que el prompt del sistema ha sido editado por seis personas diferentes con seis modelos mentales diferentes de lo que significa "útil" en este contexto.
Las reglas interrumpen la deriva de decisiones al dar a cada contribuyente el mismo punto de partida.
# Ad hoc: cada sitio de llamada redescubre "qué modelo para esta tarea"
model = "claude-opus-4-8" if "hard" in task_description else "claude-sonnet-5"
# Basado en reglas: la decisión se toma una vez, se referencia en todas partes
from claude_rules import select_model
model = select_model(task=task_description, latency_budget_ms=800)La versión basada en reglas no es más inteligente que la versión ad hoc en ninguna llamada individual.
Su valor es que la misma decisión, aplicada consistentemente en cien sitios de llamada, produce un sistema cuyo comportamiento un líder técnico puede razonar realmente, y cambiar deliberadamente, en un solo lugar, en lugar de cazar cada variante dispersa.
Consideraciones Avanzadas y Aplicaciones
Las reglas no eliminan el juicio; lo reubican.
En lugar de que cada ingeniero ejerza el juicio de forma independiente, en el momento en que escriben un sitio de llamada, el juicio se ejerce una vez, deliberadamente, por quien sea el propietario de la regla, y se revisa periódicamente a medida que evolucionan el producto y la línea de modelos.
Esto tiene un efecto de segundo orden que importa más a medida que un equipo escala: las reglas son auditable de una manera que las decisiones ad hoc dispersas no lo son.
Cuando ocurre un incidente, "¿qué regla violamos y por qué?" es una pregunta que se puede responder.
"¿Qué estaba pensando el ingeniero hace seis meses cuando escribió este prompt?" generalmente no lo es, especialmente una vez que ese ingeniero se ha mudado a otro equipo.
Las reglas también cambian el modo de fallo de los incidentes de silencioso a ruidoso.
Una base de código con una regla explícita ("todas las llamadas a herramientas destructivas requieren confirmación") convierte una violación en algo que un revisor de código o un linter pueden detectar antes de fusionar.
Una base de código con solo una norma implícita convierte la misma violación en algo que solo se manifiesta después de que ya ha causado daño en producción.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Prompting ad hoc, caso por caso | Rápido de prototipar, sin costo inicial | Deriva silenciosamente, no revisable a escala, repite errores | Exploración temprana, prototipos de un solo ingeniero |
| Reglas de opinión, escritas | Revisable, aplicable, consistente en todo el equipo | Requiere inversión inicial, puede volverse obsoleto si nunca se revisa | Cualquier función de Claude que toque usuarios reales o presupuesto real |
| Reglas aplicadas solo por convención | Barato de adoptar, sin necesidad de herramientas | Se erosiona en el momento en que se une un nuevo ingeniero que nunca aprendió la convención | Equipos pequeños y estables con baja rotación |
| Reglas aplicadas por puertas de lint/revisión | Detecta violaciones antes de fusionar, escala con el tamaño del equipo | Requiere inversión en herramientas y mantenimiento periódico | Equipos que han superado a los primeros ingenieros o al primer incidente de producción |
El patrón que aparece repetidamente en los equipos que han lanzado Claude con éxito no es que nunca cometieron errores, sino que cada error se convirtió en una regla, y la regla evitó que el mismo error se repitiera en un sitio de llamada diferente escrito por un ingeniero diferente.
Ese efecto de acumulación, más que cualquier prompt ingenioso individual, es lo que separa una aplicación Claude que se vuelve más confiable con el tiempo de una que acumula incidentes a una tasa constante sin importar cuánta ingeniería se invierta en ella.
Conceptos Erróneos Comunes
- "Las reglas significan que no podemos ser flexibles." - Las reglas restringen el camino predeterminado, no todos los caminos. Un buen conjunto de reglas tiene un proceso explícito y revisado para excepciones, no una prohibición general de las decisiones de juicio.
- "Somos un equipo demasiado pequeño para necesitar esto." - La deriva de decisiones comienza con la segunda persona que toca el código, o la primera vez que el autor original olvida su propio razonamiento seis meses después. El tamaño del equipo acelera el problema; no lo causa.
- "Si el modelo es lo suficientemente bueno, los detalles del prompt no importan." - Un modelo más capaz ejecuta una instrucción ambigua con más confianza, no más correctamente. La capacidad amplifica el costo de una regla poco clara en lugar de hacer que la regla sea innecesaria.
- "Las reglas son lo mismo que la documentación." - La documentación describe lo que hace el sistema. Una regla es aplicable: se puede verificar en una revisión, en un pase de lint o en una prueba. La documentación no aplicada se degrada en deriva de decisiones tan rápido como la falta de documentación.
- "Escribiremos las reglas después de lanzar." - Adaptar reglas a una base de código llena de decisiones ad hoc requiere primero reconstruir cuáles fueron esas decisiones, que es exactamente la información que el prompting ad hoc no preserva.
Preguntas Frecuentes
¿Qué cuenta como una "regla" en lugar de solo un buen consejo?
- Una regla es lo suficientemente específica como para verificarla: nombra una condición y una acción requerida.
- "Usar Haiku para tareas de menos de 500 tokens de entrada" es una regla.
- "Piensa cuidadosamente en el costo" es un consejo; cierto, pero no aplicable por nadie más que por la persona que ya está de acuerdo con él.
¿No ralentiza escribir reglas por adelantado la creación temprana de prototipos?
Sí, ligeramente; y esa compensación generalmente vale la pena aceptarla solo una vez que el prototipo se dirige a usuarios reales o presupuesto real. La exploración temprana y desechable puede seguir siendo ad hoc; en el momento en que un segundo ingeniero o el tráfico real tocan el código, el costo de la deriva comienza a superar el costo de escribir la regla.
¿Quién debe ser el propietario de las reglas de Claude de un equipo?
Típicamente el líder técnico o un pequeño grupo rotatorio, de la misma manera que un equipo posee su guía de estilo de codificación. La propiedad importa menos que la regla esté escrita en un lugar revisable y se revise cuando la línea de modelos o el producto cambien.
¿Cómo se diferencia esto de simplemente escribir un prompt del sistema más largo?
Un prompt del sistema codifica reglas para el comportamiento del modelo en tiempo de inferencia. Las reglas que describe esta página son más amplias: cubren decisiones de ingeniería como la selección de modelos, el alcance de las herramientas y los límites de presupuesto que ocurren fuera de cualquier prompt único, en código, revisión y proceso.
¿Cuál es la primera señal de que un equipo necesita reglas explícitas?
Una revisión de incidente donde la causa raíz es alguna versión de "olvidamos manejar eso" o "diferentes partes de la base de código hacen esto de manera diferente". Esa oración es la señal de que una decisión existía solo en la cabeza de una persona.
¿Pueden las reglas quedar obsoletas a medida que se lanzan nuevos modelos de Claude?
Sí, y eso es esperado; una regla vinculada al perfil de costo o latencia de un modelo específico necesita ser revisada cuando cambia la línea de modelos. La solución es una cadencia de revisión periódica, no evitar las reglas porque podrían necesitar actualización.
¿Las reglas reemplazan la necesidad de monitoreo y observabilidad?
No. Las reglas reducen la frecuencia con la que ocurren los incidentes; la observabilidad es cómo un equipo detecta los incidentes que ocurren de todos modos, incluidas las violaciones de las propias reglas. Los dos son complementarios, no sustitutos.
¿Existe el riesgo de tener demasiadas reglas?
Sí; un conjunto de reglas tan grande que nadie puede tenerlo en su cabeza deja de ser utilizable y comienza a ser ignorado, lo que es funcionalmente idéntico a no tener reglas. La lista de reglas principales en esta sección existe precisamente para mantener el conjunto aplicable pequeño y memorable.
¿Cómo se relacionan las reglas de opinión con la "deriva de decisiones"?
La deriva de decisiones es la enfermedad; las reglas son la prevención. La deriva ocurre cuando el mismo tipo de decisión es tomada de manera diferente por diferentes personas con el tiempo. Una regla fija la decisión una vez para que deje de derivar.
¿Son las reglas solo para prevenir resultados negativos, o también ayudan a que los resultados positivos ocurran más rápido?
Ambas cosas. Una regla escrita ahorra a cada ingeniero futuro el tiempo de redescubrir una decisión desde cero, lo que acelera el desarrollo legítimo tanto como previene errores; de la misma manera que una guía de estilo acelera la revisión de código, no solo previene código malo.
¿Qué sucede cuando una regla resulta ser incorrecta?
Se revisa, de la misma manera que se revisa cualquier otra pieza de documentación de ingeniería; a través de la revisión, no ignorándola silenciosamente en un sitio de llamada mientras se deja técnicamente "en vigor" en todas partes.
¿Se aplica esto por igual a un proyecto secundario de un solo ingeniero y a un equipo grande?
El mecanismo es el mismo, pero la urgencia escala con el tamaño del equipo y el tráfico. Las "reglas" de un ingeniero en solitario pueden vivir en su cabeza por más tiempo antes de que la deriva cause daño; un equipo de diez no puede depender de la memoria de ninguna persona.
Relacionado
- Las Reglas Centrales de Claude: Una Lista de Referencia Rápida - la versión condensada de una página de las reglas que motiva esta página.
- Reglas de Selección de Modelos: Cuándo Usar Opus, Sonnet o Haiku - el primer conjunto de reglas concretas al que se aplica este modelo mental.
- Reglas de Barreras de Seguridad que Todo Líder Técnico Debería Aplicar - la clase de incidente con el mayor costo cuando falta una regla.
- Mejores Prácticas de Reglas de Claude - todas las reglas de esta sección destiladas en una sola lista.
Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y el SDK oficial de Python
anthropic(última versión 0.x). Los nombres de los modelos, los precios y las versiones del SDK cambian rápidamente; verifique los detalles actuales en platform.claude.com/docs antes de confiar en ellos.