Почему LLM снизили стоимость кода, но не ускорили разработку

Всем привет!
Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Делюсь полезными материалами, которые считаю стоят внимания ^[1]. В основном про AI, изменение процессов, тренды и продуктовое видение.

У себя в телеграм-канале ^[2] делюсь сжатыми и структурированными саммери статей.

Сегодняшний перевод статьи ^[3] разработчика, в которой хорошо подмечены проблемы применения LLM в разработке.

На протяжении многих лет я чувствовал, что написание строк кода никогда не было узким местом в разработке программного обеспечения.

Настоящими узкими местами были и остаются код-ревью, передача знаний через наставничество и парное программирование, тестирование, отладка и человеческие издержки координации и коммуникации. Всё это завернуто в лабиринт тикетов, планерок и agile-ритуалов.

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

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

Но это не совсем верно.

Предельная стоимость добавления нового программного обеспечения приближается к нулю, особенно с LLM. Но какова цена понимания, тестирования и доверия к этому коду? Выше, чем когда-либо.

LLM перераспределяют нагрузку — они не убирают её

Инструменты вроде Claude могут ускорить первоначальную реализацию. Но результат часто означает больше кода, проходящего через системы, и больше давления на людей, ответственных за его ревью, интеграцию и поддержку.

Это становится особенно очевидно, когда:

• Неясно, полностью ли автор понимает то, что отправил на ревью.

• Сгенерированный код вводит незнакомые паттерны или нарушает установленные соглашения.

• Граничные случаи и непреднамеренные побочные эффекты неочевидны.

Мы оказываемся в ситуации, когда код легче создать, но сложнее проверить, что не обязательно делает команды быстрее в целом.

Это не новая проблема. Разработчики давно шутят о “copy-paste инженерии”, но скорость и масштаб, которые обеспечивают LLM, усилили эти привычки copy-paste.

Понимание кода по-прежнему сложная задача

“Самая большая стоимость кода — это понимание его, а не написание.”

LLM сокращают время на создание кода, но не изменили объем усилий, необходимых для рассуждения о поведении ^[4], выявления тонких багов или обеспечения долгосрочной поддерживаемости. Эта работа может стать еще сложнее, когда рецензенты с трудом различают сгенерированный и написанный вручную код или понимают, почему было выбрано конкретное решение.

Команды по-прежнему полагаются на доверие и общий контекст

Разработка программного обеспечения всегда была совместной работой. Она зависит от общего понимания, согласованности и наставничества. Однако когда код генерируется быстрее, чем может быть обсужден или проверен, команды рискуют попасть в режим, где качество предполагается, а не обеспечивается. Это создает стресс ^[5] для рецензентов и наставников, потенциально замедляя процесс более тонкими способами.

LLM мощны — но они не решают фундаментальные проблемы

Есть реальная ценность в более быстром прототипировании, создании каркасов и автоматизации. Но LLM не устраняют потребность ^[6] в ясном мышлении ^[7], тщательном ревью и продуманном дизайне. Более того, это становится еще важнее, когда генерируется больше кода.

Да, стоимость написания кода действительно снизилась. Но стоимость понимания его совместно как команда не изменилась.

Это по-прежнему узкое место. Давайте не будем притворяться, что это не так.