Пять инженерных решений, которые нужно принять до генерации кода с AI

[rumataestor]

Есть один нюанс. Все пять решений предполагают, что мы достаточно хорошо знаем существующую инфраструктуру. А зависимости могут прятаться где угодно, от конфигураций и фоновых задач до старых API, о которых уже никто не помнит. Я бы добавил нулевой этап. Инвентаризация зависимостей, проверка реального окружения и разделение фактов и предположений.

А то получается забавно. Мы учим AI не принимать инженерных решений вслепую, а сами иногда принимаем их на основании того, что нам рассказал AI. :) Как вы проверяете полноту исходных данных? Ведь самая неприятная зависимость обычно та, о существовании которой мы даже не подозреваем.

[vitaliifalkevych]

Согласен, инвентаризация зависимостей - необходимый нулевой этап. Причём проверять нужно не только код и конфигурации, но и реальные вызовы, фоновые задачи, логи и поведение системы в production.

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

Полноту зависимостей гарантировать нельзя, поэтому остаются регрессионные проверки и контролируемые релизы. Ответственность за систему нельзя делегировать AI.