Команда AWS Hydro разрабатывает подход, при котором проверка кода ИИ-агентов происходит не только через тесты и ревью, но и на уровне компилятора. Цель звучит прагматично: не дать агенту, который уверенно написал десятки файлов, незаметно сломать логику распределённой системы. Для команд, уже пускающих генеративные инструменты в production-код, это важнее очередного обещания «писать быстрее».
Как сообщает The New Stack, в начале месяца команда Hydro представила новый способ проверять, сохраняет ли распределённая система корректность работы после изменений. Идея особенно актуальна на фоне coding agents: они способны быстро собирать патчи, рефакторить сервисы и дописывать интеграции, но не получают автоматически понимания всех инвариантов конкретной системы.
Обычный компилятор хорошо отвечает на вопросы более низкого уровня: совпадают ли типы, существуют ли методы, корректно ли собран код. Но в распределённых приложениях главные неприятности часто лежат выше. Один сервис может записать состояние раньше другого, обработчик — повторно принять сообщение, а обновление схемы — пройти без ошибки компиляции и проявиться уже под нагрузкой. Тесты помогают, но не перебирают все возможные порядки событий, задержки сети и повторы запросов.
Именно здесь команда Hydro пытается расширить привычную роль компилятора. Вместо проверки только синтаксиса и типов он должен участвовать в верификации свойств системы: например, не нарушает ли очередное изменение согласованность данных или ожидаемый порядок выполнения операций. Это не магическая кнопка «сделать распределённость простой» — такой кнопки индустрия пока не выпустила. Но это попытка перенести часть критичных проверок ближе к моменту написания кода.
Для ИИ-агентов такой слой защиты выглядит логичным. Агент может предложить правдоподобную реализацию, успешно пройти линтер и даже зелёные unit-тесты. При этом он способен не заметить правило, которое существует лишь в голове автора сервиса или в старой архитектурной заметке: нельзя повторно списывать средства, нельзя подтверждать заказ до резервирования товара, нельзя удалять запись до обработки связанного события. Чем больше автономии получает инструмент, тем дороже становятся подобные недосказанные правила.
Тренд уже заметен и без громких заявлений: разработка с ИИ постепенно смещается от автодополнения к делегированию задач. Сначала модель предлагает строку или функцию, затем — готовый pull request, а дальше ей поручают исправить баг или обновить зависимость в нескольких сервисах. На каждом следующем уровне возрастает не только скорость, но и площадь возможной ошибки. Поэтому проверка кода ИИ-агентов становится задачей не про недоверие к модели, а про инженерную дисциплину.
Подход Hydro также показывает, почему разговор об ИИ в программировании нельзя сводить к сравнению качества сгенерированного кода. Даже сильная модель не заменяет ограничения, которые команда формализовала и встроила в процесс. В зрелой разработке код проверяют несколькими слоями: типовой системой, статическим анализом, тестами, CI, ревью, мониторингом и ограничениями на выкладку. Верификация свойств распределённой системы может стать ещё одним слоем — особенно там, где цена ошибки измеряется не раздражённым пользователем, а потерянными данными, деньгами или простоем.
Для российских команд вывод достаточно приземлённый. Если агентам уже поручают изменения в бэкенде, полезно сначала выписать инварианты, которые нельзя нарушать, и понять, где они проверяются. Для части задач хватит контрактных тестов и схем API, для других понадобятся формальные модели или специализированные инструменты. Самое слабое место здесь обычно не сама генерация кода, а отсутствие явного ответа на вопрос: какое состояние системы считается корректным.
У компиляторов есть шанс стать не только арбитрами синтаксиса, но и частью защиты от слишком уверенных автоматизированных изменений. Вопрос в том, смогут ли команды описать свои бизнес-правила и распределённые инварианты достаточно точно, чтобы машина действительно могла их проверять. Без этого ИИ-агент останется быстрым исполнителем, которому всё ещё приходится верить на слово.
