6 месяцев. Это сколько мы строили продукт с внешним разработчиком. Потом я психанула и сделала за 3 дня сама с помощью AI. Дальше — что я поняла из этого опыта.

Эта статья — не «AI заменит разработчиков». Это про другое — про то, как методология работы меняется, когда у тебя есть AI как партнер.

Что строили

Продукт назывался BidSpot. AI‑агент для b2b‑закупок на маркетплейсах Индонезии. Логика простая: закупщик описывает, что нужно, на естественном языке («нужны 2 ноутбука Asus Zenbook S 14 UX5406, бюджет до 30 млн IDR за штуку»). Дальше агент сам переводит запрос на индонезийский, ищет на Shopee / Tokopedia / Blibli, нормализует выдачу, считает per‑unit цены, ранжирует топ-7, сравнивает с медианой рынка и с похожими тендерами на платформе Zinit, отдает проверяемый markdown‑отчет со ссылками прямо на товары.

В ноябре 2025-го мы подписали договор с внешним разработчиком на MVP такого продукта. Архитектура двухстадийная: глубокий поиск (точная модель → лучшие предложения) и широкий поиск (если точной модели не найдено — подобрать альтернативы).

КП я запрашивала у трех подрядчиков. Все назвали MVP за 2 месяца. Сроки в трех КП были похожи — это убеждало, что 2 месяца — реалистичная оценка. Выбрала одного.

Stage 1 («Глубокий поиск») собрали. Не за 2 месяца. К маю Stage 2 еще не был в продакшне.

И вот здесь — главная проблема, которая выяснилась только в ретроспективе. Без лексики разработчика прийти к подрядчику со словами «здесь должно быть так, а не иначе, давай по‑моему» — невозможно. Не из‑за подрядчика — из‑за самой конфигурации работы. Заказчик без технического языка может только смотреть на демо, говорить «не работает» и ждать следующего демо через две недели.

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

К маю накопилось.

Что запустило

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

Вторая эмоция шла сразу: «А я не хочу злиться и ничего не делать. Я хочу делать, а не злиться».

В этот момент открылся Claude и пошел первый промт.

Что получилось за 3 дня

Вечером 27 мая — один промт, один API‑ключ, никакой инфраструктуры. Пять разных категорий товаров — ноутбук, кондиционер, промышленный клей, проектор, холодильник — прошли через прототип. Все пять вернули проверяемые markdown‑отчеты с реальными ценами на индонезийских маркетплейсах. Это был proof of concept.

Дальше — три рабочих дня.

К концу третьего дня в продакшне работало:

• Backend — FastAPI на Railway. От первого коммита до доступного API — 38 минут. Полный пайплайн: перевод запроса → SerpAPI Google Shopping → нормализация → ранжирование через Claude Opus → markdown‑отчет.

• Frontend — web‑интерфейс на Lovable, через который можно сделать запрос и получить отчет.

• Бенчмарк с платформой Zinit — автоматическое сопоставление товара из выдачи с похожими закупками в тендерах Zinit, с per‑unit нормализацией цены.

• 8 критических доработок качества — точное совпадение артикулов, обработка multi‑pack товаров, дедупликация дубликатов, бейдж «Different SKU» для близких вариантов, Marketplace Trust Rule для safety‑critical категорий и еще несколько.

• Архитектурный слой feature flags — под будущие тарифы (без него продукт нельзя продавать с разной премиум‑логикой).

• Документация для передачи — README, HANDOFF.md с блоком «как не сломать», чеклист переноса домена, описание env‑переменных.

Стек: FastAPI + Anthropic Claude (Sonnet 4.5 на пайплайне + Opus 4.5 на ранжировании) + SerpAPI Google Shopping + Railway‑хостинг + Lovable‑фронтенд. Стоимость одного поиска ~$0.53. Время одного поиска ~60 секунд.

Это не «MVP, который теоретически работает». Это продукт, который можно передать новому техлиду — он откроет HANDOFF.md, прочитает чеклист и поймет, как система устроена и где она может сломаться.

Дальше — про метод, без которого этих трех дней бы не было.

Растущее ТЗ как метод

Классический сценарий работы по ТЗ, который я знаю:

1. Пишется ТЗ.

2. ТЗ отдается разработчику.

3. Идет ожидание.

4. Приходит демо.

5. На демо что‑то не так.

6. Пишется новое ТЗ или дополнение.

7. Goto 2.

Что в этом не так: ТЗ написано до того, как кто‑либо увидел первый результат. Большая часть деталей, которые на самом деле важны, обнаруживается только когда продукт сталкивается с реальными данными. Узнавание происходит через две недели — через демо. Исправление — еще через две недели.

Этот темп — норма индустрии. Никто его не выбирал; он сложился исторически, когда цикл «гипотеза → проверка → коррекция» стоил дорого по человеко‑часам.

Когда в качестве партнера появляется AI, темп цикла меняется. И это меняет все остальное — в том числе само понятие «ТЗ».

Правило

В одной строке:

Каждая проверка результата = расширение списка задач.

В переводе на человеческий: ТЗ не пишется до конца. Пишется первый набросок. Запускается первая версия. Дальше идет проверка результата — и из того, что увидела, рождаются новые задачи в ТЗ.

Следующая итерация. Снова проверка. Снова находки → новые задачи. ТЗ растет из результата, а не из предположений.

Вот один цикл из рабочей переписки с Claude, дословно:

«Внеси в ТЗ твои находки в виде задач. Сначала зафиналим обсуждение, проанализируем еще несколько моментов (пришлю в следующем сообщении), а потом будем реализовывать задачи.»

И ответ — три новые задачи в ТЗ с описанием «где проявилось / корень / решение / acceptance / объем». Я их не формулировала. Я только смотрела на отчеты и говорила, что необходимо добавить, чего не хватает, на что обратить внимание — Claude переводил наблюдения в задачи.

Через час — следующая команда:

«Подготовь на основе этих пунктов план сессий. По приоритету — сначала устраняем качественные баги.»

13 накопленных задач разбиваются на Сессию 5 (качество, 8 задач) и Сессию 6 (надежность, 5 задач). Внутри каждой — приоритеты Critical / Should.

Это и есть «растущее ТЗ». Не оно пишется заранее — оно направляется в моменте. От человека требуется одно: смотреть на результат и говорить, что в нем важно, что мелочь, а что блокер. Перевод содержания в структуру задач делает AI.

Пример провала

Чтобы не было ощущения, что все работает с первого раза.

Одна из задач Сессии 5 звучала просто: в финальном объяснении выбора AI должен ссылаться на видимую читателю позицию товара в списке, а не на внутренний идентификатор. Логично, очевидно, исправляется через корректировку промта на 5 строк.

Первая итерация: формулировка переписана. Запускаю. Результат: AI продолжает писать «(idx N)» в скобках.

Вторая итерация: добавлен явный запрет на парентезу с idx. Запускаю. AI больше не пишет «(idx N)», но порядок ссылок все равно не соответствует видимому порядку.

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

Четвертая, финальная итерация: промт переписан с нуля. Не «не делай X», а «делай так: формулируй объяснение через цену — „за 25.7 млн получаете 32 GB, против 30 млн у первой позиции“„. Запускаю. Работает.“»

Каждая итерация — 20–30 минут. Четыре итерации на одну задачу — примерно 2 часа. И это нормально.

В классической работе по ТЗ это заняло бы 4 демо подряд через 2 недели каждое — два месяца на одну, по сути мелкую, задачу. С растущим ТЗ — два часа в один заход. Это и есть та самая разница в темпе цикла.

Санити‑чек

Без одного дополнительного правила растущее ТЗ превращается в свалку.

Правило — остановка для инвентаризации каждые 2–3 часа работы. Дословная формула, которая у меня хорошо работает:

«Делаем короткую паузу. Выдыхаем. Подготовь статус: что было зафиксировано как „необходимо сделать“, что было зафиксировано как „не забыть и обязательно“, что было упомянуто, что из этого было сделано, что осталось.»

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

Эта пауза занимает 5 минут и снимает 80% риска уйти не туда. Без нее через 3–4 часа работы накапливается дрейф: задачи трактуются по‑разному, забывается, что уже сделано, появляются дубли.

Санити‑чек — это не задержка. Это способ продолжать двигаться быстро, не теряя направления.

Эффект 50×

Хочется здесь быть особенно аккуратной — потому что часто отсюда делают неверный вывод «значит, разработчики не нужны». Это не так.

Разница в темпе цикла.

С разработчиком цикл «нашла → описала → внедрил → проверила» занимает 1–2 недели. И это нормально. Разработчик — это человек, у которого несколько проектов, ему нужно переключаться, нужно встретиться, нужно протестировать.

С AI тот же цикл занимает 15–30 минут.

Когда цикл укорачивается в 50 раз, необходимость писать ТЗ заранее отпадает. Оно пишется в процессе. И это не «улучшение старого процесса». Это другой режим работы, в котором отдельные правила старого процесса просто перестают иметь смысл.

AI как партнер снимает требование заранее знать ответ. А заранее знать ответ — это ровно то, чего не получалось у меня в первые шесть месяцев работы с подрядчиком. Я не знала индонезийские маркетплейсы. Не знала, как ведут себя multi‑pack товары. Не знала, что Google Shopping возвращает Bahasa‑результаты в три раза меньше, если запрос не переведен.

Все это узнавалось из самих отчетов. И в момент, когда узнавалось — расширялось ТЗ.

Что было сложно, а что просто

Сложно: не код. Код Claude писал хорошо.

Сложно — внешние сервисы. Railway, SerpAPI. У каждого своя логика авторизации, свои переменные окружения, свои ошибки. Это та область, где AI не работает в одиночку: он не видит мою консоль Railway, не знает, какой именно env‑var забыт. Здесь нужны руки — копировать ошибки, искать в документации, пробовать заново.

Это к разговору о «AI все сделал»: нет, не все. AI закрыл архитектуру и логику. Операционные стыки закрылись руками.

Просто: соблюдать само правило «каждая проверка результата = новая задача в ТЗ».

Но здесь важная оговорка — и она опровергает соблазнительный, но неверный вывод.

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

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

Цельная картина — в голове. Детальная инвентаризация — в ТЗ. Без первого второе бесполезно. И это к слову про порог входа: метод не «упрощает работу», он сдвигает ее в другую плоскость, где экспертное мышление становится критичнее, а память на детали — менее необходимой.

Что значит «3 дня»

Это не «все готово». Это продукт, который можно передать команде.

И вот здесь — главное отличие от шестимесячного процесса с подрядчиком. У подрядчика к шестому месяцу не было ни HANDOFF‑документа, ни чеклиста, ни описания «как не сломать систему». В работе с растущим ТЗ все это появилось автоматически — не потому что кто‑то лучше, а потому что методология растущего ТЗ порождает документацию как побочный эффект. Каждая задача описана. Каждое решение зафиксировано. Передача — это просто прочитать файл.

Кому подойдет метод

Не каждому.

Работает, если есть:

1. Цельная картина продукта в голове. Без этого растущее ТЗ становится плоским списком без приоритетов.

2. Готовность вести документацию параллельно с работой. ТЗ — не отчет после факта, а живой документ, растущий прямо в процессе.

3. Привычка проверять каждый шаг до перехода к следующему. Без этой дисциплины растущее ТЗ превратится в свалку.

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

Не работает для:

• Команды разработчиков. Растущее ТЗ — для одного человека + AI. У команды появляется проблема синхронизации.

• Регуляторных продуктов, где ТЗ должно быть зафиксировано заранее (банки, медицина, госзаказ).

• Продуктов, где цена ошибки в одной итерации очень высока (продакшн с миллионами пользователей).

Главное

Дело не в скорости.

Дело в том, что появилась новая профессиональная единица: «эксперт + AI». Эксперт здесь — не «эксперт в коде». Эксперт — это тот, кто знает задачу. Тот, кто может посмотреть на отчет и сказать «здесь не так, потому что multi‑pack искажает медиану в два раза».

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

Это и было причиной, по которой 3 дня хватило. Не AI. Знания задачи + AI хватило.

«6 месяцев vs 3 дня» — это не про то, что один лучше другого. Это про то, что сжимать цикл «гипотеза → проверка → коррекция» в 50 раз — это другой режим работы. В этом режиме одни вещи возможны, другие — теряют смысл.

Если сейчас в голове возник вопрос «а можно ли так быстро?» — попробуйте. На следующей маленькой задаче. С правилом «каждая проверка результата = новая задача в ТЗ». Через неделю напишите, что получилось.