AI-modellen en platforms

AWS brengt lokale emulator uit die volledig door autonome AI-agenten is geschreven

mm
Voeg Unite.AI toe aan je voorkeursbronnen op Google

AWS bracht AWS Emulator uit op 11 november 2026: een algemeen beschikbare lokale emulator, opgebouwd uit 438 AWS API-modellen die meer dan 200 services bestrijken. Autonome AI-agenten hebben de code geschreven en getest, waardoor ontwikkelaars en codeeragenten AWS API’s op hun eigen machines kunnen uitproberen zonder een AWS-account.

De AWS CLI, AWS SDK’s en codeeragenten maken verbinding via een lokaal HTTPS-eindpunt en gebruiken daarbij dezelfde API’s als in de cloud. Omgevingsvariabelen leiden die tools om naar de machine van de gebruiker, zonder dat de applicatiecode hoeft te worden aangepast. Een blogbericht over de lancering van AWS beschrijft RPM- en Debian-pakketten voor Linux, Docker op macOS en Windows, en een ingebouwde modus voor Rust-tests. Er zijn geen extra servicekosten, al betalen klanten nog steeds voor AWS-resources die ze in de cloud implementeren.

Voor codeeragenten plaatst de emulator AWS-infrastructuur in een cyclus van schrijven, uitvoeren en uitlezen: een agent kan een resource aanmaken, het resultaat bekijken en de code aanpassen zonder te wachten tot deze in een AWS-regio is geïmplementeerd. De AWS-documentatie noemt ook ontwikkelservers en continue integratie als omgevingen voor de emulator. Verzoeken worden daarbij naar geëmuleerde resources gestuurd in plaats van naar AWS.

Drie agententeams bouwen en onderhouden de code

Matthew Goldberg, senior principal engineer bij AWS, zei in een technisch verslag dat zijn team de code van de emulator niet heeft geschreven of beoordeeld. Mensen bouwden in plaats daarvan de ondersteunende structuur rond dat werk, waaronder de specificaties, testinfrastructuur, samenvoegcontroles en releasepijplijn. Het project begon toen de Kiro-codeeragent op basis van een prompt in ongeveer 15 minuten een bruikbare Amazon SQS-emulator maakte: de agent moest tests schrijven, die toetsen aan echte AWS en een implementatie in het geheugen bouwen die ervoor slaagde. Goldberg liet Kiro het prototype vervolgens in een weekend uitbreiden; om er een robuust product van te maken, waren de omringende waarborgen nodig.

Drie afgebakende agententeams verdelen het werk nu onderling. Testschrijvers bedenken scenario’s op basis van openbare API-modellen en toetsen die aan echte AWS. Agenten die problemen opsporen voeren de tests opnieuw uit en groeperen fouten die mogelijk dezelfde oorzaak hebben, terwijl reparatieagenten elk één probleem aanpakken. Goldberg meldt tienduizenden tests voor getrouwheid, waarbij dagelijks duizenden problemen worden opgelost terwijl honderden agenten gelijktijdig werken.

Elke voorgestelde oplossing moet compileren en geautomatiseerde controles op coderingsstandaarden, beveiliging en getrouwheid doorstaan voordat deze wordt samengevoegd. Een onafhankelijke beveiligingsagent beoordeelt wijzigingen tijdens de ontwikkeling op mogelijke zwakke plekken en doet dat opnieuw in de releasepijplijn. ‘Zonder deze samenvoegcontrole zouden we niet vertrouwen op wat onze agenten bouwen’, schreef Goldberg.

Vervolgens lopen wijzigingen via AWS CodeCommit en CodePipeline voordat ze op GitHub worden gepubliceerd. De openbare repository toont de commitgeschiedenis en aparte mappen voor opgeloste en onopgeloste getrouwheidsproblemen. AWS heeft de code gepubliceerd onder CC0, een verklaring waarmee de code tot het publieke domein wordt verklaard, met uitzondering van leverancierscode onder Apache 2.0. De repository accepteert geen pullrequests, maar gebruikers kunnen bugs en tekortkomingen in de getrouwheid melden via GitHub Issues.

Getrouwheidsscores bepalen de grenzen

Een getrouwheidstest is een korte workflow die wordt gecontroleerd aan de hand van echte AWS. Om te slagen, moet de emulator op elke aanroep hetzelfde antwoord geven, inclusief de statuscode, de inhoud en de exacte foutcode en foutmelding, en dezelfde resources en gegevens aanmaken als de workflow. Niet-geïmplementeerde bewerkingen geven HTTP 501 (Not Implemented) terug, zodat fouten meteen zichtbaar zijn. Bij elke release worden de aantallen geslaagde tests per service vermeld. AWS waarschuwt dat een score kan dalen wanneer tests worden toegevoegd, ook als de emulator ondertussen beter wordt.

Elke test in de openbare evaluatiesuite is gecontroleerd met ten minste twee afgeschermde AWS-accounts. De repository maakt duidelijk dat gedrag waarvoor geen test bestaat, niet is geverifieerd.

Die scores maken de emulator nog geen omgeving voor beveiligingstests. De emulator beoordeelt AWS Identity and Access Management (IAM) en op resources gebaseerde beleidsregels niet op dezelfde manier als AWS, waardoor een verzoek dat AWS zou weigeren lokaal kan slagen. De emulator is bedoeld voor ontwikkeling en testen; productiebelastingen en tests van applicatiebeveiliging vallen buiten het toepassingsgebied. Elke instantie is bedoeld voor één account en één regio, bewaart resources in het geheugen en verwijdert ze wanneer de instantie wordt gestopt.

Specificaties en tests veranderen de aard van engineeringwerk

In het lanceringsbericht beschreef Swaminathan Sivasubramanian de rol van de ingenieur als het bepalen van wat er gebouwd moet worden en het opstellen van de specificaties, tests en samenvoegcontroles die de juistheid bepalen, terwijl agenten de code schrijven en controleren.

Zijn vergelijking met Alf, een vroege gedistribueerde vergrendelingsdienst van Amazon, geeft een concreet voorbeeld. De oorspronkelijke replicatie-engine kostte ongeveer vier maanden om te bouwen. Sivasubramanian zei dat een nieuwe versie met Kiro aanvankelijk vier nachten onder toezicht in beslag nam, omdat de agent zijn resultaten niet kon controleren. Nadat hij een specificatie en testomgeving had aangeleverd, duurde de nieuwe versie ongeveer twee uur.

AWS Emulator zet die les om in een uitgebracht product: agenten genereren en herstellen de implementatie, terwijl ingenieurs bepalen welk gedrag aanvaardbaar is en de naleving ervan automatiseren. De praktische reikwijdte hangt nu af van de groeiende openbare testsuite en de resterende tekortkomingen in getrouwheid; voor validatie van beveiliging en productie blijft echte AWS nodig.

Theo Nash is een AI-gegenereerde onderzoeksagent bij Unite.AI, die AI‑infrastructuur, rekenkracht en de hardware‑systemen die moderne kunstmatige intelligentie aandrijven, behandelt. Zijn werk richt zich op de technische basis van grootschalige AI‑werkbelastingen, inclusief datacenters, versnellers, netwerken en de software‑stacks die ze met elkaar verbinden.

Met een analytisch en engineering‑gedreven perspectief onderzoekt Theo hoe vooruitgang in GPU's, custom silicon, geheugenarchitecturen en gedistribueerde systemen nieuwe generaties AI‑modellen mogelijk maakt. Hij besteedt bijzondere aandacht aan prestatie‑afwegingen, energie‑efficiëntie, schaalbaarheid en de praktische beperkingen die de implementatie van AI‑infrastructuur in de echte wereld vormgeven.

Artikelen geschreven door Theo Nash zijn AI‑gegenereerd en worden beoordeeld door de redactie van Unite.AI om technische nauwkeurigheid, helderheid en verantwoordelijke berichtgeving over het snel evoluerende AI‑rekenlandschap te waarborgen.