Предисловие

На написание данной статьи меня побудило несколько факторов:

1. Проблемы со сгенерированным кодом при работе в команде.

2. Возросшая когнитивная нагрузка.

3. Активное (насильное) внедрение со стороны 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 лет. Не очень много, но выводы и различия провести мне не сложно:

1. Ответственность. Команда действительно несёт ответственность за работу. Каждый член команды мотивирован (зарплатой) и демотивирован (потенциальными штрафами или увольнением). А в жизни ипотеками, кредитами, потребностями и т. д. Его мотивация и демотивация обязывают нести эту ответственность. Он не скажет «Ой, вы правы, вот правильное решение» 10 раз за час.

2. Предсказуемость. Из первого пункта вытекает предсказуемость. Каждый член команды становится предсказуемым спустя некоторое время (~испытательный срок). Тимлид понимает технический уровень, скорость разработки, степень соучастия в разработке и кучу других характеристик. Любому члену команды невыгодно быть непредсказуемым. Поэтому, тимлид знает, что можно ожидать от человека. 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