AWS lanza un emulador local creado íntegramente por agentes de IA autónomos

AWS lanzó AWS Emulator el 11 de noviembre de 2026, un emulador local de disponibilidad general creado a partir de 438 modelos de API de AWS que abarcan más de 200 servicios. Agentes de IA autónomos escribieron y probaron su código, lo que permite a desarrolladores y agentes de programación probar las API de AWS en sus propios equipos sin una cuenta de AWS.

AWS CLI, AWS SDK y los agentes de programación se conectan mediante un punto de conexión HTTPS local y usan las mismas API que utilizarían en la nube. Las variables de entorno redirigen esas herramientas al equipo del usuario, sin necesidad de modificar el código de la aplicación. Una publicación de lanzamiento de AWS detalla los paquetes RPM y Debian para Linux, Docker en macOS y Windows, y un modo integrado para pruebas de Rust. No hay cargos adicionales por el servicio, aunque los clientes siguen pagando por los recursos de AWS que implementen en la nube.

Para los agentes de programación, el emulador incorpora la infraestructura de AWS a un ciclo de escritura, ejecución y lectura: un agente puede crear un recurso, inspeccionar el resultado y revisar su código sin esperar a que se implemente en una región de AWS. La documentación de AWS también menciona los servidores de desarrollo y la integración continua como entornos para el emulador, cuyas solicitudes se dirigen a recursos emulados en lugar de a AWS.

Tres equipos de agentes crean y mantienen el código

Matthew Goldberg, ingeniero principal sénior de AWS, dijo en un relato de ingeniería que su equipo no escribió ni revisó el código del emulador. En cambio, las personas construyeron la estructura que rodea ese trabajo, incluidas las especificaciones, la infraestructura de pruebas, los controles previos a la integración y el flujo de publicación. El proyecto comenzó cuando el agente de programación Kiro creó un emulador de Amazon SQS aceptable en unos 15 minutos a partir de una instrucción para escribir pruebas, validarlas con AWS real y crear una implementación en memoria que las superara. Después, Goldberg pidió a Kiro que ampliara el prototipo durante un fin de semana; para convertirlo en un producto sólido hicieron falta las salvaguardas que lo rodeaban.

Ahora, tres equipos de agentes con funciones acotadas se reparten el trabajo. Quienes escriben las pruebas diseñan escenarios a partir de modelos de API públicos y los verifican con AWS real. Los agentes que buscan problemas vuelven a ejecutar las pruebas y agrupan los fallos que podrían compartir una causa raíz, mientras que los agentes correctores se encargan de un problema cada uno. Goldberg informa de decenas de miles de pruebas de fidelidad y de miles de problemas corregidos a diario, mientras cientos de agentes trabajan en paralelo.

Todas las correcciones propuestas deben compilar y superar comprobaciones automatizadas de estándares de programación, seguridad y fidelidad antes de integrarse. Durante el desarrollo, un agente de seguridad independiente revisa los cambios de forma adversarial y vuelve a hacerlo en el flujo de publicación. «Sin este control previo a la integración, no confiaríamos en lo que están creando nuestros agentes», escribió Goldberg.

Después, los cambios pasan por AWS CodeCommit y CodePipeline antes de publicarse en GitHub. El repositorio público muestra el historial de confirmaciones y carpetas separadas para los problemas de fidelidad resueltos y sin resolver. AWS publicó el código bajo CC0, una dedicación al dominio público, salvo el código de proveedores, que está bajo Apache 2.0; el repositorio no acepta solicitudes de incorporación de cambios, aunque los usuarios pueden informar de errores y deficiencias de fidelidad mediante GitHub Issues.

Las puntuaciones de fidelidad definen los límites

Una prueba de fidelidad es un flujo de trabajo breve que se verifica con AWS real. Para superarla, el emulador debe reproducir la respuesta a cada llamada, incluidos el código de estado, el cuerpo y el código y mensaje de error exactos, así como los recursos y datos que crea el flujo de trabajo. Las operaciones no implementadas devuelven HTTP 501 (No implementado), por lo que los fallos se detectan de inmediato. Cada versión incluye el número de pruebas superadas por servicio, y AWS advierte que añadir pruebas puede reducir una puntuación incluso cuando el emulador mejora.

Todas las pruebas del conjunto público de evaluación se verificaron con al menos dos cuentas de AWS aisladas, y el repositorio deja claro que los comportamientos que no cuentan con una prueba no están verificados.

Estas puntuaciones no convierten el emulador en un entorno para pruebas de seguridad. No evalúa AWS Identity and Access Management (IAM) ni las políticas basadas en recursos como lo hace AWS, por lo que una solicitud que AWS rechazaría podría tener éxito localmente. Su uso previsto es el desarrollo y las pruebas; las cargas de trabajo de producción y las pruebas de seguridad de aplicaciones quedan fuera de su alcance. Cada instancia está pensada para una sola cuenta y región, mantiene los recursos en memoria y los elimina al detenerse.

El trabajo de ingeniería se orienta a las especificaciones y las pruebas

En la publicación de lanzamiento, Swaminathan Sivasubramanian describió la función del ingeniero como decidir qué debe construirse y crear las especificaciones, las pruebas y los controles previos a la integración que determinan si algo es correcto, mientras los agentes escriben y comprueban el código.

Su comparación con Alf, un servicio de bloqueo distribuido de Amazon de los primeros tiempos, ofrece un ejemplo concreto. El motor de replicación original tardó unos cuatro meses en construirse. Sivasubramanian dijo que una reconstrucción con Kiro primero requirió cuatro noches bajo supervisión porque el agente no tenía forma de comprobar sus resultados; después de que le proporcionara una especificación y un entorno de pruebas, la reconstrucción tardó unas dos horas.

AWS Emulator convierte esa lección en un producto publicado: los agentes generan y reparan la implementación, mientras que los ingenieros definen el comportamiento aceptable y automatizan su cumplimiento. Su alcance práctico depende ahora del crecimiento del conjunto público de pruebas y de las deficiencias de fidelidad que aún persisten; para validar la seguridad y el uso en producción sigue siendo necesario recurrir a AWS real.