Durante los últimos meses he tenido varias conversaciones sobre cómo está cambiando nuestra forma de desarrollar software utilizando inteligencia artificial.
Y la mayoría de ellas han acabado llevándonos a una punto que, en realidad, tenía poco que ver con qué modelo genera mejor código o con qué agente es más sofisticado.
La pregunta importante era otra:
¿Estamos aprovechando la IA para hacer mejor ingeniería o simplemente estamos aprendiendo a producir software más rápido?
Porque no son lo mismo.
Y cuanto mayor sea nuestra capacidad para generar código, más importante será distinguir ambas cosas.
La aparición de agentes capaces de explorar repositorios, implementar funcionalidades, escribir tests, refactorizar o levantar aplicaciones completas ha cambiado radicalmente la economía de producir software. Lo que antes podía requerir varios días ahora puede resolverse en horas y, en determinados contextos, trabajo que antes necesitaba un equipo puede acabar haciéndolo una sola persona.
Eso abre infinidad de posibilidades, pero también introduce una tentación: asumir que nuestra principal limitación como desarrolladores siempre fue escribir código.
Quizá nunca lo fue.
El desarrollador no cobra por escribir código
Durante años hemos simplificado nuestro trabajo diciendo que somos programadores: picamos código, implementamos tickets, cerramos historias.
Esa descripción siempre fue incompleta. “Escribir código” es una parte importante del trabajo, pero normalmente estamos intentando resolver algo que existe fuera del código, un problema que va más allá de los condicionales, bucles, ceros y unos. Estamos tratando de solucionar problemas de forma ingeniosa.
Y, veces la solución será escribirlo y otras será borrarlo. En ocasiones bastará con cambiar un proceso, conectar dos sistemas existentes o automatizar una tarea. Incluso puede que la decisión correcta sea no construir absolutamente nada.
Esta posibilidad resulta especialmente relevante ahora que generar software se está volviendo extremadamente barato.
Cuando producir código era caro existía una fricción natural. Había que justificar relativamente bien qué construir porque hacerlo tenía un coste considerable. Ahora podemos generar aplicaciones, servicios o integraciones en cuestión de horas y parte de esa fricción desaparece.
Aparece entonces un riesgo distinto:
Crear software en busca de un problema.
Una solución sin un problema real puede parecer innovación durante los primeros cinco minutos. Después puede convertirse en inventario: algo que desplegar, securizar, entender y mantener durante años.
Y aunque haya tardado muy poco en generarse, alguien seguirá teniendo que hacerse responsable de ella.
La IA no elimina XP. Hace que XP vuelva a ser incómodamente relevante
Resulta curioso que, mientras hablamos de agentes, especificaciones gigantescas y procesos completamente nuevos, muchas de las preguntas que intentamos resolver ya estaban presentes hace décadas.
Extreme Programming surgió precisamente como respuesta a entornos donde los requisitos cambian, el conocimiento es incompleto y aprender pronto resulta más valioso que intentar predecirlo todo.
Sus valores de: comunicación, simplicidad, feedback, valentía y respeto; siguen siendo retos actuales. De la misma forma prácticas como: el diseño incremental, test-first, integración continua, refactorización o el ritmo sostenible siguen estando vigentes.
Nada de esto deja de ser válido porque ahora una máquina pueda escribir buena parte de la implementación.
Lo que sí cambia es el coste de equivocarnos.
Un agente puede propagar una decisión incorrecta por muchos más archivos, tests y capas antes de que alguien detecte que partíamos de una premisa equivocada. Por eso aumentar nuestra velocidad de generación sin mejorar también nuestra capacidad para aprender y verificar no garantiza un mejor sistema de desarrollo.
La velocidad amplifica tanto las buenas decisiones como las malas.
El peligro de convertir SDD en waterfall con esteroides
Una de las respuestas actuales a la incertidumbre introducida por la IA es el Spec-Driven Development.
La idea tiene bastante sentido: antes de pedirle a un agente que implemente algo, explicamos con mayor precisión qué queremos construir.
Herramientas como GitHub Spec Kit formalizan flujos del tipo:
Specify → Plan → Tasks → Implement → Converge.
Separar intención e implementación puede ser extremadamente útil cuando trabajamos con agentes.
El problema aparece cuando confundimos dar contexto con intentar eliminar toda la incertidumbre antes de comenzar. Entonces corremos el riesgo de volver al lugar del que intentamos escapar hace años: un enorme documento de requisitos, después uno de arquitectura, otro de tareas con cientos de decisiones anticipadas y finalmente una IA capaz de convertir todo aquello en código a una velocidad espectacular.
Eso puede parecer tremendamente sofisticado, pero mantiene un problema fundamental:
podemos especificar algo con enorme precisión, que todavía no sabemos si es correcto.
El Agile Manifesto colocaba el software funcionando por encima de la documentación exhaustiva y responder al cambio por encima de seguir un plan. Documentar y planificar sigue teniendo valor. El límite aparece cuando tratamos esos artefactos como si pudieran contener conocimiento que todavía no hemos adquirido.
No tengo claro dónde está exactamente esa frontera. Probablemente dependa mucho del contexto, del sistema y del riesgo que estemos asumiendo.
Me resulta más útil pensar en una especificación como contexto suficiente para empezar que como un intento de describir por adelantado el futuro completo del sistema.
Nuestra unidad de trabajo debería seguir siendo el aprendizaje
Aquí creo que XP ofrece una vía intermedia bastante interesante.
Podemos delegar una cantidad considerable de trabajo sin convertir esa delegación en un salto de fe.
Una forma de hacerlo es trabajar en pequeñas unidades de comportamiento: definir qué queremos conseguir, proporcionar algunos ejemplos relevantes, establecer qué restricciones no deberían romperse y dejar que el agente trabaje dentro de ese espacio.
Dentro de ese pequeño ciclo, el agente puede escribir una primera implementación, ejecutar las pruebas, revisar lo que ha fallado, modificar su solución y volver a intentarlo varias veces antes de devolvernos un resultado.
Eso cambia bastante nuestra relación con la implementación.
No necesitamos supervisar cada movimiento interno de un agente. Nuestro punto de control puede estar un nivel por encima: en el comportamiento esperado, las restricciones y las evidencias que utilizaremos para decidir si el resultado es, o no, aceptable.
Aquí es donde creo que los pequeños lotes siguen teniendo mucho sentido.
DevOps Research and Assessment (DORA) continúa recomendando explícitamente trabajar en cambios pequeños, y esta disciplina se vuelve especialmente relevante cuando utilizamos IA. Los modelos permiten generar modificaciones enormes con muy poco esfuerzo, pero revisar, comprender e integrar esos cambios sigue teniendo un coste.
Nuestra responsabilidad empieza a desplazarse hacia otra pregunta:
¿Qué delegamos y en qué evidencia nos basamos para aceptar el resultado?
Una Software Factory no debería ser una fábrica de código
Me resulta interesante pensar en los equipos de desarrollo como una especie de Software Factory.
El problema es que la imagen de una fábrica invita fácilmente a medir aquello que resulta más visible: cuánto producimos.
Podríamos acabar describiendo una organización así:
Tenemos agentes trabajando constantemente, generamos decenas de pull requests al día y producimos funcionalidades a una velocidad nunca vista.
Suena impresionante, pero no dice nada sobre si estamos creando valor.
La analogía industrial tiene sus límites, pero aquí resulta útil: multiplicar la producción solo es una ventaja cuando estamos produciendo algo que merece la pena producir.
Una Software Factory madura debería preocuparse menos por el volumen bruto de output y más por el outcome que consigue generar.
Líneas de código, pull requests o incluso consumo de tokens pueden ser métricas operativas útiles, pero dicen poco por sí solas sobre el objetivo final.
Me interesa bastante más cuánto conseguimos comprimir este ciclo:
problema → hipótesis → solución → evidencia → aprendizaje.
La IA puede reducir radicalmente el tiempo necesario para recorrerlo.
Ahí veo uno de sus mayores potenciales: poder explorar una idea antes, obtener evidencia antes y descubrir antes que estábamos equivocados.
La dificultad está en no utilizar todo el tiempo que ganamos para llenar el sistema de más burocracia, más funcionalidades y más código.
Construir más rápido es una capacidad extraordinaria.
La pregunta sigue siendo qué hacemos con ella.