Как LLM ломают классическую модель разработки ПО

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

И я хочу попробовать описать, что именно.

Руковожу разработкой больше пяти лет (20 лет в IT). За это время я управлял командами от стартапов до больших бюрократических компаний, строил процессы в e-commerce, fintech и healthtech. Стандартный набор инженерного лидера.

Возьмём простую задачу. Например: новый экран с фильтрами.

Стандартный маршрут выглядит так: аналитик описывает задачу, разработчик пишет код, ревьюер проверяет, тестировщик тестирует, DevOps (инженер по инфраструктуре) выкатывает на сервер.

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

В команде из 10 человек простая задача занимает от 5 до 15 рабочих дней. Из них реальной работы часа три-четыре. Остальное: кто что сказал, кто что имел в виду, кто что передал следующему.

Я наблюдал это в нескольких компаниях. Это не проблема конкретных людей или процессов. Это системная характеристика модели, в которой каждая роль является отдельным человеком с отдельной очередью задач.

LLM (большие языковые модели; технология, лежащая в основе ChatGPT, Claude и других AI-ассистентов) два года назад казались продвинутым автодополнителем для программистов. Полезно, но не революционно.

Я проверил это на практике. Поначалу именно так и оказалось.

Когда я внедрял Cursor (AI-редактор кода) в команду из 30 инженеров, мы получили около 5-10% прироста к скорости. Звучит неплохо, но на деле разочаровывает. Инструмент в руках разработчика это всё равно инструмент. Он ускоряет написание кода, но не убирает ожидание проверки, не сокращает потери при передаче задачи от человека к человеку, не меняет структуру процесса. Плюс команда с устаревшей культурой встречает любые новые инструменты со здоровым скептицизмом, что тоже замедляет эффект.

Потом я попробовал другое. В одном из проектов я запустил агента-ревьюера на базе LLM и получил уже 20% ускорения цикла разработки. Не потому что модель умнее человека. А потому что проверка кода перестала быть очередью ожидания.

Дальше интереснее. Я собрал прототип, где написание кода, его проверка и тестирование выполнялись агентами. Результат оказался неожиданным: рабочий MVP конкретного проекта был готов за три дня. Не без участия человека: архитектуру нужно было заложить, контекст удерживать, результаты проверять. Но темп был принципиально другим.

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

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

Это важно. Но это не главное.

Главное узкое место оркестрация. То, как задача попадает к агенту, как агент получает нужный контекст, как результат возвращается в процесс: в систему задач, в хранилище кода, на проверку.

Код модели пишут уже неплохо. Встроить этот код в живой рабочий процесс. Вот где реальная сложность.

В классической модели контекст задачи живёт в головах людей и в комментариях. Аналитик объяснил разработчику, тот запомнил. Разработчик написал код, а следующий специалист пытается восстановить логику с нуля.

Каждый переход это потеря. Разработчик тратит до 30% времени только на то, чтобы заново вникнуть в задачу после переключения.

LLM решают эту проблему иначе: контекст задачи передаётся явно, структурированно, воспроизводимо. Но это работает только если система спроектирована так, чтобы информация накапливалась, а не терялась на каждом шаге.

Самый неожиданный вывод: команды не отказываются от AI из-за качества кода. Они отказываются из-за непредсказуемости.

Непонятно, что именно сделал агент. Непонятно, можно ли принять его результат. Непонятно, что произойдёт завтра.

Это не проблема модели, а проблема системы контроля. Там, где человек понимает, что может проверить, остановить, откатить, доверие растёт. Там, где AI выглядит как чёрный ящик, возникает отторжение.

Крупные компании (Google, Microsoft, Atlassian) встраивают AI-ассистентов в свои инструменты. Но это ассистенты, не агенты. Они помогают человеку работать быстрее, но не меняют структуру процесса.

Стартапы в сегменте AI-разработки идут дальше: появляются системы, которые могут самостоятельно закрывать задачи от постановки до готового кода. Но большинство из них облачные и требуют переноса кодовой базы на чужие серверы.

Это создаёт понятное противоречие: компании хотят автоматизацию, но не готовы отдавать контроль над кодом и данными. Особенно в fintech, healthtech, enterprise.

Разрыв между «AI-ассистент для программиста» и «полноценная AI-native команда» пока не закрыт.

Я не верю в сценарий «завтра все разработчики заменяются агентами». И не верю в сценарий «AI это просто новый инструмент, ничего принципиально не меняется».

Реальный переход будет поэтапным. И это, на мой взгляд, единственная жизнеспособная модель внедрения.

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

Ключевые принципы, которые я вижу в работающих подходах:

Модульность. Система не должна требовать замены всего набора инструментов. Трекер задач, хранилище кода, AI-провайдер: всё должно быть заменяемым независимо друг от друга.

На своих серверах. Для большинства серьёзных компаний передавать кодовую базу в облако является стоп-фактором. Развёртывание на собственной инфраструктуре убирает это возражение.

Встраивание, а не замена. Агенты работают в существующих инструментах команды. Они не требуют нового интерфейса и появляются там, где команда уже работает.

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

Самые устойчивые результаты дают не те команды, которые внедрили самую мощную модель. А те, которые спроектировали процесс передачи информации между человеком и агентом.

Там, где это сделано, скорость разработки растёт на 20-40% (и это скромные цифры). Там, где AI добавлен поверх старого процесса без его перестройки, результат близок к нулю.

Сейчас я работаю над системой, которая позволяет внедрять AI-агентов в существующий процесс разработки постепенно: на серверах компании, с модульной архитектурой, без замены привычных инструментов. Цель: дать компаниям возможность начать с малого и наращивать автоматизацию по мере роста доверия к системе.

Где у вас сейчас главный тормоз в выпуске продукта: в написании кода, в проверке, в передаче задачи между людьми? И что уже пробовали внедрить из AI-инструментов? Каков результат?

Ярослав Криволапов, CTO, engineering-лидер
Строю AI-native модели разработки.