¿Estamos generando mejor software o simplemente más software?
La IA generativa ha reducido de forma brutal el coste de producir código. Podemos pedirle que implemente una funcionalidad, que escriba un servicio, que genere tests, que refactorice un módulo o que nos ayude a montar una arquitectura completa en cuestión de minutos.
Y eso suena increíble.
Pero hay una pregunta incómoda que creo que deberíamos hacernos como industria: ¿estamos generando mejor software o simplemente más software?
Porque si el cuello de botella antes era escribir código, ahora empieza a ser otro: entenderlo, validarlo, mantenerlo y saber si realmente encaja en el sistema que estamos construyendo.
El problema no es nuevo
Durante años, en la industria del software hemos repetido los mismos errores: correr antes de entender, construir antes de validar, dejar los tests para después, aceptar deuda técnica como si fuera inevitable, confundir velocidad con progreso, diseñar arquitecturas accidentales y revisar demasiado tarde.
La diferencia es que ahora la IA permite cometer esos mismos errores a una velocidad vertiginosa.
Antes de la IA, la industria ya tenía un problema grave. El CISQ estimó que en 2022 el coste de la mala calidad del software en Estados Unidos fue de aproximadamente 2,41 billones de dólares, y que la deuda técnica acumulada rondaba los 1,52 billones. La IA no aparece en una industria sana y perfectamente controlada. Aparece en una industria que ya arrastraba problemas estructurales.
La idea no es que la IA cree un problema completamente nuevo, sino que acelera problemas que ya existían.
La IA no crea deuda técnica nueva. Acelera la deuda técnica que ya sabíamos crear.
La deuda de verificación
Hay un concepto que merece atención: la deuda de verificación. La IA puede generar código con apariencia correcta, pero ese código debe ser verificado. Si los equipos aceptan cambios sin revisarlos adecuadamente, la deuda no está solo en el código, sino también en el proceso de validación.
Hemos reducido el coste de producir código, pero no necesariamente el coste de entenderlo, validarlo, desplegarlo, operarlo y mantenerlo. El nuevo cuello de botella no siempre será escribir código. Será saber si ese código es correcto.
Y quizá el verdadero riesgo no es que la IA sustituya a los desarrolladores, sino que nos permita automatizar nuestra falta de criterio.
La tesis
Después de plantear el problema, la tesis es sencilla:
La IA no escribe buen software por sí sola. Lo hace cuando trabaja dentro de un entorno que le proporciona límites claros, feedback fiable y espacios de intervención humana.
La calidad no depende únicamente del modelo, sino del sistema de trabajo donde lo integramos. No es una charla contra la IA. Es contra su uso ingenuo, descontrolado o basado únicamente en velocidad.
Un flujo de trabajo con criterio
Si la IA acelera nuestras malas prácticas, necesitamos una forma de introducir criterio antes, durante y después de la generación de código. La solución no es una herramienta concreta ni un framework cerrado, sino un flujo de trabajo:
Discovery → Plan → Review → Implement → Verify
No es Scrum para agentes. Es una estructura mínima de control: adaptable a cada equipo, pensada para separar cuándo queremos que la IA razone, cuándo queremos que proponga, cuándo debe ejecutar y cuándo necesitamos validar lo que ha hecho.
Discovery: ¿estamos entendiendo bien el problema?
Antes de implementar, el sistema debe pensar el problema. En esta fase no queremos código. Queremos que la IA ayude a entender el problema, explorar alternativas, identificar riesgos, hacer preguntas, explicitar supuestos y detectar ambigüedades.
El humano aporta lo que la IA no tiene de forma fiable: contexto de negocio, restricciones reales, decisiones históricas, conocimiento del producto y sensibilidad ante riesgos.
La pregunta guía: ¿estamos entendiendo bien el problema antes de tocar el código?
Plan: ¿sabemos qué vamos a cambiar y por qué?
Convertir el razonamiento en una secuencia de pasos concreta. El plan debería aclarar qué se va a cambiar, qué ficheros o módulos pueden verse afectados, qué no se va a tocar, qué pruebas hacen falta y qué riesgos hay que controlar.
El humano puede aceptar, corregir o rechazar el plan antes de que el agente modifique nada.
La pregunta guía: ¿este cambio tiene sentido antes de ejecutarlo?
Review: ¿tiene sentido la solución antes de construirla?
Revisar antes de implementar. No consiste en revisar código, sino la intención, el enfoque, los trade-offs, el impacto en el sistema, la coherencia con la arquitectura y la mantenibilidad de la solución.
Esta fase evita aceptar soluciones plausibles pero mal orientadas. También evita revisar demasiado tarde, cuando ya hay código escrito y emocionalmente cuesta más descartarlo.
La pregunta guía: ¿estamos de acuerdo con la solución antes de pagar el coste de construirla?
Implement: ¿está ejecutando el plan o improvisando?
La IA implementa el cambio, pero ya no lo hace a ciegas. Lo hace después de haber pasado por discovery, planificación y revisión. Deja de ser una máquina de generar código y pasa a ser un ejecutor dentro de un marco de decisión.
El humano supervisa que la IA siga el plan, no improvise cambios fuera de alcance, respete las decisiones tomadas y no introduzca complejidad innecesaria.
La pregunta guía: ¿está ejecutando el plan o está improvisando?
Verify: ¿qué señales tenemos de que esto es correcto?
Validar que el cambio es correcto. Verify no significa únicamente comprobar que el código compila. Significa reunir señales suficientes para decidir si el cambio puede aceptarse: tests automatizados, tipado, linters, análisis estático, integración continua, revisión del diff, pruebas manuales, validación funcional, reglas de arquitectura, contratos, observabilidad, seguridad y documentación actualizada.
El humano decide si las señales son suficientes y si el riesgo es aceptable.
La pregunta guía: ¿qué señales tenemos de que esto es correcto?
Human in the Loop: decidir en el momento adecuado
Una de las ideas centrales es que Human in the Loop no significa simplemente mirar al final lo que ha hecho la IA. Significa introducir criterio humano en los puntos donde más impacto tiene: antes de construir, antes de aceptar una solución, antes de integrar un cambio y antes de asumir riesgos técnicos.
El humano no está para revisar cada línea como si fuera un compilador emocional. Está para aportar lo que la IA no tiene de forma fiable: intención, contexto, criterio, experiencia, responsabilidad y sensibilidad ante el impacto futuro.
Human in the Loop no es revisar al final. Es decidir en el momento adecuado.
El orquestador, los arneses y el humano
Este flujo puede ser la base de un orquestador. No porque el orquestador automatice todo, sino porque separa responsabilidades: cuándo razonar, cuándo decidir, cuándo ejecutar, cuándo verificar y cuándo pedir intervención humana.
Los arneses son mecanismos que permiten que la IA opere con límites, señales y feedback: tests, tipos, linters, análisis estático, reglas de arquitectura, convenciones del equipo, documentación viva, pipelines de CI, revisión de seguridad, observabilidad, validación humana, contratos de API, métricas, feature flags y entornos de staging.
Un agente sin arneses es velocidad sin dirección.
La ecuación es sencilla:
- El orquestador aporta estructura.
- Los arneses aportan feedback.
- El humano aporta criterio.
Los tres elementos son necesarios. Ninguno sustituye a los otros.
La flexibilidad es la clave
El flujo debe ser adaptable a cada equipo y situación. En un bug pequeño, el discovery puede durar treinta segundos, el plan puede ser muy simple y la verificación puede limitarse a un test y una revisión rápida. En un cambio de arquitectura, el discovery puede ocupar una sesión completa, el plan puede requerir varios pasos, la review puede implicar a varias personas y la verificación puede incluir tests, revisión formal, seguridad, rendimiento y observabilidad.
La clave no es aplicar siempre el mismo peso a cada fase, sino decidir conscientemente cuánto control necesita cada cambio.
La gracia del flujo es que no impone un proceso. Impone una pregunta: ¿en qué momento dejamos que la IA actúe y con qué señales decidimos que lo que hizo es aceptable?
Hacia dónde vamos
No queremos que la IA simplemente vaya más rápido. Queremos que vaya más rápido en la dirección correcta.
El objetivo no es pedirle a la IA que haga más cosas. El objetivo es mejorar cómo colaboramos con ella: no pedir solo código, sino razonamiento; no aceptar cambios sin plan; no implementar sin revisar intención; no integrar sin señales; no delegar el criterio.
La IA no nos libera de la responsabilidad técnica. La hace más importante.
El reto real no es decidir si usamos IA o no. Esa conversación, en muchos equipos, ya ha quedado atrás. El reto es decidir cómo la usamos, con qué límites, con qué señales de calidad y con qué espacios de intervención humana.
Definamos nuestros arneses. Hagamos explícitas nuestras reglas. Protejamos nuestros estándares. Revisemos antes de aceptar. Verifiquemos antes de integrar. Y, sobre todo, mantengamos el criterio técnico en el centro.
Porque el futuro del desarrollo de software no será solo de quienes sepan usar mejor una herramienta. Será de quienes sepan crear mejores sistemas para usarla con responsabilidad.
La IA no escribe buen software por sí sola. El entorno sí. Y ese entorno lo diseñamos nosotros.
Este artículo está basado en la charla “La IA no escribe buen software: el entorno sí” que presenté en CommitConf 2026.