Desarrollo de software con IA: qué delegar a un asistente y qué debe seguir revisando una persona
- dmoreno
- agosto 17, 2026
- Desarrollo de software
- agentes, desarrollo, ia, software
- 0 Comments
Los asistentes de programación han cambiado de escala. Ya no se limitan a completar una línea de código: los agentes actuales pueden explorar un repositorio, modificar varios archivos, ejecutar pruebas y preparar cambios para revisión. OpenAI describe flujos donde Codex trabaja sobre tareas de ingeniería y propone pull requests; GitHub ofrece agentes capaces de investigar el repositorio, planificar una implementación y efectuar cambios en una rama.
La pregunta, por tanto, ya no es si una IA puede escribir código. La pregunta útil para un equipo técnico es otra: ¿qué trabajo podemos delegarle con suficiente autonomía y qué decisiones deben continuar bajo responsabilidad humana?
La respuesta no depende únicamente de la capacidad del modelo. Depende también del impacto del cambio, de lo fácil que sea detectarlo y revertirlo, de los permisos concedidos al agente y de la calidad de los controles que rodean al proceso.
Delegar implementación no significa delegar responsabilidad
Un asistente puede producir código correcto a primera vista y, aun así, introducir un problema de seguridad, mantenibilidad o diseño. GitHub advierte expresamente que el código generado por sus agentes puede ser sintácticamente correcto sin ser necesariamente seguro y recomienda aplicar prácticas rigurosas de revisión, pruebas y análisis de vulnerabilidades. Sus buenas prácticas también aconsejan evaluar funcionalidad, seguridad, legibilidad y mantenibilidad antes de aceptar una sugerencia.
Eso establece una distinción importante.
La IA puede encargarse de generar una implementación. El equipo continúa siendo responsable de decidir si esa implementación debe llegar a producción.
Esa separación permite utilizar los agentes con mucha más intensidad sin convertirlos en una fuente de cambios sin control.
Qué tareas son buenas candidatas para delegar
Las mejores tareas para un asistente de código suelen compartir tres propiedades: tienen un alcance claro, poseen criterios objetivos de validación y son relativamente fáciles de revertir.
1. Boilerplate y código repetitivo
Crear estructuras iniciales, modelos, DTO, adaptadores, serializadores o código semejante es un buen uso de la IA cuando las convenciones del proyecto están bien documentadas.
El valor aquí no está en que la IA tome decisiones arquitectónicas, sino en eliminar trabajo mecánico.
2. Tests a partir de comportamiento conocido
Un asistente puede resultar especialmente útil proponiendo casos de prueba, ampliando cobertura o convirtiendo requisitos concretos en tests.
Eso sí: generar el test y validar que el test representa correctamente la regla de negocio son dos problemas diferentes. Un conjunto de pruebas generado automáticamente puede reproducir una interpretación equivocada del requisito.
3. Documentación técnica
Explicar una función, resumir un módulo, documentar una API o preparar notas sobre un cambio son tareas de bajo riesgo siempre que una persona compruebe que la explicación coincide con el comportamiento real.
4. Refactorizaciones acotadas
Renombrados, extracción de funciones, eliminación de duplicación o modernización de patrones conocidos pueden delegarse con bastante comodidad cuando existe una buena batería de tests.
El criterio importante es mantener el cambio pequeño. Cuanto mayor sea el radio de impacto, menos conveniente resulta aceptar automáticamente la propuesta del agente.
5. Investigación dentro del código
Los agentes también son útiles para localizar dónde se implementa determinada lógica, seguir dependencias o identificar posibles puntos de modificación. De hecho, buena parte de su valor actual está en reducir el coste de comprender un código base antes de tocarlo.
Qué debería conservar una revisión humana explícita
Hay categorías de cambios donde la IA puede ayudar a analizar alternativas o preparar una primera implementación, pero no debería convertirse en la autoridad final.
Arquitectura
Elegir límites entre servicios, introducir una nueva dependencia estructural, decidir cómo dividir responsabilidades o establecer una estrategia de datos son decisiones cuyo coste aparece durante meses o años.
Un agente puede proponer opciones. El equipo debe evaluar las consecuencias.
La arquitectura contiene contexto organizativo que rara vez está completamente expresado en el repositorio: experiencia del equipo, planes del producto, costes operativos, sistemas heredados, obligaciones contractuales y evolución prevista.
Autenticación, autorización y secretos
Los cambios en permisos son especialmente sensibles porque un error puede funcionar correctamente desde el punto de vista funcional y seguir creando una vulnerabilidad.
En este ámbito conviene mantener revisión humana explícita y aplicar el principio de mínimo privilegio también al propio agente. Anthropic, por ejemplo, documenta un modelo de permisos restrictivos por defecto para Claude Code antes de ejecutar acciones adicionales.
Datos sensibles
Cambios relacionados con información personal, credenciales, información financiera o datos regulados requieren saber no solo si el código funciona, sino también qué datos atraviesan cada sistema, dónde se almacenan y quién puede acceder a ellos.
Ese contexto no debería darse por supuesto.
Migraciones difíciles de revertir
Modificar un esquema de producción, transformar grandes cantidades de información o eliminar datos merece un nivel de supervisión mayor que añadir una función aislada.
Una regla práctica funciona bien:
cuanto más difícil sea revertir un cambio, menos autonomía debería tener el agente.
Reglas críticas de negocio
Un descuento, un límite de crédito, una condición fiscal, el cálculo de una factura o la elegibilidad de un usuario pueden parecer simples funciones.
Pero el peligro no está necesariamente en escribir mal el código. Está en implementar perfectamente una interpretación incorrecta del negocio.
La nueva superficie de riesgo: agentes con herramientas
Existe además una diferencia fundamental entre un chatbot que sugiere código y un agente autorizado para ejecutar acciones.
Cuando el asistente puede leer archivos, ejecutar comandos, acceder a servicios o interactuar con herramientas externas, una instrucción equivocada deja de producir únicamente una respuesta incorrecta: puede provocar una acción.
OWASP ha destacado entre los riesgos de los sistemas agénticos el abuso de herramientas y privilegios. También documenta el riesgo de prompt injection indirecta, donde instrucciones maliciosas pueden esconderse en contenidos que el agente procesa, incluyendo comentarios de código, documentación, mensajes de commits, issues o páginas web.
Esto cambia el modelo de seguridad.
No basta con preguntarse: «¿Confío en la respuesta del modelo?».
También hay que preguntar:
- ¿A qué puede acceder?
- ¿Qué comandos puede ejecutar?
- ¿Qué credenciales tiene disponibles?
- ¿Puede escribir directamente sobre recursos sensibles?
- ¿Existe una aprobación antes de una acción irreversible?
El diseño seguro consiste en limitar las consecuencias posibles de un error, no en asumir que el modelo nunca cometerá uno.
Un flujo práctico para trabajar con agentes
Una organización no necesita elegir entre prohibir la IA o darle acceso ilimitado. Existe una opción mucho más productiva: diseñar distintos niveles de autonomía.
Un flujo razonable puede funcionar así:
1. Definir una tarea acotada.
Cuanto mejores sean los criterios de aceptación, menos espacio queda para una interpretación inesperada.
2. Permitir que el agente investigue y proponga un plan.
Antes de generar grandes cambios conviene comprobar si ha entendido correctamente el problema.
3. Ejecutar en un entorno controlado.
Permisos mínimos, credenciales limitadas y aislamiento reducen el impacto de una acción incorrecta.
4. Exigir tests automáticos.
El agente debería demostrar el comportamiento de su implementación, no limitarse a producir código.
5. Revisar el diff.
La revisión debe centrarse especialmente en los límites de confianza: autenticación, permisos, entrada de usuario, datos, dependencias y efectos laterales.
6. Utilizar herramientas automáticas adicionales.
Linters, análisis estático, escáneres de dependencias y pruebas de seguridad siguen siendo relevantes aunque el código haya sido generado o revisado por IA.
7. Mantener aprobación humana antes del merge en cambios de riesgo relevante.
Los propios flujos modernos de desarrollo con agentes mantienen esa idea de revisión e iteración. OpenAI ha descrito procesos internos donde los agentes revisan cambios, reciben feedback y vuelven a iterar antes de completar un PR.
Una matriz sencilla: impacto y reversibilidad
No todas las empresas necesitan una política compleja para empezar. Dos preguntas proporcionan un criterio sorprendentemente útil:
¿Qué impacto tendría un error?
¿Qué tan fácil sería revertirlo?
Un cambio de bajo impacto y fácilmente reversible puede concederse al agente con bastante autonomía.
Un cambio de alto impacto y difícil reversión debería exigir planificación, revisión humana y controles adicionales.
Entre ambos extremos existen diferentes niveles de supervisión.
Esta matriz evita una política demasiado simplista de «código humano» frente a «código de IA». Lo importante no es quién escribió cada carácter, sino qué riesgo introduce el cambio y qué evidencias tenemos de que es correcto.
La habilidad que cambia: revisar sistemas, no solo escribir código
A medida que aumenta la capacidad de los agentes, parte del trabajo del desarrollador pasa de producir cada línea manualmente a definir restricciones, proporcionar contexto, revisar propuestas y validar resultados.
Eso no elimina la ingeniería. Cambia dónde se concentra.
El desarrollador que utiliza bien estos sistemas necesita comprender arquitectura, pruebas, seguridad y dominio precisamente porque debe evaluar una producción de código cada vez más rápida.
La productividad real no consiste en generar más líneas.
Consiste en reducir el tiempo necesario para llevar una solución correcta y mantenible hasta producción sin aumentar el riesgo en la misma proporción.
Y ahí está probablemente la regla más importante del desarrollo de software con IA:
delega ejecución cuando puedas verificarla; conserva el criterio humano allí donde un error sea costoso, ambiguo o difícil de revertir.