Моделі та платформи ШІ
AWS випускає локальний емулятор, повністю створений автономними ШІ-агентами
Додайте Unite.AI до бажаних джерел у Google
11 листопада 2026 року AWS випустила емулятор AWS — локальний емулятор, доступний для загального використання й побудований на основі 438 моделей API AWS, що охоплюють понад 200 сервісів. Автономні ШІ-агенти написали й протестували його код, тож розробники та агенти для написання коду можуть перевіряти роботу з API AWS на власних комп’ютерах без облікового запису AWS.
AWS CLI, AWS SDK та агенти для написання коду підключаються через локальну кінцеву точку HTTPS, використовуючи ті самі API, що й у хмарі. Змінні середовища спрямовують ці інструменти на комп’ютер користувача, тож код застосунку залишається незмінним. У публікації про запуск AWS описано пакети RPM і Debian для Linux, Docker для macOS і Windows, а також вбудований режим для тестів Rust. Додаткової плати за сервіс немає, однак клієнти, як і раніше, платять за ресурси AWS, які розгортають у хмарі.
Для агентів, що пишуть код, емулятор вбудовує інфраструктуру AWS у цикл «записати — запустити — прочитати»: агент може створити ресурс, перевірити результат і змінити код, не чекаючи розгортання в регіоні AWS. У документації AWS серед середовищ для емулятора також зазначено сервери розробки та безперервну інтеграцію; запити в них надсилаються до емульованих ресурсів, а не до AWS.
Три команди агентів створюють і підтримують код
Старший головний інженер AWS Метью Голдберг розповів у звіті про роботу інженерної команди, що його команда ані писала, ані перевіряла код емулятора. Натомість люди створили інфраструктуру для цієї роботи, зокрема специфікації, механізми тестування, етапи перевірки перед злиттям і конвеєр випуску. Проєкт розпочався з того, що агент для написання коду Kiro приблизно за 15 хвилин створив прийнятний емулятор Amazon SQS у відповідь на запит написати тести, перевірити їх у справжньому AWS і побудувати реалізацію в пам’яті, яка б ці тести пройшла. Потім Голдберг доручив Kiro розширити прототип за вихідні; щоб перетворити його на надійний продукт, знадобилися супровідні механізми контролю.
Тепер роботу розподілено між трьома командами агентів із чітко окресленими завданнями. Автори тестів розробляють сценарії на основі публічних моделей API та перевіряють їх у справжньому AWS. Агенти пошуку проблем повторно запускають тести й групують збої, які можуть мати спільну першопричину, а агенти-виправлювачі беруться кожен за одну проблему. За словами Голдберга, є десятки тисяч тестів на відповідність, а сотні агентів працюють паралельно й щодня виправляють тисячі проблем.
Перш ніж зливати будь-яке запропоноване виправлення, воно має пройти компіляцію й автоматизовані перевірки стандартів кодування, безпеки та відповідності. Незалежний агент із безпеки під час розробки критично перевіряє зміни, а потім повторює перевірку в конвеєрі випуску. «Без цього етапу перевірки перед злиттям ми не довіряли б тому, що створюють наші агенти», — написав Голдберг.
Потім зміни проходять через AWS CodeCommit і CodePipeline, перш ніж їх опублікують на GitHub. У публічному репозиторії доступна історія змін, а також окремі папки для усунених і неусунених проблем із відповідністю. AWS опублікувала код за ліцензією CC0 — присвятою суспільному надбанню, — за винятком коду постачальників, на який поширюється Apache 2.0. Репозиторій не приймає запитів на злиття змін, однак користувачі можуть повідомляти про помилки й невідповідності через GitHub Issues.
Оцінки відповідності визначають межі можливостей
Тест на відповідність — це короткий сценарій роботи, перевірений у справжньому AWS. Щоб пройти тест, емулятор має відтворити відповідь на кожен виклик, зокрема код стану, тіло відповіді, точний код і текст помилки, а також ресурси й дані, створені під час виконання сценарію. Нереалізовані операції повертають HTTP 501 (Not Implemented), тому збої помітні одразу. У кожному випуску наводяться кількісні показники успішного проходження тестів для кожного сервісу, і AWS застерігає, що додавання тестів може знизити оцінку, навіть якщо сам емулятор удосконалюється.
Кожен тест із публічного набору для оцінювання перевірено щонайменше у двох ізольованих облікових записах AWS, а в репозиторії чітко зазначено, що поведінка, для якої немає тесту, не вважається перевіреною.
Однак ці оцінки не перетворюють емулятор на середовище для тестування безпеки. Він не перевіряє політики AWS Identity and Access Management (IAM) і політики на рівні ресурсів так, як це робить AWS, тож запит, який AWS відхилив би, локально може бути успішним. Емулятор призначений для розробки й тестування; виробничі навантаження та тестування безпеки застосунків не входять до сфери його застосування. Кожен екземпляр розрахований на один обліковий запис і регіон, зберігає ресурси в пам’яті й видаляє їх після зупинки.
Інженерна робота зміщується до специфікацій і тестів
У публікації про запуск Сვამінатан Сівасубраманіан описав роль інженера як визначення того, що потрібно створити, і підготовку специфікацій, тестів та етапів перевірки перед злиттям, які визначають відповідність вимогам, поки агенти пишуть і перевіряють код.
Як наочний приклад він навів Alf — одну з ранніх розподілених служб блокувань Amazon. Створення початкового механізму реплікації тривало близько чотирьох місяців. За словами Сівасубраманіана, перебудова за допомогою Kiro спершу зайняла чотири ночі роботи під наглядом, оскільки агент не мав змоги перевірити результати; після того як він надав специфікацію та тестове середовище, перебудова тривала близько двох годин.
AWS Emulator втілює цей урок у готовому продукті: агенти створюють і виправляють реалізацію, а інженери визначають прийнятну поведінку й автоматизують контроль за її дотриманням. Практична сфера застосування емулятора тепер залежить від розширення публічного набору тестів і усунення наявних прогалин у відповідності, тоді як перевірка безпеки та готовності до виробничого використання все ще потребує справжнього AWS.
