AWS lansează un emulator local scris în întregime de agenți IA autonomi

AWS a lansat AWS Emulator pe 11 noiembrie 2026, un emulator local disponibil în regim general, construit pe baza a 438 de modele API AWS care acoperă peste 200 de servicii. Agenți IA autonomi i-au scris și testat codul, oferindu-le dezvoltatorilor și agenților de programare posibilitatea de a testa API-urile AWS pe propriile mașini, fără un cont AWS.

AWS CLI, SDK-urile AWS și agenții de programare se conectează printr-un punct final HTTPS local, folosind aceleași API-uri pe care le-ar utiliza în cloud. Variabilele de mediu redirecționează aceste instrumente către mașina utilizatorului, fără a modifica codul aplicației. O postare AWS despre lansare prezintă pachete RPM și Debian pentru Linux, Docker pe macOS și Windows, precum și un mod încorporat pentru testele Rust. Nu există taxe suplimentare pentru serviciu, deși clienții plătesc în continuare pentru resursele AWS pe care le implementează în cloud.

Pentru agenții de programare, emulatorul aduce infrastructura AWS într-o buclă de scriere, rulare și citire: un agent poate crea o resursă, poate examina rezultatul și își poate revizui codul fără să aștepte implementarea într-o regiune AWS. Documentația AWS menționează și serverele de dezvoltare și integrarea continuă ca medii în care poate fi folosit emulatorul, cererile fiind direcționate către resursele emulate, nu către AWS.

Trei echipe de agenți construiesc și întrețin codul

Matthew Goldberg, inginer principal senior la AWS, a declarat într-o relatare despre activitatea de inginerie că echipa sa nici nu a scris, nici nu a revizuit codul emulatorului. În schimb, oamenii au construit infrastructura necesară pentru această activitate, inclusiv specificațiile, mecanismele de testare, porțile de control pentru integrarea modificărilor și fluxul de lansare. Proiectul a început când agentul de programare Kiro a creat un emulator Amazon SQS acceptabil în aproximativ 15 minute, pornind de la o solicitare de a scrie teste, de a le valida cu AWS real și de a construi o implementare în memorie care să le treacă. Apoi, Goldberg i-a cerut lui Kiro să extindă prototipul pe parcursul unui weekend; transformarea acestuia într-un produs robust a necesitat măsurile de protecție din jurul lui.

Trei echipe de agenți, cu responsabilități bine delimitate, împart acum munca. Autorii testelor concep scenarii pe baza modelelor API publice și le verifică folosind AWS real. Echipa care identifică problemele rulează din nou testele și grupează erorile care ar putea avea aceeași cauză principală, în timp ce agenții care le remediază se ocupă fiecare de câte o problemă. Goldberg raportează zeci de mii de teste de fidelitate și mii de probleme remediate zilnic, în timp ce sute de agenți lucrează simultan.

Fiecare remediere propusă trebuie să se compileze și să treacă verificările automate privind standardele de programare, securitatea și fidelitatea înainte de a fi îmbinată. Un agent independent de securitate analizează modificările în mod adversarial în timpul dezvoltării și din nou în conducta de lansare. „Fără această poartă de verificare, nu am avea încredere în ceea ce construiesc agenții noștri”, a scris Goldberg.

Modificările trec apoi prin AWS CodeCommit și CodePipeline înainte de a fi publicate pe GitHub. Depozitul public oferă acces la istoricul modificărilor și la dosare separate pentru problemele de fidelitate rezolvate și nerezolvate. AWS a publicat codul sub licența CC0, o dedicație în domeniul public, cu excepția codului furnizorilor, publicat sub licența Apache 2.0; depozitul nu acceptă cereri de integrare a modificărilor, însă utilizatorii pot raporta erori și lacune de fidelitate prin GitHub Issues.

Scorurile de fidelitate stabilesc limitele

Un test de fidelitate este un flux de lucru scurt, verificat pe AWS real. Pentru a trece testul, emulatorul trebuie să reproducă răspunsul pentru fiecare apel, inclusiv codul de stare, corpul răspunsului și codul și mesajul exacte ale erorii, precum și resursele și datele create de fluxul de lucru. Operațiunile neimplementate returnează HTTP 501 (Neimplementat), astfel încât eșecurile apar imediat. Fiecare versiune include numărul de teste trecute pentru fiecare serviciu, iar AWS avertizează că adăugarea de teste poate reduce scorul chiar dacă emulatorul se îmbunătățește.

Fiecare test din suita publică de evaluare a fost verificat folosind cel puțin două conturi AWS în medii izolate, iar depozitul precizează clar că un comportament pentru care nu există un test nu este verificat.

Aceste scoruri nu transformă emulatorul într-un mediu de testare a securității. Acesta nu evaluează politicile AWS Identity and Access Management (IAM) sau politicile bazate pe resurse în același mod ca AWS, astfel că o solicitare pe care AWS ar refuza-o ar putea reuși local. Utilizarea acceptată constă în dezvoltare și testare; sarcinile de producție și testele de securitate a aplicațiilor nu intră în domeniul de aplicare. Fiecare instanță este destinată unui singur cont și unei singure regiuni, păstrează resursele în memorie și le șterge la oprire.

Activitatea de inginerie se mută către specificații și teste

În postarea despre lansare, Swaminathan Sivasubramanian a descris rolul inginerului ca fiind acela de a decide ce trebuie construit și de a crea specificațiile, testele și porțile de verificare pentru îmbinarea codului, care stabilesc criteriile de corectitudine în timp ce agenții scriu și verifică codul.

Comparația sa cu Alf, un serviciu timpuriu de blocare distribuită al Amazon, oferă un exemplu concret. Construirea motorului de replicare original a durat aproximativ patru luni. Sivasubramanian a spus că o reconstrucție cu Kiro a necesitat inițial patru nopți de lucru sub supraveghere, deoarece agentul nu avea cum să-și verifice rezultatele; după ce i-a furnizat o specificație și un mediu de testare, reconstrucția a durat aproximativ două ore.

AWS Emulator transformă această lecție într-un produs lansat: agenții generează și repară implementarea, în timp ce inginerii definesc comportamentul acceptabil și automatizează aplicarea acestor cerințe. Utilitatea sa practică depinde acum de extinderea suitei publice de teste și de lacunele de fidelitate rămase, iar verificarea securității și validarea pentru producție necesită în continuare AWS real.