Купили программистам ИИ, а задачи не закрываются быстрее: шесть причин и что менять

Путь задачи в компании: кто-то её сформулировал; разработчик понял; написал код; код проверили; выпустили; убедились, что работает.

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

Ассоциация ФинТех опросила свои компании в этом году: скорость разработки выросла у 95 % (45 % «существенно», 50 % «скорее»), а качество кода улучшилось у 41 % и ухудшилось у 41 %. Код пишется быстрее и ломается чаще — значит, время уходит на починку.

РУССОФТ добавляет неудобное: совокупный оборот компаний с ИИ в 2025 году вырос на 7,5 %, а у остальных — на 14,1 %; сама ассоциация пишет, что денежный эффект «не выявлен». Это не причинная связь, но это точно не «в десять раз».

Руководитель с Хабра сформулировал короче, чем консультанты: «Если вам обещают, что ИИ ускорит разработку в 5 раз — скорее всего, вам пытаются что-то продать».

У нас ускорение есть, и оно измерено: 6 844 коммита за 94 дня, медиана задачи «от реплики в чате до выпуска на прод» — 25 минут по 115 задачам.

Но это не потому, что агент быстро набирает код. Это потому, что остальные пять шагов перестроены под агента. Дальше — по шагу.

Первый вопрос, который мы задаём руководителю: задачи у вас записаны так, что новый человек поймёт без созвона? В большинстве команд — нет.

Задача живёт в голове у заказчика, разработчик додумывает, ИИ додумывает за разработчика, и втроём они делают не то.

Агент беспощадно показывает эту дыру. 29 июля файл правил нашего проекта не подгрузился в десктопной версии Claude Code, и сессия прожила день без закона: дорогая модель верстала сама то, что должна была отдать дешёвой, 3,4 млн токенов, около $146 за день.

30 июля правило сменилось посреди долгой сессии, и агент ещё полдня жил по старому. С тех пор у нас две привычки: первый шаг любой сессии — прочитать правила и назвать, какие; задача ставится словами «что за вещь, кому, зачем и как понять, что готово».

Что менять: заведите один файл правил в корне репозитория — для людей и агентов одновременно. И формулу «готово» у каждой задачи: «готово, когда колонка видна в админке и проверка зелёная», а не «сделай колонку».

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

Наш случай: 29 сентября в 07:14 одно новое слово в словаре сайта положило прод на два с половиной часа. Проверки были зелёные, а сборка упала уже на хостинге — на этот тип данных проверки не хватало.

5 сентября четыре выпуска подряд падали при зелёных проверках, а с 19 по 22 августа основная ветка три дня была красной, и никто этого не заметил.

Файлов с тестами в репозитории с июля стало 494 вместо 92.

После каждого такого случая правило одно: красная проверка — не сделано, даже если на экране всё есть; а то, что ломает прод при зелёных, получает свою проверку в тот же день.

Что менять: сначала проверки на главное — оплата, вход, выпуск, — потом агенты. Правило «без зелёных не вливаем» записывается в файл правил, а не держится на дисциплине.

Третий вопрос: есть ли описание проекта для нового человека — как устроен, как запустить, почему решено так. У нас ответ такой: в репозитории 387 тысяч строк документов рядом с 391 тысячей строк кода (срез августа; сейчас обе цифры выросли примерно в два с половиной раза).

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

Поломка, из которой это выросло: 21 июля агент переизобрёл логотипы сайта при живом складе готовых — потому что склад не был описан там, где агент искал. Лечение было не «быть внимательнее», а починить документ, по которому следующий агент найдёт склад.

Что менять: один документ «как устроен проект» и журнал решений. Если его нет, первые две недели работы агентов уйдут на то, чтобы он появился — это нормальная цена входа, а не провал пилота.

Четвёртый вопрос: кто смотрит правку перед выпуском. Ответ «автор сам» с агентами перестаёт работать: автор теперь не читает каждую строку.

У нас правку принимает второй агент с чистым контекстом, который не видел, как она делалась. 26 сентября на первом прогоне серии подборок он нашёл десять фактических ошибок, которых автор не заметил.

Без приёмника писатель выводит факты «по смыслу» — мы ловили это 21 августа и 26 сентября. Для кода то же самое: ревью и проверки — всегда, второе мнение — там, где риск (деньги, доступы, схема данных).

Что менять: правило «правку принимает не тот, кто её делал» — человек или второй агент. И классы риска: что можно влить после проверок, а что только после человека.

Пятый вопрос: сколько правок в неделю у вас вливается и сколько проходит от задачи до выпуска. Большинство руководителей, которые нам пишут, не знают — у них есть только счёт за подписки и число входов в инструмент. Один написал: метрики внедрения растут, а сроки и число дефектов не меняются.

Мы мерим три вещи и показываем их открыто: коммиты в день (вчера — 104), влитые правки в неделю (больше двух тысяч с июля, около 150–170 в неделю), время от задачи до выпуска (медиана 25 минут).

Строки кода и «процент кода от ИИ» не мерим: они растут всегда и ничего не говорят. DX и GitHub в своих рамках метрик называют их антиметриками.

Что менять: три числа до старта пилота и те же три через 30 дней. И ни одно из них — не в оценку людей.

Последний вопрос — про людей. Руководители пишут: одни сопротивляются, другие «имитируют, чтобы руководство видело красивую картинку», третьих никто не учил. Технический директор с Hacker News: «Building teams that use those tools effectively is the problem» — проблема не инструмент, а команда вокруг него.

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

Два текста, которые работают: письмо руководителя «мы включаем агентов, вот что изменится в вашей работе и как мы поможем» — и запрет на оценку людей по метрикам ИИ. Приказ «всем пользоваться к пятнице» дал в Coinbase увольнения и публичный откат — это дорогой способ узнать то же самое.

Что менять: один владелец программы, два-три человека в пилоте, которые хотят, и честный разговор с остальными. Не «ваша работа в безопасности», а «вот как изменится работа и чем мы поможем».

1. ИИ ускоряет четверть пути задачи; выпуск быстрее не станет, пока не перестроены остальные три четверти.

2. Задача — словами с критерием «готово»; правила — одним файлом для людей и агентов.

3. Без зелёных проверок не вливаем; что сломало прод при зелёных — получает проверку в тот же день.

4. Правку принимает не тот, кто её делал.

5. Три числа до старта и через 30 дней: правок в неделю, дней до выпуска, доля переделок. Не знаете, где вы сейчас, — запишитесь на звонок; некому ставить — отдайте работу.