Комментарии 19
Пост, перечисляющий системные недостатки внедрения ллм заканчивается советами по внедрению ллм в работу 🤷
По факту ИИ сейчас похож на часто ошибающегося джуна. Ему можно делегировать рутину, но всё равно придётся проверять всё критичное.
Не могу согласиться. ИИ допускает множество специфичных ошибок, которыми даже джуны не "болеют". Ревьюить Джуна и ревьюить ai, два разных навыка. А вот ревьюить джуна с ai уже третий навык, так как временами у такого кода появляются эмерджентные свойства)
Код проще по структуре и менее разнообразен.
Так это же, вроде, хорошо?
Появляется 4х‑кратный рост “code cloning”: модель склонна копировать и чуть менять уже увиденные блоки, вместо того чтобы выделять абстракции и переиспользуемые компоненты.
Тыкаем носом и заставляем "осушать" (DRY). Хотя, кто ж на хайпе этим заниматься будет.
Качество ИИ-кода - это не проблема, если найти нужный баланс между ИИ и человеком, особенно если этот человек и сам умеет думать. И в этом плане ИИ намного сильнее джуна, потому что джун умеет делать джуновские задачи, а ИИ может набрать код для сеньорской задачи. То есть я думаю, пишу, что надо сделать, ИИ делает. Если бы это был джун, мне бы пришлось построчно диктовать ему код.
А ещё статья чудным образом обходит один интересный момент. Большинство ИИ-евангелистов — это одиночки. Они называют себя "солопренёрами" и делают "микропроекты". А по факту это обычные фрилансеры с типичными для фрилансеров проектами (это когда у клиента много хотелок, мало денег, и надо вчера). Вероятно, на этом рынке будет небольшое повышение спроса со стороны бизнеса - будут заказывать те самые "микропроекты" для автоматизации чего-нибудь. Но с другой стороны из-за ситуации на рынке труда количество таких фрилансеров будет расти. Из-за увеличения производительности труда проекты будут делаться быстрее, значит больше фрилансеров будет искать себе заказы, конкуренция вырастет, расценки упадут. С падением расценок упадёт качество. В итоге ничего не поменяется: есть деньги - иди заказывай софт у большой конторы с процессами и прочим, нет денег - заказывай ИИ-поделку у фрилансеров.
В плане фрилансеров, возможно вы правы. Но почему то и про качество разработки таких проектов то же умалчиваете.Обычно оно сильно отличается от энтерпрайза.
Конечно отличается, и далеко не в лучшую сторону. Кроме того, в большинстве случаев у фрилансерских проектов отсутствует стадия сопровождения. То есть написал, отдал и забыл. А потом, когда надо внести изменения, клиент полгода ищет, кто ещё согласится потыкать в это г-но палкой. В итоге найдётся кто-то, кто скажет "зачем вам это легаси, сейчас сделаем новое". И так по кругу.
Почему план «заменить разработчиков ИИ» превращается в техдолг и кадровый кризис.
Потому что это попытка бежать впереди паровоза. Да можно даже запрыгнуть на него спереди, но всё равно свалишься от холода.
И вот кто бы сомневался! Уже ясно всем, а некоторым было ясно с самого начала. Автору огромное спасибо за сводку статистики. Очень чётко и конкретно
Словосочетание "разработчиков ИИ" немного сбивает...
Хочу поручить джуну + LLM задачу:
Разделить на слои код визарда создания, клонирования, редактировался ддд агрегата со сложными бизнес правилами. (типичная задача для CRM, ERP). 5000 строк. Заодно устранить уязвимости. Скажем, 2 недели с 50% временем.
Как думаете, справится?
Срок самому лень: много тестов на завершении каждой фазы.
Примерный план:
Фаза 0: снапшот тесты (сохранить HTML со страничек?) Самый большой риск это регрессия. Ключевое: менять UX UI нельзя. Пользовательский опыт не меняется. Тут я участвую, часа 2 максимум.
Фаза 1. Убить eval(), который использовался для шаблонной обработки (читается из БД, отображения и т.п.) элементов интерфейса. Для этого: Конфиг-строки с кодом заменить на: JS/CSS-файлы (отдельно чтобы не сломать UX, UI при дальнейшем редактировании) декларативные описания полей с шаблонами по типам виджетов, типизированные DTO и валидаторы — по образцу уже существующего слоя сохранения.
Фаза 2. Окончательно разделить HTML/JS/PHP в остальной части кода: шаблоны, скрипты, логика — в разные файлы.
Фаза 3. Бэк - типизированные get, post model, чистая логика и состояние
Фаза 4. Анализ и устранение уязвимостей (хотя, на предыдущих шагах уже 90% будет устранены)
Компании всё равно нуждаются в опытных инженерах, но одновременно “рубят под собой сук”: если нет джунов, то и сеньоры не появятся внутри компании через 5–7 лет.
Дополнительная проблема: исчезают “учебные” задачи. Раньше джуны набивали руку на boilerplate-коде, сейчас эта работа делегируется AI-ассистенту, а от джуна ждут решения архитектурных задач без достаточной базы.
так в том-то и дело, как написано в статье чуть ниже - путь джуна меняется. 5-7 лет сжимается в 1-2 года.
Конечно, это уже будет другой "сеньёр". Но уровень задач, который он сможет эффективно решать, будет сеньёрский.
Делаю этот вывод на основе опыта руководства стажем у студентов в 2025 году. Если у молодого специалиста есть чёткое понимание, как эффективно использовать GenAI, он растёт очень быстро. Конечно, меньше опыта, основанного на "граблях и шишках", да и сами грабли уже другие, и зависимость от AI, но паника по поводу "откуда брать сеньёров", на мой взгляд, не оправдана.
Одно мне не понятно. Пусть ИИ пишет код который кожанные не могу понять и тем более проревьюрить, но если он закрывает свою задачу, укладывается в SLA производительности, и не содержить уязвимостей, то не все ли равно как его оценивают кожанные?
если он закрывает свою задачу
Например, если поисковик быстро отвечает, закрывает ли он задачу?
"Заказываю" ему словосочетание - он правильно сформулировал "техническую" часть полного ответа, но полностью опустил "литературную"?
Запрос (фразу из головы) подтвержден точной цитатой, но через несколько часов этой цитаты нет в выборке вообще...(?)
Если.

Почему план «заменить разработчиков ИИ» превращается в техдолг и кадровый кризис