“Trust I seek and I find in you, something new for us every day… and nothing else matters.”
Con esos versos de Metallica, pronunciados casi a modo de confidencia, Werner Vogels, vicepresidente y CTO de Amazon abrió su última keynote en AWS re:Invent 2025. No buscaba un efecto dramático, aunque lo produjo. La cita resonó en el auditorio como un recordatorio de la relación peculiar que une a los desarrolladores con sus herramientas, con sus equipos y con una disciplina que cambia más rápido de lo que cualquiera puede anticipar. La confianza, la apertura a lo desconocido y la disposición a ver las cosas desde otro ángulo aparecían antes incluso de que el CTO de Amazon.com entrara en materia.
Unos segundos reveló una noticia que dejó la sala en silencio: tras catorce ediciones consecutivas, esa sería su última intervención en el escenario principal del evento. No dejará Amazon, aclaró, pero consideraba necesario ceder el espacio a nuevas voces. Dicho desde alguien que ha marcado el tono filosófico y arquitectónico de AWS durante más de una década, el anuncio cambió de inmediato la percepción de lo que iba a ser la sesión.
De ahí en adelante, la keynote se convirtió en una reflexión amplia sobre cómo ha cambiado el desarrollo de software y qué supone seguir siendo ingeniero en un momento en el que las herramientas evolucionan más rápido que los lenguajes de épocas anteriores. Esa mirada hacia el presente derivó de forma natural hacia la continuidad histórica: cómo distintas generaciones de desarrolladores han absorbido, a veces sin margen para procesarlo, sucesivas olas de cambio que van del 6800 assembler a COBOL y Pascal, y de ahí a las arquitecturas distribuidas del siglo XXI. Vogels no recurrió a la nostalgia; utilizó ese recorrido para subrayar que la transformación permanente siempre ha sido parte del oficio. Pero la secuencia conducía a una inquietud mucho más actual, repetida en todos sus viajes y en todas las industrias: ¿quitará la IA el trabajo a los desarrolladores?
La respuesta fue matizada. Algunas funciones desaparecerán, otras cambiarán, y muchas se automatizarán. Pero, aun así, lo sustancial —la capacidad de razonar, de conectar sistemas, de plantear hipótesis y de interpretar el comportamiento emergente del software— seguirá siendo responsabilidad humana. Lo expresó de forma directa: la obsolescencia solo amenaza a quienes no evolucionan. Y el ejemplo histórico, desde los compiladores hasta la nube, apunta en la misma dirección: cada salto tecnológico desplaza habilidades, pero amplía el alcance del desarrollo.
Evolución del desarrollo en AWS re:Invent 2025: herramientas, expectativas y arquitecturas
Vogels revisó varias décadas de cambios en los entornos de trabajo, desde el paso de la programación estructurada al paradigma orientado a objetos, hasta la transformación del monolito de Amazon en una red de servicios con equipos propietarios de su ciclo de vida. La escena de 1998, cuando la compañía aceleró la descomposición de su arquitectura, funcionó como recordatorio de que las decisiones organizativas y técnicas se retroalimentan. La independencia de los equipos, la claridad en la propiedad de cada servicio y la cultura de interfaces definidas acabaron convirtiéndose en modelo de referencia para empresas que buscaban escalar sin bloquear a sus ingenieros.
Los cambios en las herramientas, subrayó, también han ocurrido por capas. De los primeros entornos gráficos a Visual Studio Code, del editor rápido a los sistemas enriquecidos por IA como Cursor o Kite, cada generación ha reescrito su propio flujo de trabajo. Y es probable que 2026 vuelva a hacerlo. Sin embargo, la clave no era la herramienta en sí, sino la responsabilidad que permanece: “El trabajo es vuestro, no de las herramientas”. Una frase que sonó a advertencia para una época en la que los modelos generativos producen código más rápido de lo que puede analizarse.
Un paralelismo histórico: de la IA al Renacimiento
Después de recorrer esta historia tecnológica, Vogels conectó la actualidad con un periodo cultural inesperado: el Renacimiento. La comparación no buscaba épicas; servía para ilustrar cómo la innovación se acelera cuando varias disciplinas progresan al mismo tiempo y se refuerzan entre sí. La llegada del telescopio, la perspectiva en pintura o la imprenta de Gutenberg fueron herramientas que multiplicaron el impacto de la curiosidad colectiva. Sin ese contexto, Da Vinci o Copérnico no habrían alcanzado semejante amplitud creativa.
Para Vogels, los desarrolladores actuales se encuentran en un momento similar. La convergencia entre IA, robótica y exploración espacial, mencionada incluso por Jeff Bezos, genera un entorno donde el avance en un campo impulsa el de los demás. Y si algo caracterizó a los protagonistas del Renacimiento, no fue únicamente la genialidad, sino un tipo mentalidad: curiosidad activa, experimentación constante, disposición a fallar, y una visión transversal que hacía permeables los límites entre áreas de conocimiento.
Ese marco le sirvió para introducir su concepto central: el “desarrollador renacentista”. Un profesional que combina cinco cualidades: curiosidad, pensamiento sistémico, comunicación precisa, sentido de propiedad y una amplitud intelectual que complementa la especialización técnica. El planteamiento no sonó a eslogan. Vogels lo reforzó con ejemplos recientes de su trabajo de campo.
Lo que explica Werner Vogels en AWS re:Invent 2025 sobre lo que aprende viajando por el mundo
A lo largo de 2024 viajó por África subsahariana y América Latina en visitas de trabajo que marcaron su visión. Sus encuentros con empresas como Guayakí, que busca generar oportunidades económicas en comunidades amazónicas, o con equipos que estudian el flujo de plástico en ríos mediante modelos predictivos, mostraban un patrón común: desarrolladores que aplican ingeniería a problemas sociales complejos. Desde el uso de drones y cámaras con IA para rastrear residuos en ríos, hasta sistemas de salud pública en Ruanda que operan con paneles en tiempo real para identificar brotes y planificar infraestructuras sanitarias, la tecnología actuaba como fundamento de decisiones políticas y operativas.
El caso de Coco Networks, en Nairobi, ilustró cómo un enfoque técnico puede transformar dinámicas económicas extremadamente frágiles. La creación de dispensadores de etanol de bajo coste, accesibles a través de microtransacciones, redujo la dependencia de combustibles contaminantes y facilitó que familias con ingresos diarios mínimos pudieran cocinar sin recurrir al carbón. No era un despliegue masivo de infraestructura, sino un diseño de sistema concebido desde las restricciones de su entorno.
Estos ejemplos reforzaban un punto que Vogels sostuvo varias veces: los desarrolladores han sido actores esenciales en cada avance tecnológico reciente, y lo seguirán siendo en retos globales como la alimentación, la energía o la salud. En su narrativa, la tecnología no aparece como herramienta neutra, sino como mecanismo de ampliación de capacidades humanas en entornos donde los recursos son escasos o las variables cambian con rapidez.
De la curiosidad al método: cómo piensa el desarrollador renacentista
El primer atributo del modelo —la curiosidad— fue presentado como una disciplina más que como una inclinación. Vogels recordó que la capacidad de desmontar un sistema, ya sea un lenguaje nuevo o una arquitectura desconocida, lleva al aprendizaje profundo. Y dio un paso más al relacionarlo con la “Jirgen Dobson Law”, que describe la relación entre presión y rendimiento: el aprendizaje ocurre en la franja donde el reto no paraliza, pero tampoco permite al desarrollador acomodarse.
El segundo rasgo —pensar en sistemas— se articuló desde la ecología. La reintroducción de lobos en Yellowstone, que transformó el comportamiento de los ríos sin intervención directa, sirvió como analogía para explicar cómo cambios pequeños pueden desencadenar efectos amplificados en sistemas interconectados. En software, modificar una política de reintentos altera la carga; añadir una caché cambia los patrones de tráfico; reasignar propiedad modifica la velocidad de entrega. Cada decisión reconfigura el sistema completo, no solo la parte modificada.
Vogels citó a Donella Meadows y su ensayo sobre puntos de intervención en sistemas dinámicos. Más que un guiño intelectual, era un recordatorio de que la ingeniería moderna se mueve en entornos donde el comportamiento emergente supera a menudo el control explícito.
Comunicación: del requisito ambiguo a la especificación precisa
Para ilustrar el tercer pilar —la comunicación— cedió el escenario a Clelia Loriggi, senior principal developer en el equipo de Kiro, que presentó el nuevo ciclo de desarrollo basado en especificaciones dentro de Kiro IDE. Su intervención mostró un matiz importante: en un entorno dominado por herramientas generativas, el reto ya no es escribir código, sino describir con precisión qué debe hacer. La ambigüedad de la comunicación humana, que normalmente se resuelve con contexto o intuición, se convierte en un problema cuando interactúa con modelos que generan respuestas plausibles pero no verificadas.
Loriggi explicó cómo el equipo experimentó con varias aproximaciones —desde TDD hasta especificaciones técnicas completas— para acabar en un flujo estructurado en tres documentos: requisitos, diseño y tareas. Esta secuencia permitió controlar el comportamiento del asistente y evitar que se derivara hacia soluciones técnicamente correctas pero alejadas de la intención del equipo.
Lo más significativo fue un detalle operativo: al desarrollar Kiro, utilizaron Kiro para construir Kiro. Rapid prototyping acelerado por IA, pero guiado por especificaciones que reducían el margen de error. La diferencia con el vibe coding era clara. En lugar de iterar sobre código incorrecto generado a partir de un prompt difuso, la iteración se concentraba en refinar la intención hasta que el sistema la captara con precisión.
Propiedad y mecanismos: la ingeniería más allá de la generación de código
El cuarto elemento —la propiedad— ocupó una parte extensa de la intervención. Vogels advirtió sobre dos riesgos que crecen con la automatización: la deuda de verificación, derivada de código generado más rápido de lo que puede comprenderse, y las alucinaciones arquitectónicas, que producen estructuras plausibles pero incompatibles con APIs reales, patrones del sistema o restricciones del dominio.
Para explicar cómo evitar que estos problemas lleguen a producción, introdujo una distinción fundamental: entre buenas intenciones y mecanismos. Basta con recordar su historia sobre Jeff Bezos y el sistema de devoluciones para comprender la diferencia. Hasta que Amazon no dio a los agentes de atención al cliente un botón para hacer un producto “no disponible”, la organización no reaccionó de manera sistemática ante un defecto conocido. De ahí que mecanismos como los durability reviews del equipo de S3 o las revisiones de código tengan un papel decisivo: convierten la calidad en hábito, no en aspiración.
Las revisiones de código, en particular, fueron defendidas con una intensidad inusual en una keynote dominada por la IA. Según Vogels, en un mundo donde los modelos generan código a gran velocidad, la revisión humana se convierte en el punto de control crítico para restablecer el equilibrio. Además, funcionan como vehículo de transferencia de conocimiento entre generaciones de ingenieros.
El desarrollador como polímata
La última cualidad —la amplitud intelectual— conectó de nuevo con la figura de Leonardo, pero también con Jim Gray, mentor de Vogels y creador de los principios de transacciones modernas. Gray ejemplificaba al tecnólogo capaz de unir especialización y visión transversal. Desde detectar problemas de acceso a disco por el sonido de un servidor, hasta diseñar sistemas para astronomía computacional, su carrera mostraba la importancia de no limitarse a un único dominio.
Ese tipo de perfil, el desarrollador en T, combina profundidad y amplitud. Entiende cómo su módulo afecta al resto del sistema. Interpreta costes, patrones de acceso, expectativas del negocio y riesgos operativos. En la lectura de Vogels, esta diversidad cognitiva no es un lujo, sino una necesidad para construir software que funcione en sistemas complejos y cambiantes.
Un cierre que fue despedida y lección final
La keynote terminó con una reflexión sobre la invisibilidad del trabajo bien hecho. Los usuarios no elogian a un equipo de bases de datos por cada despliegue silencioso, ni celebran que un sistema crítico permanezca operativo toda la noche. Pero, según Vogels, esa discreción es precisamente lo que define la excelencia en ingeniería: operar con rigor incluso cuando nadie está mirando. Un recordatorio dirigido a quienes cargan con la responsabilidad de mantener sistemas esenciales en segundo plano.
La despedida fue breve: “Two more words: Werner out”. Pero la intervención completa dejó una idea más permanente. En un entorno donde la IA reconfigura flujos, roles y ritmos de entrega, la relevancia del desarrollador no se reduce; cambia de forma. Y según Vogels, quienes adopten curiosidad, visión sistémica, precisión comunicativa, responsabilidad operativa y amplitud intelectual estarán mejor preparados para un ciclo tecnológico que apenas está empezando.
