С этими LLM одни проблемы — количество идей увеличилось в несколько раз. Когда их воплощать то?

Вторая проблема (связанная с первой), о которой мало говорят — как и многие современные технологии LLM вторгаются в стандартный культурно-обусловленный дофаминовый цикл. Если раньше в процессе работы над проблемой радость от решения проблем была размазана на длительность работы, то теперь за час разговора можно получить подробный план решения, и пачку тикетов в персональную (или не обязательно персональную) тикетницу на довольно рутинную реализацию.

У меня получилась такая эвристика: «если после разговора с LLM ты не почуствовал себя дураком, или не ушел из разговора с вооот такенным списком задач — ты поговорил зря» — знай эти задачи как-то приоритезируй и разгребай. Но в разгребании радости гораздо меньше чем собственно в поиске решения.

Навык «разбивать большую задачу на много маленьких, каждая из которых приносит пользу» становится еще более актуальным чем во времена пост-ватерфола: сейчас становится супер легко попасть в ловушку over-engeneering, причем сразу на множестве уровней одновременно: уровне описания проблемы, уровне описания концепции решения, уровне постановки задач, уровне проработки архитектуры решения, уровне определения и проработки границ между компонентами, уровне определения качества этих компонентов. Чуть промахнулся — получил тонны нейрослопа, который еще не сразу заметишь.
На уровне реализации все наоборот, хорошо — написал задание, модель тебе написала ответ. Но попутно тут же наплодила долга на всех перечисленных уровнях (и нескольких не перечисленных).

А если делать интероп LLM с человеком — чтобы по-очередно могли писать код и люди и LLM получается все еще более интересно, но об этом в другой раз.

Что любопытно, практики Devops описанные отцами-основателнями и далее превратившиеся в DX, Evolutionary Architecture, и частично Platform Engineering на концептуально-методическом уровне вполне неплохо помогут справиться с возросшей сложностью.
У тебя внезапно продуктивность команды разработки становится такой, что может делать десятки коммитов в день (хотя до этого хорошо если коммит в неделю).
Как вы думаете, станет ли после этого команда High Performer по DORA? Увеличится ли частота релизов, снизится ли Lead Time, снизится ли CFR?
Чем будут заниматься разработчики, которые внезапно «стали суперпроизводительными»?

Мне кажется, количество работы возрастет для всех:
- для разработчиков — нужно будет научиться разбираться не только в легаси-коде, но и в нейрослопе, и срочно учиться становиться техлидами
- для техлидов — появится головная боль как обеспечивать поддерживаемость и качество кода, которые до этого держались на их авторитете, опыте и peer review
- для девопс-инженеров — вариантов не интегрировать проверки (все какие можно) в пайплайны больше не осталось. Ну и запросов от команд разработки будет больше (если только не реализован self-service для них)
- для операционных менеджеров/менеджеров бэклога — количество технических задач без которых delivery не поедет значительно возрастет, и им придется научиться въезжать в технические вещи
- для руководителей в целом — кратно вырастет количество решений, которые им нужно будет принимать

Ну либо еще пока можно оставаться в древнем начале 21в, когда все писали код руками — кстати, тоже очень неплохой вариант, пока не появились подходы коллективной работы с участием LLM.

Всех с новым годом!