Dos leyendas de la ingeniería de software hablan sin filtros sobre el momento más incierto y emocionante de la historia del desarrollo.
Hace unas semanas, Martin Fowler y Kent Beck —dos de los 17 firmantes del Manifiesto Ágil— se sentaron frente a una sala llena de startups de IA para hablar sobre lo que está pasando en nuestra industria. No como vendedores de tecnología. No como gurús con respuestas prefabricadas. Sino como ingenieros con décadas de experiencia que, por primera vez en mucho tiempo, admiten que tampoco saben qué va a pasar.
Lo que dijeron merece tu atención.
"Nadie tiene las respuestas. Eso es la buena noticia."
Durante 25 años, cuando alguien llegaba con un problema —demasiados bugs, código imposible de mantener, equipos disfuncionales— Kent Beck y Martin Fowler tenían respuestas. Escribe pruebas. Refactoriza. Trabaja en pareja. Itera en ciclos cortos.
Eso se acabó. Y ellos lo dicen sin drama.
"Lo que ha cambiado es que en este momento, nadie sabe las respuestas a nada." — Kent Beck
Pero Beck añade algo importante: la mala noticia es que no hay respuesta. La buena noticia es que nadie más la tiene tampoco. Eso pone a todos —junior, senior, los propios Fowler y Beck— en el mismo punto de partida.
Si llevas tiempo sintiéndote perdido frente a la IA, no es porque te falte experiencia. Es porque estamos todos en territorio desconocido.
La IA como amplificador: por qué este es el mejor momento para ser junior
Kent Beck tiene una opinión que va contra la narrativa del miedo: este es la época dorada para los programadores junior.
Su argumento es directo: la IA es un amplificador. Si aprendes rápido —y los juniors aprenden rápido— la IA multiplica esa capacidad. Si eres curioso y estás dispuesto a explorar, la IA te da superpoderes que antes tomaban años conseguir.
Usa una analogía que vale la pena repetir:
"Esto es como si fueras carpintero y acaban de inventar la sierra circular. No se acabó la carpintería. Ahora tienes herramientas más poderosas."
El riesgo no es que la IA te reemplace. El riesgo es que otro desarrollador —junior o senior— que sepa usarla bien te deje atrás. La diferencia entre los dos grupos va a ser enorme.
TDD en la era de los agentes: por qué los fundamentos importan más que nunca
Aquí hay algo que sorprendió incluso a Kent Beck: alguien le agradeció el impulso del Test-Driven Development (TDD) durante los últimos 20 años. No por razones de calidad de código en abstracto, sino porque resulta que las pruebas son críticas cuando trabajas con agentes de IA.
¿Por qué? Porque cuando tienes un "genio grande y poderoso" generando código, necesitas verificar que está haciendo lo correcto. Necesitas una red de seguridad. Necesitas pruebas.
Martin Fowler también menciona algo revelador: el código bien modularizado —otro fundamento clásico— facilita mucho el trabajo de los agentes. La buena arquitectura no es un lujo del pasado. Es lo que permite que la IA funcione bien.
Los fundamentos no murieron con la IA. Se volvieron más valiosos.
El escepticismo como habilidad: cómo navegar sin perderse
Fowler es brutalmente honesto sobre su propia experiencia inicial con la IA: no le impresionó. Probó Copilot, lo configuró en Emacs, y lo abandonó a los tres o cuatro días porque era inconsistente. Si esa hubiera sido su única experiencia, habría descartado toda la tecnología.
No lo hizo. ¿Por qué? Porque aprendió a no confiar demasiado en sus reacciones iniciales.
Su consejo: busca voces que ofrezcan equilibrio entre lo bueno y lo malo, y que además estén dispuestas a decir "no sé". Eso es una señal de que vale la pena escuchar. Las voces que solo venden o solo critican son ruido.
También advierte sobre el "complejo industrial ágil": igual que surgió una industria entera de charlatanería alrededor del movimiento ágil, lo mismo está pasando con la IA. Ya está pasando. Distinguir entre lo valioso y el ruido es una habilidad que debes desarrollar activamente.
Su regla: sé escéptico. Pero sé escéptico también de tu propio escepticismo.
El futuro de los equipos: ¿una pizza o dos?
Una de las conversaciones más interesantes fue sobre cómo va a cambiar la estructura de los equipos. La pregunta que plantearon: ¿los "equipos de dos pizzas" (el famoso tamaño de equipo de Amazon) se van a convertir en "equipos de una pizza" porque los agentes no comen?
Beck tiene su apuesta: equipos de dos pizzas, pero más efectivos.
No cree que la respuesta correcta sea un programador solo con diez agentes. Cree que la dinámica humana —dos personas con perspectivas diferentes, niveles de energía distintos, capaces de tener conversaciones reales sobre filosofía de diseño— sigue siendo irremplazable.
De hecho, señala algo inesperado: aprecia que los modelos de IA sean lentos. Cuando le das una instrucción a un agente y tarda tres minutos en responder, tienes tiempo para conversar con tu colega sobre convenciones de nombres, sobre la próxima decisión de diseño, sobre lo que deberían hacer después. Si el modelo responde en 15 segundos, esa conversación desaparece.
Lo que más debería preocuparte (y no es lo que crees)
Fowler habla de algo que lo inquieta: empresas —incluso grandes— que están considerando dar a los LLMs control total sobre sus correos electrónicos. Acceso de lectura y escritura. Respuesta automática.
Su reacción: "No. ¿Qué? No."
Hay una prisa ciega por aprovechar lo que parece funcionar, sin dimensionar los riesgos reales de seguridad. Y en sistemas grandes y complejos —con millones de líneas de código, donde un error puede dejar una aerolínea fuera de servicio dos días— el margen de error es cero.
La madurez técnica que le tomó a la industria décadas construir (modularización, pruebas, revisión de código, seguridad) no es opcional cuando introduces agentes. Se vuelve crítica.
Una idea que te cambia la perspectiva
Hubo un momento en la conversación que quedó grabado: alguien mencionó que el diagrama de Venn entre la experiencia del desarrollador y la experiencia del agente es un círculo.
Lo que es bueno para los agentes —código modular, funciones pequeñas, nombres claros, pruebas— también es bueno para los humanos. Y al revés.
Eso significa algo importante: si te enfocas en mejorar como desarrollador —en entender los fundamentos reales, en escribir código limpio, en pensar bien el diseño— estás al mismo tiempo mejorando en trabajar con IA. No son caminos separados.
Para cerrar: lo que estos 25 años enseñan sobre los próximos 25
Martin Fowler terminó diciendo algo que resume bien su postura: dejó de escribir libros para trabajar con personas que sí están en proyectos reales, escribiendo código de verdad, y ayudarlas a compartir lo que aprenden. Porque en este momento, eso es más valioso que cualquier respuesta de un libro.
La industria está en modo exploración. Nadie tiene el manual. Y eso —si lo ves bien— es una oportunidad enorme para los desarrolladores que estén dispuestos a explorar, a aprender en público y a construir criterio propio.
Fowler y Beck llevan 25 años haciéndolo. La diferencia es que ahora no están solos.
