Начну с того, что разработка — это не только программирование
Думаю тут нужно говорить о полном цикле производства/поддержки/развития программного продукта

Цикл строится так:
1 - идея
2 - декомпозиция до задач и их постановка
3 - собственно программирование
4 - тестирование и выкатывание в продуктовую среду
5 - возвращаемся к пункту 1

Поехали по пунктам
Идея:
Если это что-то новое и неведомое, то это работа человека, который должен идею донести до следующего этапа. Если же это какие-то количественное изменение, на которое способны ИИ, то это скорее не первый пункт, а пятый. Вначале всегда слово, и это слово сказал человек из мяса

Декомпозиция:
Вот тут, вероятно, можно усилить аналитиков нейросетями. Заменить не выйдет, толковые аналитики знают систему целиком (это то самое ограничение размера контекста в ИИ), а бестолковых уже выгнали, кризис на дворе.

Постановка задач в разработку:
Это большая боль, как не умели нормально ставить задачи так и не умеют. Вот то самое, про без ТЗ результат ХЗ — это этот пункт. И вот на этом этапе нужно начинать качать скилл производственной команды, а не привычно отдавать ее в следующий.

Вот оно, программирование, самое вкусное:
Мы привычно перегружаем проблему хреново поставленной задачи в разработчика, он ее как умеет описывает ИИ, получает кодосодержащий продукт.
— Проблема номер раз. Результат работает немного не так (аппендицит не с той стороны! Вы совершенно правы, сейчас вырежу с другой). Это немного очень тяжело отловить. Поскольку система в целом работает как хотелось
— Проблема номер два. Оно работает идеально. И это серьезнее чем первый случай, т.к. никто не вникает как оно работает и насколько модифицируемо в будущем. Это как раз тот случай, когда следующая итерация доработок будет просто разработкой с нуля.

Тестирование:
Вот тут можно писать автотесты по коду, e2e и т.д. с помощью ИИ. Пока это то, что получается наиболее хорошо. Возможно из за того, что со стороны это не настолько значимый этап, как программирование

Теперь вернемся к стоимости фичи:
Мы получаем нечто якобы работающее очень быстро. Вот прямо на порядок.
И на этом менеджмент счастлив, мы хотели фичу, мы получили фичу. Давайте посчитаем как мы сэкономили.
А то, что это творение работает только само по себе и не вяжется с другими компонентами проекта никого не волнует. Это заметается под коврик и объясняется тем, что «люди тоже формируют техдолг», не факт что потребуется дорабатывать (потребуется, 100% потребуется).

Но всегда наступает завтра, когда этот код нужно допилить. Интегрировать с другими частями проекта и т.д.
И вот тут выясняется, что его нужно делать заново. Никто не понимает как работает текущий код, менеджмент выдвигает аргумент о том, что «прошлую версию вон как быстро сделали» и снова вываливает это в разработку, которая опять творит какой-то MVP пошире, но такого же качества.
И вот этот цикл может продолжаться бесконечно, позволяя менеджементу отчитываться о героически-быстрой доставке фич на бой.

Очень частая фраза — нужен правильный промпт и тогда будет дешевле. При этом не видел измерений того, что будет, если разжевывать задачу не нейросети, а разработчику. Но почему-то для нейросетей стараются описать задачу, а людям и так сойдет )

Вот эта односторонняя математика создает впечатление того, что стало дешевле.

Ну и конечно есть огромный плюс от ИИ. Он тебе не скажет, что твою продукт ляжет, что его вот тут и тут могут подломать, что производительность никакая. В этом отношении нейросети гораздо приятнее инженеров.

Есть еще проблемы навырост:
— мы переквалифицируем разработчиков в промпт-инженеров. Они не пишут код, а донашивают что-то с чужого плеча. Эта проблема убивает те самые горящие глаза, которые все любят у соискателей. Разработчику приходится чаще менять фокус своей работы и теперь короткие итерации напряженной деятельности, от которых выходили в окна менеджеры разного звена, пришли и к ним.