Вайб-код для настоящих инженеров: старые практики в новых реалиях

Итак, вопреки утверждениям скептиков (среди которых не так давно был и я) ИИ-разработка с двух ног влетела в настоящую промышленную эксплуатацию, и мем уже совсем не тот: не джун теперь роняет прод, а нейросеть убивает статистику доступности гитхаба, амазона, Cloudflare и даже самой мекки вайб-кодинга — сервисов Anthropic и OpenAI. 

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

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

Но ведь не с чистого же листа начинать?

Так и быть, не буду я сгущать краски. Во-первых, уже есть база, с которой согласны ± все. Во-вторых, уже точно видно, что есть идеи, куда все идёт. В-третьих, никто мне не мешает воспользоваться трибуной и поделиться своими опытом ^[1], мнением и подходом к этому делу. Тем более, что эта статья появилась именно потому, что меня несколько человек попросили поделиться опытом.

Всё последующее следует из 3,5 месяцев танцев с Claude, 4к коммитов, 1500 тестов (из которых ~350 — e2e), 25к строк весьма неплохо отрефакторенного продакшн-кода (12k java back + 12k ts/tsx FE) и такого же объёма тестового кода. Ну и внимательного наблюдения за коллегами и индустрией.

Меня зовут Саша Раковский. Работаю техлидом в расчётном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка ^[2] может стоить банку сотни миллионов рублей. Законченный фанат экстремального программирования, а значит и DDD, TDD, и вот этого всего. Штуки редкие, крутые, так мало кто умеет — для этого я здесь, делюсь опытом. Если стало интересно, добро пожаловать в мой блог ^[3].

Коротко по теории

Начнём с того, о чём уже все более-менее договорились: ЛЛМ-ки бессовестно врут и фатально ошибаются. Это часть их природы, тут остается только смириться и учиться работать в такой токсичной среде.

Сontext Rot

Что ещё важнее, ЛЛМ-ки тем больше врут, чем больше контекста в них загрузить. Модель путает файлы, забывает ^[4] ограничения, выдумывает то, чего нет.

Это явление называется Context Rot — деградация качества ответов с ростом контекста. По сути, это центральное понятие во всей ИИ-разработке. Вся остальная свистопляска, как правило, происходит именно вокруг минимизации его негативного влияния и зовётся Context Engineering.

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

Конкретные значения

Судя по тому, что публикуется в разных исследованиях, мы видим общую логику ^[5]: чем больше контекста в модели, тем хуже её предсказательная способность. Зависимость нелинейная, очень варьируется от модели, её контекстного окна и от исследования.

Опираясь на свой опыт и на то, что я встречал в источниках, я пришёл для себя к следующим цифрам для моделей семейства Opus:

• на контексте >80% модель превращается в невменяемого олигофрена, любая нормальная агентская система в этот момент запускает процесс компактизации контекста;

• на контексте >70% для 200К и >40% для 1М модель может вывезти только простенькие задачки, надёжно решать регулярные задачи она неспособна;

• на контексте >50% для 200к и >20% для 1М модель перестает стабильно решать сложные задачи;

• на контексте <40% для 200к и <10% для 1М модель ведёт себя оптимально.

Инструменты контекстного инжиниринга

Итак, коротенько пробежимся по основным инструментам работы с контекстом, предоставляемым агентскими системами:

• /clear — самое частое и полезное. Утилита сброса контекста: новая сессия, теряются вся история прошлой сессии. После этого, как в фильме Memento, модель просыпается с чистого листа, познает окружающий её мир каждый раз заново. Поэтому и процесс разработки должен быть такой, чтобы переживать такие амнезии.

• /compact — сжатие контекста в рамках той же сессии: ЛЛМ-ка кратко пересказывает весь контекст. Тут, как в анекдоте про Рабиновича, который выиграл в лотерее Волку, могут потеряться важные нюансы, поэтому полезно указывать, что сохранить при компактизации.

• agents — чтобы не засорять память ^[6] главного агента, очень полезно как можно больше задач отдавать субагентам. С таким делегированием неплохо справляются сами агентские системы, но абсолютно не вредно им в этом “помогать”. Хотя они гордые, легко могут и не послушаться.

• /statusline – утилита редактирования статусной строки, куда можно вывести состояние контекста, чтобы понимать, кто перед тобой – Альберт Энштейн или Форрест Гамп.

• /context — утилита для отображения текущего состояния контекста для тех, кому, как мне, Клод написал кривой скрипт, и в статусной строке контекст периодически не отображается.

• /resume – утилита для продолжения сессии. Полезно, когда надо вернуться к контексту какой-то работы, и продолжить в нем. Большая часть моих сессий с Claude начинается именно с /resume.

Помимо этого с большой эффективностью используются следующие техники:

• Spec-Driven Development (SDD) — подход с широкой опорой на документацию (в основном, генерированную), чтобы агент после обнуления памяти имел консистентное представление о системе и, в первую очередь, о планах;

• прогресс-файлы (progress.md ^[7]) — чек-листы с прогрессом выполнения той или иной задачи, чтобы сброс контекста не мешал понимать, что уже сделано, и что еще осталось;

• Progressive Disclosure – структура файлов, построенная таким образом, чтобы постепенно раскрывать только необходимые детали для модели. Этакое индексирование контекста.

Тон и философия взаимодействия

Даже в этом вопросе постепенно появился некий консенсус, который позволяет получать более качественные ответы от LLM:

1. Ask don’t tell. LLM лучше работает, когда это не инструмент, а полноценный коллега. Вместо того, чтобы написать “сделай вот так” и смотреть на то, как ЛЛМ делает не так, очень полезно формулировать промпт в виде открытого вопроса “Какие у нас есть варианты? Какой тебе нравится больше?” Одна лишь просьба написать опции и аргументацию делает ЛЛМ на 150 баллов IQ ^[8] умнее.

2. Интервью. Один из самых-самых полезных инструментов – не формулировать требования в деталях, а попросить провести тщательное и глубокое интервью. Буквально через пару таких вопросов начинает казаться, что ЛЛМ лучше шарит в том, что тебе надо, чем ты. Позволяет уточнить детали в тех вещах, о которых ты и сам не думал.

3. Графика. Многие современные ЛЛМ-ки неплохо справляются с графикой: как с её чтением, так и с рисованием. Многие вещи, которые тяжело понять на словах, можно попросить нарисовать. И наоборот, кривую бажину, которую ни пером не описать, ни в сказке не рассказать, можно просто вставить в CLI скрином.

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

5. Чек-листы. ЛЛМ регулярно пропускают инструкции. Даже агент, который должен только проверить предыдущую LLM, нет-нет да проигнорирует что-нибудь важное. Если число инструкций превышает десятки и сотни важных требований, то ЛЛМ практически гарантированно что-то забудет. Поэтому один из полезных инструментов поддержания дисциплины в инструкциях – чек-листы. ЛЛМ должна письменно отписаться по каждому пункту, как она его прошла, и что сделала.

   Часто они и тут жульничают – могут написать, что низкий coverage в этом модуле после её изменений – это за пределами скоупа этой задачи. Или то, что тесты сломаны – это нормально, это они и раньше были сломаны. Но все это чинится аккуратным промптингом и ревью.

Prompt Harness

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

Поэтому уже, наверное, все агентские системы вполне справедливо предоставили инструменты для работы с подобными промптами.

1. Skills – переиспользуемые промпты для типовых задач.

2. Rules – загружаются каждую сессию. Контекст, который может оказаться полезным в любой момент.

3. Agents – см. выше, механизм параллелизации работы + борьбы с Context Rot.

4. Hooks – bash скрипт, выполняемый по какому-то событию (например, после выполнения таски). Я использую для уведомлений о завершении выполнения задачи.

5. Skill-creator – skill от антропик для Claude, который включает в себя базовые рекомендации по построению скиллов, и, к тому же, умеет с помощью ключевого слова verify валидировать свои правки. Но при валидации надо его подправлять, чтобы он не подсказывал тестовым агентам, что он от них ждёт.

Три главных требования к ИИ-разработке

В целом, на этом, наверное, более-менее общепринятые идеи и инструменты заканчиваются, и дальше кто во что горазд уже. Поэтому для тех, кто заскучал, пора навалить отсебятины – краткую выжимку уже лично моего видения вопроса.

Я вижу 3 основные проблемы в современной агентской разработке, в которые вляпываются почти все разработчики.

1. Нельзя без фреймворка.

Разработчики регулярно занимаются голым промптингом. Просто пишут нейросетке, что они хотят, чтобы та сделала. Потом просто пишут, что они хотят, чтобы та подправила. Потом снова пишут, что исправить. Потом кидают клавиатуру в экран со словами “Вы же обещали, что Coding is solved” и правят всё сами.

Контекст-менеджмент, правила написания кода/тестов, архитектурные идеи, управление документацией, общее описание процессов разработки – всё это составляет весьма немалый объём знаний, который, если нигде не записать, придётся раз за разом повторять ^[9] снова и снова.

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

Без обвязки из десятка-другого промптов (skills и rules), разработка превращается в постоянное объяснение одних и тех же идей и непрерывную борьбу с одними и теми же косяками LLM. Фреймворк же, напротив, превращает разработку в ритмичный спокойный созидательный процесс.

2. Нельзя без тестов.

Все последние 30 лет своего существования эта идея всё никак не может прижиться. Но это очень важная концепция: именно зелёный тест-кейс – это единица поведения ^[10], неделимая частица, атом, из которых состоит все поведение ^[11] системы. И если в обычной разработке разработчики регулярно саботируют автотесты по той или иной причине, то ИИ-разработка без 100% покрытия функционала – это безумие.

Автотесты никогда еще не были так дёшевы в написании и поддержке. При этом разработка ещё никогда не была столь рискованной на баги, как при ИИ: мы видим это на примере хит-парада фейлов 2025-2026 годов в AWS, OpenAI, Anthropic, Microsoft Azure, Cloudflare и GitHub.

3. Нельзя без ревью.

Есть очень распространенное мнение, что ИИ может писать код сам. 

Может. Но будет как в том бородатом анекдоте: “Я печатаю со скоростью 1000 знаков в минуту… но такая фигня получается!”

Когда Антропик заявляет, что “Coding is solved”, а потом не может 2 девятки показать (см. скрин в начале статьи), то это наталкивает на размышления. Может, Антропик и способен построить успешный бизнес на двух девятках, но для огромного числа информационных систем такой уровень доступности – непозволительная беспечность.

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

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

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

Итого: Нельзя без фреймворка с тестами и ревью.

Какой фреймворк? Получается, что на выходе для взрослой ИИ-разработки необходим фреймворк, который содержит в себе все основные правила и идеи, которым вы следуете в своей разработке. Этот фреймворк обязан опираться на тест-кейсы, как на первостепенную вещь и мерило прогресса. И этот фреймворк должен содержать в себе ревью, как часть процесса.

Какие тесты? На всю эту структуру идеально ложится идея TDD. Ничего лучше не убеждает в корректности теста и решения, чем красный тест, превратившийся в зелёный. К тому же TDD отлично вписывается в крайне естественный для ИИ-разработки Spec-Driven Development: сначала мы проектируем требования, потом на их основе проектируем тест-план – набор кейсов, необходимый, чтобы убедиться, что все работает. И только после этого мы реализуем эти кейсы один за другим, пока задача не будет окончательно решена.

Какое ревью? Самое частое, какое только возможно. Мы все видели эти PR на 100+ файлов с единственным комментарием: LGTM. Чем больше объём кода подлежит ревью, тем труднее его отсмотреть, и тем легче пропустить что-то важное. Почему так – очевидно: большие изменения просто не способны влезть в ограниченное пространство человеческой черепушки.

Собственно, фреймворк

Есть ли такой фреймворк в открытом доступе? Ну, с оговорками, я бы сказал, что это Superpowers ^[12]. Это крайне популярный фреймворк (в топ-50 на гитхаб), который опирается на идеи Spec-Driven Development и TDD. 

Хоть мне он и не подошёл из-за недостаточной строгости, я его, конечно, рекомендую, как выбор по умолчанию. Это open-source с большим коммьюнити, не навязывающий ни технологических, ни архитектурных ограничений – только SDD и TDD. Идеальный выбор для легковесных, но всё еще высокодисциплинированных процессов разработки.

Альтернатива

Своё знакомство с Claude я начинал без фреймворка, пытаясь перенести на ИИ-разработку практики из работы нашей команды. Получившиеся промпты постепенно сами собой переросли в систему скиллов и правил, сформировав самостоятельный фреймворк. В итоге, я весьма доволен результатом, желания переехать на опенсурсный Superpowers, разрабатываемый большим коммьюнити, нет.

Почему? Ну просто я себя не сдерживал ненужными мне ограничениями типа: не навязывать архитектуру, технологию или процесс. В итоге, для моих подходов (ATDD, Clean Architecture) и накопленного набора промптов Superpowers подходит заметно хуже, чем мой фреймворк.

После того, как я поделился результатом в канале, меня попросили опубликовать наработки. Так что, кому тоже интересно потрогать, во второй части можно будет спуллить примерчик и за полчаса-час разобраться, как это работает. Ну и, конечно, залетайте на канал ^[3].