Всем привет!
Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Делюсь полезными материалами, которые считаю стоят внимания. В основном про AI, изменение процессов, тренды и продуктовое видение.
У себя в телеграм-канале делюсь сжатыми и структурированными саммери статей.
Сегодняшний перевод статьи разработчика, в которой хорошо подмечены проблемы применения LLM в разработке.
На протяжении многих лет я чувствовал, что написание строк кода никогда не было узким местом в разработке программного обеспечения.
Настоящими узкими местами были и остаются код-ревью, передача знаний через наставничество и парное программирование, тестирование, отладка и человеческие издержки координации и коммуникации. Всё это завернуто в лабиринт тикетов, планерок и agile-ритуалов.
Эти процессы, призванные повышать качество, часто замедляют нас больше, чем само написание кода, потому что требуют размышлений, общего понимания и здравого суждения.
Теперь, когда LLM позволяют генерировать рабочий код быстрее, чем когда-либо, появился новый нарратив: что написание кода было узким местом, и мы наконец его преодолели.
Но это не совсем верно.
Предельная стоимость добавления нового программного обеспечения приближается к нулю, особенно с LLM. Но какова цена понимания, тестирования и доверия к этому коду? Выше, чем когда-либо.
LLM перераспределяют нагрузку — они не убирают её
Инструменты вроде Claude могут ускорить первоначальную реализацию. Но результат часто означает больше кода, проходящего через системы, и больше давления на людей, ответственных за его ревью, интеграцию и поддержку.
Это становится особенно очевидно, когда:
Неясно, полностью ли автор понимает то, что отправил на ревью.
Сгенерированный код вводит незнакомые паттерны или нарушает установленные соглашения.
Граничные случаи и непреднамеренные побочные эффекты неочевидны.
Мы оказываемся в ситуации, когда код легче создать, но сложнее проверить, что не обязательно делает команды быстрее в целом.
Это не новая проблема. Разработчики давно шутят о "copy-paste инженерии", но скорость и масштаб, которые обеспечивают LLM, усилили эти привычки copy-paste.
Понимание кода по-прежнему сложная задача
"Самая большая стоимость кода — это понимание его, а не написание."
LLM сокращают время на создание кода, но не изменили объем усилий, необходимых для рассуждения о поведении, выявления тонких багов или обеспечения долгосрочной поддерживаемости. Эта работа может стать еще сложнее, когда рецензенты с трудом различают сгенерированный и написанный вручную код или понимают, почему было выбрано конкретное решение.
Команды по-прежнему полагаются на доверие и общий контекст
Разработка программного обеспечения всегда была совместной работой. Она зависит от общего понимания, согласованности и наставничества. Однако когда код генерируется быстрее, чем может быть обсужден или проверен, команды рискуют попасть в режим, где качество предполагается, а не обеспечивается. Это создает стресс для рецензентов и наставников, потенциально замедляя процесс более тонкими способами.
LLM мощны — но они не решают фундаментальные проблемы
Есть реальная ценность в более быстром прототипировании, создании каркасов и автоматизации. Но LLM не устраняют потребность в ясном мышлении, тщательном ревью и продуманном дизайне. Более того, это становится еще важнее, когда генерируется больше кода.
Да, стоимость написания кода действительно снизилась. Но стоимость понимания его совместно как команда не изменилась.
Это по-прежнему узкое место. Давайте не будем притворяться, что это не так.