Por qué los agentes de programación como Claude Code necesitan una capa de gobernanza, y no solo instrucciones mejores.

Las instrucciones más precisas sí generan respuestas mejores. Reducen los malentendidos, clarifican las indicaciones y dan una dirección clara a una sola sesión, lo que por un tiempo parece mejorar todo el modo en que trabajas con la IA. Esa sensación desaparece una vez que los agentes pasan a formar parte del trabajo diario. Dejas de solicitar una única respuesta convincente para una petición aislada y esperas que el agente conozca el proyecto, respete las decisiones ya tomadas, elija el procedimiento adecuado, se mantenga dentro de sus competencias, utilice las herramientas apropiadas y deje evidencias que puedas verificar.

Una instrucción da forma al intercambio que tienes ante ti, pero no puede controlar todo lo que rodea a ese intercambio.

Codex y Claude Code ya incluyen muchas de las herramientas útiles. Lo que falta es un sistema completo y portátil que decida qué reglas son aplicables, qué contexto es relevante, qué puede hacer un agente de programación, cómo se distribuye el trabajo y qué se considera prueba. Alguien tiene que crear esa capa alrededor del entorno de ejecución. Un nombre para ella es núcleo: una capa de gobernanza que uno controla, la cual lleva el trabajo desde la intención humana hasta la prueba. No contiene modelos internos ni ejecuta nada por sí sola.

En concreto, dicho núcleo puede comenzar como un conjunto de archivos Markdown estructurados y portátiles: reglas, protocolos, índices, decisiones aceptadas, estado del proyecto y políticas de memoria. Cuando las instrucciones escritas no son suficientes, las habilidades, scripts, atajos y complementos cubren esa brecha.

El contexto era solo el síntoma

El primer problema visible es la pérdida de contexto. Una sesión nueva a menudo no tiene conocimiento sobre la arquitectura, los cambios recientes ni la lógica detrás de una tarea, por lo que es necesario realizar otra auditoría antes de poder reanudar el trabajo útil. Esa repetición consume tiempo, recursos y paciencia.

Más contexto ayuda, pero deja intactos los problemas más profundos. Un agente aún puede seguir el procedimiento incorrecto, actuar con más autoridad de la debida, incluir material irrelevante o anunciar el éxito sin evidencias.

La solución obvia es incluir las reglas y el contexto faltantes en AGENTS.md, CLAUDE.md o un archivo similar de inicio de sesión. Eso es sensato, pero insuficiente. Dichos archivos realmente mejoran el proceso de adaptación, pero esperar que regulen todo el flujo de trabajo es un error. Un archivo de inicio de sesión puede establecer reglas estables y remitir a fuentes fiables. No puede, por sí solo, mantener el estado del proyecto actualizado, elegir el contexto adecuado para cada tarea, decidir qué puede hacer el agente o verificar el resultado.

Hay un principio que queda en el centro: definir qué significa “terminado” antes de la ejecución y luego exigir pruebas al final.

Eliminar la repetición nunca fue el objetivo principal. La IA había pasado de ser un experimento ocasional a convertirse en una herramienta indispensable en el día a día, y la pregunta interesante era cuánto valor podía extraerse de un entorno creado con un enfoque habitual en el diseño de software. La IA había llegado por varias vías al mismo tiempo: en editores, en Xcode y VS Code, y en agentes como Codex y Claude Code. Cada uno de ellos facilitaba el uso de modelos capaces, pero ese acceso más sencillo no ayudaba en nada a organizar todo lo que ocurría alrededor de dichas llamadas.

En un buen día, un agente puede inspeccionar código, explicar un framework desconocido, proponer una arquitectura o ayudar a lanzar una función, y puede sentirse muy similar a trabajar en pareja con otro desarrollador. Cuanto más dependas de esto, más importancia adquieren las preguntas relacionadas. Cuando dos fuentes discrepan, ¿cuál prevalece? ¿Qué reglas se aplican a esta tarea? ¿Puede el agente tomar la decisión o solo hacer recomendaciones? Si dice que el trabajo está terminado, ¿qué deberías esperar ver?

El contexto responde a la primera parte de esto, ya que proporciona al agente el conocimiento relevante. El resto se refiere a cómo se utiliza ese conocimiento. “Gobernanza” es una palabra adecuada para todo el conjunto: el vínculo práctico entre la intención, el conocimiento confiable, las reglas, la autoridad, la ejecución y la prueba. Se mantiene práctico cuando las partes consecutivas de un flujo de trabajo son lo suficientemente explícitas como para inspeccionarlas, corregirlas y reutilizarlas.

Para un ingeniero a quien le gusta diseñar sistemas cuyas partes cooperan de manera eficiente, dejar que el flujo de trabajo con los agentes sea improvisado parece un desperdicio. Se convierte en algo que hay que diseñar, no en una serie de conversaciones que deben supervisarse cuidadosamente. Hacerlo bien implica observar sus propios hábitos durante mucho tiempo: qué inspecciona antes de abordar un proyecto, qué patrones reutiliza, cuándo ralentiza su trabajo y qué verificaciones realmente le convencen de que una tarea está completada. El objetivo es transformar esos hábitos tácitos en comportamientos que un agente pueda seguir y que una persona pueda auditar.

Qué puede y qué no puede hacer un bootstrap

Un desarrollador que se une a un proyecto ya establecido necesita algo más que talento. Debe aprender cómo está organizado el código, qué decisiones se han tomado, qué ha cambiado recientemente y dónde se encuentran los límites. Sin eso, incluso un empleado excelente pasa días redescubriendo el entorno.

Las sesiones de los agentes padecen una forma comprimida del mismo problema. Se explica la arquitectura, los objetivos, el estado actual y las restricciones; el agente realiza un buen trabajo, pero en la sesión siguiente es necesario reconstruir gran parte de esa información.

Al colocar ese material en un archivo AGENTS.md o CLAUDE.md, el proceso de incorporación resulta mucho más económico. La palabra “bootstrap” sirve como marcador y no constituye una queja: un buen documento establece el contrato operativo mínimo y indica al agente dónde se encuentra la información fiable. Codex organiza archivos AGENTS.md en capas, limitando su tamaño total, mientras que Claude Code propone instrucciones breves para los proyectos, sacando los procedimientos poco necesarios a categorías de habilidades. Ambos temas se tratan en la documentación de los proveedores: la guía de memoria de Claude Code y la guía AGENTS.md de Codex. Una habilidad encapsula un procedimiento reutilizable para que pueda aplicarse en diferentes proyectos, y los “hooks” permiten forzar un comportamiento específico cada vez. Aun así, algún otro elemento debe decidir cuándo se aplica cada mecanismo y cómo se verifica su resultado.

Los problemas comienzan cuando se espera que un solo archivo contenga todo el espacio de trabajo. No puede ser breve y al mismo tiempo incluir cada decisión arquitectónica, el plan actual, informes anteriores, protocolos y detalles de las tareas. Además, si la ventana de contexto pudiera abarcar todo, llenarla con información en cada sesión conllevaría su propio fracaso: las instrucciones importantes competirían con texto obsoleto o irrelevante. Corregir un error requiere un contexto diferente al de revisar una arquitectura. El lanzamiento del producto sigue un proceso distinto al de una llamada inicial, y una pregunta rápida no debería generar los costos de coordinación necesarios para una función compleja.

Por lo tanto, un bootstrap debe ofrecer una vía de acceso al sistema y no intentar ser el sistema en sí.

De bootstrap a mapa

En este diseño, el sistema bootstrap alberga un pequeño contrato operativo y luego apunta a fuentes separadas a medida que estas se vuelven relevantes. Las decisiones aceptadas permanecen en el proyecto. Los protocolos describen tipos de trabajo recurrentes, las habilidades incluyen procedimientos reutilizables, los atajos comprimen solicitudes frecuentes y los planes actuales conservan la información que otra sesión podría necesitar.

Nada de inteligencia se oculta dentro del kernel. Su valor proviene de la forma en que los archivos se separan, vinculan, seleccionan y mantienen a lo largo de las sesiones y los tiempos de ejecución.

Esta separación también protege el significado. Una decisión aceptada determina cómo evoluciona un proyecto, un informe de estado describe un momento específico y un resultado de prueba registra pruebas concretas. Si se mezclan los tres en una memoria sin diferenciar, una observación antigua comienza a parecerse a una instrucción actual.

A medida que la configuración se perfecciona, abarca la política de memoria, la complejidad de las tareas, la cantidad de esfuerzo de razonamiento necesario y qué modelo utilizar, los atajos, la continuidad entre sesiones, así como la validación y coordinación entre varios agentes. Un inventario completo ocultaría la arquitectura. Lo importante es que el agente pueda descubrirlos gradualmente, según lo exijan las tareas. Detrás de este esquema hay cuatro responsabilidades, que no describen cada mecanismo pero sí explican por qué pertenecen entre sí.

Algunos conocimientos deben sobrevivir al chat

El chat funciona mientras la tarea está en curso, pero no debería ser el registro oficial de una decisión del proyecto. La arquitectura aceptada, las restricciones y las elecciones de codificación deben encontrarse en fuentes controladas a las que cualquier sesión posterior pueda acceder, y los planes en desarrollo necesitan tener su propio estado reanudable. Mantener una verdad duradera no es lo mismo que archivar cada conversación, ya que la mayor parte de ella son elementos temporales. En su lugar, pregúntese qué debería seguir considerándose autoritativo una vez finalizada la sesión.

Cargar solo lo que necesita la tarea

Un agente necesita lo suficiente para comprender su tarea, no todo lo que el sistema ha almacenado jamás. Un pequeño cambio en el código puede requerir las reglas del proyecto y unos pocos archivos. Una función compleja también puede necesitar la intención del producto, decisiones arquitectónicas, aportes de especialistas y un plan de validación. El objetivo es contar con el contexto mínimo necesario, no con el máximo disponible. La continuidad implica poder encontrar el material adecuado en el momento adecuado, y no tener que llevar toda la historia histórica en cada tarea.

Encontrar algo no es un permiso

Encontrar un archivo, un mensaje o una recomendación no autoriza a actuar sobre él. El sistema debe separar la información de la autoridad, sobre todo en lo que respecta a acciones destructivas, validación final, publicación y cualquier cosa que afecte al mundo fuera del espacio de trabajo. Esta capa es menos visible que la inteligencia del modelo, pero resulta crucial siempre que un error cometido con confianza cuesta más que detenerse para tomar una decisión.

La finalización requiere prueba

El dominio del idioma no implica corrección, y lo plausible no significa que algo esté terminado. Por lo tanto, el núcleo del sistema pregunta qué debe verificarse, qué pruebas deben conservarse y dónde se debe anotar el estado confirmado. Si un agente edita código y informa que “está listo”, solo has recibido una afirmación y nada más. La verificación puede consistir en pruebas positivas, una compilación exitosa, el comportamiento observado en la aplicación en ejecución y el estado registrado. Otros campos requieren pruebas diferentes, pero la regla es la misma: el final de la conversación no significa que el trabajo haya concluido.

Una organización como analogía

Imagínese una empresa con un edificio, computadoras y equipos excelentes, pero sin un método de trabajo compartido. Tiene capacidad, pero no es coherente. La gente sigue necesitando conocimientos comunes, procedimientos, derechos de decisión, responsabilidades claras y controles de calidad. La comparación es aproximada, porque un agente no es un empleado y un entorno de ejecución hace más que colocar a las personas en escritorios. Sin embargo, muestra cómo se relacionan las partes: los agentes desempeñan roles definidos, las herramientas son los equipos y el entorno de ejecución es el lugar donde se llevan a cabo las tareas. El núcleo es la capa compartida de reglas, conocimientos, métodos y controles que permite su cooperación. Los modelos mejores no generan automáticamente un sistema mejor.

Dónde se encuentra la capa

El kernel no compite con Codex, Claude Code, Gemini ni con cualquier otro entorno de ejecución que surja en el futuro. Estos últimos proporcionan el entorno en tiempo real: modelos, herramientas, sesiones, configuraciones de razonamiento y un conjunto cada vez mayor de sus propios subagentes, complementos y habilidades. La capa de gobernanza funciona alrededor de ese entorno y resuelve tres cuestiones: qué debe persistir, qué puede hacer el agente y qué evidencia se considera válida como cumplimiento.

Cada vez que un entorno en tiempo de ejecución incluye una función similar a alguna ya desarrollada manualmente, la división del trabajo se vuelve más valiosa. Reconstruir cada capacidad del entorno en tiempo de ejecución consumiría tiempo que sería mejor emplear en los proyectos a los que sirven los agentes. Permitir que los entornos en tiempo de ejecución se encarguen de la ejecución mientras la capa de gobernanza permanece portátil es el enfoque más sostenible. Los proveedores difieren en modelos, herramientas, interfaces y estilo de salida, y la portabilidad mantiene tus reglas independientes de cualquiera de ellos sin pretender que esas diferencias hayan desaparecido.

La gobernanza no garantiza certeza

Escribir una regla no asegura que un agente la lea, la entienda o la aplique en el momento adecuado. Un punto de inicio puede indicar el protocolo correcto y aún así ser ignorado. Una decisión canónica puede conservarse perfectamente mientras su contenido se vuelve obsoleto sin que se note. Un mecanismo de enlace puede hacer cumplir una regla fielmente mucho después de que esta haya dejado de ser útil.

La experiencia demuestra que esto ocurre rápidamente. Las reglas añadidas para los árboles de trabajo y los ganchos comienzan a superponerse, chocar y bloquear las tareas que se suponía debían proteger, por lo que es necesario simplificarlas y corregirlas. La gobernanza requiere mantenimiento, y los costos no se detienen allí: las interfaces e índices consumen tiempo y tokens y aún pueden no reflejar el estado más reciente; los agentes ignoran las instrucciones a medida que el sistema crece, y es difícil reconstruir la confianza cuando un flujo de trabajo declara éxito sin la prueba esperada.

Un sistema como este nunca está completo ni es universal. Se trata de una configuración personal que se prueba, daña y corrige a lo largo de meses. Mejora tu capacidad para observar y ajustar el comportamiento de los agentes, pero ninguna regla, protocolo, atajo o mecanismo de memoria se sigue a la perfección. La gobernanza puede facilitar la inspección y corrección del comportamiento, pero no puede convertir a un agente probabilístico en uno determinista.

Tres preguntas que hacer primero

La pérdida de contexto es lo que lleva a las personas por este camino. Lo que las mantiene allí es una pregunta de ingeniería más importante: ¿cómo debe diseñarse el enfoque para un modelo capaz, prestando la misma atención a cualquier otra arquitectura importante?

Entonces, ¿se puede demostrar que el trabajo está terminado? Solo cuando “terminado” se haya definido antes de la ejecución y el resultado presente pruebas que se ajusten a la tarea. Sin eso, lo que se tiene es una afirmación, y una afirmación no es prueba.

No se necesita un sistema como este para empezar a pensar de esta manera. Antes de agregar otro prompt o archivo, pregúntese:

1. ¿Qué fuentes tienen permiso para definir qué es cierto?
2. ¿Qué decisiones y acciones requieren autoridad humana?
3. ¿Qué pruebas demostrarán que el trabajo está terminado?

Esas preguntas convierten las distintas funciones de la IA en partes de un flujo de trabajo fiable, en lugar de capacidades que simplemente coexisten. No toda solicitud menor debería arrastrar al sistema entero. Los controles deben escalar según las consecuencias: ser flexibles cuando el riesgo es bajo y más estrictos cuando un error tendría costos elevados. Los modelos proporcionan la capacidad, y el camino regulado desde la intención hasta la prueba es lo que se construye alrededor de ellos.