А нам точно нужны code agents?

Вот важная новость с фронта ИИ: whoisking 12 минут назад А нам точно нужны code agents? Средний 9 мин 795 Python * Java * C# * JavaScript * . NET * Аналитика Recovery Mode ПредисловиеНа написание данной статьи меня побудило несколько факторов:Проблемы со сгенерированным кодом при работе в команде.

Возросшая когнитивная нагрузка. Активное (насильное) внедрение со стороны CTO/менеджерского класса. Да и в целом, с коллегами особо не подискутируешь, нужна аудитория побольше.

Технические детали

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

В них однозначно есть польза и они однозначно ускоряют некоторую рутину. «Сгенерируй мне json для моков, вот схема контракта», «А что ты думаешь о…», «Видишь ли ты проблемы в этом куске кода…», «Вот ORM запрос, мне нужен аналогичный SQL на диалекте postgreSQL», «Я пишу на языке X, фреймворке Y, столкнулся с такой проблемой, вот лог, в чём причина и как я могу это пофиксить…»Примеры запросов, которые, на мой взгляд, вполне валидны и LLM справляется с ними в большинстве случаев просто замечательно. LLM очень неплохи как second opinion.

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

Отраслевые последствия

А также, пограничные случаи, когда, разработчик, якобы, читает сгенерированный код и контролирует агента. Сгенерированный код при работе в командеМерж реквесты. LLM генерируют много кода, LLM не способны продумать фичу глубоко, LLM не способны сформировать пул вопросов и сходить к продактам/дизайнеру/аналитику за дополнительной информацией, которая может помочь продумать и написать более простой, более интуитивно-понятный код.

LLM пишут код только для текущего запроса, их не интересует что будет завтра, их не интересует роадмап, не интересуют последствия для соседних сервисов/модулей. В итоге мы видим много кода на маленькую фичу в мерж реквесте. Через несколько дней приходит запрос на добавление ещё одной фичи в тот же модуль и LLM перелопачивает весь код и снова прилетает дифф на +1500 -1400.

Читать такие объёмы так часто просто невозможно. Это не то что снижает скорость разработки, это просто сводит все плюсы на нет. Это увеличивает темпы изменения кодовой базы, скорости становятся неподъёмными для мозга.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.