Инженерия с ИИ в маленькой команде: кто за это отвечает

Почему это быстро превращается в хаос

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

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

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

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

Вот так старые инструкции продолжают жить. Новый коллега берёт не тот промпт, получает аккуратный ответ и думает, что он соответствует текущим правилам. Часто это не так.

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

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

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

Один ответственный лучше, чем общая ответственность

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

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

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

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

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

Что решает ответственный

Ответственность — это не просто выбор инструмента. Это ещё и границы.

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

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

Хороший ответственный делает эту границу очевидной. Ассистенты могут делать черновики рутинных задач. Инженеры утверждают каждое изменение кода перед слиянием. Более опытные люди принимают финальные решения по архитектуре, безопасности и изменениям данных. Команда использует небольшой набор одобренных шаблонов промптов для типовых задач. Любой процесс, который создаёт больше переделок, чем скорости, нужно ставить на паузу или убирать.

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

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

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

Как внедрять это в маленькой команде

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

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

Простой чек-лист может включать четыре вопроса:

• Проходит ли код существующие тесты?
• Проверяют ли новые тесты реальное поведение, а не только happy path?
• Не изменил ли ассистент что-то за пределами задачи?
• Одобрил бы это человек в команде, не переписывая половину?

Заморозьте шаблон на первые две недели. Это важнее, чем кажется. Как только каждый разработчик начинает подкручивать формулировки, добавлять свои инструкции и копировать старые чаты, хаос в промптах быстро возвращается. Если кто-то заметил проблему, зафиксируйте её. Пусть один ответственный обновляет шаблон пакетно, а не в середине ежедневной работы.

Ведите простой журнал. Таблицы достаточно. Записывайте задачу, сколько времени ушло с ИИ, сколько, вероятно, заняла бы ручная работа, что пошло не так и поймала ли это проверка. После десяти–пятнадцати задач картина обычно становится очевидной. Возможно, ассистент экономит 20 минут на тестах, но постоянно пропускает крайние случаи. Это полезно. Это можно исправить.

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

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

Держите человеческое решение в контуре

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

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

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

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

Привычки проверки, которые работают

Несколько привычек берут на себя основную работу:

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

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

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

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

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

Простой пример из небольшой продуктовой команды

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

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

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

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

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

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

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

Где команды теряют контроль

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

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

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

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

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

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

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

Короткий чек-лист проверки

Перед слиянием изменения, написанного с помощью ИИ, проверьте пять вещей.

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

Во-вторых, сделайте изменение легко отслеживаемым. Проверяющий должен видеть путь от исходной задачи или промпта до сгенерированного результата и финального коммита. Если этого следа нет, проверка превращается в угадайку.

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

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

В-пятых, запишите, что сломалось и почему. Коротко. Пара строк о плохом промпте, неверном предположении или пропущенной проверке сэкономят часы позже. Со временем это становится командным playbook по предотвращению хаоса в промптах.

Что делать дальше

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

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

Первый проход может быть совсем простым:

• назначьте одного ответственного за процесс
• выберите одну задачу с понятным вводом и выводом
• напишите один шаблон промпта и один чек-лист проверки
• запустите это на одну неделю, прежде чем расширять

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

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

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

Если в команде некому взять это на себя, внешняя помощь может оказаться очень полезной. Олег Сотников на oleg.is работает со стартапами и небольшими бизнесами как CTO на частичной занятости и помогает с практичным внедрением ИИ, включая правила проверки, стандарты промптов и бережливые инженерные процессы. Короткой консультации часто достаточно, чтобы задать границы и остановить хаос в промптах, пока он не превратился в дорогую переделку.

Но полезный первый шаг всё равно прост: назначьте одного ответственного, начните с одной задачи и проверьте результат на следующей неделе.