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, прочитает чеклист и поймет, как система устроена и где она может сломаться.
Дальше — про метод, без которого этих трех дней бы не было.
Растущее ТЗ как метод
Классический сценарий работы по ТЗ, который я знаю:
-
Пишется ТЗ.
-
ТЗ отдается разработчику.
-
Идет ожидание.
-
Приходит демо.
-
На демо что‑то не так.
-
Пишется новое ТЗ или дополнение.
-
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‑документа, ни чеклиста, ни описания «как не сломать систему». В работе с растущим ТЗ все это появилось автоматически — не потому что кто‑то лучше, а потому что методология растущего ТЗ порождает документацию как побочный эффект. Каждая задача описана. Каждое решение зафиксировано. Передача — это просто прочитать файл.
Кому подойдет метод
Не каждому.
Работает, если есть:
-
Цельная картина продукта в голове. Без этого растущее ТЗ становится плоским списком без приоритетов.
-
Готовность вести документацию параллельно с работой. ТЗ — не отчет после факта, а живой документ, растущий прямо в процессе.
-
Привычка проверять каждый шаг до перехода к следующему. Без этой дисциплины растущее ТЗ превратится в свалку.
-
Дисциплина формулировок. Отдельная большая тема — как именно нужно говорить с AI, чтобы получать неповерхностные ответы. Об этом — следующим текстом.
Не работает для:
-
Команды разработчиков. Растущее ТЗ — для одного человека + AI. У команды появляется проблема синхронизации.
-
Регуляторных продуктов, где ТЗ должно быть зафиксировано заранее (банки, медицина, госзаказ).
-
Продуктов, где цена ошибки в одной итерации очень высока (продакшн с миллионами пользователей).
Главное
Дело не в скорости.
Дело в том, что появилась новая профессиональная единица: «эксперт + AI». Эксперт здесь — не «эксперт в коде». Эксперт — это тот, кто знает задачу. Тот, кто может посмотреть на отчет и сказать «здесь не так, потому что multi‑pack искажает медиану в два раза».
Я не разработчик. Но я знаю задачу. Знаю, какой результат должен получить закупщик. Знаю, что в Индонезии маркетплейсы работают на Bahasa и что без перевода запроса выдача в три раза меньше. Знаю, что b2b‑закупщик не верит круглым числам и хочет видеть проверяемый источник цены.
Это и было причиной, по которой 3 дня хватило. Не AI. Знания задачи + AI хватило.
«6 месяцев vs 3 дня» — это не про то, что один лучше другого. Это про то, что сжимать цикл «гипотеза → проверка → коррекция» в 50 раз — это другой режим работы. В этом режиме одни вещи возможны, другие — теряют смысл.
Если сейчас в голове возник вопрос «а можно ли так быстро?» — попробуйте. На следующей маленькой задаче. С правилом «каждая проверка результата = новая задача в ТЗ». Через неделю напишите, что получилось.
ссылка на оригинал статьи https://habr.com/ru/articles/1046147/