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

Мы несколько дней проверяли, может ли агент получить ТЗ один раз и дальше сам двигать продуктовую разработку DoveryAI Market. Короткий ответ: да, это возможно. Более честный ответ: это требует оркестрации, recovery, жесткой приемки и постоянной настройки. Качество пока неровное и местами слабое, но как концепция долгого автономного контура эксперимент себя доказал.

У нас было техническое задание на DoveryAI Market: B2B-партнер добавляет товар, оператор проверяет и выпускает его, покупатель видит корректное предложение, а вся цепочка сохраняет статусы, доверие к товару и историю действий. Мы использовали эту задачу как тест режима founder-agent: агент получает продуктовую цель и дальше сам планирует и ведет разработку крупными шагами.

Это не был режим обычного coding assistant, где человек каждые десять минут пишет следующую команду. Мы один раз дали ТЗ. Дальше продуктовый код руками не писали. Основная ручная работа была вокруг Hermes: системы, которая оркестрирует агентную разработку, запускает Codex/Claude, следит за задачами, восстанавливает зависшие сессии и помогает продолжать следующий шаг.

Что получилось

За несколько дней появился рабочий alpha-срез CRM+marketplace. По масштабу это было около пяти дней эксперимента, в среднем примерно 15 часов активной работы в день. В проекте появилось порядка десятков тысяч строк Go и JS. Но важны не строки кода, а то, что появился связанный продуктовый сценарий.

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

Это еще не production marketplace. Платежи, OAuth, юридические детали, операционные регламенты и безопасность нельзя считать полностью готовыми. Но как alpha-сценарий для проверки бизнес-гипотезы это уже работает: можно открыть продукт, пройти основной путь и обсуждать его предметно.

Что оказалось самым важным

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

Но почти сразу стало понятно: модель плюс доступ к репозиторию недостаточны. Нужна система вокруг агента. Hermes пришлось дорабатывать прямо по ходу эксперимента: усиливать планирование, добавлять recovery для зависших сессий, вводить проверки результата, требовать бизнес-сдвиг вместо формального списка файлов и отдельно контролировать frontend/UI.

Где качество проседало

Первая проблема - Hermes из коробки не был готов к такому режиму автономной разработки. Founder-mode требует длинного горизонта, восстановления после сбоев, контроля активной задачи, качества планирования и понимания, что именно считается полезным продуктовым результатом.

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

Третья проблема - UX/UI. Агент может сделать функционально рабочий экран, который выглядит как техническая демо-панель, а не как marketplace или CRM. После этого мы усилили требования к first viewport, убрали технический язык из пользовательских экранов, стали ориентироваться на знакомые marketplace-паттерны и требовать browser-proof.

Четвертая проблема - внешние интеграции. OAuth, платежи, юридические и операционные сценарии нельзя доказать без реальной интеграционной среды, ключей, sandbox-условий и ответственных решений. Агент может подготовить границы, статусы и диагностику, но production-ready интеграция требует реального контура.

Что это говорит о доверии к агентам

Основной вывод совпадает с нашей общей позицией: доверие к агенту строится не верой в модель, а архитектурой вокруг нее. Если дать одному агенту слишком широкий scope, доступ ко всему и ожидание, что он одновременно будет product, UX, backend, QA и DevOps, ошибок будет много. С человеком в плохо организованной роли было бы то же самое.

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

Почему это все равно важно

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

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

Что это значит для бизнеса

Founder-agent подход уже выглядит применимым для быстрых alpha- и MVP-задач, особенно когда продукт можно выразить через роли, статусы и сценарии. Он полезен там, где нужно быстро получить не презентацию, а рабочий предмет для обсуждения: какой путь проходит партнер, где нужен оператор, что видит покупатель, какие статусы понятны людям и где интеграции пока только подготовлены.

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

Итог

Мы дали агенту ТЗ один раз и дальше не вели его как обычного разработчика. За несколько дней он собрал рабочий alpha-срез CRM+marketplace и показал, что режим founder-agent реалистичен.

Но главный урок не в том, что "ИИ сам пишет продукт". Главный урок другой: автономная разработка начинает работать, когда вокруг модели есть правильная система управления. Без нее агент быстро уходит в мелкие задачи, слабый UI, неочевидные решения и recovery-проблемы. С ней он уже может несколько дней двигать продуктовую гипотезу вперед.

Контекстные материалы: про доверие к агентам, про tools vs skills и про агрессивность агента.