Pull to refresh

Comments 7

Человек держит в голове некое намерение: например, «хочу добавить кнопку оформления заказа». Потом проходит цикл: намерение → код → pull request → CI → код-ревью → merge.

сначала ты собираешь свой сраный код через CI и гоняешь тестами, междометие из пяти (трёх) букв, и только потом оформляешь PR, междометие из пяти (трёх) букв

Сейчас ругаемся "О, это #$@!% легаси и монолит", потом будем: "О, этот #$@!% нейрослоп!!!"

Не совсем понятно почему гонять те же самые тесты в CI/CD медленнее чем на виртуалке агента?

Изменятся и окружения для агентных проверок. Они станут более stateful: с заранее подготовленными зависимостями, прогретыми кэшами, локальным контекстом и сохранённым состоянием между итерациями. Иначе агентный цикл будет слишком медленным.

Сборочные кэши и сейчас есть, а stateful тесты пожалуйста не надо)

Кажется, следующим шагом будет сокращение участия человека внутри быстрого агентного цикла. То есть разработчику уже не придётся смотреть каждую итерацию изменений и каждый PR. Для этого появятся специализированные агенты. Можно легко представить такую агентную команду:

Васюки ?)

О чем статья ?

Мне кажется или пока все еще наивно считать что его можно отпускать без присмотра? Если не потому что фигни наделает то потому что сожжет все токены или деньги.

Поменял я как-то лет n назад название кнопочки - сборка, юнит тесты, деплой на дев, е2е тесты, деплой на тест. Асинхронно еще и перфонанс тесты... вы спросите а при чем тут ии и агенты? А куй его знает

Тезис про "валидацию внутри агентного цикла" интересный, но там есть скрытая проблема: агент валидирует собственный вывод с теми же слепыми зонами, с которыми он его генерировал. Если валидация переезжает внутрь агентного цикла, возникает вопрос: кто валидирует саму валидацию?

Агент-ревьюер может проверить тесты и код, но не весь контур исполнения - как CI запускает проверки, как устроена изоляция, какие состояния разделяются между прогонами.

Был практический кейс: после миграции JS → TS CI выглядел зелёным, тесты проходили, но Playwright подхватывал оба расширения и запускал один и тот же набор тестов дважды. С точки зрения "внутреннего агента" всё корректно - тесты зелёные.

Статья хорошо описывает переход к "continuous compute", но не поднимает слой observability этого контура. А без него агентный цикл может завершаться успешно и именно это будет проблемой.

Sign up to leave a comment.

Articles