7 hábitos para programar con IA sin perder el control

Las buenas prácticas para programar con IA se resumen en siete hábitos: darle contexto en un archivo de instrucciones, pedir un plan antes del código, trabajar en tareas pequeñas, escribir los tests primero, revisar cada diff, hacer commits pequeños y mantener los secretos fuera de su alcance. Ninguno es nuevo; lo nuevo es que, con un agente que escribe cientos de líneas en un minuto, saltarse uno sale mucho más caro.

Todos los ejemplos valen para cualquier asistente o agente de código (Claude Code, Cursor, Codex, Copilot). Cuando un comando es propio de una herramienta, lo decimos. Si estás empezando, la guía para programar con IA explica antes el ciclo completo.

1. Dale contexto en un archivo de instrucciones (y pódalo)

Cada sesión con un agente empieza casi de cero. Lo que no esté escrito, el agente lo deduce o se lo inventa: qué comando ejecuta los tests, qué librería de fechas usáis, qué carpeta no se toca. El archivo de instrucciones (CLAUDE.md, AGENTS.md o el que use tu herramienta) se lee al principio de cada sesión y evita repetir lo mismo cada día.

Un ejemplo de estructura:

# Tienda (API en Python con FastAPI)

## Comandos
- Tests: `pytest -q` (todos deben pasar antes de terminar)
- Lint y formato: `ruff check . && ruff format .`
- Servidor local: `uvicorn app.main:app --reload`

## Dónde está cada cosa
- Rutas en `app/routes/`, lógica en `app/services/`, modelos en `app/models/`.
- Las decisiones de arquitectura, en `docs/decisiones.md`.

## Convenciones que no se ven en el código
- Los precios se guardan en céntimos (enteros), nunca en float.
- Los errores de negocio lanzan `ErrorDominio`, no `HTTPException`.

## Prohibido
- Añadir dependencias sin preguntar.
- Tocar `migrations/` o leer `.env`.

Lo que conviene incluir y lo que sobra, según la guía de buenas prácticas de Claude Code, que vale para cualquier herramienta:

¿Cuándo añadir una línea? Cuando el agente comete el mismo error por segunda vez, cuando una revisión detecta algo que debería haber sabido o cuando te descubres escribiendo la misma corrección que en la sesión anterior. ¿Cuándo quitarla? Cuando el agente ya lo hace bien sin ella. La documentación de Claude Code recomienda no pasar de 200 líneas: en archivos largos, las reglas importantes se pierden entre el ruido.

Si usas varias herramientas, mantén un solo archivo. AGENTS.md es el formato abierto que leen Codex, Cursor, Copilot y otros; para Claude Code basta un CLAUDE.md con la línea @AGENTS.md, que lo importa.

2. Pide un plan antes que el código

Para cualquier cambio que toque más de un archivo, el primer prompt no pide código: pide un plan.

Quiero que los cupones de descuento caduquen. Lee app/services/cupones.py
y app/models/cupon.py y propón un plan: qué campos añadirías, qué
funciones cambian, qué migración hace falta y qué tests escribirías.
No escribas código todavía.

En Claude Code existe un modo específico para esto (Shift+Tab hasta «plan mode», o /plan) en el que el agente investiga pero no puede editar hasta que apruebas el plan. En las demás herramientas, basta con pedirlo así.

Para trabajos más grandes, invierte los papeles y que te entreviste él. Este prompt está adaptado del que propone Anthropic:

Quiero construir un sistema de cupones con caducidad y límite de usos.
Hazme preguntas detalladas sobre la implementación, los casos raros
y lo que no haya pensado. Sigue preguntando hasta cubrirlo todo y
después escribe la especificación completa en SPEC.md.

Con el SPEC.md escrito, abre una conversación nueva para implementarlo: empiezas con el contexto limpio y una referencia escrita contra la que comprobar.

Y cuándo saltarse el plan: si puedes describir el cambio en una frase («renombra esta variable», «añade un log aquí»), pídelo directamente.

3. Una tarea pequeña por petición, una conversación por tarea

Cuanto más grande es la petición, más decisiones toma el modelo por ti y más difícil es revisar el resultado. Compara tres peticiones vagas con su versión comprobable:

• «Arregla los cupones» se convierte en «Los cupones caducados siguen aplicándose. Mira aplicar_cupon en app/services/cupones.py. Escribe un test que lo reproduzca y arréglalo».
• «Añade tests» se convierte en «Añade tests a calcular_total para carrito vacío, cupón del 100 % y precios con céntimos. Sin mocks».
• «Mejora el rendimiento» se convierte en «El endpoint /pedidos tarda 3 segundos con 1.000 pedidos. Encuentra la consulta lenta y propón un arreglo antes de cambiar nada».

La versión buena siempre dice dónde mirar, qué significa «terminado» y qué no debe hacer.

Si una tarea no cabe en una frase con un criterio de terminado, divídela. Y si no eres capaz de revisar en cinco minutos el cambio que te propone, la tarea era demasiado grande.

La otra mitad del hábito: una conversación por tarea. Mezclar en la misma sesión el arreglo de los cupones, una duda sobre el despliegue y un cambio de estilos llena el contexto de cosas que no vienen a cuento, y el modelo rinde peor cuanto más lleno está. Entre tareas sin relación, conversación nueva (/clear en Claude Code). Y si has corregido al agente dos veces en lo mismo sin éxito, no insistas: conversación nueva con un prompt mejor que incorpore lo que has aprendido.

4. Escribe los tests primero

Un test que falla es la forma más precisa de decirle a una IA qué quieres. Y a un agente le da algo más valioso: la forma de comprobar por sí mismo si lo ha conseguido. El ciclo, con los prompts:

Paso 1, los tests en rojo:

Escribe tests en tests/test_cupones.py para la caducidad de cupones:
un cupón caducado ayer no se aplica, uno que caduca hoy sí, uno sin
fecha de caducidad siempre. No escribas la implementación. Ejecuta
pytest y confirma que los tests nuevos fallan.

Paso 2, revisa tú los tests y guárdalos:

git add tests/test_cupones.py
git commit -m "Tests de caducidad de cupones (fallan a propósito)"

Paso 3, la implementación:

Implementa la caducidad para que pasen los tests de
tests/test_cupones.py. No modifiques los tests. Ejecuta pytest
y enséñame la salida completa.

Paso 4, comprueba que no ha hecho trampa:

git diff --stat -- tests/   # si sale algo, ha tocado los tests
pytest -q

Ese último paso importa. Cuando un agente no consigue que un test pase, a veces «arregla» el test en lugar del código. Con los tests en un commit aparte, cualquier cambio en ellos salta a la vista.

5. Lee cada diff, y que lo revise alguien más

Leer el diff antes de aceptar un cambio es lo que te mantiene como responsable del código. Es también lo primero que se deja de hacer cuando el agente acierta diez veces seguidas. Los comandos:

git diff --stat   # qué archivos ha tocado: ¿todos tienen sentido?
git diff -w       # los cambios, sin el ruido de espacios
git add -p        # aceptar bloque a bloque, no todo de golpe

La lista de lo que más se cuela:

• Archivos que no tenían relación con la tarea.
• Dependencias nuevas que no pediste (en requirements.txt, package.json…).
• Tests modificados o borrados para que todo salga en verde.
• Errores tragados: except: pass, un catch vacío, un # type: ignore.
• Valores escritos a mano que deberían ser configuración: URLs, rutas, claves.
• Código duplicado de algo que ya existía en el proyecto.

Si algo no lo entiendes, pregunta antes de aceptarlo: «¿por qué has añadido este reintento en la línea 42?». Si la respuesta no te convence, no lo aceptes.

Y una segunda revisión con ojos nuevos. El agente que escribió el código tiende a darlo por bueno, así que la revisión funciona mejor en una conversación aparte o con un subagente que solo ve el diff. Anthropic lo llama el patrón escritor y revisor:

Revisa el diff de la rama cupones-caducidad contra SPEC.md.
Comprueba que cada requisito está implementado, que los casos
raros tienen test y que no ha cambiado nada fuera de la tarea.
Informa solo de lo que afecte a la corrección, no de estilo.

Claude Code trae comandos para esto (/code-review y /security-review), y GitHub Copilot hace revisiones de pull requests. Pero ninguna revisión automática sustituye a la tuya en las partes delicadas: autenticación, pagos, permisos y datos personales.

6. Commits pequeños, ramas y nada de --force

Git es tu botón de deshacer. Con un agente que cambia diez archivos en un minuto, es la diferencia entre volver atrás en un segundo y pedirle a la IA que deshaga lo que hizo (y que se equivoque deshaciendo).

El flujo:

git switch -c cupones-caducidad   # una rama por tarea
# ... el agente trabaja, los tests pasan ...
git add -p
git commit -m "Los cupones dejan de aplicarse al caducar"

Commit cada vez que algo funciona, no al final del día. Si el siguiente paso sale mal:

git restore .        # descarta los cambios sin confirmar
git stash            # o apártalos por si acaso
git revert HEAD      # deshace el último commit con otro commit

Tres reglas más. El mensaje de commit explica el porqué, no solo el qué; el agente puede redactarlo, pero tú lo lees. Nunca git push --force sobre ramas compartidas, ni dejes que el agente lo haga. Y si trabajas con varios agentes a la vez, dale a cada uno su copia de trabajo con git worktree add -b cupones-caducidad ../tienda-cupones, para que no se pisen.

7. Secretos y permisos bajo llave

El último hábito es el que evita los disgustos serios. Según el informe de GitGuardian de 2026, en 2025 aparecieron 28,6 millones de secretos nuevos en commits públicos de GitHub, y los commits hechos con ayuda de IA filtran secretos al doble de ritmo que el resto.

Fuera del repositorio. Las claves van en variables de entorno o en un .env que está en .gitignore desde el primer commit. En el repositorio se sube un .env.example con los nombres de las variables y valores vacíos, para que el agente sepa qué existe sin ver los valores:

# .env.example
STRIPE_SECRET_KEY=
DATABASE_URL=

Fuera del alcance del agente. Prohíbele leer esos archivos. En Claude Code, con una regla en .claude/settings.json:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Un escáner antes de cada commit. Gitleaks es gratuito, de código abierto, y se integra con el framework pre-commit. Su README trae la configuración:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Con el framework pre-commit instalado y pre-commit install en el repositorio, cada commit que lleve una clave se bloquea antes de salir de tu ordenador.

Permisos mínimos. Que el agente pueda leer y editar el proyecto es razonable. Que pueda desplegar a producción, tocar la base de datos real o borrar ramas sin preguntar, no. Empieza con el modo más restrictivo de tu herramienta y abre solo lo que necesites. Los modos que se saltan todas las comprobaciones son para contenedores aislados, nunca para tu ordenador. Y ninguna credencial de producción en la máquina donde trabaja el agente.

Si a pesar de todo una clave se escapa, borrarla del código no basta: hay que revocarla. Los pasos están en qué hacer si se filtra una API key.

Por dónde seguir

Estos hábitos se aplican igual con cualquier herramienta. Si aún no has elegido una, la comparativa de Claude Code, Cursor, Codex y Copilot te ayuda a decidir. Si ya usas Claude Code, el tutorial desde cero explica cómo configurar permisos, hooks y subagentes para que varios de estos hábitos se cumplan solos. Y para ver qué pasa cuando se ignoran todos a propósito, lee qué es el vibe coding.