Как я разрабатываю продукты с ИИ-агентами

Суть метода

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

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

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

Конвейер: от брифа до продакшна

1. Бриф и решения владельца

Заход начинается с файла-брифа: где мы сейчас, что уже на проде и не переделывается, список известных хвостов, состав потоков, Definition of Done каждого потока и «критичные грабли» прошлых заходов. Отдельный раздел — вопросы ко мне; ответы фиксируются с датой прямо в брифе, и поток не стартует, пока развилка не закрыта.

2. Нарезка на потоки и слайсы

Работа режется на 5–8 параллельных потоков. Ключ к параллельности — таблица зон: у каждого потока перечислены конкретные файлы, зоны не пересекаются, а общие файлы (документация, роадмап, спецификация) правит только интегратор в конце. Где два потока зависят друг от друга, контракт замораживается отдельным файлом: один реализует его, другой строит интерфейс по нему, отклонение — только через интегратора.

3. Параллельная работа агентов

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

4. Сведение

Интегратор сводит потоки, разбирает совпавшие по смыслу правки, прогоняет полный набор проверок по всем контурам и формирует PR в репозиториях раздельно. Изменения ядра, сервиса, админки и клиента идут разными коммитами и разными CI-джобами — видно, что именно сломалось.

5. Definition of Done и тесты

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

6. Выкатка

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

7. Приёмка на живом контуре

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

8. Память захода

В конце обновляются манифест состояния проекта, скрипт быстрой сверки контуров и файл истории. Новый заход начинается с одного-двух дешёвых чтений вместо ручной разведки по SSH и git.

Цифры

Все цифры ниже взяты из отчётов заходов, источник указан в скобках.

• 8 параллельных потоков в одном срезе: клиент, периферийный сервис, ядро, админка, сквозной поток, QA на живом контуре, документация, юридическое исследование (бриф среза).
• 5 потоков в следующем срезе; ранее — 7 потоков; всего срезы 4–11 уложились в три календарных дня (даты решений в брифах срезов).
• Тесты на момент сведения: ядро — 346 юнит-тестов (+8 за заход) и 169 интеграционных в 52 наборах; периферийный сервис — 73 теста (было 65), затем 74 и 78; клиент — 71 тест (было 47, +24 за один заход); статический анализ клиента — 0 замечаний; админка — чисто по типам, линту и сборке (отчёты потоков и отчёт QA).
• 61 миграция применена в базе, при этом прогон выполнялся дважды для проверки идемпотентности; для одной из задач новая миграция честно не потребовалась (отчёт потока ядра).
• Живой «день кассы»: 9 заказов, 4 Z-отчёта на реальном фискальном регистраторе, 9 кухонных чеков, 1 инкассация; продажи в ядре выросли с 35 до 44, сумма — с 10 580 до 13 190; очередь синхронизации — 42 доставленных события, 0 отклонённых и 0 дублей; бонусный баланс сошёлся арифметически до копейки (отчёт QA-потока).
• Сам сквозной прогон дня занял около девяти минут живого времени.
• Офлайн-цикл: 3 события накопились в очереди, догон дал «отправлено 3, принято 3, дублей 0» (отчёт QA-потока).
• Найденный и закрытый за один заход дефект: касса позволяла закрыть заказ с недоплатой, из-за чего Z-счётчик расходился с суммой продажи на 80 единиц; QA-поток нашёл это на живом контуре, поток разработки в тот же заход закрыл корневую причину проверкой до списания денег, плюс регрессионный тест.
• Масштаб продукта: план покрывает 16 разделов и около 108 пунктов рыночного эталона, в ядре 10 схем базы, в интерфейсе кассы около 36 экранов.
• Экономия на разведке: старт нового захода сократился с 15–30 вызовов SSH, git и diff плюс чтения файла памяти в 600+ строк до одного-двух чтений.

Почему это даёт заказчику деньги

Скорость через параллельность, а не через спешку

Восемь потоков работают одновременно, поэтому календарное время захода определяется самым длинным потоком, а не суммой работ. Так один заход вместил изменения клиента, сервиса, ядра, админки, спецификации и юридическое исследование.

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

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

Качество проверяется до выкатки, а не в пилоте

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

Приёмка доказана цифрами

Заказчик получает не «готово», а сверку: продажи, тендеры, счётчики Z-отчёта и бонусный баланс сходятся с учётной базой. Расхождение, найденное на живом контуре, устраняется в тот же заход вместе с тестом против его возврата.

Предсказуемость из повторяемости

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

Стоимость

Дорогое время — моё — уходит на решения, контракты и приёмку; дешёвое машинное — на код, тесты и рутину. Экономия не в том, что агент бесплатный, а в том, что дорогой ресурс работает только там, где он нужен.

Честные ограничения

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

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

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

Что не делится на потоки. Ключевые изменения, переворачивающие основной сценарий, выполняются последовательно: сначала контракт, потом сервис, потом клиент. Параллелить их — значит получить конфликт в самом важном месте.

Стоимость координации. Бриф, runbook интеграции и правила гигиены контекста — это работа, которую надо делать. Без неё параллельность не ускоряет, а переносит расходы в ручную разведку и разбор конфликтов.

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

Что это значит для вашего проекта

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

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