Tres desarrolladores de un mismo equipo están convencidos de que su asistente de IA siempre revisa casos límite antes de dar por terminada una tarea. Un cuarto se suma al equipo, clona el mismo repositorio, y a él no le funciona igual. Nadie tocó el código del asistente. El problema estaba en otro lado: la regla vivía en la configuración personal de los tres primeros, no en el proyecto.

En síntesis

  • Los sistemas de configuración de agentes de IA suelen tener niveles: personal, de proyecto, de equipo. Cada uno tiene un alcance distinto.
  • Una regla en el nivel equivocado no falla de forma visible — simplemente no llega a quien no la tiene configurada.
  • La solución no es “explicarle mejor la regla al modelo”. Es poner la configuración en el nivel que corresponde a quién necesita heredarla.
  • Es uno de los criterios que evaluamos cuando auditamos cómo un equipo integra IA agéntica a su flujo de trabajo real.

El síntoma engañoso

Cuando algo así pasa, la reacción típica es pensar que el asistente “se rompió” o que “dejó de funcionar como antes”. Pero el comportamiento nunca cambió. Lo que cambió es quién está corriendo la sesión. Si la regla vive en un archivo de configuración personal —algo específico a la máquina de cada desarrollador, no versionado junto al proyecto— cualquiera que no tenga esa configuración local simplemente nunca la tuvo.

Es un error fácil de cometer porque, desde adentro del equipo original, todo funciona perfecto. El problema solo se hace visible cuando entra alguien nuevo, y para ese momento ya pasó tiempo suficiente como para que nadie recuerde dónde quedó escrita la regla original.

Los niveles importan, y se suman

Varias de las herramientas de asistencia de IA para desarrollo más usadas hoy tienen una jerarquía de niveles de configuración: uno personal (vive en la máquina de cada persona, nunca se versiona), uno de proyecto (vive en el repositorio, todo el equipo lo recibe al clonar), y a veces un nivel intermedio por subdirectorio o módulo. La regla clave es que estos niveles se suman, no se reemplazan entre sí: una convención de proyecto sigue aplicando aunque exista además una regla personal, y viceversa.

El error del ejemplo inicial no fue escribir la regla. Fue escribirla en el nivel personal cuando lo que se necesitaba era compartirla con todo el equipo. La corrección es simple una vez que se identifica: mover la directiva del nivel personal al nivel de proyecto, versionado, para que cualquiera que clone el repositorio la reciba automáticamente.

Cuándo modularizar en vez de amontonar

Un problema relacionado aparece cuando el archivo de configuración de proyecto crece sin control: se convierte en un documento largo, difícil de mantener, donde una convención de testing convive con reglas de estilo y decisiones de arquitectura sin ningún orden. La respuesta no es evitar escribir reglas — es organizarlas por tema en archivos separados, cada uno enfocado en un dominio específico (testing, estilo, arquitectura), en vez de un único archivo monolítico que crece indefinidamente.

Hay un matiz adicional que suele pasarse por alto: algunas reglas no deberían aplicar siempre, sino solo cuando se está trabajando en cierto tipo de archivo. Una convención de testing no necesita cargarse en cada sesión — solo quiere activarse cuando efectivamente se está editando un archivo de test. Separar “lo que siempre aplica” de “lo que se activa según el contexto” es, en la práctica, la diferencia entre un sistema de configuración que escala con el equipo y uno que se vuelve ruido que nadie lee.

Por qué esto es parte de una auditoría seria

En Arteclaw ayudamos a organizaciones a adoptar arquitecturas agénticas de forma segura. Como parte de ese trabajo, sometemos sistemas —los nuestros y los de las organizaciones que asesoramos— a auditorías periódicas contra un framework propio, informado por los criterios de la certificación oficial de arquitectos de Claude que ofrece Anthropic. En nuestras auditorías, la jerarquía de configuración aparece de forma recurrente como fuente de problemas silenciosos: no porque sea complicada, sino porque es invisible hasta que alguien nuevo se suma al equipo y el comportamiento esperado deja de replicarse.

La pregunta que conviene hacerse

Si tu equipo depende de reglas o convenciones configuradas para que un asistente de IA se comporte de cierta manera, la pregunta que vale la pena hacerse es simple: si mañana se suma alguien nuevo y clona el proyecto desde cero, ¿hereda automáticamente todo lo que el resto del equipo da por sentado? Si la respuesta no es un sí inmediato, hay una regla viviendo en el lugar equivocado.

Inspirado en la serie de BridgeIntoAI sobre la certificación oficial Claude Certified Architect Foundations de Anthropic.