Lo que rellena y marca se queda solo en esta ventana del navegador. No enviamos nada salvo que pida la evaluación por correo. Al cerrar la página desaparece, así que imprima su resultado.
Para CTO y tech leads cuyos desarrolladores ya usan Claude Code, Codex o Cursor, cada uno a su manera. El plan no cambia sus herramientas. Cambia lo que vale para todos: reglas en el repositorio, puertas en la CI, review y medición.
Hoy la IA escribe todo nuestro código y un senior responde del resultado. Desde 2023 hemos entregado más de 15 proyectos en producción. Este plan describe cómo lo tenemos montado nosotros. La base puede tomarla de nuestro repositorio público claude-code-production-starter.
1. Día 0: mida cómo está hoy
Sin cifras de partida no sabrá dentro de un mes si algo ha mejorado. Bastan tres, de los últimos 20 PR fusionados:
- Tiempo desde que se abre un PR hasta que se fusiona. La mediana, no la media.
- Cuántos PR volvieron de la review al menos una vez. Y por qué, en una palabra.
- Cuántos cambios hubo que deshacer después del despliegue. Un revert, un hotfix o una corrección en dos días.
Dónde está hoy su equipo lo sabrá en unos minutos con el test ¿A qué distancia está de un SDLC AI-native?. Los puntos que le falten son su trabajo para las próximas cuatro semanas.
2. El plan de cuatro semanas
Semana 1: reglas en CLAUDE.md y AGENTS.md
El agente lee sus reglas al empezar cada tarea. Si solo están en la cabeza de las personas, cada agente trabaja de una forma. AGENTS.md lo leen Codex, Cursor y otras herramientas, Claude Code lee CLAUDE.md. Lo más sencillo es tener las reglas en AGENTS.md y enlazarlo desde CLAUDE.md.
La plantilla completa de reglas está en la herramienta Reglas para agentes de IA en equipo. Una versión más corta para empezar:
# Reglas para agentes de IA en este repositorio
## Comandos
- Después de cada cambio: pnpm verify (typecheck, lint, tests unitarios)
- Antes del PR: pnpm verify:full
## Está terminado cuando
- pasan los tests, el typecheck, el lint y el build,
- el código cambiado tiene un test cambiado o nuevo,
- la plantilla del PR está rellenada, incluido lo que no se hizo.
## El agente nunca
- se conecta a la base de datos de producción,
- lee archivos .env ni claves,
- despliega ni ejecuta migraciones en producción,
- modifica el test con el que se le evalúa para que pase.Semana 2: puertas de CI y hooks
Una frase en AGENTS.md es una petición. El agente puede saltársela cuando tiene prisa por terminar. Lo importante tiene que imponerlo una configuración, un hook o la CI. En Claude Code eso lo hacen .claude/settings.json (comandos prohibidos y permitidos) y los hooks que se ejecutan antes de un comando o antes de que el agente diga "terminado".
{
"permissions": {
"deny": ["Read(**/.env)", "Bash(git push --force:*)", "Bash(git reset --hard:*)", "Bash(psql:*)"],
"ask": ["Bash(git push:*)", "Bash(gh pr merge:*)"]
},
"hooks": {
"Stop": [{ "hooks": [{ "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/stop-gate.sh" }] }]
}
}Las puertas concretas, con ejemplos, están en la herramienta ¿Cuántas de las 10 puertas frenan el código de IA malo en su CI?.
Semana 3: reglas de review y review agéntica
Cuando el agente escribe más rápido, el cuello de botella pasa a ser la review. Las reglas deben decir qué revisa siempre una persona y qué se deja a la máquina.
Semana 4: medición e implantación en el equipo
Mida las mismas tres cifras que el día 0 y compare. Después convierta el piloto en el estándar de todo el equipo.
3. Dónde va cada regla
Una regla que se ha incumplido dos veces sube un nivel.
| Nivel | Fuerza | Ejemplo |
|---|---|---|
| Frase en AGENTS.md | la más débil | "No ponga datos personales de clientes en un prompt." |
| Configuración o hook | media | Prohibido leer .env, hook de secretos antes del commit |
| CI y rama protegida | fuerte | Los tests en rojo bloquean la fusión |
| Lint o test | la más fuerte | Un test que falla en la rama principal y pasa en la suya |
Más herramientas para usted
12 preguntas sobre reglas para agentes de IA, controles de CI y responsabilidad. Vea dónde está hoy su equipo.
Marque las puertas que tiene y vea cuáles faltan. Cada una con un ejemplo para GitHub Actions.