¿Qué son los estándares de desarrollo con IA?

Casi todos los equipos tenían estándares de código mucho antes de la IA: una guía de estilo, la configuración del linter, una página de la wiki sobre cómo nombrar las migraciones de base de datos. La gente los leía una vez, si acaso. Los agentes de programación leen sus instrucciones en cada petición, y eso cambia para qué sirve un estándar. El archivo que lee el agente decide si usa pnpm o npm, si toca el código generado y si corre las pruebas antes de decir que terminó.

¿En qué se diferencian los estándares de desarrollo con IA de los estándares de código?

Los estándares de desarrollo con IA se escriben para un lector que los sigue al pie de la letra y los olvida entre sesiones. Una persona aprende “preferimos funciones pequeñas” a lo largo de meses de revisiones de código. Un agente recibe exactamente las palabras que hay en su contexto, cada vez, y nada más. Por eso el estándar tiene que ser explícito, corto y verificable.

Además cubren más que el estilo del código. Un agente actúa: ejecuta comandos, llama herramientas, lee sistemas internos. Un estándar completo dice qué herramientas puede usar, qué procedimientos debe seguir para el trabajo recurrente y qué acciones se detienen de forma automática. Eso se parece más al trabajo de un equipo de plataforma que a una guía de estilo.

¿Qué incluye un estándar de desarrollo con IA?

Un estándar de desarrollo con IA tiene cinco partes, y cada una corresponde a un tipo de archivo que las herramientas de programación ya leen.

Parte	Qué decide	Dónde vive hoy	Tipo de Artifact en HubBound
Reglas	Convenciones que el agente siempre debe seguir	AGENTS.md, CLAUDE.md, .cursor/rules, .github/copilot-instructions.md	Regla
Procedimientos	Trabajo repetible que el agente ejecuta por nombre	Una carpeta con SKILL.md (formato Agent Skills)	Skill
Herramientas y datos	A qué sistemas llega el agente, y cómo	Configuración de servidores MCP	Servidor MCP
Delegación	Especialistas para tareas acotadas (revisión, pruebas, migraciones)	Definiciones de subagentes	Subagente
Cumplimiento	Controles que corren antes o después de que el agente actúe	Configuración de hooks	Hook

La fila de reglas es donde la mayoría de los equipos empieza y se queda. Las otras cuatro son las que convierten un consejo en un estándar. Una regla que dice “nunca subas secretos” es una petición. Un hook que revisa el diff antes del commit y lo bloquea es un control.

¿Qué formatos abiertos existen para los estándares de desarrollo con IA?

Tres formatos abiertos cubren casi todo lo que un equipo pone por escrito, y adoptarlos mantiene el estándar portable entre herramientas.

AGENTS.md es un archivo Markdown en la raíz del repositorio que sus mantenedores describen como “un README para agentes”. Nació de una colaboración entre OpenAI Codex, Amp, Jules de Google, Cursor y Factory, hoy lo custodia la Agentic AI Foundation dentro de la Linux Foundation, y su sitio reporta más de 60.000 proyectos de código abierto que lo usan.

Agent Skills es el formato SKILL.md, desarrollado originalmente por Anthropic y publicado como estándar abierto. Una skill es una carpeta con un archivo SKILL.md (un nombre, una descripción e instrucciones) más scripts y referencias opcionales. Los agentes cargan solo el nombre y la descripción al iniciar y leen el resto cuando una tarea coincide, así que un equipo puede tener muchas skills sin llenar la ventana de contexto.

El Model Context Protocol es el estándar abierto, presentado por Anthropic en 2024, para conectar un agente con herramientas y datos mediante servidores MCP. Un estándar de equipo que nombra los servidores MCP aprobados es la forma de que el agente de cada desarrollador llegue al mismo gestor de incidencias de la misma manera.

Los formatos no lo cubren todo. Los hooks, los subagentes y los archivos de reglas propios de cada herramienta siguen siendo distintos entre herramientas, y por eso un equipo que usa dos o tres agentes termina manteniendo varias copias de la misma intención.

¿Cómo se ve una buena regla?

Una buena regla nombra una acción concreta y se puede verificar leyendo el diff. Una regla débil describe un valor.

## Débil
- Escribe código limpio y mantenible.
- Sigue buenas prácticas de pruebas.

## Fuerte
- Usa pnpm. Nunca ejecutes npm ni yarn en este repositorio.
- Antes de decir que una tarea está lista, ejecuta `pnpm test --filter <paquete>` en cada paquete que cambiaste.
- Nunca edites archivos dentro de `src/generated/`. Los regenera `pnpm codegen`.
- Las rutas nuevas de la API van en `src/routes/` y necesitan una entrada en `docs/api.md`.

Cada línea fuerte podría fallar en una revisión de código con un motivo claro. Ninguna línea débil podría. Con los agentes pasa lo mismo: una regla que pueden comprobar contra el repositorio se cumple mucho más que una que les pide criterio.

¿Cómo evita un equipo que sus estándares de desarrollo con IA se desvíen?

Un equipo evita la desviación de configuración teniendo una sola fuente para cada estándar y una forma de llevarla a cada máquina. La desviación empieza el día en que alguien copia un archivo de reglas. Alguien corrige una línea en su máquina, nunca la devuelve, y seis meses después el equipo tiene seis versiones de “el” estándar.

Tres cosas lo detienen. El versionado, para que cada cambio genere una versión nueva y cualquiera pueda decir cuál usa. La distribución, para que la versión vigente llegue a los desarrolladores sin que nadie copie archivos. Y la fijación de versiones, para que un equipo se quede en una versión conocida mientras un cambio se prueba en otro lado.

Ese es el problema alrededor del que está construido HubBound. Cada parte de un estándar es un Artifact (una regla, una skill, un servidor MCP, un subagente o un hook) con su propio historial de versiones. Los Artifacts se agrupan en un Kit, y un admin distribuye el Kit a un equipo o a toda la organización como Obligatorio u Opcional, con Siempre la última o fijado a una versión. El Runtime de HubBound instala los Kits obligatorios en cada máquina en su siguiente sincronización en segundo plano, en Claude Code, Cursor, OpenAI Codex, GitHub Copilot y Antigravity.

¿Cuándo no son la herramienta correcta?

Un estándar no garantiza un comportamiento. Los agentes pueden ignorar instrucciones, y lo hacen, sobre todo cuando son largas. Si un resultado importa de verdad (nada de secretos en los commits, nada de escrituras en producción), hazlo cumplir con un hook o con el pipeline de CI, y deja la regla como documentación del porqué.

Más reglas no es mejor. Cada regla compite por la atención del agente con la tarea real. Un archivo de reglas de 2.000 líneas es para un agente lo que una política de 2.000 líneas es para alguien nuevo en el equipo: las líneas importantes se pierden. Poda tan seguido como agregas.

Y una preferencia personal no es un estándar. Cómo le gusta a una persona que su agente redacte los mensajes de commit pertenece a su propia configuración, no al archivo que recibe todo el equipo.

¿Por dónde debería empezar un equipo?

Empieza por los comentarios de tus revisiones de código, no por un documento en blanco. Cada comentario que alguien deja más de dos veces sobre código escrito por IA (“ya no usamos esa librería”, “las pruebas van junto al archivo”, “no toques el cliente generado”) es una regla esperando a escribirse. Esas reglas son concretas por naturaleza, el equipo ya está de acuerdo con ellas y puedes ver si funcionan: el comentario deja de aparecer.

El AI Capabilities Model de DORA pone una “postura clara y comunicada sobre la IA” como la primera de sus siete capacidades. Un conjunto corto y versionado de reglas que salió de revisiones reales es la versión más concreta de esa postura que puede tener un equipo. El glosario define cada una de las cinco partes, y Artifacts y Kits muestra cómo se versiona cada una en HubBound.