Писать код стало дёшево, думать — дорого. ИИ надо отдавать реализацию, а не продумывание, и только после того, как всё зафиксировано, — иначе он закроет каждую недосказанность своей догадкой.
Думаю, многие читатели Хабра уже видели перевод 8 уровней агентной инженерии — тот самый, где путь от автодополнения до автономных команд агентов разложен по восьми ступеням.
Я тоже его прочитал и решил: раз я с нейросетями вожусь ещё с бета-теста Copilot, мне-то можно сразу к фоновым агентам, которые всё делают сами. Попробовал — и на дурака запрыгнуть на последний уровень не вышло: что бы я ни поручал, на выходе получал не то, что хотел. Вернувшись к статье, я обнаружил, что автор буквально об этом и предупреждал:
Важная оговорка: это работает только если вы проделали работу на уровнях 3–6. Если контекст чист, ограничения явные, инструменты хорошо описаны, а feedback loops настроены, модель может планировать без вашего предварительного одобрения. Если этой работы не было, план придётся курировать вручную.
Иными словами, верхние уровни не работают, пока не проделана работа на нижних, — вот почему перепрыгнуть ступеньки не вышло и у меня. Так что я начал с чистого листа и, перечитывая статью, зацепился за одно утверждение:
Планируете задачу с достаточным контекстом для успеха LLM.
И зацепило меня одно слово — «достаточным». Сколько это — достаточно? Где та граница, за которой контекста уже хватает, чтобы отдать задачу и получить не мусор, а именно то, что задумал?
Ну давайте разбираться
Ещё недавно всё было понятно: появлялась идея, сам её продумывал, набрасывал на доске архитектуру, а потом реализовывал и получал ровно то, что хотел, — думать и делать было работой человека.
Потом пришёл ИИ, и показалось, что всю разработку можно делегировать: мы начали кидать нейросети сразу идею и ждать того же результата, к которому сами пришли бы, посидев не один час над тем, как её реализовать.
А на деле получалось далеко не то, что мы ожидали.
Раньше я описывал ИИ как младенца-супергероя: захочет — сделает, не захочет — не сделает. Ругался с ним и не понимал, ну что ж он меня игнорирует и забывает всё, что я ему говорил. Но стоило осознать, что это не разум, который действительно понимает, что от него хотят, а алгоритм, который на основе доступного ему контекста старается предсказать, как должно выглядеть то, что ему описали, — и наш тандем сразу стал сильно лучше. Он не думает, а достраивает самое правдоподобное продолжение к моим словам. А раз он предсказывает, а не понимает, то ровно там, где мы недоговорили, он и подставит свою догадку вместо нашей мысли. Вот и весь ответ: проблема не в ИИ, а в том, что мы ему отдали, — ответственность за продумывание.
Многие вокруг меня пытались выстроить работу через ИИ, но делегировали ему сразу слишком много ответственности и ждали от него ювелирных решений — а не получив их, решили, что он ещё глуп, и бросили попытки двигаться дальше по этой лестнице (если опыт был на бесплатных моделях или на бесплатном тарифе, разочарование там ещё сильнее).
Честно скажу, я и сам был скептиком и искал поводы не давать ему всё больше и больше контроля. Но перелом случился после фразы товарища:
Раньше все писали на ассемблере. Пришли языки высокого уровня — сменился уровень абстракции: чтобы писать код, тебе больше не нужно было знать, как всё устроено под капотом. То, что происходит сейчас, — также смена установок: теперь, чтобы быть программистом, тебе не нужно знать, как код написан.
Вот после этой мысли я и открылся технологии по-настоящему, полез разбираться, как самому стать вайбкодером, — и вот к чему в итоге пришёл.
То, что встраивать ИИ нужно через воронку «планирование → имплементация → ревью», сегодня уже не откровение — интереснее, как именно это выглядит на практике. И вот что я для себя понял.
Сначала идея, потом брейншторм: сам или с ИИ, но решения всегда за мной. Из брейншторма рождаются роудмап, архитектура и документация — я их фиксирую и только тогда отдаю реализацию ИИ. На выходе получаю то, что задумал, а не что-то похожее.
Архитектура, документация и роудмап — не обязательно большие документы и схемы, их можно объяснить на словах прямо в промпте в несколько предложений. Всё зависит от масштаба.
На практике эта фиксация — несколько конкретных привычек:
-
Вываливаю агенту всё, что у меня в голове, в самом сыром виде: без этого для него это всё равно что готовить блюдо по рецепту, который меняется на каждом шаге. Поэтому я отдаю весь контекст, что у меня есть.
-
Ловлю момент, когда у руля я, а когда передаю его агенту: пока веду я, не даю ему тянуть меня за собой — слушаю, какие вопросы он задаёт, но держу в голове то, что важно мне, а не то, что важным называет он. Передал руль — делаю его ответственным и прислушиваюсь уже к его рекомендациям.
-
Анализирую весь его текущий контекст перед передачей и выцепляю всё, у чего есть развилка: каждый незакрытый вопрос агент закроет по-своему. С опытом я заранее чувствую, как он поведёт себя, получив ТЗ, и просто не оставляю ему лазеек.
-
Диагностирую и лечу болезнь, а не симптомы, если агент всё равно делает не то, что я просил: разбираюсь, почему так вышло, и сразу подстраховываюсь, чтобы не повторилось, а не латаю дыру наспех.
-
Отношусь ко всей этой команде агентов как к предпринимательству: она должна давать лучший результат при минимуме моего времени.
Собрав всё вместе, приходим к схеме, где мы планируем и только потом делегируем выполнение. Конус на картинке — это разброс того, куда в принципе может прийти ИИ; роудмап ведёт по центру, прямо к цели, а документация и архитектура работают стенками конуса и не дают уехать вбок. Чем больше мы документируем и фиксируем архитектуру, тем сильнее сужается этот конус. В этом и есть грамотное встраивание: свобода ИИ ограничена ровно тем, что человек зафиксировал заранее.
Так сколько же — «достаточно»? Ответ прячется в том же конусе. Достаточно — это не абсолютное количество документов и схем, а момент, когда я сузил конус настолько, что любой исход, к которому ИИ может прийти, меня устраивает. Не «описал всё», а «отрезал всё, чем не готов рискнуть».
Отсюда простой вопрос, который я задаю себе перед передачей: устроит ли меня результат, если ИИ пойдёт по любой из развилок, что я оставил открытыми? Если да, контекста достаточно, отдаю. А если есть развилка, решение которой я не готов делегировать, — её и закрываю роудмапом, доком или архитектурой.
А насколько узким должен быть конус — задаёт цена ошибки. Небольшой PoC живёт один вечер: конус можно оставить широким, без документации и архитектуры — пару раз поиграемся, а думать будем потом. Решили строить всерьёз — конус сужаю: продумываю все возможные крайние случаи и фиксирую итоговое видение в документации и роудмапе. А если хочется, чтобы вышло ещё и эффективно, и масштабируемо, — сужаю до предела, добавляя схемы того, как я вижу имплементацию продукта.
Ну а теперь — к практике
Я собрал для себя пятислойный харнес для Claude Code — назвал его mycrew, — и каждый слой в нём отвечает ровно за свой кусок того, о чём я говорил выше: чтобы весь этот подход не жил только у меня в голове как принцип, а был зашит в инструмент, которым пользуется и агент. Слои складываются снизу вверх: каждый следующий пользуется тем, что дал предыдущий. Для меня очень ценно, что в зависимости от задачи я могу подстраиваться и брать подходящий инструмент: если надо написать новый микросервис, я отдаю работу на пятый уровень, где агент принимает решения вместе со мной, а если надо сделать несколько мелких правок — спускаюсь, например, на второй, где агент строго выполняет мои приказы, и точечно беру из пайплайна то, что нужно.
Я определил для себя, что скилл — это набор правил, что нужно сделать, а команда — намерение сделать что-то. Поэтому у меня есть и команда /worker, которую я вызываю сам, и агент-воркер, которого вызывает шеф: оба работают по правилам одного скилла. /setup — это буквально то, о чём я говорил выше: я стараюсь, чтобы весь контекст, которым я обладаю, был зафиксирован в репозитории, и команда работает как цикл, который вытягивает из меня всё для документации.
Самый интересный, на мой взгляд, скилл — how-to-do. В нём я постарался описать ход мыслей, который происходит у меня в голове, когда я решаю, как что-то реализовать. У меня это вылилось в компас из четырёх полюсов: сделать быстро против сделать качественно и сделать своё против взять готовое. Аргументы каждого полюса передаются противоположному, и они приходят к компромиссу. Так воркер работает самостоятельно и принимает действительно качественные решения.
Такой же скилл есть и у шефа — what-to-do. Он решает вопрос уровнем выше — что приоритетнее всего сделать в проекте прямо сейчас, — и растягивает компас по другим полюсам: добавить новую фичу? доработать уже реализованную? реализовать её как-то иначе? или отрефакторить код?
Пример. Начинаю с голой пустой папки продукта — в ней нет ничего, кроме имени.
my-product/
Внутри постепенно намечаются папки будущих проектов, каждая — свой git-репозиторий. Кода в них ещё нет, есть только границы: из каких частей состоит продукт и где проходит шов между ними.
my-product/├── backend/ # свой git-репозиторий├── frontend/ # свой git-репозиторий└── contracts/ # свой git-репозиторий
Первым делом собирается общий CLAUDE.md продукта: North Star, текущее состояние — есть ли живой прод, ведь от этого зависит, насколько осторожными должны быть все дальнейшие шаги, — и по строчке на каждый проект.
my-product/├── CLAUDE.md # North Star, состояние, из чего состоит продукт├── backend/├── frontend/└── contracts/
Дальше в каждом проекте запускается тот самый брейншторм /setup — интервью с ИИ, которое формализует всё в доках прямо внутри проекта: фичи, архитектуру, спецификации.
my-product/├── CLAUDE.md├── backend/│ ├── CLAUDE.md│ └── docs/│ ├── features/features.# по строке на фичу, ничего не удаляется│ ├── architecture/model.c4 # дерево того, что реально работает│ └── specs/ # детали там, где одной строки мало├── frontend/│ └── … то же самое└── contracts/ └── … то же самое
И только после этого я передаю руль: воркер читает эти доки, имплементирует всё по ним, а я уже проверяю результат, а не продумываю на ходу, что делать дальше. Код появляется последним — и это единственная папка, которую я не писал руками.
my-product/└── backend/ ├── CLAUDE.md ├── docs/ # что строим и как оно устроено — это моё └── src/ # ← а это уже пишет ИИ
Таким образом, сейчас я работаю, вообще не касаясь кода. Грустно ли мне от этого? И да, и нет. Мы, программисты, видим в написании кода свой guilty pleasure — строим абстракции над абстракциями и гигантские системы автоматизации по одной кнопке; и тут пришло какое-то ИИ-нечто, которое, заручившись поддержкой начальства, пытается отобрать у нас наш маленький мир. Думаю, поэтому многим так тяжело пройти этап отрицания в вопросе вайбкодинга: как только агент делает что-то не так, хотя мы «вроде понятно объяснили», мы вновь возвращаемся на этап гнева и идём делать руками, утверждая, что он дурак какой-то. Но главную нашу любовь у нас не отберут — выстраивать домики с нуля по нашим чертежам, в которых всё продумано до мельчайших деталей; мы просто делегируем ИИ написание кода. Привыкнем.
Автор: 0xKubik
