📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Llevaba años viendo este movimiento venir, pero igual me sorprendió cuando llegó: el 11 de noviembre AWS lanzó AWS Emulator, un programa gratuito que corre en tu máquina y emula más de 200 servicios de AWS para que pruebes tus aplicaciones sin gastar un peso en la nube. Hasta ahí, noticia de desarrolladores. Lo que hizo histórica la fecha es una frase del ingeniero principal del proyecto, Matt Goldberg: «el emulador fue escrito íntegramente por agentes autónomos. Nuestro equipo no escribió ni revisó ni una sola línea de ese código». Y no es marketing: es literal.
El repo como evidencia
El código está en GitHub bajo licencia CC0 y el historial habla solo. Arrancó el 21 de octubre con un commit llamado «Initial emulator scaffold» y ya acumula 29.684 commits en tres semanas. El autor del último commit es una cuenta llamada IssueFinderAgent. Los mensajes de commit incluyen metadatos como Producer: scaffold y Producer: issue-fixer. En la lista de contribuidores hay una palabra: Ninguno. Y el repo ni siquiera acepta pull requests: el aporte humano, directo, no forma parte del flujo.
La mecánica, contada por Goldberg, es de una elegancia brutal. Tres equipos de agentes: uno escribe pruebas de fidelidad contra la nube real de AWS (decenas de miles, derivadas de los modelos de API), otro las reproduce contra el emulador y archiva lo que falla, y un tercero toma un problema a la vez y lo arregla. Cada fix pasa por un merge gate que verifica compilación, estándares de código, seguridad y fidelidad. Miles de problemas resueltos al día, con cientos de agentes trabajando en paralelo. Empezó como un experimento de fin de semana con Kiro: le pidieron una versión de SQS y volvió en 15 minutos con algo usable.
La revisión no murió, se mudó
Aquí viene mi opinión, que ya la probé en mi propia pega: la revisión humana no desapareció, se desplazó. El trabajo del equipo se fue hacia arriba, a diseñar la especificación y las pruebas, no a leer código. Goldberg lo resume con una imagen que me encantó: a los agentes hay que darles «cuadernos para colorear», tareas acotadas con una meta inequívoca, y dentro de esas líneas colorear solos. Lo he sufrido caro: un agente me rompió a media noche un script que administraba mis respaldos, y la solución nunca fue sentarme a auditar línea por línea, fue definir la prueba primero y dejarlo correr contra ella hasta que pasara verde. Es la misma tesis, a escala doméstica.
Pero cuidado con romanticizar. Ese merge gate de «seguridad» es, también, un agente revisando el trabajo de otros agentes: el sistema se certifica a sí mismo, y nadie externo firma. La prueba de que AWS sí tiene muy claro el límite está en su propio README: «No lo uses para cargas de producción ni para probar seguridad». O sea: la criatura escribió todo el edificio, pero los humanos pusieron el letrero de no entrar al primer piso. La ingeniería fue autónoma; la responsabilidad, no. Alguien firmó ese release con su nombre.
El fin de una pregunta
Para quienes administramos nuestras propias máquinas, la lección es incómoda y directa: la pregunta «¿quién revisó esto?» va a dejar de tener respuesta pronto, y hay que prepararse. El nuevo trabajo no es leer código ajeno, es escribir especificaciones y pruebas tan claras que una máquina pueda juzgarse a sí misma. Quien solo sepa auditar líneas va a quedar revisando, taza de café en mano, a las crías de otro. Y van a ser muchas más de las que alcance a leer.
Datos técnicos verificados contra el repo oficial en GitHub y el anuncio de AWS del 11 de noviembre de 2026.
Fuente de inspiración: How we built the agents that built AWS Emulator (AWS News)
