Как организовать работу AI над сложным продуктом

Почему исправить один модуль недостаточно

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

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

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

Сначала разбираемся, что агент знает о проекте

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

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

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

Контекст помогает найти решение, а не заменить документацию

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

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

Задача проходит через людей, модули и границы ответственности

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

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

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

Как понять, что изменение действительно готово

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

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

Когда агент пишет «готово», мы просим показать, что именно было проверено. Прошедшая сборка подтверждает, что код собирается; она ничего не говорит о сохранности начатого рейса. Успешный тест планировщика полезен, но без экрана диспетчера и данных водителя картина неполная. Честная запись о границах проверки ценнее уверенного общего вывода.

Что остаётся, когда работа прерывается

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

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

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

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