Разработка с ИИ-ассистентами: организация работы команды

Проект ЦИТадель

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

1. Минимум об инструменте: три важных свойства

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

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

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

2. Первый принцип внедрения: определите узкое место

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

Поэтому первый практический шаг (задание 1 практикума) — составить карту потока и измерить время до внедрения. Определите, где задачи ждут и сколько проходит от создания диффа до первого просмотра. Если ожидание измеряется днями, начните с организации ревью: ассистент только увеличит существующую очередь.

3. Второй принцип: адаптируйте контроль к новой стоимости проверки

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

• Ограничивайте входящий поток: установите предельный размер диффа как командную норму. Принцип небольших партий подробнее разобран в статье «Инженерный конвейер». Прямо запишите в соглашениях команды правило: «сгенерированное проверяется как код незнакомого разработчика». Включите в определение готовности способность разработчика объяснить каждое решение в диффе: если объяснить его невозможно, код не был должным образом проверен.
• Повышайте пропускную способность проверки: формальные операции должны выполнять линтеры, анализаторы и средства форматирования, а человек — проверять смысл и инварианты. Автоматические тесты обязательны, но сгенерированный код нередко успешно проходит тесты, полученные из той же реализации: такие тесты могут закрепить ошибку. Поэтому контракт следует сформулировать до генерации или хотя бы независимо от кода. Время первого ответа и приоритет ревью над новой работой должны стать правилами, а не пожеланиями.
• Учитывайте слепые зоны автоматической проверки: конкурентность, распределённые инварианты, сложную предметную логику и безопасность. Успешное прохождение тестов в этих областях не гарантирует корректности (причины разобраны в главе 11 курса о распределённых системах). Здесь человеческий разбор должен быть обязательной частью процесса.

4. Ответственность: одно правило, записанное письменно

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

5. Контекст — ресурс команды и источник данных для ассистента

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

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

6. Подготовка специалистов: новая система обучения

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

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

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

7. Метрики: что измерять и как избежать самообмана

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

8. Порядок внедрения: экспериментальный подход

Сведём рекомендации в последовательность, которая станет основой практикума:

1. Измерьте исходный поток (раздел 2): составьте карту этапов, зафиксируйте время ожидания и найдите узкое место. Если им оказалось ревью или приёмка, сначала улучшите этот этап.
2. Изложите политику на одной странице: зафиксируйте ответственность (раздел 4), периметр данных (раздел 5), области допустимого и недопустимого применения (раздел 6), нормы ревью (раздел 3). Краткий документ, согласованный командой, полезнее подробного регламента, который никто не читает.
3. Проведите месячный пилот на реальных задачах и ведите журнал: класс задачи → принято, переписано или отклонено → затраченное время. По итогам команда получит собственную оценку инструмента вместо чужих обещаний.
4. Перестройте контроль по данным пилота (раздел 3): ограничьте размер диффов, автоматизируйте формальные проверки и установите нормы времени ревью.
5. Повышайте автономию поэтапно: автодополнение → диалог → агентные режимы. Вместе с автономией должен расширяться и контур проверки: агенту нужна песочница — изолированная копия или контейнер, тесты должны служить обязательным контролем, единицей приёмки остаётся дифф, а перед слиянием требуется ревью. Агент с доступом к продакшену подобен конвейеру без контроля; как показано в статье «Инфраструктура как код», автоматизация масштабирует не только работу, но и ошибки.
6. Регулярно пересматривайте правила: оценка инструмента и политика его использования должны оставаться живыми документами. Поскольку возможности ассистентов быстро меняются, раз в квартал проверяйте правила по собственным данным, а не по новостям.

9. Практикум для руководителя

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

Задание 2. Политика на страницу. По рекомендациям раздела 8 опишите ответственность, информационный периметр, области применения и нормы ревью. Новый сотрудник после чтения документа должен понимать, что разрешено, что запрещено и как действовать в спорных случаях.

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

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

Задание 5. Учебная программа. Спроектируйте для одного начинающего разработчика месячную программу: определите, какие задачи он выполняет самостоятельно и зачем, какие — с ассистентом; добавьте три упражнения на поиск дефекта в сгенерированном коде и ревью вместе с наставником. Это прототип новой системы обучения.

Задание 6*. Разбор инцидента. Если произойдёт инцидент, связанный со сгенерированным кодом, проведите разбор без поиска виноватых по правилам раздела 4 и улучшите контроль, пропустивший дефект. Запишите выводы в карту оценки ассистента.

Итоги

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

Литература

1. E. Goldratt, "The Goal" — изложение теории ограничений, на которой основан раздел 2.
2. N. Forsgren, J. Humble, G. Kim, "Accelerate," IT Revolution, 2018 — метрики потока поставки; ежегодные отчёты DORA продолжают эти исследования и рассматривают влияние ИИ-ассистентов.
3. F. Brooks, "The Mythical Man-Month" — сущностная и случайная сложность: ассистент уменьшает случайную сложность, но сущностная остаётся задачей людей; серебряной пули по-прежнему нет.
4. Материалы нашего сайта: «Инженерный конвейер» (контроль, размер партий и метрики), курс «Распределённые системы», глава 11 (слепые зоны тестов), «Инфраструктура как код» (цена автоматизации без контроля), «Контейнеры» (песочницы для агентных режимов), «Облака на практике» (периметр и ответственность за данные).