Где в цикле разработки ИИ уже есть, а где его нет ни у кого

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

01Почему уровень команды не выводится из разговора с заказчиком

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

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

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

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

Групповая сессия с представителями команд. Около двух с половиной часов, каждый рассказывает про свой контур: продукт, типовые задачи, где болит, чем пользуется. Дальше сквозные темы — тестирование, ревью, архитектурные решения, инфраструктура. Важна рамка, объявленная на первой минуте: мы пришли понять, как всё устроено, и никого здесь не оцениваем. Инженеры мгновенно считывают, оценивают их или изучают, и во втором случае говорят совсем другое.

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

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

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

Отдельно от инструментов стоит дисциплина разбора. В работу шли только дословные цитаты: записи разложены на 219 цитат по семнадцати категориям, каждое утверждение отчёта опирается на цитату с источником, а неподтверждённое помечено как гипотеза и так и названо. Без этого правила отчёт превращается в набор впечатлений, спорить с которыми можно бесконечно, а с цитатой спорить нельзя — можно только уточнить контекст.

03Где ИИ в цикле разработки уже работает, а где его нет

Мы разложили восемь этапов цикла разработки по командам и отметили, где ИИ применяется, а где нет.

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

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

Отсюда получается неочевидный порядок обучения. Ревью — ближайшая быстрая победа: правила понятные, риск низкий, результат заметен без долгих замеров. Требования — самая тяжёлая и самая ценная работа. На нашей сессии самый содержательный вопрос прозвучал именно про них: если функциональные требования описаны криво, сгенерированные по ним тесты будут проверять логику разработчика, а не логику задачи. Это точка, где обучение работе с ИИ упирается в инженерную культуру, и ни один модуль про инструменты её не закрывает.

04Что люди говорят о себе и что видит эксперт

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

Они разошлись. В анкетах десять человек из шестнадцати отнесли себя к верхним ступеням, восемь оценили долю кода с моделью выше семидесяти процентов, а основным инструментом у тринадцати из шестнадцати оказался Claude Code — стандарт в команде сложился сам, без всякой договорённости о нём. По наблюдениям устойчивая работа с несколькими агентами не подтвердилась ни у кого: точечные удачные случаи есть, системы нет. Сильнее всего расхождение там, где у нас было меньше всего данных: команды, которых мы не слышали на сессии, ставили себе высокие ступени.

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

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

05Чего команда просит на самом деле

Программы обучения работе с ИИ традиционно строятся вокруг приёмов работы с моделью. Замер показал другое распределение спроса. Семь независимых источников, не сговариваясь, назвали одно: личные находки не становятся командными. У отдельных инженеров уже собраны рабочие агенты под свои задачи, и живёт каждый такой агент в одной голове и одном репозитории. Сосед про него не знает.

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

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

Состав модулей остаётся, меняется наполнение внутри.

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

06Почему нельзя обещать проценты ускорения

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

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

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

Здесь же проходит граница честного обещания. Освоение навыка — зона ответственности того, кто учит: показать, как работает приём, провести через него на боевой задаче участника, оставить материал, к которому можно вернуться. Перестройка ежедневной работы происходит внутри компании и уже после занятий. Внешний исполнитель не стоит у людей за спиной и не управляет их поведением, поэтому обещать перестройку процессов он не может — может обещать, что проведёт по этому пути и оставит инструменты. Разница выглядит крючкотворством ровно до того момента, когда приходит время отчитываться за результат.

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

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

ИИ забирает целиком те процессы, которые целиком формализуются. Если бы задача сводилась к этому, учить людей было бы незачем — дешевле собрать агентов и не заводить разговор про обучение. Программа строится вокруг другого: внедрённый ИИ создаёт свой тип работы. Поставить задачу так, чтобы её понял агент. Собрать контекст, без которого он ошибётся. Проверить результат и увидеть, где он ошибается уверенным тоном. Выстроить процесс вокруг новых инструментов и удержать качество, когда кода становится больше, а времени на его чтение меньше. Этой работы становится больше, а не меньше, и именно ей учит программа. Человек, который умеет оркестрировать агентов и отвечать за результат их работы, оказывается не тем, кого заменяют, а тем, кто управляет.

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

07Как провести замер своими силами

Половина замера делается внутри компании, и это лучше, чем не делать его вовсе.

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

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

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

08Частые вопросы

Четыре вопроса, которые задают чаще всего, когда речь заходит о замере перед обучением.

09Словарь

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