Команда платит за Claude, но быстрее не стала. Почему?

Почти у каждой команды разработки в 2026 году есть подписка на Claude или GPT. Часто — на обе. Разработчики пользуются ими каждый день: спрашивают, как написать функцию, просят объяснить чужой код, генерируют тесты.

И всё равно спринты срываются. Документации нет. Code review занимает полдня. Онбординг нового разработчика — три недели.

Дело не в инструментах. Дело в том, что методологии нет.

Почему «все используют ИИ» — это не то, что вы думаете

Когда руководитель говорит «у нас команда работает с ИИ», обычно это означает следующее: у каждого разработчика открыт Claude в браузере, и он иногда вставляет туда кусок кода или вопрос. Ответ получает, копирует, идёт дальше.

Проблема в том, что такой подход не масштабируется и не накапливает знания. Каждый пишет промпты так, как умеет. Один получает хороший результат с первого раза, другой переформулирует запрос пять раз и бросает. Стандартов нет, шаблонов нет, результат непредсказуем.

Где конкретно теряется время

Если посмотреть на типичный спринт, потери концентрируются в трёх местах.

Code review и тестирование. По нашим замерам, в командах без AI‑методологии это занимает 40–60% времени спринта. Ревью проходит вручную, тест‑кейсы пишутся вручную, покрытие остаётся низким — просто потому что «некогда». ИИ в этих точках почти не используется, хотя именно здесь он даёт наибольший прирост.

Документация. Написать ADR, обновить README, зафиксировать архитектурное решение — всё это откладывается до «потом», которое не наступает. В итоге каждый новый человек в команде восстанавливает контекст из кода и голосовых объяснений. Это стоит недель.

Планирование и оценка задач. Декомпозиция, оценка трудозатрат, ретроспективы — всё это проводится по‑старинке. Хотя Claude справляется с декомпозицией эпиков в user story за минуты, а не за час встречи.

Что такое AI‑Driven Development

AIDD — это не название очередного инструмента. Это методология встраивания ИИ в каждую точку цикла разработки: от написания кода до планирования спринта.

Ключевая идея: ИИ должен быть не отдельной вкладкой в браузере, а частью процесса. Каждая точка SDLC — написание кода, ревью, тестирование, документация, оценка задач, ретроспектива — имеет свои стандарты работы с ИИ, свои промпты, свои чек‑листы.

Что меняется на практике

Команды, которые прошли через AIDD‑внедрение, фиксируют несколько устойчивых изменений.

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

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

Главное — всё это остаётся в компании. Playbook, библиотека промптов, адаптированный Scrum, задокументированные стандарты. Не в голове консультанта, а в собственности команды.

С чего начать прямо сейчас: четыре шага без подрядчика

AIDD не требует немедленного найма консультантов. Значительную часть пути команда может пройти самостоятельно — если действовать последовательно, а не хвататься за всё сразу.

Шаг 1 — Найдите одну точку боли и начните с неё. Самая частая ошибка при внедрении ИИ — попытка перестроить всё и сразу. В итоге через месяц ничего не поменялось, энтузиазм угас, тема закрыта до следующего года.

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

Договоритесь с командой: с этой недели эту задачу сначала делает ИИ, человек только проверяет и правит. Не «попробуйте если хотите» — а именно договоритесь как о новом процессе. Разница принципиальная: в первом случае это эксперимент одного энтузиаста, во втором — изменение в команде.

До старта зафиксируйте, сколько времени эта задача занимала раньше. Через месяц сравните. Это и будет ваш первый замер эффекта.

Шаг 2 — Соберите библиотеку промптов. У каждого разработчика в команде уже есть промпты, которые работают. Они живут в личной истории чатов, в заметках, иногда просто в голове. Проблема в том, что они ни с кем не расшарены — и когда человек уходит в отпуск или уволится, всё это знание уходит вместе с ним.

Попросите каждого члена команды записать три промпта, которые он реально использует и которые дают хороший результат. Не придумывать новые, а достать те, что уже работают. Соберите всё в один документ — Google Docs, Notion, Confluence, что угодно.

Это займёт час. И это будет первая версия вашей библиотеки.

Шаг 3 — Найдите внутреннего чемпиона. Это самый недооценённый шаг. Без конкретного человека, который отвечает за тему, всё хорошее быстро растворяется в текучке.

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

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

Шаг 4 — Запишите цифры до того, как что‑то менять. Этот шаг кажется очевидным, но его пропускают почти всегда — потому что хочется скорее начать, а не фиксировать «и так понятное».

Через полгода, когда вам нужно будет ответить на вопрос «а стало ли лучше?», окажется, что сравнивать не с чем. И тогда вместо цифр будут ощущения: «кажется, быстрее», «вроде меньше багов», «не уверен». Это не аргумент ни для команды, ни для инвестора.

Запишите прямо сейчас: сколько в среднем длится code review одного PR, как часто спринт не выполняется в срок, сколько времени занимает онбординг нового разработчика до первого самостоятельного коммита. Три цифры, час работы. Всё это есть в вашем трекере — просто никто не смотрел.

Когда без внешней помощи не обойтись

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

Команда больше десяти человек. Договориться о единых стандартах внутри большой команды — это отдельная задача, которая легко превращается в политику. Кто‑то будет игнорировать новые правила, потому что «и так работает». Кто‑то переделает под себя, потому что «я лучше знаю». Без нейтрального модератора, который не встроен в внутреннюю иерархию, этот процесс затягивается на кварталы.

Нужен результат с измеримым KPI. Если стоит задача показать эффект от ИИ совету директоров, инвесторам или просто обосновать бюджет на следующий год — самодеятельность рискованна. Нужна методология с воспроизводимым результатом, метрики, зафиксированные до старта, и кто‑то, кто уже делал это и знает, где обычно ломается.

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

Вывод

В 2025 году ещё можно было сказать «мы присматриваемся». В 2026‑м компании, которые выстроили AIDD, разрабатывают быстрее, дешевле и с лучшим качеством, чем те, кто этого не сделал.