Как спланировать инфраструктурную задачу и не сломать мозг: разбор на примере деплоя в AWS

[InsiderCrush]

Развернуть новый веб-сервис в AWS. У него React-фронтенд и Python-бэкенд, для работы нужен PostgreSQL. Есть github репозиторий с приложением .

Нет, спасибо! У нас у самих таких репозитариев три вагона у каждого, со своими nib-ами и иными IDE и харнессами. Вы нам покажите что именно создано с помощью ии-агента и оно гарантированно работает. Прямо вот ссылку кидайте. И распишите что лично Вы выиграли, привлекая ИИ-агента к деплою веб-сервиса на AWS. Или это процесс ради процесса? Пока что другие реальные кейсы, что нам тут показывают, таких работающих продуктов не готовы предъявить. Все больше тоже свои репозитарии гениальные пиарят и зовут попробовать.

[javdet12]

Спасибо за прямой вопрос, он справедливый: обещаний вокруг агентов сейчас больше, чем результатов, которые можно проверить.

Ссылки. Всё, что в статье сделал агент, лежит в открытом репозитории, и проверить это можно без запуска nib:

• PR #1: Terraform и два workflow, которые агент написал по плану, 20 файлов.

• Список PR: PR открываются под моим токеном, а ветки агента называются nib/<id диалога>. По ним видно, что сделано агентом, включая повторные итерации и исправления. Например, в PR #9 он чинил CloudFront, который подменял 404 от API страницей SPA.

• Actions: прогоны «Deploy to prod» этими workflow, удачные и упавшие.

«Гарантированно работает» я бы не сказал ни про агента, ни про инженера-человека. В статье прямо описано, где агент ошибся: OIDC-провайдер был создан без части thumbprints, и это всплыло только при первом запуске workflow. Поэтому в nib есть проверки с явно записанным ожидаемым результатом, план отката и обязательное ревью PR человеком.

Задачу я выбрал намеренно лёгкую и знакомую всем, кто работал с AWS. На ней видна механика (этапы, проверки, откат, исполнение), и читатель не отвлекается на предметную область. Дальше будут задачи сложнее, из тех, с которыми инфраструктурные инженеры сталкиваются в работе.

Terraform опытный инженер напишет и сам, поэтому главное для меня в другом:

• План появляется до начала работы и хранится не в голове. Здесь это четыре этапа, десять шагов, пятнадцать проверок и откат, на всё ушло около двух минут. Такой план можно обсудить, отдать на ревью или передать коллеге, если меня выдернули посреди задачи.

• Проверки не выпадают под дедлайн: они записаны заранее с конкретным ожидаемым результатом.

• Объём работы виден до старта, и на вопрос «сколько займёт» есть ответ точнее, чем «день-два».

• У разных людей в команде задачи идут по одному процессу: правила команды попадают в каждый план, который затрагивает соответствующую систему.

Моя цель — сделать инфраструктурную работу стандартизированной, наблюдаемой и измеримой. Если в вашей команде это уже выстроено без агента, nib вам, скорее всего, ничего не добавит, и это нормальный ответ.