Всем привет!
Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Делюсь полезными материалами, которые считаю стоят внимания. В основном про AI, изменение процессов, тренды и продуктовое видение.
У себя в телеграм-канале делюсь сжатыми и структурированными саммери статей.
Сегодняшний перевод статьи разработчика, в которой хорошо подмечены проблемы применения LLM в разработке.
На протяжении многих лет я чувствовал, что написание строк кода никогда не было узким местом в разработке программного обеспечения.
Настоящими узкими местами были и остаются код-ревью, передача знаний через наставничество и парное программирование, тестирование, отладка и человеческие издержки координации и коммуникации. Всё это завернуто в лабиринт тикетов, планерок и agile-ритуалов.
Эти процессы, призванные повышать качество, часто замедляют нас больше, чем само написание кода, потому что требуют размышлений, общего понимания и здравого суждения.
Теперь, когда LLM позволяют генерировать рабочий код быстрее, чем когда-либо, появился новый нарратив: что написание кода было узким местом, и мы наконец его преодолели.
Но это не совсем верно.
Предельная стоимость добавления нового программного обеспечения приближается к нулю, особенно с LLM. Но какова цена понимания, тестирования и доверия к этому коду? Выше, чем когда-либо.
LLM перераспределяют нагрузку — они не убирают её
Инструменты вроде Claude могут ускорить первоначальную реализацию. Но результат часто означает больше кода, проходящего через системы, и больше давления на людей, ответственных за его ревью, интеграцию и поддержку.
Это становится особенно очевидно, когда:
Неясно, полностью ли автор понимает то, что отправил на ревью.
Сгенерированный код вводит незнакомые паттерны или нарушает установленные соглашения.
Граничные случаи и непреднамеренные побочные эффекты неочевидны.
Мы оказываемся в ситуации, когда код легче создать, но сложнее проверить, что не обязательно делает команды быстрее в целом.
Это не новая проблема. Разработчики давно шутят о "copy-paste инженерии", но скорость и масштаб, которые обеспечивают LLM, усилили эти привычки copy-paste.
Понимание кода по-прежнему сложная задача
"Самая большая стоимость кода — это понимание его, а не написание."
LLM сокращают время на создание кода, но не изменили объем усилий, необходимых для рассуждения о поведении, выявления тонких багов или обеспечения долгосрочной поддерживаемости. Эта работа может стать еще сложнее, когда рецензенты с трудом различают сгенерированный и написанный вручную код или понимают, почему было выбрано конкретное решение.
Команды по-прежнему полагаются на доверие и общий контекст
Разработка программного обеспечения всегда была совместной работой. Она зависит от общего понимания, согласованности и наставничества. Однако когда код генерируется быстрее, чем может быть обсужден или проверен, команды рискуют попасть в режим, где качество предполагается, а не обеспечивается. Это создает стресс для рецензентов и наставников, потенциально замедляя процесс более тонкими способами.
LLM мощны — но они не решают фундаментальные проблемы
Есть реальная ценность в более быстром прототипировании, создании каркасов и автоматизации. Но LLM не устраняют потребность в ясном мышлении, тщательном ревью и продуманном дизайне. Более того, это становится еще важнее, когда генерируется больше кода.
Да, стоимость написания кода действительно снизилась. Но стоимость понимания его совместно как команда не изменилась.
Это по-прежнему узкое место. Давайте не будем притворяться, что это не так.
Комментарии (8)
Rive
21.07.2025 08:06В таком случае одиночки теоретически получают бешеный буст производительности, потому что только они могут извлечь выгоду от такой автоматизации труда, добрать недостающие компетенции и крайне сильно сэкономить на отсутствии коммуникаций с командой (начиная от более низкой платы и заканчивая заменой асинхронного общения на промпты в режиме on-line).
JuryPol
21.07.2025 08:06Одиночек 100500. Пока весь их “буст” приводит к появлению бесчисленного количества ненужных практически никому чат-ботов.
akakoychenko
21.07.2025 08:06Я бы сказал, что ЛЛМ не ускорил разработку в тех командах, которые догматично применяют доЛЛМные практики.
Очевидно, что старые подходы оптимизировали объем кода на +1 задачу и сапортабилити каждого куска кода.
С ЛЛМ эти вещи обесцениваются. Приведу пример: есть, скажем, CRM система написанная на махрово-энтерпрайзном C#/Java, и работающая с MSSQL/Postgres. Раньше было принципиально важно правильно продумать объекты, интерфейсы, суррогаты, дто, взаимодействие объектов. И потом, на основе этой базы уже делать фичи просто и лаконично (никому ж не придёт в здравом уме на каждую фичу писать с 0 полключение к БД и все такое). Да, в такой подход LLM вообще даром не нужен. Ибо сложно описать каждый раз контекст и легко нагенерить говнокода, начав "пилить поперёк волокон". Но прикол в том, что, в случае LLM, вот эта база из объектов-интерфейсов-etc вообще не нужна. Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние). Зато можно каждый такой блочек инкапсулировать в свой сервис, протестировать, и просто написать заново, когда он устареет. Вообщем, надо мозг развернуть. Или подождать, пока умные люди придумают новые догмы за нас
DarthVictor
21.07.2025 08:06Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние).
Машине написать не лень, зато пользователю потом пользоваться неконсистентной системой будет лень.
Более менее ваш подход работает на статичной вёрстке фронтенда, но и там есть проблемы, даже тот же Lovable не случайно делает все свои интерфейсы приколоченными гвоздями к одной и той же библиотеке компонентов (что характерно, написанной кожаными мешками). И всё равно возникают проблемы с высокоуровневыми абстракциями. А пользователям почему то не нравится пользоваться системой, в которой на каждой таблице фильтр работает и выглядит немного не так как на остальных.
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет. И никто не скажет, в каких именно, потому что разработчкики сами не знают. А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Rive
21.07.2025 08:06Впрочем, существующие парадигмы написания кода возникли и выходили из моды из-за давления инструментов: класс с паттерном "Посетитель" появился пришёл в ООП-ориентированные языки из Java из-за отсутствия анонимных функций (и был затем поглощён ими), а длинные методы и процедуры оказались вне фавора из-за того, что их трудно тестировать.
LLM точно так же могут затребовать специфичную структуру проекта, которая для них оптимальна (что собственно уже и происходит - специально для них создают rules-файлы с выжимкой архитектуры и код стайла проекта).
akakoychenko
21.07.2025 08:06Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет
Вы так говорите, будто оно сейчас не так. Поскреби любой продукт, на который потрачены миллиарды $, чуть глубже поверхности, и так все вот такое полезет. Общался пару лет назад с сотрудником техподдержки ФБ: он рассказывал, что в рекламном кабинете баг на баге, от которых рвет пукан рекламодателям, и ниче, всем до жопы, пока метаверс на кону.
>А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Представил. "Финансовый софт" звучит, как догма. А оно там внутри далеко не все так офигенно. Там внутри полно индусов, которые делают работу, которую должен делать софт, но не делает. Полно ноукода, в котором иногда, при очередном редактировании, происходит мисклик, и "съезжает" процесс. Куча задач, где вообще всем пох, сколько там багов (условно, пуш надо разослать с партнерской рекламой, и, в принципе, если он уйдёт чуть не тем, кому надо, то норм). Понятно, что есть ядро, где так не пишут. Но, оно, как правило, уже давно написано. А вот прямо сейчас надо фич накидать, которые, что с, что без ллм, будут написаны примерно с одинаковым качеством
Akuma
21.07.2025 08:06API ВК, кстати, работает как раз как с видео. Загрузка фото в товары - это практически рандом. Может сработать, может не сработать в зависимости от фазы луны.
А еще у них каптча в серверном API, но это уже другой диагноз.
sergey_prokofiev
Очень здравое и взвешенное мнение посреди истерии про "ИИ
убьетзаменит всех человеков"