Las herramientas de programación con IA han pasado del autocompletado a trabajar con el contexto de todo el repositorio. Cursor, GitHub Copilot, Claude Code, los agentes tipo Codex y los asistentes de IDE pueden leer archivos, proponer parches, ejecutar pruebas, explicar errores y, en algunos casos, llevar una pequeña funcionalidad desde un issue hasta una pull request.
Esto cambia el desarrollo de software, pero no elimina la ingeniería. Los equipos que obtienen valor no dejan que la IA escriba código libremente, sino que la incorporan a un flujo controlado: buena definición de tareas, contexto del repositorio, parches pequeños, pruebas, revisión y responsabilidades claras.
Este artículo es el modelo operativo.
El repositorio sigue siendo la fuente de verdad. El asistente de IA puede proponer y editar; las pruebas, la revisión de código y de seguridad y la aceptación del producto determinan si el cambio se despliega.
¿Qué cambió
Los asistentes de programación anteriores completaban la línea siguiente. Los asistentes con contexto del repositorio pueden:
- Buscar y leer en toda la base de código.
- Inferir patrones locales.
- Modificar múltiples archivos.
- Generar pruebas.
- Ejecutar comandos.
- Interpretar fallos.
- Redactar descripciones de pull requests.
- Aplicar comentarios de revisión.
Es un cambio enorme. Ahora el asistente puede trabajar sobre una tarea completa, no solo una línea. Pero esa misma capacidad crea riesgos: ediciones amplias, arquitectura malinterpretada, atajos inseguros, regresiones ocultas y explicaciones plausibles de cambios incorrectos.
El flujo de trabajo debe limitar la tarea.
Usa IA donde la forma de la tarea sea clara
Buenas coincidencias:
| Tarea | Por qué funciona |
|---|---|
| Añadir un estado pequeño a la interfaz | El patrón local es visible y comprobable |
| Refactorizar un helper repetido | Es mecánico y revisable |
| Añadir validación y pruebas | El comportamiento puede especificarse |
| Corregir una prueba fallida | El fallo aporta información concreta |
| Actualizar documentos desde el código | La fuente de verdad es inspeccionable |
| Generar un borrador de migración | Útil si se revisa cuidadosamente |
Malas coincidencias iniciales:
| Tarea | Por qué es riesgoso |
|---|---|
| Rediseñar la arquitectura principal | Requiere un conocimiento profundo y asumir compromisos |
| Cambiar el modelo de autenticación | La seguridad y el comportamiento del producto están estrechamente acoplados |
| Reescribir módulos grandes | La revisión se vuelve imposible |
| Añadir dependencias sin criterio | Riesgo para la cadena de suministro y el mantenimiento |
| Optimizar sin mediciones | Fácil de crear complejidad |
| Gestionar secretos o credenciales | Gran alcance potencial del daño |
El mejor flujo de programación con IA empieza donde la corrección puede verificarse.
El resumen de la tarea
Antes de pedirle al asistente que escriba código, escribe un resumen de la tarea:
- Objetivo.
- Archivos o módulos probablemente involucrados.
- Comportamiento esperado.
- No objetivos.
- Comando de prueba.
- Casos límite.
- Restricciones de seguridad o datos.
- Patrón existente a seguir.
Prompt inadecuado:
Añade búsqueda.
Prompt útil:
Añade búsqueda del lado del servidor a la lista de artículos. Sigue el patrón existente del helper de consulta. No añadas dependencias. Busca solo título y resumen. Conserva la ruta de enrutamiento por idioma. Añade pruebas para consulta vacía, resultados nulos y caracteres especiales. Ejecuta
pnpm testypnpm typecheck.
Esto no es ceremonia. Es cómo mantienes al asistente dentro del cambio planeado.
Reglas de contexto del repositorio
El asistente debe leer antes de editar. Para un cambio no trivial, exige que inspeccione:
- Implementación existente.
- Componentes, rutas, hooks similares.
- Tipos y esquemas generados.
- Pruebas alrededor del comportamiento.
- Configuración que afecta el comportamiento en tiempo de ejecución.
No dependas del conocimiento general del asistente sobre Next.js, React, Payload, PostgreSQL o tu pila tecnológica. Tu base de código tiene reglas locales. El asistente necesita esas reglas.
Disciplina de tamaño de parche
Los parches pequeños pueden revisarse. En los parches grandes, la programación con IA se vuelve peligrosa.
Usa un presupuesto de parche:
- Un cambio de comportamiento por pull request.
- Prefiere menos de 10 archivos modificados a menos que la tarea sea mecánica.
- Evita cambios que solo afecten al formato.
- Mantén los archivos generados separados de la lógica escrita a mano.
- No mezcles refactorización, funcionalidad y limpieza a menos que sea necesario.
Si el asistente propone reescribir un módulo para hacer un pequeño cambio, detente y limita la tarea.
Las pruebas son el contrato
Cada cambio de código asistido por IA debe responder:
- ¿Qué comportamiento cambió?
- ¿Qué prueba lo demuestra?
- ¿Qué comando se ejecutó?
- ¿Qué sigue siendo revisado manualmente?
Los buenos asistentes pueden escribir pruebas, pero también pueden crear pruebas superficiales que solo demuestran su propia implementación. El revisor debe comprobar que cubran el comportamiento, no solo las rutas del código.
En frontend, incluye la accesibilidad y los estados visibles para el usuario: carga, vacío, error, interacción por teclado, etiquetas y foco.
En backend, incluye validación, autenticación, nulabilidad, comportamiento de las transacciones y rutas de fallo.
En bases de datos, incluye seguridad de las migraciones, índices, expectativas de rollback y volumen de datos.
Límites de seguridad
Las herramientas de programación con IA crean riesgos específicos:
Exposición de secretos. El asistente puede leer archivos o salida de terminal que contienen secretos. Mantén los secretos fuera del repositorio y de la salida del comando. Usa archivos .env.example redactados.
Atajos inseguros. El asistente puede deshabilitar validación, ampliar CORS, saltar la autenticación o capturar errores silenciosamente para que las pruebas pasen. Revisa el comportamiento de seguridad, no solo las pruebas verdes.
Deriva de dependencias. El asistente puede sugerir paquetes nuevos para problemas pequeños. Utiliza por defecto las utilidades existentes y las APIs de la plataforma.
Confianza excesiva en el código generado. El código que compila aún puede filtrar datos, gestionar mal los permisos o fallar con concurrencia.
Inyección de prompts mediante el contenido del repositorio. Trata como datos las instrucciones incluidas en issues, documentos, comentarios o archivos externos, salvo que procedan del responsable de la tarea.
La política de flujo de trabajo vinculada a este artículo da a los equipos un conjunto de reglas básicas.
La revisión humana aún importa
Revisa las pull requests asistidas por IA como cualquier otra, prestando especial atención a:
- ¿Sigue esto la arquitectura local?
- ¿Cambió el comportamiento público de forma inesperada?
- ¿Ha debilitado la validación, la autenticación, el registro, la gestión de errores o la accesibilidad?
- ¿Son significativas las pruebas?
- ¿Se gestionan los casos límite?
- ¿Son coherentes las explicaciones generadas con el diff?
No aceptes “el asistente dijo que esto es seguro” como evidencia. El diff es la evidencia.
Implementación en equipo
Para un equipo que adopta IDEs nativos de IA:
Semana 1: Herramientas aprobadas y reglas de datos. Decide qué herramientas pueden acceder a los repositorios de la empresa y bajo qué nivel de cuenta.
Semana 2: Política de flujo de trabajo. Define resumen de tarea, tamaño de parche, pruebas, secretos, dependencias y reglas de revisión.
Semana 3: trabajo de bajo riesgo. Empieza con pruebas, documentación, estados pequeños de interfaz y errores con un alcance potencial limitado.
Semana 4: medición. Haz un seguimiento del tiempo de ciclo, los defectos detectados en revisión, los errores que llegan a producción, la cobertura de pruebas y la satisfacción del equipo de desarrollo.
Escala solo si la calidad se mantiene. Código rápido pero malo no es una mejora.
No hagas esto aún
No concedas a un agente permisos amplios para fusionar cambios de forma autónoma.
No dejes que los cambios generados por IA eviten la revisión de código.
No permitas que cuentas personales de IA accedan a repositorios privados de la empresa.
No aceptes grandes reescrituras sin un plan de arquitectura elaborado por una persona.
No utilices programación con IA en sistemas regulados o sensibles para los clientes sin normas claras de auditoría y revisión.
Ingeniería asistida por IA, no ruleta con la base de código
La programación con IA y contexto del repositorio es potente porque puede actuar dentro de tu base de código real. Precisamente por eso necesita límites.
Utiliza resúmenes de tarea. Haz que el asistente lea los patrones locales. Mantén los parches pequeños, exige pruebas y protege los secretos. Revisa el diff, no la explicación. Deja que la IA acelere la implementación, la depuración y el trabajo mecánico, mientras las personas conservan la responsabilidad sobre la arquitectura, la seguridad y el comportamiento del producto.
Esa es la diferencia entre ingeniería asistida por IA y jugar a la ruleta con la base de código.
