AWS udostępnia lokalny emulator napisany w całości przez autonomicznych agentów AI

AWS udostępniła AWS Emulator 11 listopada 2026 r. To lokalny emulator o ogólnej dostępności, zbudowany na podstawie 438 modeli API AWS obejmujących ponad 200 usług. Autonomiczni agenci AI napisali i przetestowali jego kod, dając programistom i agentom kodującym możliwość korzystania z interfejsów API AWS na własnych komputerach bez konta AWS.

AWS CLI, pakiety AWS SDK i agenci kodujący łączą się przez lokalny punkt końcowy HTTPS, korzystając z tych samych interfejsów API co w chmurze. Zmienne środowiskowe przekierowują te narzędzia na komputer użytkownika, dzięki czemu kod aplikacji pozostaje bez zmian. Wpis AWS zapowiadający premierę zawiera informacje o pakietach RPM i Debian dla systemu Linux, Dockerze na macOS i Windows oraz trybie osadzonym na potrzeby testów w języku Rust. Usługa nie wiąże się z żadną dodatkową opłatą, choć klienci nadal płacą za zasoby AWS wdrażane w chmurze.

W przypadku agentów kodujących emulator umieszcza infrastrukturę AWS w cyklu tworzenia, uruchamiania i odczytywania wyników: agent może utworzyć zasób, sprawdzić wynik i poprawić kod bez oczekiwania na wdrożenie w regionie AWS. Dokumentacja AWS wymienia także serwery programistyczne i ciągłą integrację jako środowiska, w których można korzystać z emulatora; żądania są kierowane do emulowanych zasobów, a nie do AWS.

Trzy zespoły agentów tworzą i utrzymują kod

Matthew Goldberg, starszy główny inżynier AWS, powiedział w relacji z prac inżynieryjnych, że jego zespół ani nie napisał, ani nie sprawdzał kodu emulatora. Ludzie przygotowali natomiast infrastrukturę wspierającą te prace, w tym specyfikacje, mechanizmy testowania, bramki weryfikacyjne przed scaleniem oraz potok wydawniczy. Projekt rozpoczął się, gdy agent kodujący Kiro w około 15 minut stworzył działający emulator Amazon SQS na podstawie polecenia, by napisać testy, zweryfikować je z rzeczywistą usługą AWS i zbudować implementację działającą w pamięci, która je przechodziła. Następnie Goldberg polecił Kiro rozbudować prototyp w ciągu weekendu; przekształcenie go w niezawodny produkt wymagało odpowiednich zabezpieczeń.

Obecnie pracę dzielą między siebie trzy zespoły agentów o ściśle określonym zakresie. Autorzy testów opracowują scenariusze na podstawie publicznych modeli interfejsów API i weryfikują je na prawdziwym AWS. Agenci wyszukujący problemy ponownie uruchamiają testy i grupują błędy, które mogą mieć tę samą przyczynę, a agenci naprawiający usterki zajmują się pojedynczym problemem. Goldberg informuje o dziesiątkach tysięcy testów zgodności i tysiącach problemów naprawianych każdego dnia, gdy setki agentów pracują równolegle.

Każda proponowana poprawka musi się kompilować i przejść automatyczne kontrole standardów kodowania, bezpieczeństwa i zgodności, zanim zostanie scalona. Niezależny agent ds. bezpieczeństwa przeprowadza wrogą analizę zmian podczas prac, a następnie ponownie w potoku wydawniczym. „Bez tej bramki scalania nie ufalibyśmy temu, co tworzą nasi agenci” — napisał Goldberg.

Następnie zmiany przechodzą przez AWS CodeCommit i CodePipeline, zanim zostaną opublikowane w GitHubie. Publiczne repozytorium udostępnia historię commitów oraz osobne foldery z rozwiązanymi i nierozwiązanymi problemami dotyczącymi zgodności. AWS opublikowała kod na licencji CC0, będącej przekazaniem do domeny publicznej, z wyjątkiem kodu dostawców objętego licencją Apache 2.0; repozytorium nie przyjmuje pull requestów, ale użytkownicy mogą zgłaszać błędy i luki w zgodności za pośrednictwem GitHub Issues.

Wyniki zgodności wyznaczają granice

Test zgodności to krótki przepływ pracy sprawdzany na prawdziwym AWS. Aby go zaliczyć, emulator musi dopasować odpowiedź na każde wywołanie, w tym kod statusu, treść oraz dokładny kod i komunikat błędu, a także zasoby i dane utworzone w ramach przepływu. Niezaimplementowane operacje zwracają HTTP 501 (Not Implemented), dzięki czemu błędy są widoczne od razu. Wraz z każdym wydaniem publikowane są osobne wyniki zaliczonych testów dla poszczególnych usług, a AWS zastrzega, że dodanie testów może obniżyć wynik, nawet jeśli emulator działa coraz lepiej.

Każdy test w publicznym zestawie ewaluacyjnym został zweryfikowany na co najmniej dwóch odizolowanych kontach AWS, a repozytorium wyraźnie zaznacza, że zachowanie nieobjęte testem nie zostało zweryfikowane.

Wyniki te nie oznaczają, że emulator nadaje się do testowania bezpieczeństwa. Nie sprawdza on uprawnień AWS Identity and Access Management (IAM) ani zasad opartych na zasobach w taki sposób jak AWS, dlatego żądanie odrzucane przez AWS może lokalnie zakończyć się powodzeniem. Emulator służy do tworzenia i testowania; nie jest przeznaczony do obciążeń produkcyjnych ani testów bezpieczeństwa aplikacji. Każda instancja jest przeznaczona dla jednego konta i regionu, przechowuje zasoby w pamięci i usuwa je po zatrzymaniu.

Prace inżynieryjne przesuwają się w stronę specyfikacji i testów

We wpisie o premierze Swaminathan Sivasubramanian opisał rolę inżyniera jako określanie, co należy zbudować, oraz tworzenie specyfikacji, testów i bramek scalania, które wyznaczają kryteria poprawności, podczas gdy agenci piszą i sprawdzają kod.

Porównanie z Alf, wczesną rozproszoną usługą blokad Amazon, stanowi konkretny przykład. Zbudowanie pierwotnego mechanizmu replikacji zajęło około czterech miesięcy. Sivasubramanian powiedział, że przebudowa z użyciem Kiro początkowo wymagała czterech nadzorowanych nocy, ponieważ agent nie miał możliwości sprawdzania wyników. Gdy otrzymał specyfikację i środowisko testowe, przebudowa zajęła około dwóch godzin.

AWS Emulator przekształca tę lekcję w gotowy produkt: agenci generują i naprawiają implementację, a inżynierowie określają akceptowalne zachowanie i automatyzują egzekwowanie tych wymagań. Praktyczny zakres zastosowań emulatora zależy obecnie od rozbudowywanego publicznego zestawu testów i pozostałych braków w zgodności, a walidacja bezpieczeństwa i zastosowań produkcyjnych nadal wymaga prawdziwego AWS.