Может быть, я что-то не так делаю, но мне сложно понять, при каких обстоятельствах можно в ноль сжечь ВСЕ токены тарифа Claude Code PRO[1]. Вернее не так, представляю и вот об этом хочу немного поразмышлять, как говорится “вслух”. Я сжигал токены, потому что не знал/не понимал правил общения с агентами ИИ.
Первая попытка сделать что-то с помощью ИИ агента для своего сайта у меня была 24 января 2026 года, сейчас 1 апреля 2026 года и за эти три месяца я научился взаимодействовать с ИИ агентами так как по идее задумывали инженеры. В первые пару недель, где-то до середины февраля я сжигал токены на всем что позволяло мне это сделать: Gemini модели flash и pro, Claude Code, в котором нет разделения на лимиты Opus/Sonnet, “сгорал” быстрее остальных, буквально за пару “запусков” и пару “задач”. Меня это не раздражало и не нервировало, я понимал что у меня “конфетно-букетный” период отношений с ИИ, когда ничего не жалко.
Но прошла любовь, осталась рутина и в лучшей традиции эволюции, которую прошли наши отношения, я пережил культурный шок и вернулся на исходную точку с новым знанием, которое и хочу зафиксировать в этой заметке.
Как и в любом приличном обществе в общении с ИИ следует придерживаться некоторых правил и вообще во взаимодействии с ИИ следует руководствоваться определёнными установками, которые регламентируют то, как ставить задачу, как контролировать, что делать после завершения выполнения, как поступать, если что-то не сработало. Вот про эти правила и хочу рассказать.
Это не универсальный и точно не избыточный набор правил, а то, что работает у меня. Прочитав эти правила, с очень высокой вероятностью можно перестать “сжигать” все токены у всего что позволяет их сжечь, но это не точно.
Правила будут двух категорий: ВСЕГДА и НИКОГДА. Описывать правила я буду к проекту “создание” своего сайта. ВСЕГДА и НИКОГДА идут не по категориям или логическому порядку, а так как мне удобнее рассказывать о них как о некоторой истории.
[!always]
ВСЕГДА фиксируй то, что сделано
Любая работа, которая хоть как-то сделана с помощью ИИ должна быть задокументирована, для этого не требуется никаких технических навыков. ИИ написал код, ИИ сможет написать что он сделал. Наша задача как руководителя – уметь прочесть, понять и задать вопросы, если что-то не понятно.
У меня три категории файлов, которые я ВСЕГДА заполняю вместе с ИИ:
-
==Беклог==. В него попадают случайные идеи, записи про всякие недоделки и переделки. В этом же файле я описываю технический долг.
-
==Архитектура==. Так как на моем сайте хренова туча элементов, базовый стек, с которого я начал начинает обрастать базами данных, всякими свистоперделками для себя, например “колесо выбора” и таблицы Шульте для лонгитюдного исследования в школе, то мне нужно помнить все технические фишки, реализованные за время разработки.
-
==Путешествие==. Самый большой из логов, в нем описаны все мои действия от момента, когда я впервые создал лендос-витрину, до сложной архитектуры цифрового садика, онтологии, визуальной обработки, интеграции обсидиана в экосистему садика, создания скриптов обработки MD файлов. В общем, каждый этап имеет номер[2] и дату[3].
[!always]
ВСЕГДА начинай новый диалог
Я вайбкодю с помощью Antigravity[4], основной мой инструмент это Gemini Flash, но даже с его щедрым контекстным окном в 2 млн токенов, он имеет свойство глупеть в зависимости от объема контекста диалога. Поэтому мне проще начинать новый диалог, если функция, над которой я работал, закончена и я ее выкатил на основной сайт.
Контекст прошлых диалогов никуда не исчезнет, все что мы сделали ВСЕГДА попадает в том или ином виде в “беклог”, “архитектуру” или “путешествие”.
[!always]
ВСЕГДА используй GIT[5]
Несколько раз, на других проектах, я вырывал у себя волосы из всех доступных мест, когда “вайбкодинг” пошел не так как планировалось. Помните, у нас команда очень умная, но спешащая удовлетворить любой наш запрос. Эти ребятки могут все и даже читать мысли, как ни странно, и выполняют работу быстро, но иногда в спешке, или потому что “прочитали мысли” не верно, могут сломать все нахрен. Я так пару исследовательских python отчетов уконтролпупил и сидел плакал. В общем git init и потом регулярные git add . && git commit -m “описание вашего изменения”.
А в случае если задумали какую-то серьезную переделку, рефакторинг, создание новой фичи, то идем с рабочим проектом в новую ветку.
[!always]
ВСЕГДА разговаривай как с подчиненным
Мне кажется, что в “Дивном новом мире” агентов самыми востребованными навыками будут: умение логично, понятно и доходчиво выражать свои мысли. А также навыки управления. Если кто-то в команде меня не понял, то проблема с очень высокой вероятность, что не “команда/исполнитель тупой”, а в том, что я “тупой”, просто потому, что выражать свои мысли не могу логично.
Помните, я говорил выше, что у нас в распоряжении команда очень умных и шустрых подчиненных, так вот, они хоть и умеют читать мысли, делают это не точно и с ошибками, поэтому лучше не “доводить” до чтения мыслей, а поставить задачу так, чтобы ее понял ребенок. Отсюда, кстати, берёт начало следующее правило
[!always]
ВСЕГДА пиши избыточно
Сложная задача, например рефакторинг светлой и тёмной темы, создание онтологической модели на основе существующих связей в заметках – это задача со звездочкой. И поэтому чем больше контекста агент ИИ получает в свое распоряжение, по крайней мере во время первого запроса, тем с бОльшей вероятностью, он выполнит работу с меньшим (не без) количеством ошибок. А еще можно накатить в проект скиллы из этого репозитория, после чего агент будет “доставать” вопросами прежде чем начать.
Очень помогают вопросы агента “прочистить” мозг.
[!never]
НИКОГДА не давай ему возможности вносить правки в документы и файлы
Часто даже после того как я ответил на первый раунд вопросов от агента, он начинает СРАЗУ работать. Вносит правки, обновляет конфигурации, в общем делает работу, которую я: а. его еще не просил и б. которую сам еще не понял. Второй пункт значительно важнее.
Мы не даем шустрой, умной и услужливой команде делать что-либо, пока мы сами не поняли, что он планирует делать и как думает приступать к выполнению задачи. Даже если у “руководителя” нет технических компетенций, как у меня, нужно уметь читать код и понимать элементарный синтаксис. Ну вот пока агент будет объяснять, и сам разберешься в том какие изменения планирует сделать агент.
[!never]
НИКОГДА не доверяйся одному агенту
Именно это правило позволяет мне экономить токены. Повторю, что я использую преимущественно Gemini Flash и Claude Code, но с одной особенностью. У Гемини – огромное контекстное окно, 2 млн токенов[6], гемини дешевый, но сильный. Ему вообще не сложно поднять пару сотен файлов, пройтись по их содержанию, выявить вероятную логику внедрения изменений. Он сделает это быстро, токен-эффективно, и даже не вспотеет, в смысле не сожжет и 10% своих токенов, в то время как если попросить Клода сделать ту же самую работу, которую он сделает ГОРАЗДО лучше Гемини, то исчезнут до 20-25% токенов, а у Клода токены золотые, буквально золотые.
Поэтому, Гемини поднимает тяжести, подносит то, что нужно починить или то из чего нужно собрать новую фичу, а Клод оценивает правильно ли Гемини все сделал, если нет, вносит правки в план или говорит, что можно было бы еще посмотреть.
[!never]
НИКОГДА не используй Клода для работы
Если сравнивать КЛОД и ГЕМИНИ, то это два разного уровня специалиста. Клод – это академик, очень опытный хирург, мудрый философ, Мастер. Гемини – это парень на все задачи, пойди, принеси, посиди, подожди.
Они существуют для разной деятельности. Гемини работает, Клод контролирует, вносит правки и корректирует. Клод точечно “чинит”, то что Гемини не смог ни с первой, ни со второй, ни с третьей попытки.
[!never]
НИКОГДА не проси Гемини сделать сложный рефакторинг
Гемини запутается при выполнении сложной работы – это факт. Но это не делает Гемини “плохим” агентом. Он просто не для сложной работы, где нужно держать в контексте “развесистую” логику новой фичи. Это его сломает.
Гемини готовит материал, подносит данные, Клод проверяет и делает рефакторинг. Делать будет долго, сожжет уйму токенов, но как правило сделает с первого раза и правильно.
[!always]
ВСЕГДА читай код
Если агент написал – это написал он, а не ты, поэтому читай что он написал. Можно не все, но читать обязательно. Смотри изменения в файлах, если git работает, то изменения всегда будут подсвечены в IDE-приложении. Чтение кода решает две задачи, первая “быть в курсе” изменений, вторая – разбираемся в синтаксисе и где какую переменную нужно поменять, если что-то не понравится, например скорость анимации или того как ведут на экране элементы интерфейса.
[!never]
НИКОГДА не проси агентов исправлять текст
На сайте уйма текста. Элементы управления сайтом имеют свои названия, обладают подписями, ВЕСЬ текст нужно править ручками! Не надо сжигать токены на это.
Ну вот и всё… написанное выше — мой трёхмесячный опыт работы с агентами, который я попытался обобщить в некоторый свод правил.
П.С. Свод правил будет обновляться по мере моего “личного” просветления.
Я понимаю, что даже на PRO лимиты малые и действительно тем, кто используют Claude постоянно, PRO мало, нужен хотя бы x5. Я умышленно усугубляю. ↩︎
сейчас 46. ↩︎
Первый 24.01, последний 30.03 ↩︎
Google Antigravity — агентная среда разработки (IDE) от Google, созданная специально для вайбкодинга. В ней используется подход agent-first: вместо обычного автодополнения строк можно ставить высокоуровневые задачи (агент прочитает мысли), а автономные ИИ-агенты (на базе Gemini 3) сами пишут код, работают с терминалом, проверяют верстку во встроенном браузере и сохраняют контекст. ↩︎
“Бывалым”, тем кто давно в разработке об этом нет смысла напоминать, но вайбкодинг – это поляна “непуганых”. ↩︎
Кто-то скажет, что и у клода контексте в 1 млн токенов уже, на что я ему отвечу, что угу, 1 млн, но эти токены у Клода – буквально золотые. Экономика должна быть экономной. ↩︎