AWS Emulator: código sin revisión humana

«El emulador lo han escrito enteramente agentes autónomos. Nuestro equipo no ha escrito ni revisado nada del código.»

Lo dice Matthew Goldberg, ingeniero principal sénior de Amazon Web Services, en el anuncio con el que AWS presentó el miércoles AWS Emulator: una copia local de sus servicios, gratuita, que cualquiera puede descargar y que está en dominio público.

La frase me sonó. En septiembre conté la historia de Moltbook, cuyo fundador presumía de no haber escrito «ni una sola línea de código» y que a los pocos días tenía su base de datos abierta a cualquiera. Dos meses después, la misma frase la firma una de las empresas que más saben de infraestructura del mundo, y aplicada a un producto que puede descargar cualquier desarrollador.

No me parece una contradicción, y explicar por qué es lo que más me interesa de la noticia.

Ilustración generada con IA para este artículo. No representa nada real de AWS ni de su emulador.

Qué es un emulador de AWS y para qué sirve

AWS es el mayor proveedor de nube del mundo: servidores, bases de datos, almacenamiento, colas de mensajes y varios cientos de servicios más, todos manejados por programa a través de su API. Cuando haces una aplicación que usa AWS, probarla tiene un problema: cada prueba habla con AWS de verdad. Hace falta una cuenta, cuesta dinero, es lento, y si una prueba crea algo y se le olvida borrarlo, lo pagas a fin de mes.

Un emulador es un programa que se hace pasar por AWS en tu propio ordenador. Tu aplicación cree que habla con la nube y en realidad habla con un proceso local que contesta lo mismo que contestaría AWS. Sin cuenta, sin factura, sin esperar.

No es una idea nueva. La herramienta de referencia durante años ha sido LocalStack, que tenía una edición gratuita muy usada. Pero desde el 23 de marzo de este año las versiones nuevas de LocalStack se distribuyen en una sola imagen que exige cuenta y token para arrancar, también en su plan gratuito. Las versiones antiguas de la edición libre se pueden seguir usando, pero ya no se actualizan. Desde entonces han aparecido varios proyectos libres que intentan ocupar su sitio. Ahora llega el propio AWS, gratis y sin pedir nada. El anuncio no menciona a LocalStack ni una vez, y tampoco le hace falta.

Cómo dicen que se hizo

Según el anuncio, todo empezó como un experimento de fin de semana con Kiro, el entorno de programación con agentes de la propia AWS: en quince minutos sacó una primera versión aceptable de SQS, su servicio de colas, y en el resto del fin de semana, un esbozo del resto de AWS. Lo que vino después ya no fue un fin de semana. Montaron tres equipos de agentes sobre el mismo repositorio:

• Los que escriben pruebas. Cada prueba es un escenario real —crear una cola, enviar un mensaje, recibirlo, confirmarlo, borrar la cola— que se ejecuta contra AWS de verdad y se graba, para poder repetirlo después sin volver a llamar a AWS. Dicen tener decenas de miles.
• Los que buscan fallos. Repiten esas pruebas contra el emulador, ven dónde contesta distinto y agrupan los fallos por causa.
• Los que arreglan. Cada agente coge un fallo y lo corrige. El arreglo solo entra si pasa un filtro automático: compila, cumple las normas de código, pasa las comprobaciones de seguridad y no empeora la fidelidad.

Hablan de cientos de agentes trabajando a la vez y miles de fallos arreglados al día. El repositorio en GitHub tiene más de 31.000 cambios, y solo el viernes 13 publicó tres versiones en siete horas, con más de cien arreglos en la última. Cada uno lleva un título como «ec2-createnatgateway-stub»: hasta ese día, la operación de EC2 que crea una puerta de enlace NAT era un stub, un hueco que responde sin hacer de verdad el trabajo.

Mi anécdota favorita del anuncio: una versión temprana, para poder ejecutar funciones Lambda escritas en Python, se escribió su propio intérprete de Python. Desde entonces a los agentes se les dice que reutilicen librerías existentes. Es exactamente lo que habría hecho un programador junior muy rápido y sin nadie al lado.

Por qué aquí sí puede funcionar

Lo que falló en Moltbook, lo conté entonces, no fue que la IA programara mal. Fue que la única prueba era «funciona»: abrías la aplicación, hacía lo que querías y la dabas por buena. La seguridad no aparece en esa prueba, así que nadie la echó de menos.

AWS Emulator tiene algo que casi ningún proyecto tiene: un juez que sabe la respuesta correcta. Para cada operación, la verdad está en AWS. Si creas una tabla de DynamoDB con un nombre demasiado corto, AWS te devuelve un error concreto, con un código y un mensaje concretos. La prueba no pregunta si el emulador «parece funcionar»: pregunta si contesta exactamente lo mismo que AWS, con el mismo código de estado, los mismos recursos creados y el mismo error cuando toca error. Y esa comparación la puede hacer una máquina, millones de veces, sin cansarse y sin opinar.

Eso cambia la naturaleza del trabajo. Un agente que escribe código sin revisión humana es peligroso cuando nadie puede decir si el resultado está bien. Cuando lo puede decir una prueba automática con respuesta conocida, buena parte del trabajo se convierte en un ciclo: escribir muchas pruebas, ejecutarlas muchas veces y arreglar lo que falle. Y repetir un ciclo sin cansarse es justo lo que se le da bien a una máquina.

Con un límite que conviene no olvidar: el juez solo opina de los escenarios para los que alguien ha escrito una prueba. Lo que ninguna prueba cubre puede funcionar bien o no, y nadie lo sabe hasta que lo usa. La propia documentación lo dice: las pruebas todavía no cubren todos los comportamientos.

No es que AWS haya descubierto cómo prescindir de la revisión humana. Es que ha encontrado un proyecto en el que la revisión la puede hacer, en buena parte, la propia AWS.

Los números, tal como salen

Con cada versión, AWS publica un fichero con el resultado de todas sus pruebas de fidelidad. He bajado el de la última, la 1.0.343, ejecutado el viernes 13 a media mañana, y he hecho las cuentas:

• 43.548 pruebas, repartidas entre 355 servicios.
• Pasan 26.605, el 61 %. Fallan 16.860, y 83 se saltan.
• 15 servicios lo pasan todo y 21 no pasan ninguna.

Por servicios conocidos (una prueba que toca dos servicios cuenta en los dos):

Un 61 % suena flojo, y para según qué usos lo es. Pero hay que leerlo bien. Primero, mide esa batería de pruebas, no toda la compatibilidad con AWS: lo que no tiene prueba no entra en la cuenta, ni a favor ni en contra. Y segundo, es el porcentaje de pruebas que reproducen exactamente el comportamiento de AWS, error incluido, y las pruebas las elige AWS para encontrar diferencias, no para quedar bien. La propia documentación avisa de que el emulador se parece más a AWS en las operaciones de gestión (crear, listar, borrar recursos) que en el uso real del servicio, y que el soporte para herramientas de infraestructura como CloudFormation o Terraform varía mucho. El 20 % de CloudFormation lo confirma.

Y conviene saber que no hay un número que valga dos días: es una foto de un proyecto que publica varias versiones al día.

Lo que el propio emulador dice que no hace

Aquí viene lo que más me ha gustado de la documentación. La página de seguridad empieza con un aviso destacado: no uses AWS Emulator para comprobar si tu aplicación es segura. Y explica por qué con una frase que lo resume todo:

El emulador nunca deniega una petición firmada con su propia clave.

Es decir: algunos servicios evalúan las políticas de IAM de los usuarios y roles que creas en el emulador, pero no igual que AWS; no mira las políticas de los buckets de S3 ni las de las claves de KMS, y no admite llamadas entre cuentas ni entre regiones. Una petición que AWS rechazaría puede funcionar en el emulador, y al revés. Si tu aplicación funciona en local, eso no dice nada sobre si tus permisos están bien puestos.

Fíjate en la coincidencia. La parte que el emulador declara fuera de su alcance es justo la que dejó abierta a Moltbook: el control de quién puede ver y tocar qué. No es que no se pueda emular. Las decisiones de permisos también se pueden comparar con las de AWS, y quizá algún día el emulador las reproduzca bien. Hoy es una limitación de este producto, no del método.

Pero ni con un emulador perfecto desaparecería el problema de fondo. El juez de AWS puede decir si el emulador decide como AWS. Lo que no puede decir es si tus políticas son las que querías poner. Esa pregunta no tiene una respuesta guardada en ninguna nube.

El resto de límites, también declarados:

• No es para producción. Es para desarrollar y probar.
• Todo vive en memoria. Al pararlo se pierde, y no está probado para cargas largas ni pesadas.
• La telemetría viene activada por defecto. Según AWS, no incluye el contenido de las peticiones ni datos personales, y se apaga con --telemetry off o con la variable EMULATOR_TELEMETRY=off.
• No acepta contribuciones. El repositorio lo dice tal cual: «no acepta PR». Puedes avisar de un fallo; el arreglo lo escribirá un agente.
• Los fallos conocidos están en una carpeta del repositorio, issues/things-that-do-not-work/, y los ya resueltos pasan a things-that-now-work/. El viernes había 6.769 pendientes y 13.530 resueltos, uno por fichero. Es una forma muy honesta de publicar los defectos.

Lo que no cuadra del todo

Tres cosas que conviene leer con cuidado:

• Miles o cientos. El titular del anuncio habla de «miles de agentes autónomos»; el texto, de cientos trabajando a la vez. Puede ser que hayan pasado miles en total y nunca más de unos cientos a la vez, pero no lo aclaran.
• «Cada línea de código». El emulador incluye una carpeta vendor/ con librerías de terceros, con licencia Apache 2.0. Es lo normal en cualquier proyecto, pero esas líneas no las escribió ningún agente de AWS.
• «Sin revisión humana» no quiere decir sin revisión. Hay un filtro automático muy exigente en cada cambio, y unas pruebas escritas contra el comportamiento real de AWS. Lo que no hay es una persona leyendo el código. Que no es lo mismo, y es lo que hace que funcione.

Un detalle más: el repositorio se creó en GitHub el 11 de septiembre, dos meses antes del anuncio. El «fin de semana» fue el principio, no el proyecto.

¿A quién le sirve?

Si desarrollas sobre AWS, probablemente te sirva ya para pruebas automáticas y para la integración continua, con una condición: comprobar antes que los servicios y operaciones que usas tienen buena nota. La documentación explica cómo hacerlo, y AWS publica también las pruebas de fidelidad para que veas qué se comprueba y qué no.

Y después, sin excepción, probar en AWS de verdad antes de producción. Sobre todo los permisos.

Si tienes una empresa y no sabes qué es SQS, esto no te cambia nada hoy. Pero sí te dice algo sobre cómo se va a hacer software en los próximos años.

El juez es lo difícil

La lectura fácil de la noticia es «la IA ya programa sola, sin humanos». La que yo me llevo es otra: la IA puede programar sola donde hay un juez automático que sabe la respuesta correcta. AWS ya tenía la referencia, porque es su propia nube. El trabajo fue construir las pruebas y los controles para que cientos de agentes pudieran aprovecharla.

La mayoría de los proyectos no lo tienen. ¿Cuál es la respuesta correcta de una web de reservas, de un formulario de contacto, de una tienda online? Está en la cabeza del cliente, en una normativa, en lo que pasará el día que alguien intente lo que nadie había previsto. Esa es la parte que no se automatiza con más agentes, y es justo la que faltaba en Moltbook.

Antes de decir «esto lo hace la IA sola», la pregunta útil es: ¿quién va a decir si está bien? Si la respuesta es una prueba que compara con algo que ya sabe la verdad, adelante. Si la respuesta es «se ve que funciona», volvemos a septiembre.