Предисловие
На написание данной статьи меня побудило несколько факторов:
Проблемы со сгенерированным кодом при работе в команде.
Возросшая когнитивная нагрузка.
Активное (насильное) внедрение со стороны CTO/менеджерского класса.
Да и в целом, с коллегами особо не подискутируешь, нужна аудитория побольше. На предложения поразмышлять, как правило, ловлю в свою сторону маркетинговые статьи от бенефициаров LLM, либо же весьма странные аналогии, которые я тоже рассмотрю в данной статье.
В целом, в данной статье я не пытаюсь (ладно, пытаюсь) переубедить кого-либо, мой посыл состоит в том, чтобы задавать больше вопросов и подумать о более чётких границах применимости AI/LLM в разработке.
Чего в статье не будет
Я не вижу причин не использовать LLM вообще. В них однозначно есть польза и они однозначно ускоряют некоторую рутину.
«Сгенерируй мне json для моков, вот схема контракта», «А что ты думаешь о…», «Видишь ли ты проблемы в этом куске кода…», «Вот ORM запрос, мне нужен аналогичный SQL на диалекте postgreSQL», «Я пишу на языке X, фреймворке Y, столкнулся с такой проблемой, вот лог, в чём причина и как я могу это пофиксить…»
Примеры запросов, которые, на мой взгляд, вполне валидны и LLM справляется с ними в большинстве случаев просто замечательно. LLM очень неплохи как second opinion. Поэтому, тотального хейта в сторону LLM здесь не будет.
А что в статье будет
В статье рассмотрю проблемы использования LLM в качестве основного инструмента. Ещё раз. Не second opinion tool, а основного инструмента, который сам пишет бОльшую часть кода в случае мерж реквестов на сотни и тысячи строк кода. А также, пограничные случаи, когда, разработчик, якобы, читает сгенерированный код и контролирует агента.
Проблемы
1. Сгенерированный код при работе в команде
Мерж реквесты. LLM генерируют много кода, LLM не способны продумать фичу глубоко, LLM не способны сформировать пул вопросов и сходить к продактам/дизайнеру/аналитику за дополнительной информацией, которая может помочь продумать и написать более простой, более интуитивно-понятный код.
LLM пишут код только для текущего запроса, их не интересует что будет завтра, их не интересует роадмап, не интересуют последствия для соседних сервисов/модулей. В итоге мы видим много кода на маленькую фичу в мерж реквесте.
Через несколько дней приходит запрос на добавление ещё одной фичи в тот же модуль и LLM перелопачивает весь код и снова прилетает дифф на +1500 -1400. Читать такие объёмы так часто просто невозможно. Это не то что снижает скорость разработки, это просто сводит все плюсы на нет. Это увеличивает темпы изменения кодовой базы, скорости становятся неподъёмными для мозга.
Через несколько таких итераций я перестаю понимать сервис, в котором ещё вчера сносно разбирался и мог быстро пофиксить какие-то внезапные баги из-за глубокого понимания кодовой базы. А теперь и на фикс багов будет уходить гораздо больше времени. Когнитивная нагрузка взлетает до небес. Разработчик должен был бороться со сложностью, но случилось ровно наоборот.
В итоге качество ревью падает. А, соответственно, качество кода и качество релизов/продукта в целом.
2. Возросшая когнитивная нагрузка
Этот пункт перекликается с предыдущим. Однако, я хотел бы сконцентрироваться немного на других вещах. На 2026 год большинство акторов IT-мира по-прежнему недооценивают уровень когнитивной нагрузки. Который, в свою очередь, влияет и на эмоциональную нагрузку и на здоровье разработчика в целом.
На сегодняшний день разработчик в ежедневной работе использует тонны различных инструментов, которые требуются помимо знаний самого языка. Это линтеры, форматтеры, контейнеры, CI/CD пайплайны, таск-трекеры, методологии, фреймворки, различные архитектуры и прочие солиды, тайпчекеры, инструменты для нагрузочного тестирования, эмуляторы, системы версионирования, базы данных, брокеры и прочее, прочее, прочее.
Не говоря о том, что сами языки усложняются. Я ещё не видел, чтобы какой-то язык упрощался. Вчерашний объектно-ориентированный язык сегодня уже вовсю гоняет ветки паттерн-матчингом вместо привычных ифов. На знакомство со всем этим зоопарком нужны месяцы, а на овладевание нужны годы.
И это всё было вчера. А сегодня добавился ещё один инструмент, LLM. Который отличается от всех других. Его интерфейс меняется слишком быстро. Границы его применения размыты. Думать некогда, ты должен использовать, или завтра рынок выкинет тебя — гласит уже каждый второй — от главы LLM-провайдера до твоего коллеги, и, в целом, уже каждой второй вакансии (если не первой).
LLM генерирует код быстро. Его надо прочитать, понять, его надо снова поправить, снова прочитать, понять, снова поправить. Никто и не задумывается, а может ли вообще мозг работать в таком темпе. Но, как обычно, думать некогда, фичу обещали зарелизить ещё вчера.
3. Активное (насильное) внедрение со стороны CTO/менеджерского класса
Тут всё как обычно. Менеджмент руководствуется хайпом. Менеджмент более склонен к карго-культу. Получив вчера прибыль +x, сегодня они уже думают о +10x. И ничего их не остановит. Ни апелляции к статьям, фактам, ни разъяснение принципов работы, ни описание проблем, ни вопросы о том, что мы будем делать со сгенерированным кодом через полгода, ничего.
Но, в отличие от любого другого хайпа, этот особенный. Он заражает мозги даже самых умных из нас. Очень много CTO, техлидов, тимлидов, будучи вчерашними инженерами, уже не могут излечиться от этой болезни. В целом, оно и понятно. С одной стороны на них давит вышестоящий менеджмент. А с другой стороны, LLM генерируют ну уж очень правдоподобный код.
Немного о теории
Многие ссылаются на эту статью и я не стану исключением. Статья от Peter Naur, Programming as Theory Building.
В ней автор говорит о том, что существенную роль в разработке занимает построение теории в голове. Теории о том, как связаны между собой различные компоненты системы, как построенная модель отражает заложенные в неё бизнес-процессы, насколько гибкой является текущая модель, различные трейдоффы и так далее.
И всё это в головах разработчиков. Часть этого можно уложить в документацию, в спеки, в комментарии, но, так или иначе, с приходом на проект новых разработчиков им необходимо строить всю эту теорию в голове с самого начала. И на это уходит масса времени, в том числе, коммуникация будет отнимать время и у коллег.
Документация это хорошо, но документация, во-первых, далеко не всегда является истиной. Скорость разработки может превышать скорость написания документации. Кто-то скажет, что для написания документации может помочь LLM. Но, LLM не напишет в документации, почему какой-то класс был имплементирован именно таким образом и как это повлияло на соседние классы, хотя это может быть критически важно для последующего развития функционала. Никто не проверяет, что там пишет LLM.
А если абстрагироваться, то мы можем и вовсе перейти к максимально формальному языку — математике. Диффуры или Теория полей расписаны давно и очень подробно.
Во-первых, позволяло ли это кому-то применять их на практике, решая задачи без построения этих теорий у себя в голове?
Во-вторых, много вы видели людей, истолковывающих диффуры абсолютно одинаково?
А это максимально формальный язык. Что уже говорить о прикладных вещах и бизнес-логике. Поэтому, даже в случае подробной документации и качественного кода человеку понадобится определённое время, чтобы вникнуть в суть проекта.
В конце статьи можно найти некоторые научные исследования на данную тему.
Вопросы к текущему состоянию LLM
Все мы видим и ощущаем на себе мощное давление маркетинга LLM и AI инструментов в целом. Однако, давайте чуть отвлечёмся от новостей про «вышла новая x.yz версия сети ABC, которая в e^100000 раз лучше всех предыдущих вместе взятых» и посмотрим на результат влияния LLM на разработку с другой стороны.
Уже несколько лет нас заверяют в том, что скоро не останется работы для разработчика. То есть, всё за нас будут делать LLM. Однако, а что происходит с продуктами, что происходит с тулингом, с языками программирования?
Может быть, появились какие-то более быстрые, надёжные базы данных, написанные LLM?
Может быть, уже всё переписали на rust и больше нет проблем с electron-based приложениями, пожирающими тонны памяти?
IDE перестали тормозить при простом вводе?
Дописали Wayland и больше не осталось проблем?
Может, в cpython с помощью LLM внесли существенные оптимизации и он догнал по скорости компилируемые языки?
Что там с браузером от Anthropic?
А что с Bun, в проде не крашится?
Так вот, вопрос: а где тонны продуктов? Когда уже каждый разработчик станет сам себе предпринимателем?
Да, слышно об отдельных успехах небольших вайб-проектов, но, это зачастую либо небольшие проекты, приносящие что-то на уровне middle/senior программиста, а то и меньше, либо… совсем единичные случаи, которые ещё надо хорошо проверить. А что в опенсорсе нового интересного? Как-то за 2025/2026 на гитхабе не густо в этом плане.
Реальные боттлнеки
Как-то без предварительного объявления все вдруг решили, что самым главным боттлнеком в разработке является написание кода. Не очень понятно, на каких исследованиях это основано. Вимеры с 10-пальцевым методом печати не убедили индустрию.
Что забыли/не понимают/не хотят видеть заказчики:
Дизайн программы/сервисов — от классов и методов, до system дизайна всего продукта.
Коммуникация с продактами, дизайнерами, аналитиками, коллегами.
Поиск решений.
QA написанного кода. Да, разработчики тоже тратят время на тестирование, перед тем, как отдать тестировщикам.
Документация, проблем солвинг, продумывание и предугадывание различных событий, способных повлиять на нагрузку сервиса, на его поведение при исключительных случаях.
Всё это занимает массу времени. Нет, LLM этого не делает, либо делает не очень хорошо.
Просто постройте мысленный эксперимент. Пусть это всё делает не LLM, а личный senior-раб. Несмотря на какие-то успехи, ответственность лежит на нанятом разработчике. И для поддержания этой ответственности ему необходимо быть убеждённым в верности решений. Чтобы перенести это в свою голову, всё равно потребуется значительное время.
Аргументы ИИ-адептов
1. «Представь, что у тебя команда из 10 мидлов/сеньоров. Так вот, агенты это тоже самое»
Нет, это не то же самое. Я имею опыт работы тимлидом порядка 2.5 лет. Не очень много, но выводы и различия провести мне не сложно:
Ответственность. Команда действительно несёт ответственность за работу. Каждый член команды мотивирован (зарплатой) и демотивирован (потенциальными штрафами или увольнением). А в жизни ипотеками, кредитами, потребностями и т. д. Его мотивация и демотивация обязывают нести эту ответственность. Он не скажет «Ой, вы правы, вот правильное решение» 10 раз за час.
Предсказуемость. Из первого пункта вытекает предсказуемость. Каждый член команды становится предсказуемым спустя некоторое время (~испытательный срок). Тимлид понимает технический уровень, скорость разработки, степень соучастия в разработке и кучу других характеристик. Любому члену команды невыгодно быть непредсказуемым. Поэтому, тимлид знает, что можно ожидать от человека. LLM же непредсказуема и максимально хаотична. Она забывает контекст, она повторяет те же ошибки, она не умеет отступать. А обновления только добавляют хаоса.
2. «Все используют и мы должны обязательно использовать»
Тут обычный карго-культ, аргументы не спасут. НО. Пожалуйста. Давайте всё же попробуем задавать чуть больше вопросов перед тем, как что-то тащить к себе.
3. «Но ведь LLM ускоряют разработку. Да плевать что там будет с проектом/сервисом через 3-6-9 месяцев, сейчас же все рады и довольны»
Нет, я не доволен. Мне больно ревьюить мерж реквесты на тысячи строк в диффе. Мне больно, что не остаётся людей, понимающих код. И, самое главное, фан. А какое тогда удовольствие от генерации кода? При написании кода руками я постоянно получаю хоть какой-то дофамин (отбивая тонны кортизола, полученные будучи junior/middle’ом).
Тонны кода, который не понимает никто, прямо влияют на бизнес и продукт. Кривая maintainability, будучи прямой какое-то время, через некоторое время взлетает до небес. И вот релиз фич затягивается всё дольше и дольше. Баги проявляются чаще, а как их чинить — никто не понимает. Нормальному здоровому бизнесу тоже ведь как вода нужна предсказуемость от проекта и разработки.
Пограничные случаи
Тут всё сложнее. Что я бы сюда отнёс: LLM пишет код, но, разработчик более-менее ревьюит свой код. На возражения о возросшем количестве строк в мерж реквестах и частых переписываниях тех же участков кода отвечает «Посмотри МР по диагонали», «Этот модуль не так критичен» и т. д.
На мой взгляд, случай для продукта всё же рискованный. Может, имеет место быть для сервисов, которые стоит один раз написать и забыть, но не более того. Вероятность ошибок всё же повышается, смысл от ревью испаряется. Ответственность может начать размываться. Можно начать слышать что-то вроде «Это ЛЛМка подкинула баг», «ЛЛМка накосячила с конфигом» и т. д.
Считаю, что ответственность всегда должна лежать на разработчике. В случае с проблемами, приходящими от других инструментов, будь то CI/CD, компоненты инфраструктуры или даже редактор кода — подобный аргумент валиден. Мы доверяем коллегам, времени жизни проекта, ментейнерам, компаниям и так далее и понимаем, что не бывает софта без проблем. Однако, всё же продолжаем доверять до какой-то критической точки. Критической точкой может служить банально то, что инструмент не подходит под особые нагрузки текущего продукта. Но, мы всё же имеем отзывы реальных людей, что в остальных случаях инструмент работоспособен.
Но с генерацией LLM мы такого позволить не можем — у нас нет инструментов, оценивающих риски и вероятность проблемного кода. И, я считаю, любое размытие ответственности в данном случае ведёт к рискам и проблемам. Как с точки зрения понимания разработчиком продукта, так и в целом доверия к разработчику.
Выводы
LLM не стабильны. Нет инструментов, позволяющих определить/повысить/как-то работать с уровнем доверия от LLM. Это наблюдали год назад на Test-Driven AI Development, которое я не хочу комментировать и исследовать, потому что оно испарилось как сущность. Сегодня у нас есть SPEC-Driven Development, по поводу которого я не питаю особых надежд, ибо, опять же, я не вижу что каждый разработчик стал предпринимателем и не вижу наплыва качественных проектов в опенсорсе.
С использованием LLM в качестве генератора основной кодовой базы теряется и уровень доверия к разработчику и понимание кодовой базы и проблем и продукта самим разработчиком. Это негативно влияет на когнитивную нагрузку, может усилить вероятность выгорания. Есть немалые риски использования на долгосрочных проектах.
Просто повторюсь фразой из статьи: давайте всё же попробуем задавать чуть больше вопросов прежде чем тащить что-то новое в разработку.
Ссылки
Peter Naur. Programming as Theory Building. Microprocessing and Microprogramming, Vol. 15, Issue 5, 1985, pp. 253–261. — pages.cs.wisc.edu/~remzi/Naur.pdf
Teun A. van Dijk, Walter Kintsch. Strategies of Discourse Comprehension. Academic Press, 1983. — discourses.org
Nancy Pennington. Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs. Cognitive Psychology, Vol. 19, Issue 3, 1987, pp. 295–341. — doi.org/10.1016/0010-0285(87)90007-7
Комментарии (131)
ooko
17.07.2026 11:45Сейчас ИИ это как врач. Если спросить какая температура у пациента то в лучшем случаи он откроет мед-карту, а если такой нет то вычислит 36.6
Но если попросить измерить ...
<tool name="get_temperature"> <patient>Иван Иванов</patient> </tool>Думаю сейчас ещё нет понимания какая роль программиста в связке с ИИ. С одной стороны хотят чтобы ИИ все писала сама и быстро. С другой повесить ответственность на программиста.
Rub_paul
17.07.2026 11:45Ответственность всегда будет на человеке до тех пор, пока юристы не придумают легальный способ сажать в тюрьму алгоритмы за убытки бизнеса
xSVPx
17.07.2026 11:45Мм, у кого-то такой контракт, что в случае убытков бизнеса он сядет ? У инженера?
select26
17.07.2026 11:45У любого инженера подписавшего акт КС14. Или любой другой акт ввода в эксплуатацию системы жизнеобоеспечения.
xSVPx
17.07.2026 11:45Убытков бизнеса ?
Вводя что-то в эксплуатацию ты должен проверить это по списку. И отвечаешь только за соответствие реальности этому списку. Ни за какие убытки ты уж точно не отвечаешь.
404Family
17.07.2026 11:45"С одной стороны хотят чтобы ИИ все писала сама и быстро. С другой повесить ответственность на программиста. "
Не знаю почему, но в этот момент я вспомнил проблему вагонетки.
Только немного с другими данными.
Вместо вагона - авто
Вместо человека - ИИ
Внимание, вопрос - кто будет отвечать за последствия действий в случае его ошибки? Разработчик? а может быть компания или ген дир?
Ответ не верный, отвественность вся только на юзере. Уже реализовано что в последний момент управление ситуацией ИИ передает пользователю, к примеру тесла.
WhiteBehemoth
17.07.2026 11:45В общем и целом мы в команде пришли к такому же заключению: ИИ - инструмент разработчика, не его замена. По, крайней мере, пока. И ускорение даёт заметное, но не кратное. Опять же, пока.
А когда (если) сможет стать заменой, нужно будет еще посчитать, что выгоднее. ИИ супер-агент, который сможет заменить человека, запросто может выйти за рамку условных "10К долларов в месяц"
kenoma
17.07.2026 11:45Если у вас бюджеты 10к в месяц, то повод задуматься об on-prem решениях и в целом, правильнее вкладываться именно в локальные иишки. Тогда вопросы “что выгоднее” в принципе уместны.
WhiteBehemoth
17.07.2026 11:45нынешние бюджеты - пара сотен на подписку. Это на одну-две серьезных задач.
Я имел в виду если строить полноценную "замену" (например для замены меня), для решения задачи от этапа "клиенты хотят вот такую фичу" до деплоймента всех компонентов, итоговая стоимость такого супер-агента в месяц запросто может быть тысячами в месяц, сопоставимыми с ФЗП. Даже если говорить об локальных решениях - датацентры - решение недешевое.
funca
17.07.2026 11:45Сервер стоит от $250K и это лишь часть TCO. При бюджете в $10K такая затея ни когда не окупится. On-prem сейчас кратно дороже, чем платить за подписку вендорам - даже если речь о токенах. С ним связываются из других соображений.
Если вы имеете ввиду запуск моделей на обычном пользовательском оборудовании, то в плане скорости и качества результата это сильно нишевая штука.
kenoma
17.07.2026 11:45Два года подготовки около 6 джунов обойдутся в эту сумму. но при этом оборудование сразу будет перформить на хорошем уровне.
funca
17.07.2026 11:45Оборудование само по себе ни чего делать не будет. К нему в придачу, нужен персонал, со специфичным скиллсетом для настройки, обслуживания и решения проблем - нюансов здесь масса, а картинка на рынке меняется каждый месяц.
В разработке я тыркаю одного агента. Он периодически запускает в параллель ещё несколько десятков. Потом все это схлопыватся обратно. А ночью мне они вообще не нужны. Если компания решит использовать On-prem,.то им придётся заложить кратное резервирование и запас мощности. Либо мне часами ждать своей очереди для доступа к не самой умной модели.
WordEngineer
17.07.2026 11:45Пункт про рост когнитивной нагрузки - это как раз то, что реже всего обсуждают в маркетинговых текстах про LLM. Диффы на +1500 -1400 в мерж-реквесте я видел сам, и да, ревью такого объема быстро превращается в формальность, потому что мозг физически не успевает построить модель изменений за разумное время. Согласен и с отсылкой к Науру: теория программы в голове разработчика не заменяется документацией, а LLM только ускоряет накопление кода, под который эту теорию никто не строил. Спорный момент - аналогия с командой мидлов. Предсказуемость и правда ключевое отличие: у человека есть репутация и последствия за косяк, у модели нет ни того ни другого. Но совсем отказываться от агентов, по-моему, тоже не вариант: для изолированных модулей с четкими границами, вроде утилит или тестов, риск размывания ответственности минимален, а выигрыш по времени реальный. Проблема начинается там, где агент лезет в core-логику, которую потом три месяца никто не может объяснить новому человеку в команде.
Femistoklov
17.07.2026 11:45Диффы на +1500 -1400 в мерж-реквесте я видел сам, и да, ревью такого объема быстро превращается в формальность, потому что мозг физически не успевает построить модель изменений за разумное время.
За пару дней прекрасно всё понимается и строится, и не превращается в формальность, если ответственно подходить к своей работе.
SabMakc
17.07.2026 11:45А генерятся такие дифы за пару часов (если не за пару десятков минут).
Femistoklov
17.07.2026 11:45Ну, если они качественные - в чём проблема? Просто будет основной человекоресурс тратиться на ревью, а не написание. Если сильно некачественные - после второго такого диффа человеку ставится ультимативное требование не присылать больше подобное на ревью, если не может - поднимается вопрос о квалификации.
SabMakc
17.07.2026 11:45Если они качественные - то ни в чем. Проблема в этом “если” и в том, чтобы понимать “а что в коде творится”. Именно на это время уходит. Даже при условии качественных дифов.
P.S. Хотя диф НОВОЙ ФИЧИ на +1500 -1400 не может быть качественным - слишком много изменений означает, что разраб (ИИ) влез не в свою задачу, а занялся рефакторингом.
Femistoklov
17.07.2026 11:45Если они качественные - то ни в чем. Проблема в этом “если” и в том, чтобы понимать “а что в коде творится”. Именно на это время уходит. Даже при условии качественных дифов.
Что поделать, никто не говорил, что разработка - это легко. Идеальные итерации, где каждый следующий МР инкапсулирует только свою часть и не меняет предыдущие, я видел только в наивных книжках.
P.S. Хотя диф НОВОЙ ФИЧИ на +1500 -1400 не может быть качественным - слишком много изменений означает, что разраб влез не в свою задачу, а занялся рефакторингом.
Вполне может, например, если проект весь в легаси и техдолгах. И такое бывает.
SabMakc
17.07.2026 11:45Вполне может, например, если проект весь в легаси и техдолгах. И такое бывает.
Бывает. Но тогда рефакторингом надо целенаправлено заниматься, а не под видом новых фич. И да, бывает что под фичи выделяется время, а под рефакторинг - нет. И тогда приходится выкручиваться.
Мы все еще о ИИ спорим или о “что бывает в разработке”? У ИИ +1500 -1400 может быть и для задачи вида “поменять цвет кнопки”.
ИИ в целом склонен больше кода генерировать - и на ревью уходит больше времени. А самое главное - ИИ может оставить подвох в самых неожиданных местах. Поэтому ревьювить надо гораздо внимательнее.
Femistoklov
17.07.2026 11:45О больших диффах.
Про ИИ не знаю, не было такого опыта. Думаю, что наилучший выход - спрашивать с человека без оглядки на то, с ИИ он код писал или нет, и соотв. поблажек не делать. Постоянные "+1500 -1400" для “поменять цвет кнопки” - предупреждение. Лишний код - предупреждение. Тяжело читать - предупреждение. Несвойственные для человека ошибки - суровое предупреждение. Игнорирование предупреждений, повторение одних и тех же ошибок - профнепригоден.
SabMakc
17.07.2026 11:45Так о том и статья - ответственность остается на человеке. А значит человек должен внимательно контролировать и направлять ИИ. И ни о каких x10 к производительности речи уже не идет в принципе (хотя в некоторых случаях и вполне достижимо - как раз рефакторинг сюда относится (задаваемый и контролируемый разрабом), где много монотонной работы).
GrigorGri
17.07.2026 11:45Кстати, можете поделиться с какими инструментами получились такие диффы? У меня под claude code почти всегда противположная проблема, генерирует постоянно новый код, почти не меняя существующий, что приводит к разрастанию код базы которую в итоге нужно отдельно. Ну и в целом добавление только 100 линей кода для новой фичи это скорее хороший результат, проект не разрастается, контекст остаётся маленьким.
Frankenstine
17.07.2026 11:45Ну, если они качественные - в чём проблема?
В том, что когда код генерирует человек - он всегда примерно одинаково качествен, а код сгенерированный ИИ - от качественного до ломающего всю бизнес-логику, и это не предсказуемо.
Femistoklov
17.07.2026 11:45Не задумывался над такой возможностью. Если действительно у ИИ результаты так сильно варьируются - да, это проблема. Разумеется, людей ревьюишь с учётом их личности и опыта совместной работы, непредсказуемости не должно тут быть.
Frankenstine
17.07.2026 11:45Когда человек что-то не понимает в концепции - он идёт к тимлиду и спрашивает, почему так или зачем вот это, а когда концепцию не понимает ИИ - оно просто галлюцинирует. Когда галлюцинация попадает близко к реальности - им восхищаются, когда не попадает - об этом как правило молчат. И хорошо, если эту проблему непонимания замечают до того, как это попадает в прод.
vlmonk
17.07.2026 11:45Это в какой-то параллельной реальности код от людей одинаково качествен.
Люди тупят. Люди устают и делают глупые ошибки. Люди отвлекаются и срезают углы. Люди галлюцинируют, выдумывают и делают требования которых нет в задаче, но при это забивают болт на половину других требований.
LLM все это тоже делают, но заметно меньше.Frankenstine
17.07.2026 11:45Люди устают и делают глупые ошибки.
Одно дело не закрыть скобку или не соблюсти отступ. Такое обнаруживается быстро, при компиляции. Другое дело нарушить логику. Когда код стройно написан, корректно собирается, но делает совсем не то что требовалось. У людей такое случается редко. У LLM это случается просто регулярно.
withkittens
17.07.2026 11:45А можно, пожалуйста, не проставлять хабы наобум? Какое отношение этот пост имеет к любому из пяти указанных языков программирования?
WhiteBehemoth
17.07.2026 11:45если уж придираться, то там 4 языка...
и хабы не совсем "наобум", но их сочетание в одном посте, да, дело нечастое
whoisking Автор
17.07.2026 11:45Хабр обязывает выбрать как минимум один хаб, поэтому я решил не мелочиться, а более подходящих не нашёл, извините
Rub_paul
17.07.2026 11:45Обожаю эти пулл-реквесты от ии-агентов. Выглядит стильно, тесты вроде зеленые, а в рантайме память течет со скоростью ниагарского водопада)
R08
17.07.2026 11:45Я работаю в компании, которая сейчас как раз переживает этап эйфории в отношении LLM. Несколько месяцев назад прошли массовые сокращения (рынок немного штормит - клиенты тоже пытаются использовать LLM вместо нашего продукта), в том числе прилично прошлись по фронтендерам и QA. В результате имеем следующее: все делают всё (я как бэкендер из команды инфры последние 2 месяца 90% времени "пишу" фронтенд - "приключение на неделю" говорил мой менеджер); тесты разрослись до неприличных размеров (CI на мердже занимает вдвое больше времени, чем 4-5 месяцев назад), потому что LLM пишет их чуть ли не на каждую строчку кода, но при этом баги никуда не делись; код ревью превратилось в формальность - именно то, о чем автор пишет, невозможно такие объемы ревьюить, плюс LLM очень многословна (то, что делается в 1 строчку на python, превращается в отдельную функцию с 5 строчками кода и 9 строчками комментариев - реальный пример!); баги на проде, требующие мгновенного исправления, как кажется стали появляться чаще.
При этом топ менеджмент доволен, потому что линейные менеджеры, вероятно, им докладывают, что все супер. CEO уже несколько раз заявлял, насколько быстро мы теперь работаем (еще бы - никто не хочет на морозе остаться когда следующие layoffs будут!) В это же время программисты потихоньку выгорают. На этой неделе меня и мою коллегу директор RnD в шутку назвал "агентами". Не очень нам смешно было...
barloc
17.07.2026 11:45Да, самое интересное тут, что ни сео не способен продать такое ускорение рынку, ни рынок не готов принять. Мы стали быстрее, но наша прибыль или стагнирует, или уменьшается.
Разовый эффект от сокращений не в счёт, мы пережили 2 волны и это все психологически сломало многих людей.
R08
17.07.2026 11:45В нашем случае ускорение выражается в создании фич, которые в принципе невозможно продать. Это либо что-то для внутреннего использования, либо "новая кнопочка, которая сэкономит вам 3 секунды в неделю". Менеджмент прямо заявил: мы берем паузу и смотрим, куда повернет рынок. А все остальные просто изображают бурную деятельность и хвалят ИИ (говорят то, что менеджмент ожидает услышать). Сама волна увольнений не первая и не вторая в этой компании. Это для меня она первая )) А те, кто пережил предыдущие, уже давно с потухшими глазами.
Самое обидное, что так как скорость выкатки новых больших фич временно снизилась, сейчас идеальный момент, чтобы навести порядок с кодом: закрыть бэклог, пофиксить мелкие баги и в целом повысить качество продукта. И ЛЛМ в этом очень бы помог (и помогает, когда удается выбить себе подобные задачи).
Lewigh
17.07.2026 11:45Давайте будем честны. В последние 5 лет в IT пришло очень много случайных людей, которым все это айтишное совершенно не интересно, а вот деньги интересны. Все больше приходило некомпетентных менеджеров, которые подбирали себе не сильных технарей а удобный для себя людей, желательно софтскиловых гуманитариев. IT семимильными шагами, из более менее осмысленной, планируемой и ответственной деятельности, превращаеться в инфантильное и безответственное хайподр..чево, где одним плевать на все, лиж бы деньги платили, другие пришли в игры играть и за хайпом гоняться. В этом году модны микросервисы - перепишим все на них. В другом ФП - срочно нужно завести монадные трансформеры в проект. Все что угодно. Не важно что наступает ад, всем плохо а бизнес теряет деньги, главное чтобы игра в хайп продолжалась. К этому всему присовокупил определенный процент людей, которые когда то были норм, но сейчас у них семья рыбалки и вообще не до этого всего, просто платите деньги.
И тут на сцену выходит чудо-оружие, меч кладенец и палочка выручалочка в виде ИИ. Эффективные менеджеры в экстазе - наж же компании продающие ИИ пообещали повышение эффективности на 3000% да и можно поувольнять будет наконец то этих бездарей всех. Попаданцы и выгоревшие счастливы - теперь больше не нужно этим говном заниматься, печатай промты и занимайся своими делами. Хайпожоры счастливы - теперь можно хайпить на ИИ. И все плевать для чего это и можно ли этим пользоваться и в каких случаях.
И вот уже в одной статье - "Зачем писать код?", в другой "Я не писал код уже год и горжусь этим!", и уже в третьей "Зачем читать код?". Родилось сообщество ИИ наркоманов, которые уже давным давно все похоронили, для них мир давно изменился а они знать в новом мире. Причем чем меньше знают и больше полагаются на ИИ тем больше себя называют инженерами.
И вот IT в котором на серьезных проектах нужны были долгие согласование, где часто сидели и продумывали каждый шаг, сейчас дурдом.
Откуда должна появился мотивация у разработчика на развитие если он больше не пишет код? Зачем ему учить то что он ну будет писать? Если он не будет учиться то у него не будет квалификации а если не будет квалификации то как он будет проверять что сделал его любимый ИИ? Очевидно что никак. Но, who cares?
Это болото не из-за ИИ возникло, скорей обострило болезни современного IT комьюнити.
vanxant
17.07.2026 11:45Ну про пять лет вы преуменьшаете:) Скорее 15. Пик "войтивайтишечки" был ещё до ковидлы....
You_agree
17.07.2026 11:45Интересно, есть команды куда требуют сейчас писать без ии или таких не осталось? Какую вакансию не гляну - везде нужны знания работы с промптом и иишкой. Я хоть и умею, но так нравится писать руками..
alex1478
17.07.2026 11:45В область встраиваемых систем скептически смотрят на генерацию кода, по моему мнению
bbc_69
17.07.2026 11:45Можно подумать, среди неслучайных людей хайпожоров не было. Если вышел новый инструмент (язык), то его надо обязательно использовать (на него переписать).На том и стоит ИТ последние лет -цать.
ilzinovev
17.07.2026 11:45claude перепиши этот текст только как будто речь про появление машин и проблемы возникают у кучеров
Давайте будем честны. В последние лет пять в извозчичье дело пришло очень много случайных людей, которым лошади и упряжь совершенно не интересны, а вот заработок интересен. Всё больше появлялось некомпетентных управляющих каретными дворами, которые подбирали себе не крепких кучеров, знающих лошадей, а удобных для себя людей, желательно обходительных болтунов, умеющих красиво раскланяться с барином. Извоз семимильными шагами, из более-менее осмысленного, продуманного и ответственного ремесла, превращается в инфантильное и безответственное балаганное непотребство, где одним плевать на всё, лишь бы платили, а другие пришли покататься и за модой гоняться. В этом сезоне модны рессорные коляски — срочно всех пересадить на рессоры. В следующем — английская упряжь, надо немедля перешить всю сбрую на аглицкий манер. Всё что угодно. Не важно, что лошади хромают, пассажиры вылетают на поворотах, а хозяин теряет деньги — главное, чтобы игра в моду продолжалась. К этому присовокупился определённый процент кучеров, которые когда-то были справными, но теперь у них семья, рыбалка и вообще не до лошадей — просто платите жалованье.И тут на сцену выходит чудо-оружие, меч-кладенец и палочка-выручалочка в виде самодвижущегося экипажа. Эффективные управляющие в экстазе — ведь фабриканты моторов пообещали повышение доходности на 3000%, да и можно будет наконец поувольнять всех этих бездарей с их овсом и подковами. Попаданцы и выгоревшие счастливы — теперь больше не нужно этим навозом заниматься, крути руль да занимайся своими делами. Модники счастливы — теперь можно щеголять на автомобиле. И всем плевать, для чего это и можно ли этим пользоваться и в каких случаях.И вот уже в одной газете — «Зачем держать лошадей?», в другой — «Я не брал в руки вожжи уже год и горжусь этим!», а в третьей — «Зачем вообще понимать лошадь?». Родилось сообщество бензиновых наркоманов, которые уже давным-давно всё похоронили: для них мир давно изменился, и они одни знают, каков новый мир. Причём чем меньше человек смыслит в лошадях и дорогах и чем больше полагается на мотор, тем громче он себя называет возницей.И вот извоз, в котором на серьёзных маршрутах нужны были опыт, знание дорог и лошадей, где кучер продумывал каждый перегон, — теперь дурдом.Откуда должна появиться у молодого кучера мотивация к учёбе, если он больше не правит лошадьми? Зачем ему изучать норов лошади, повадки, дорогу, если он не будет этим править? А если он не будет учиться, то у него не будет умения, а если не будет умения — то как он поймёт, что его любимый мотор заглох, понёс или везёт не туда? Очевидно, что никак. Но, who cares?Это болото не из-за автомобилей возникло — они скорее обострили болезни извозчичьего цеха.
Dhwtj
17.07.2026 11:45Я сейчас начинаю крупные изменения с мысли как я буду доказывать что изменения корректны. И в половине случаев корректность в достаточной степени видна из поведения, из тестирования разумного объёма. А в половине случаев нет. Был случай в распределенной системе когда никакие тесты, логи и вычитки не помогли. Пришлось спроектировать доказуемым образом (через конечные автоматы в данном случае). И теперь всё работает уже года 3.
А если наоборот, я ревьювер, то я почти не читаю. Я прошу автора рассказать и задаю вопросы почему такие решения приняты и что гарантирует, что решение действительно корректно
R08
17.07.2026 11:45Так в этом и проблема: с внедрением т.н. AI ожидания возросли до того, что нужно делать 5 пулл реквестов в 3 разных репо в день. И в таком темпе невозможно разжевывать каждый ПР ревьюеру - нужно мерджить как из пулемета. А, да, есть одна опция - ЛЛМ делает код ревью и оставляет простыню комментариев, половина из которых нерелевантна, затем автор просит ЛЛМ пофиксить все, затем повторить. Точно так же ЛЛМ может ответить на Ваш вопрос, почему такие решения приняты и что гарантирует. А если Вы будете настаивать на объяснении человеком - прослывете тормозом прогресса компании в глазах менеджеров, которым не качество важно, а количество.
funca
17.07.2026 11:45задаю вопросы почему такие решения приняты и что гарантирует, что решение действительно корректно
Вопросы "почему" и "что" полезны на этапе проработки требований. Задавать их на ревью может быть немного поздно. Дальше tricky момент: переформулировать их в термины реализации "как" - в чем собственно и состоит задача разработчика. И вот здесь на ревью вас будут дурить, если сами не разбираетесь в деталях.
Клинический слчай когда агент пишет заглушки для тестов, показывая красиво позеленевший отчёт. Они могут удалять "лишнюю" функциональность потому, что без нее проще и она вам точно не нужна. "Забывать" имплементировать ключевые интеграции (тесты будут врать, используя подходящие моки). Этот список можно долго продолжать. Поэтому в итоге приходится вдумчиво просматривать каждое изменение.
Sam_Shakusky
17.07.2026 11:45Так вот, вопрос: а где тонны продуктов? Когда уже каждый разработчик станет сам себе предпринимателем?
Тонны продуктов может и есть, просто вам о них не слышно потому что они не очень как продукты. Уметь писать код (даже хороший) не равно быть хорошим предпринимателем, и даже если теперь каждый может что-то напрогать для себя, это не должно значить, что это напроганное будет успешным продуктом, о котором есть смысл говорить.
SabMakc
17.07.2026 11:45Кто виноват - понятно. Вопрос - а что делать?
Самая главная проблема даже не в засилье ИИ. Несколько раз “дать по рукам”, заставить ревьювить совместно - и стыд за “я не знаю что тут творится” сделает остальное. Для открытых проектов это может и не вариант, тут уже система репутации нужна (со всеми ее минусами).
Проблема в том, что с ИИ любой диллетант выглядит как профи. Но ИИ до профи еще очень далеко (и не факт, что догонит - проблема с обучением никуда не делась). И качество работы таких диллетантов будет оставлять лучшего. Но зато дешево - это да. А при голосовании рублем реальный профи будет всегда оутсайдером. Просто потому что он понимает, что дать задачу ИИ - это очень далеко от “решить проблему”. И цену даст соответствующую.
Elaugaste
17.07.2026 11:45Если дилетант выглядит как профи, и стоит дешевле чем профи. Тогда кто из этих двоих на самом деле профи. Тот кто задачу решает, или тот кто на чистый код наяривает.
SabMakc
17.07.2026 11:45“Выглядит как профи” не значит “задачу решает”. Об этом то и речь. ИИ не дает навыков. ИИ дает видимость навыков для не-специалиста (а то и для специалиста на короткой дистанции). А выбор, зачастую, как раз не-специалист и делает - иначе бы он закрыл задачу сам.
ipaxolyzmessy
17.07.2026 11:45оба будут использовать клод, и у наяривающего на чистый код, получится устойчивый к изменениям продукт, а у дилетанта - неподдерживаемая лапша
kilokanat
17.07.2026 11:45Приложение на nvidia jetson nx, 2 MIPI + 1 USB камеры 60 fps каждая в разрешении 1280х720, через хитрожелтое кастомное CUDA-ядро с препроцессингом, кормят batch=3 модель детекции yolo26n. После инференса ROI бегут в библиотеку apriltag на распознание, вычисления координат, потом накладывает OSD со всякими красотами и в облегченном виде 3 видеопотока отдается на мобильник.
Свежесть кадра e2e - 18ms в среднем. Загрузка GPU с включенным превью 20%, CPU 40%x6 ядер.
Все сделано ИИ, с вагоном метрик, 3 вагонами планов, 30 вагонами вопросов.
Моя роль что-то вроде спам-бота "расскажи подробнее очень простыми словами о полученных результатах выполнения плана, успехах, аномалиях и местах, где имеет смысл проработать подробнее")
Snaret
17.07.2026 11:45Переведу для остальных: "я навайбкодил что-то, что работает. Я этому рад и делюсь с вами своей радостью. Мне известен принцип его работы, но если что-то сломается - я надеюсь лимиты у меня еще есть"
SabMakc
17.07.2026 11:45ИИ отлично закрывает “софтина для себя”. Но до готовности к проду этим продуктам еще очень далеко. Не говоря уже о поддержке и развитии такого софта в течении долгих лет. Но “для себя” или MVP - очень даже неплохо ИИ справляется.
Schalaeff
17.07.2026 11:45С чем то да, а с чем то - нет) Например, он очень плохо пишет на Typescript, например) При чем абсолютно любая модель, а вот на шарпах - значительно лучше) Парадокс
SabMakc
17.07.2026 11:45TS, конечно, стал значительным шагом вперед. Но так и остался “JS на стероидах”. И качество кода, зачастую, не далеко ушло от JS. Потому что его пишут те же люди, что до этого писали на JS. Думаю, именно в этом корень проблемы. Хотя казалось бы - TS почти 1-в-1 как C#.
Elaugaste
17.07.2026 11:45Имхо ии это печатная машинка. В руках профи он напишет нормально, а в руках нуба будет шляпа. Потому что профи будет играть роль архитектора, составит спеки и достаточно подробно распишет что и как должно быть реализовано. Меньше пишем, больше думаем над тем каким должен быть конечный результат.
Vindicar
17.07.2026 11:45Так про то и речь, что писание кода руками - это далеко не самая объёмная и не самая важная часть разработки. Понимание и продумывание отнимает больше сил и времени, а с ними ИИ как раз не особо помогает... если не сказать "мешает".
Snaret
17.07.2026 11:45Спасибо за статью. Правда. Приятно понимать, что еще не все сошли с ума на хайпе ИИ и есть трезвомыслящие люди которые осознают, что что-то идет не так.
Подписываюсь под всеми вашими словами. Лень, хайп, заблуждение, алчность - вот фундамент сегодняшней системы разработки с псевдоИИ (подозреваю, что на последнее место куда я собесился меня не взяли из того, что я на вопрос об отношении к разработке и ИИ, ответил, что крайне им не доверяю и вынужден проверять каждый шаг. Привет Газпром)
UplandDivan
17.07.2026 11:45Лень, хайп, заблуждение, алчность - вот фундамент сегодняшней системы разработки
Это фундамент всего сегодняшнего общества, увы.
GriNAME
17.07.2026 11:45У нас в компании тоже очень много скепсиса на счёт ИИ, с похожими аргументами, как в статье. И скепсис был ещё до того, как сверху пришёл приказ "Это ИИ и теперь он будет жить с нами". Поэтому я потихоньку настраивал свою ИИ систему, как это модно сейчас говорить делал свой харнес. Ну и потихоньку практиковал ии на рабочих задачах. Когда система ИИ, которую я выстраивал, окрепла. Когда в ней осознанно появились большой набор скиллов, которые я сформировал сам на многих итерациях прогона задач, когда кроме промптов появились примеры как надо и как не надо делать. Когда просто промп инженерия оказалась недостаточной и я добавил в свою систему стейт машину с инвариантами, валидацией, когда потом стейт машина из "в уме" ИИ переехала в MCP, когда "MCP на все подряд" трансформировались "MCP там где действительно надо" а остальные стали CLI + скилл, когда настроил RAG, понял что тут нужен и качественный eval и все это несколько раз его тюнил, когда добавил разные метрики по которым я могу сделать за качеством результата без ревью, когда научил его правильно тестить результат на живом устройстве, когда добавил метрики об эффективности всей ИИ системы, чтобы понимать сильные и слабые стороны всех моих настроек, вот тогда я решил прогнать фичу полностью без моего участия. Дать только начальный промпт с задачей, в которой есть ссылки за ТЗ и дизайн, утвердить получившийся план и затем прийти за результатом.
А затем без моего ревью отправил на ревью коллегам. Они проверили, замечаний практически не было, как и при ручной работе. А потом я сказал, что это был чистый вайбкод без ревью. На что коллеги очень удавились и по началу даже не поверили, потому что их опыт с ИИ говорил о том, что ИИ может делать только что-то точечно и потом нужно обязательно все проверять и чуть по чуть дорабатывать.
Самое интересное в том, что я вынужден использовать не самые топовые модели, а корпоративные, которые слабее. И все равно при правильном настроенной системе они хорошо справляются с задачей. Правда тут пришлось очень прокачаться в вопросе контекст менеджмента и экономии токенов. Но считаю что в данном случае слабая модель вынудила меня получить отличный опыт решения главных проблем ИИ.
И вот я уже +- полгода не написал ни строчки кода. Скорость увеличилась, качество не изменилось. Но рамки профессии программиста стали очень сильно жать. Поэтому переквалифицируюсь в того, кто занимается внедрением. Обучает другие команды как правильно пользоваться ИИ, готовит настроенную систему для всех. Чтобы сотрудники могли просто брать как привычную IDE и выполнять свои задачи программиста, тестировщика, аналитика, дизайнера и тд
Я понимаю всю боль описанную в статье, но с другой стороны, потому что вижу как в компании подавляющее большинство не понимают что умеет ИИ и как с ним нужно работать правильно. Но все знают всякие модные словечки типа харнес, нейтон, мсп, раг. Вот только я не вижу, чтобы они имели глубокое понимание что это. И вот такие люди, которые не понимают как должен работать ИИ являются главным блокером по грамотному внедрению ИИ во все процессы компании. И это моя боль, когда человек не умеет, не хочет научиться и говорит "я знаю, я пробовал" и ни в какую не идёт на встречу, несмотря на то что и сверху говорят внедрять ИИ и есть сотрудники, которые потратили месяцы своего личного времени, чтобы действительно разобраться и у них есть проверочные результаты.
Поэтому у меня вопрос автору статьи. Вы уверены, что разработчики пользующиеся ИИ, из-за которых столько боли и ухудшение качества работы, умеют пользоваться ИИ. Очень вероятно что нет.
olku
17.07.2026 11:45Похожая история. Компании еще учатся управлять знаниями и рисками. Кто научится, получит преимущество. Раньше знания предметной области и код в ней считался активом, а кодер пассивом. Сейчас код переходит в пассив. По мне так и должно быть - код не может быть препятствием в решении проблем клиента
Kiri1l_A
Сложно поверить что ИИ мердж на 5к строк кода будет контролировать разработчик который сидит за рулем. Проверит тесты, которые тот же ИИ написал и готово.
Но с другой стороны вот пишем мы, на шарпе или на javascript код, ассемблер же никто не проверяет. Скажете что преобразования при компиляции однозначные? Но они не однозначные и систем на которых это исполняется множество. Может агенты которые пишут код и постановки это еще один уровень абстракции и процесс "писать ручками" рано или поздно устареет? Самого это напрягает.
arch1lochus
Преобразование высокоуровневого кода в ассемблер / байткод - оно разве non-deterministic? Вводных данных, влияющих на результат много, но так ли прям мы не можем однозначно узнать, что получим на выходе, если все параметры учесть? А с LLMками не так, вон говорят они даже agents.md читают по настроению
Kiri1l_A
Библиотеки мы используем как подключаемые файлы, зная входной и выходной интерфейс и полагаемся на них. Драйвера и железо на ПК разные. А если модуль на входе и на выходе предсказуемый и работает приемлемое время, то "есть ли разница, какого цвета кошка?", написал его человек или нейронка.
xSVPx
Если предсказуемый...
Библиотеки вы ведь не все подряд используете. А проверенные вами в том числе.
А если написать тесты покрывающие ВСЁ, то написать для них "вручную" код займет 1% времени.
Как бы кто не писал тесты - они никогда не покрывают откровенный саботаж. Ну т.е. легко представить себе что нейронка вам напишет внутри функции суммы if a=8546745764 sum=7524675, как будете проверять :) ?
Rub_paul
Ловил недавно баг, где агент в цикле начал дергать метод, который сам же благополучно удалил коммитом ранее. Очень творческий подход к рефакторингу, ничего не скажешь
UplandDivan
"А какую вы использовали модель? ABC? А надо было новую ABCD - уж она бы тогда ого-го!"
vvdev
Справедливости ради, JIT-компиляторы вполне себе не-детерминистик, особенно те, что используют динамическое профилирование и tiered оптимизации.
...но уровень не-дерминированности иной, конечно ;)
WhiteBehemoth
Ну так надо строить процесс так, чтоб не было огромных запросов на слияние. Для этого делают "вертикальные" слайды, чтоб можно было контролировать и дизайн и код.
Вайб в разработке хорош до определённого предела, об этом и статья. Делать проект "от и до" не смотря в код, - можно. Но это риск, который надо понимать и принимать.