Со стартапами и новыми продуктами всё понятно: вайб-кодинг радикально ускоряет проверку гипотез на живом продукте — разработка становится намного быстрее и дешевле, чем само получение обратной связи от клиентов. Но давайте разберёмся, что меняется в другом кейсе:
- когда у вас годами отлаженные процессы и куча пользователей легаси-продукта,
- когда годами жили по принципу «работает — не трогай!»,
- но всё-таки хочется внутри старого делать новое на порядок быстрее и дешевле, чем прежние 10 дней и ~$1000 на фичу или на красивый лендинг.
Мы с COO ScrumTrek Сергеем Липчанским это желание уже реализовали. Не будучи программистами, мы заменили самую большую легаси-систему Скрамтрека, включающую публичный сайт, CMS, CRM и автоматизацию работы с участниками и оплатами тренингов/курсов/конференций. У Серёжи, кстати, есть свои инсайты про этот кейс: например, вот про «парное программирование».
А я здесь расскажу про свои инсайты — с точки зрения бывшего системного аналитика и менеджера. Большинство моих ИИ-проектов и ИИ-исследований до сих пор были не про разработку софта. Но этот софтверный проект превзошел мои ожидания по количеству находок в области управления ИИ-агентами.
Пару слов о масштабе проекта. Старая система на PHP+React проработала ровно 10 лет: два программиста писали её почти три года, потом один много лет дорабатывал. 280 тысяч строк PHP, почти столько же JavaScript, дюжина интеграций. Новая система на Next.js уложилась в 450к строк TypeScript — кодовая база от ИИ, на удивление, не раздулась по сравнению с теми 550 тысячами строк, что писали люди.
Расходы на поддержку упали минимум в десять раз: теперь не нужно тратить ни ~300к руб/мес на разработчика, ни ~80к руб на красивый лендинг от Tilda-дизайнера. А расходами на токены можно пренебречь: одной подписки Claude за $100 в месяц с запасом хватает на доработки системы, которые сотрудники заказывают в telegram-чате с ботом (а в ScrumTrek работает больше 20 человек).
Выросли только усилия того сотрудника, кто ставит задачу и оценивает соответствие результата своей задумке, но это было ожидаемо. Т.е. времени теперь нужно раза в два больше, чем при делегировании живому разработчику в духе "сделай нам хорошо".
Эта статья — не про инструменты, а про общий процесс разработки с ИИ-агентом; в нашем кейсе замены легаси процесс оказался необычным. Он позволил обойтись совсем без разработчика — несмотря на то, что это не новый продукт: большое число клиентов нам не позволяло выпустить "MVP" вместо полнофункционального сайта.
Подробнее об этом — в разделе 3 и далее.
1. С чего начать. Спеки из кода — необходимо, но недостаточно
Первый вопрос, который надо задать себе, — это не «как клонировать легаси один в один?», а «чем вообще это должно быть лучше легаси?». У нас ответами стали, например:
- пересмотр некоторых частей структуры сайта (страницы почти без трафика решили редиректить на правильные с точки зрения SEO),
- замена части интеграций собственным функционалом с прямой экономией на подписках (например, свой рассыльщик вместо SendPulse),
- несколько новых сущностей в ER-модели вместо денормализованных легаси-таблиц.
Ну, а привычные сотрудникам экраны и неустранимые интеграции мы сознательно копировали как есть: лучшее — враг хорошего. Только некоторые мелочи ИИ-агент предлагал делать современнее, чем было, и мы обычно соглашались.
Второй вопрос — стек, архитектура и прочие технические решения для новой системы в целом. Общения с Клодом вполне хватило Серёже для того, чтобы взвесить альтернативы, выбрать Next.js как основной фреймворк, Prisma для работы с данными и принять кучу более мелких решений. Модели Claude и OpenAI сейчас очень хорошо обучены таким темам, не уступают опытным разработчикам.
Параллельно я делал спецификации из легаси-кода, у меня они были трёх видов: по UI, по бэкенду и по интеграциям. Уже на этом этапе я считаю обязательным, чтобы агент задавал вопросы человеку. Потому что в легаси точно есть проблемы юзабилити, архитектурные проблемы, не нужный функционал и такие техрешения (например, уровня ER-схемы), которые не следует копировать без изменений. На скриншоте ниже — самый первый промпт из тех, которым я генерировал такие спеки (специальный харнесс для такого делать не стал, так как задача для меня одноразовая).
После этого я генерил спеки для эпиков и крупных фич уже почти на автомате — по сделанному в первый раз гайдлайну или по наиболее подходящему примеру другой спеки.
Если вы уже хотите заменять свое легаси, посмотрите flow-диаграмму ниже и обратите внимание на Q&A — те самые вопросы агента человеку.
Вот полезная фраза из упомянутого на диаграмме гайдлайна для спек по бэкенду:
A backend spec captures functional server-side requirements derived from this project, so that another AI can implement equivalent behaviour in a new codebase. The new project has its own development guidelines, tech stack, and data model. Don't over-specify. Capture only the unobvious functional solutions — the rules and behaviours that would be lost if someone only looked at the UI spec.
Но какие бы продуманные у вас ни были гайдлайны, и на сколько бы вопросов вы ни ответили, всё равно это ничего не гарантирует. Как на этапе составления спеки, так и на этапе её чтения другим агентом всегда будут незамеченные или неверно понятые места. Это нормально, у людей внимательность точно не лучше. Как не пустить эти косяки в продакшен — ниже и в разделе 3.
Первый ключ к качеству и скорости вайб-кодинга (ну, после хорошего агентного харнесса, который за рамками этой статьи) — это широкий разнообразный контекст + немного контекст-инжиниринга.
Здесь контекст — не только легаси-код, легаси-документация и схема легаси-БД, но и указания агенту самостоятельно ходить в локальную копию легаси-базы, а также по страницам старого сайта. Причем это не столько на этапе первичного создания спек, сколько на этапе реализации нового кода по этим спекам.
Кстати, о документации. У старой системы её не было — были только неактуальные user stories и иные заметки в таск-трекере. У новой системы — 270 тысяч строк в markdown, и ~80% из них агент актуализирует сам по ходу изменений, а не «для истории». Описанные выше спеки из легаси (~15%) стали лишь источником для основной документации.
Кроме вышеперечисленного, полезный контекст агенту иногда может дать поиск в интернете (кодинговые агенты по умолчанию в веб-поиск не ходят — нужно явно их туда отправлять). А иногда бывают и неожиданные источники информации: пример с 1С я описывал здесь.
Но конечно, не стоит добавлять всё это к каждому запросу бездумно, так как агент очень любознателен и будет часто пользоваться всеми источниками, указанными ему явно. А перегруз агента информацией легко уведёт его от простых правильных решений к сложным или неправильным, или даже к решениям неактуальных проблем (мы же не просто копируем легаси, а сразу улучшаем!). Лично я решил НЕ включать инструкции типа «смотри в легаси-базу» даже в скиллы (не говоря уже про общий CLAUDE.md). Мне было несложно добавлять такую инструкцию в промпт — в тех случаях, когда я считал, что это поможет.
2. Циклы как способ борьбы за качество
Я полностью разделяю эту формулировку Серёжи. В частности, ИИ может нас удивлять, предусматривая кучу полезных деталей, но при этом может упускать очевидные несоответствия. Вот типичный пример, когда я (не разбираясь в деталях, но разбираясь в общем смысле задачи) задал агенту два вопроса:
Бывают разные циклы для устранения подобных проблем, т.е. для повышения качества результата.
- Многие циклы включают human in the loop, т.е. ждут человека в определенных точках. Благодаря этому я и смог задать агенту вопросы, которые исправили ситуацию на скриншоте выше.
- Самые короткие циклы в кодинге полностью автоматизированы. Например, цикл из code review и устранения найденных по коду несоответствий может требовать несколько итераций совсем без участия человека.
- Некоторые циклы могут занимать месяцы, а каждая из их итераций инициируется человеком.
Но прежде чем переходить к самым длинным циклам последнего типа (в которых половина смысла этой статьи), дам еще одну схему. Вот из чего состоял мой типичный процесс работы над функционалом:
- Specifying features: из легаси-спек и кода через сессию вопросов-ответов появляются спеки конкретных фич. Именно они «синхронизируются» с кодом при дальнейшей разработке и поддержке.
- Implementing/refining a feature: обычный цикл «разведка по коду/базе → уточнение спеки → разработка → приёмка → тесты, ревью и сборка».
- Validating features: высокоуровневые промпты, с которых начинается разведка сразу по многим фичам — они запускают те длинные итерации, о которых речь в следующем разделе.
Заметьте: флоу на вышеприведенных схемах "линейные" — никаких дополнительных итераций. В том числе, это позволяет использовать привычные общие для разных проектов agent skills (а не городить свои скиллы под один проект замены легаси только из-за повышенных требований к качеству в этом проекте).
И конечно, такая "линейность" не отменяет встроенную в Claude Code способность к агентным циклам. Эта способность нередко достаточна для микро-итераций ради повышения качества внутри одного шага отдельной задачи. Имею в виду, что вокруг каждой циферки на вышеуказанной схеме обычно крутится свой цикл с самопроверками даже «из коробки». Ну, а наш девелоперский харнесс от Серёжи Липчанского включает кучу конкретных условий и инструкций, заставляя этот цикл быть ещё более «внимательным» и ещё меньше требовать участия человека. В данном случае harness (агентная обвязка) состоит из скиллов, правил, субагентов и хуков.
3. Сквозные итерации: проверка того, что уже «работает»
С учетом нехватки времени и девелоперской экспертизы, в нашем проекте оказались нужны не только обычный агентный цикл и итерации харнесса. Мы также запускали итерации на уровне ВЫШЕ решения отдельной задачи (фичи). Это итерации для валидации/улучшения уже запрограммированного функционала — почти всегда для многих фич сразу. Причём границы функционала бывают размыты и не очень предсказуемы — в одну итерацию входит один набор фич, а в следующую итерацию другой. Тут всё зависит от нижеописанного «угла зрения», с которого мы смотрим на систему.
Управление таким циклом сложно поручить агенту, но несложно вести самому. То есть, от вас требуются промпты из нескольких слов, каждый раз эти слова разные, так что думать всё-таки надо. Я бы поделил такие промпты на два типа (в терминах известной модели Херси-Бланшара это 1-й и 4-й типы лидерства):
- Вы направляете. Например, «Посмотри, как реализована таблица продуктов в админке, и убедись, что пользователи, промокоды и шаблоны рассылок имеют соответствующий функционал, отображение и поведение ссылок» или «Проверь все кейсы процесса регистрации неавторизованного клиента с точки зрения возможных ошибок. При любой ошибке должно показываться осмысленное сообщение». В этом случае вы сами указываете угол зрения, и от вашей способности чувствовать возможные проблемы многое зависит. Среди углов зрения также может быть, например, code reusability или security, хотя это уже ближе ко второму пункту:
- Вы делегируете. Например, «Исследуй возможные проблемы с текстовыми метаданными всех публичных страниц [или: с миграцией, с отправкой этих рассылок, …] и предложи план валидации». Кстати, «исследуй» — это вообще волшебное слово, которое переключает кодинговых агентов от дефолтного «поиска в глубину» на «поиск в ширину». Здесь даже можно не сужать цель работы (в данном примере можно было бы сузить до «SEO»). Только тогда агент с большой вероятностью подумает и про те перспективы/углы зрения, которые вам не пришли в голову (в данном примере это может быть превью страниц для соцсетей и неконсистентность og-атрибутов с основными title и description).
Изначально я ничего такого делать не собирался. Но по ходу проекта понял, что нужно выделять не меньше трети времени на подобные сквозные (cross-feature) валидации функционала.
Заметьте, что в сквозной валидации функционала на входе нет ни задач из бэклога, ни каких-то еще конкретных требований. Есть угол зрения (или несколько углов от ИИ), вопросы и ответы. По верхнеуровневому промпту агент делает кучу проверок (тоже своего рода агентный цикл) и дальше вы с ним решаете, какие его находки оформить в задачи, какие оставить на потом, а какие вообще нерелевантны здравому смыслу. А вот сколько таких проходов нужно делать — сильно зависит от того, какой функционал перед вами.
4. Сколько раз переделывать
С разработчиками-людьми число итераций определялось их стоимостью, а также терпением (чем больше одно и тоже переделываем, тем скучнее это разработчику). С агентом оба ограничителя исчезают, и остаётся один — ваша голова. И поэтому ответ на вопрос «сколько раз переделывать» теперь разный для разных типов функционала. Сделаете мало итераций там, где глубоко не погружались, — система останется недоделанной (даже хуже, чем если бы разработчик ее делал по классическому водопаду). Сделаете много итераций в задаче, непонятной для вас и для ИИ, — потратите на повторные размышления свое дорогое время.
Что лучше переделывать оптом
Возьмём статический контент и визуал, который с ИИ переделывать можно очень часто. В отличие от обычной разработки, в одну итерацию можно включать сразу много типов страниц или даже весь сайт целиком. Ценой «перерасхода» токенов вы «экономите свои усилия на декомпозицию задач и, например, на продумывание, чем разные страницы у вас на сайте отличаются (у вас же есть легаси-сайт, с которого ИИ быстро соберёт структуру и типы страниц).Структуру, контент и визуал агенту разжёвывать нужно меньше, чем разработчику-человеку. Поэтому скоуп каждой итерации можно смело увеличивать на порядок, не говоря уже про большее число итераций.
Рутинный функционал: черновой MVP и цикл улучшений
Другой похожий пример — админская панель или иной CRUD-функционал (сюда же можно отнести типовые отчёты и настройки). При замене этой части легаси можно быстро создавать черновой MVP на основе схемы БД, буквально в несколько промптов. Да, этот MVP будет намного менее юзабельным, чем старая система. Но это станет базой, поверх которой достаточно легко запускается итеративный процесс функциональных улучшений.
И кстати, он не обязан закончиться в момент релиза новой системы. Благодаря ИИ процесс улучшений происходит настолько быстро, что сотни недоработок и багов исправляются за считанные недели, так что пользователи не успевают сильно расстроиться.
Миграционные скрипты: семь раз отмерь
Противоположный в некотором смысле пример — миграционные скрипты, которые прогоняются всего один раз при выходе в продакшен. Но с ИИ здесь тоже можно и нужно делать кучу итераций, постепенно сводя к нулю вероятность ошибки или неполной миграции. «7 раз отмерь — 1 раз отрежь» — это 7 итераций. Сначала скрипты были написаны через сравнение старой и новой схемы БД, но затем я возвращался к их валидации раз пять под разными углами (ретроспективно стало понятно — нужно было возвращаться еще больше!).
Здесь тоже думать особо не надо, так как промпты очень простые: «Проверь миграцию с точки зрения …» и «А теперь снова прогони на реальных данных и проанализируй отчёт». При обычной разработке мы не могли себе такого позволить. Причём нормального разработчика, в отличие от агента, на третий-пятый раз уже начинало тошнить от перепроверки одного и того же.
Сложный и непонятный функционал: почти без итераций
Самое спорное. Очень сложный и/или наименее понятный вам функционал (например, интеграцию с 1С или сложный биллинг) стоит реализовывать в последнюю очередь, чтобы избежать его поломки в процессе итеративной переработки остального продукта. Да, это противоречит обычным принципам разработки, когда сложности и риски планируются на самые первые этапы проекта. Но вайб-кодинг требует несколько итераций валидации, поэтому вам придётся несколько раз загружать всю эту сложность в голову. Чтобы сэкономить умственные усилия, достаточно погрузиться в нее 1 раз, а потом забыть как страшный сон, выйдя в продакшен и больше не ломая этот сложный кусок смежными фичами.
Ну, а риск «вдруг это не успеем» в случае замены легаси закрывается: этот "страшный" кусок всегда можно клонировать один в один, отвечая на вопросы агента лишь о том, как старое стыкуется с уже изменённым новым вокруг него.
Таким образом, я на своем опыте пришел примерно к тому же, что раньше лишь читал у кого-то: экономить надо, прежде всего, свою голову, а не токены. За счет многократных переделок экономить голову получается хорошо. Если, конечно, не превращать такие итерации в догму.
5. Что меняется в процессе без разработчиков
Чем описанный мной процесс отличается от обычной разработки руками программиста (пусть даже с ИИ-ассистентом в его руках)?
При ИИ-разработке отдельных фич от вас требуется меньше внимательности, девелоперской экспертизы и глубины погружения в каждую тему. Девелоперского опыта у вас может вообще не быть (например, я раньше программировал только небольшие некоммерческие проекты). Впрочем, тогда нужен опыт управления разработкой или опыт участия в ней в любой другой роли — например, тестировщика или аналитика.
Несмотря на такие низкие требования к себе, вы добиваетесь приемлемого качества за счёт того, что по одному и тому же функционалу проходите много раз.
А если смотреть еще шире, общий принцип создания больших систем без разработчиков вижу так: не натягивайте на это привычный процесс управления разработчиками-людьми. Даже если с людьми оптимальным процессом достижения цели был бы водопад (замена легаси как раз хороший пример такой цели), с ИИ лучше делать много итераций, причём каждая итерация с непривычно большим скоупом.
Обычно разработчик внимательно продумывает и доводит каждую фичу до состояния «работает, но могут быть баги». Здесь иначе: сначала большая часть системы доводится до «работает не полностью и очень криво», но по ней легко запускается цикл улучшений и добавлются сложные фичи.
На практике это добавляет на этап Delivery новую единицу работы (отчасти уменьшая требования к этапу Discovery, если он в вашем проекте нужен). Раньше единственной единицей была задача (фича или фикс чего-то конкретного): сформулировать, подождать разработчиков, принять. А теперь значительное время должны занимать проверки разработанной системы с разных точек зрения — на том высоком уровне общности, который раньше относился только к Discovery. Теоретически, такое было полезно и раньше, но без ИИ частые проверки со всех углов зрения занимали бы неприлично много ресурсов.
Какие для этого нужны навыки? Углы зрения — это всегда нечто очень большое и неконкретное. Но если вы руководитель или техлид или хотя бы технически грамотный продакт, то именно это для вас привычно, а все остальное — "дело техники", и как раз ту конкретную часть работы во многом теперь забирает ИИ. Если вы аналитик или тестировщик, вам намного сложнее думать на высоком уровне абстракции; но если хотите остаться в этой индустрии, придется учиться мыслить почти как технический менеджер. Тестированием, кстати, в этом проекте я почти не занимался: агенты с Playwright творят чудеса.
Значит ли это, что в ходе такой высокоуровневой ИИ-разработки вам почти не нужно думать как технарь? Конечно, нет! Сэкономленные на чтении спецификаций и кода когнитивные усилия однозначно есть куда применить:
- ИИ почти всегда ошибается в реализации ваших идей. Как бы ваш харнесс ни заставлял агента заниматься самопроверками на всех этапах (включая adversarial code review через другую модель), ваши проверки на адекватность промежуточных результатов совершенно необходимы. И это не только «бегло проверять UI глазами», но и «читать саммари каждой написанной спеки и каждой находки из кода, которую агент счёл нужным довести до вашего сведения». Это ваше ревью решений: почему сделано так, что при этом отброшено, как это сочетается с другими похожими кусками функционала и т.п. Без этого процесс починки дефектов может «расходиться» или сходиться слишком медленно, т.е. система будет глючной очень долго, несмотря на кратное ускорение каждого фикса.
- ИИ почти всегда ошибается в проектировании. На начальных этапах проекта, он точно будет переусложнять в одних местах и забывать предусмотреть важное в других. В случае легаси-системы эта проблема становится не слишком критичной (легаси уже наступало на грабли плохого проектирования и рефакторилось); но зато здесь велик риск, что агент будет принимать за основу архитектурные и технические решения легаси. Поэтому в вашем процессе должно быть:
- не только восстановление по коду всех техрешений по крупным кускам функционала (low-level design),
- но и критическая оценка агентом этих решений,
- а главное — ваши обсуждения с агентом, включая вопрос «почему так сделано?» к агенту и «зачем это нужно?» к вам.
Да, часть решений, которые раньше принимали разработчики или даже вы сами, теперь отдаются на откуп ИИ: как лучше декомпозировать задачу, как сдизайнить UI, как покрыть осмысленными тестами, ... почти все, что касается кода, тестов и даже спецификаций.
Как ни странно, к этой второй части относятся не только ответы на вопросы ИИ перед кодингом, чтение саммари после него, и обдумывание, с какой стороны ещё раз проверить миграцию или публичную часть сайта. Например, мне нередко приходилось самому приводить агента к мысли о выделении хелпер-функций для сходного функционала (после чего он обычно радостно рассказывал, что отсутствие оного reusable code уже привело к таким-то проблемам 🙂). И это даже несмотря на крутой харнесс. Впрочем, уже через год этот пример может остаться в прошлом: модели и агенты становятся всё внимательнее и умнее.
Заключение
Итак, вот небольшой чек-лист для тех, кто смотрит на свою легаси-систему и думает «а может, хватит с ней возиться?».
- Начните с вопроса «чем новое должно быть лучше?», а не «как клонировать?».
- Первичные спеки снимайте с легаси-кода, но с обязательными вопросами агента к вам.
- Спек недостаточно: Давайте агенту доступ к широкому контексту — коду, базе, старому сайту, интернету, ... — но не в каждом промпте, а там, где это поможет.
- Оставляйте не меньше трети времени проекта на валидацию и переделку крупных кусков функционала "оптом". В понятных вам случаях направляйте агента (угол зрения задаёте сами), в менее понятных или очень громоздких случаях — делегируйте ему поиск проблем и вопрос "а что еще можно проверить?".
- Подбирайте характер итераций под тип функционала: многое можно сделать "хуже чем MVP" одним проходом и затем запустить цикл улучшений; а там, где тратится больше всего ваших когнитивных усилий, лучше обойтись вообще без итераций.
- При ИИ-разработке не копируйте бездумно привычный процесс управления живыми разработчиками.
Ваша роль вайб-кодера — в сравнении, скажем, с ролью технического менеджера — в чем-то становится более технической (теперь только вы можете заметить в словах агента конкретные потенциальные проблемы), а в чем-то — менее технической (высокая скорость ИИ делает возможной валидацию системы на самом высоком уровне абстракции).
Больше всего мыслетоплива уходит на пункты 2 и 4, на ревью сводок агента и на переключение между уровнями абстракции... экономьте свои усилия ценой перерасхода токенов. В частности, пункт 2 требует времени и умения принимать решения при неполной информации. Пункт 4 требует не столько времени, сколько когнитивных усилий — умения посмотреть на систему с высоты птичьего полёта, причём каждый раз под новым углом.
По-моему, главные критерии применимости таковы:
- Наличие большого контекста, в идеале включающего много кода. В моём случае это была большая легаси-система, но может подойти, например, код нескольких опенсорсных проектов, которые в совокупности содержат почти весь нужный вам функционал.
- Наличие нескольких месяцев от старта проекта до продакшена. Описанный процесс — отнюдь не для «MVP за неделю»… Но, к счастью, для MVP вообще никаких серьёзных процессов не нужно.
- Ваша техническая грамотность. Вы не обязаны знать все слова про код, который пишет вам агент (при необходимости уточняйте у него смысл терминов или просите переформулировать «на продуктовом языке»). Но вам нужно понимать, как устроен код в целом, каковы базовые принципы проектирования, тестирования, деплоймента и т.д. Впрочем, если вы поняли 90% слов из этой статьи, вашего уровня грамотности должно хватить 😊.
