Многие думают, что появление больших языковых моделей (LLM) наконец устранило главное узкое место в разработке — написание кода. Но правда в том, что написание строк кода никогда не было основной проблемой.
Настоящие препятствия — это ревью, передача знаний, тестирование, отладка и координация людей. Всё это обернуто в сложную систему процессов, тикетов и agile-церемоний, которые требуют времени, понимания и вдумчивости.
LLM действительно снижают стоимость создания нового кода — сегодня можно быстро сгенерировать рабочие фрагменты. Но цена за понимание, проверку и сопровождение этого кода только выросла.
Модели не снимают нагрузку — они её перераспределяют.
Инструменты вроде Claude или GPT отлично справляются с первичной реализацией. Но в итоге это означает больше кода, который нужно ревьюить, тестировать и поддерживать. Особенно когда:
Создавать код стало проще. Понимать его — сложнее.
И это не новая история. Copy-paste-инжиниринг был и раньше, но LLM усилили эту практику, масштабировав её.
Сложность осталась там же — в понимании.
Как и прежде, больше всего времени уходит не на написание, а на осмысление кода. Автоматическая генерация не уменьшила эту работу, а порой делает её даже труднее: рецензенты не всегда могут распознать сгенерированный код или разобраться, почему было выбрано то или иное решение.
Разработка остаётся командной работой.
Она требует контекста, доверия, наставничества и согласованных решений. Когда код появляется быстрее, чем его успевают обсудить, качество начинает предполагаться, а не подтверждаться — и это создает невидимые тормоза в процессе.
LLM — мощные помощники, но не решение корневых проблем.
Они ускоряют прототипирование и упрощают рутинные задачи, но не заменяют вдумчивое проектирование, проверку и коммуникацию. Наоборот, эти вещи становятся критичнее, когда код множится в разы быстрее.
Да, писать стало дешевле. Но понимать — нет.
И пока понимание кода остаётся ключевым барьером, узкое место никуда не делось. Просто оно стало менее очевидным.
Настоящие препятствия — это ревью, передача знаний, тестирование, отладка и координация людей. Всё это обернуто в сложную систему процессов, тикетов и agile-церемоний, которые требуют времени, понимания и вдумчивости.
LLM действительно снижают стоимость создания нового кода — сегодня можно быстро сгенерировать рабочие фрагменты. Но цена за понимание, проверку и сопровождение этого кода только выросла.
Модели не снимают нагрузку — они её перераспределяют.
Инструменты вроде Claude или GPT отлично справляются с первичной реализацией. Но в итоге это означает больше кода, который нужно ревьюить, тестировать и поддерживать. Особенно когда:
- Автор не до конца понимает, что именно он сгенерировал;
- Код нарушает принятые в команде соглашения;
- Поведение в граничных случаях остаётся неочевидным.
Создавать код стало проще. Понимать его — сложнее.
И это не новая история. Copy-paste-инжиниринг был и раньше, но LLM усилили эту практику, масштабировав её.
Сложность осталась там же — в понимании.
Как и прежде, больше всего времени уходит не на написание, а на осмысление кода. Автоматическая генерация не уменьшила эту работу, а порой делает её даже труднее: рецензенты не всегда могут распознать сгенерированный код или разобраться, почему было выбрано то или иное решение.
Разработка остаётся командной работой.
Она требует контекста, доверия, наставничества и согласованных решений. Когда код появляется быстрее, чем его успевают обсудить, качество начинает предполагаться, а не подтверждаться — и это создает невидимые тормоза в процессе.
LLM — мощные помощники, но не решение корневых проблем.
Они ускоряют прототипирование и упрощают рутинные задачи, но не заменяют вдумчивое проектирование, проверку и коммуникацию. Наоборот, эти вещи становятся критичнее, когда код множится в разы быстрее.
Да, писать стало дешевле. Но понимать — нет.
И пока понимание кода остаётся ключевым барьером, узкое место никуда не делось. Просто оно стало менее очевидным.
