Сразу договоримся о формате. Это не подборка «секретных техник» и не попытка удивить тех, кто давно работает с ИИ-агентами. Скорее, это первая часть заметок в формате «сверим часы». Большинство приёмов наверняка вам знакомо. Увидели знакомое — спокойно переходите к следующему пункту.
Почему я всё же решил написать о базовых вещах? Буквально сегодня, пока готовил этот материал, коллега рассказал, что запускает Claude Code на виртуальном сервере (VPS), но при перезагрузке рабочего компьютера теряет соединение с сервером по протоколу удалённого доступа SSH, а вместе с ним — запущенный в обычном терминале процесс. Затем приходится заново подключаться и возобновлять разговор через claude --resume, а если работа оборвалась посреди шага — повторять часть действий и снова расходовать лимит. Оказалось, он просто не знал, что процесс можно запустить в tmux или Herdr на самом VPS, а потом подключиться к нему заново.
А неделю назад другой коллега, который уже давно занимается вайб-кодингом, впервые услышал от меня о голосовом вводе.
После этих разговоров я перестал считать такие приёмы слишком очевидными для статьи. Очевидно только то, о чём уже знаешь. Поэтому ниже — шесть отдельных лайфхаков, которые делают работу с ИИ-агентами удобнее, дешевле или надёжнее. Возможно, вы заберёте отсюда только один пункт. Но один полезный приём всё равно лучше нуля.
Конкретные модели, тарифы и интерфейсы меняются быстро, поэтому названия инструментов здесь — примеры, а не рекомендации «на все времена».
Актуальность: команды и возможности инструментов проверены на 31 августа 2026 года. Если вы читаете статью значительно позже, проверьте текущую документацию и доступные модели у своего провайдера.
Чтобы знакомые пункты можно было быстро пропустить, вот вся подборка: выбор модели под риск задачи, отдельное планирование, постоянные терминальные сессии, голосовой ввод, проверка в свежем контексте и параллельная работа через Git worktree.
1. Не тратить дорогую модель на каждую мелочь
Один из примеров — сборка внешней обработки для переноса данных. У меня была автоматизирована выгрузка обработки (по этому воркфлоу), а в имя готового файла добавлялся комментарий последнего Git-коммита. После очередной сборки вместо ожидаемого суффикса B18 получился B17.
Основной агент уже был занят более сложной работой, и тратить его лимит на локальную ошибку в скрипте мне не хотелось. Я передал задачу более дешёвой модели: показал скрипт сборки, фактическое имя файла и последний комментарий коммита. Модель нашла причину — скрипт брал не то значение — и предложила исправление. После повторной сборки обработка получила правильное имя.
В видео к статье использовалась модель, которая на тот момент была бесплатной. Сейчас условия уже изменились, и это нормально. Бесплатность конкретного сервиса — временный бонус. Сам принцип от этого не меняется.
Скриншота из тех времён у меня нет (пример из февраля 26 года), но вот свежий - бесплатная модель распределяет АРМы по подсистемам.
(с конфигурациями OneBase вообще бесплатные модели неплохо справляются)
Я выбираю исполнителя не только по условной «сложности» задачи. Полезнее оценить три свойства:
Например, дешёвой модели можно поручить:
- поправить локальную ошибку, для которой уже есть воспроизведение;
- написать однотипные тесты по готовому образцу;
- обновить README.md по уже реализованным изменениям;
- выполнить механический рефакторинг с обязательным запуском проверок;
- разобрать длинный лог и вернуть краткое резюме.
Пример из сегодня - перестала открываться публичная демобаза, а скрипт диагностики зависал на каждом действии
Практически бесплатная модель справилась и ещё сделал ПР в платформу
Но экономить нужно на модели, а не на проверке. Сообщение агента «готово» и даже успешная сборка ещё не означают, что обработка работает правильно. После изменения я как минимум смотрю diff и повторяю сценарий, на котором проявлялась ошибка.
Полезное правило: если дешёвый исполнитель дважды не решил одну и ту же проблему или начал заметно расширять область изменений, я останавливаю цикл и передаю задачу более сильной модели вместе с историей попыток. Иначе низкая цена одного запроса легко превращается в высокую цену десяти исправлений.
Ну и воспоминание из будущего (если интересно расскажу в следующий раз):
Бесплатная модель может свернуть горы, если её проверяет (и нарезает ей задачи) топовая.
На скриншоте полностью автономный конвеер, бесплатная модель делает итерацию и уверена, что всё готово, платная модель проверяет и возвращает на доработку.
Так потратив 5% лимита GPT Сол и почти весь недельный лимит практически бесплатной Gemini 3.7 flash (подписка меньше 1 рубля в день) я получил готовую обработку без моего участия.
2. Сильная модель — для плана и сложных решений
Сложную задачу необязательно целиком отдавать дорогой модели. Часто достаточно поручить ей исследование и план — ту часть работы, где ошибка направления обойдётся дороже самой реализации.
Для более-менее сложной задачи я сначала включаю режим планирования. Агент исследует проект, задаёт вопросы и предлагает порядок изменений, но не начинает немедленно переписывать файлы. В Claude Code это именно режим разрешений: его можно включить через Shift+Tab, командой /plan для отдельного запроса или запустить с claude --permission-mode plan. На этом этапе полезна модель с более сильным рассуждением: она лучше замечает архитектурные зависимости, неявные ограничения и рискованные допущения.
После согласования план может выполнять более быстрая и дешёвая модель. В старых записях я переключал модели вручную. В актуальном Claude Code для этого есть режим opusplan выбираемый командой /model opusplan: при планировании он использует семейство Opus, а при исполнении переключается на Sonnet. У других инструментов могут быть свои механизмы маршрутизации — важна не команда, а разделение ролей.
Хороший план должен отвечать не только на вопрос «что изменить». Я прошу включать в него:
1. цель и наблюдаемое поведение после реализации;
2. затрагиваемые файлы и подсистемы;
3. ограничения и то, что менять нельзя;
4. критерии приёмки;
5. команды сборки и тестирования;
6. риски и способ отката;
7. условия, при которых нужно остановиться и перепланировать задачу.
Последний пункт особенно важен. Во время реализации могут обнаружиться факты, которых не было на этапе планирования. В этот момент исполнитель не должен молча придумывать новую архитектуру. Лучше остановиться, зафиксировать, какое допущение оказалось неверным, и вернуть задачу на планирование.
Сам план тоже не является истиной. Для дорогих изменений — обменов, миграций, разграничения прав, фоновых заданий — я отдаю его на независимое ревью до начала кодирования. Исправить ошибку в плане обычно дешевле, чем переделывать уже работающий код и тесты.
3. Сохранять агентские сессии, а не жить среди десятков терминалов
Уточню историю из вступления. Перезагрузка локального компьютера не перезапускает VPS, но обрывает SSH-соединение. Если агент запущен прямо в обычной удалённой оболочке, вместе с соединением может завершиться и его процесс. Именно так коллега терял текущую работу и затем возобновлял разговор через claude --resume.
Терминальные агенты часто выполняют долгие задачи: исследуют проект, собирают конфигурацию, запускают тесты, ожидают результат внешнего процесса. Случайно закрытое окно или нестабильная связь не должны уничтожать этот процесс.
Классическое решение — tmux . Он позволяет отключиться от терминальной сессии, оставить процессы работающими и позднее подключиться снова:
tmux new -s onec-project
# Отключиться, не завершая процессы:
# Ctrl+B, затем D
tmux attach -t onec-project
Для большого количества ИИ-агентов я сейчас использую Herdr. По смыслу это терминальный мультиплексор, ориентированный именно на агентскую работу. В нём видны проекты, вкладки и панели, а также состояния агентов: кто работает, кто завершил задачу и кто ждёт ответа. Можно разделять работу по проектам и Git worktree, подключать интеграции и возвращаться к сессиям после отключения клиента.
(на самом деле у меня много Herdr'ов а управлять я ими всеми могу из одного окна, но об этом в другой статье)
В моём сценарии Herdr нужен прежде всего для наблюдения за живыми процессами: он позволяет увидеть состояние нескольких агентов и быстро перейти к тому, кому требуется внимание.
Важно различать несколько ситуаций:
- закрытие локального окна терминала;
- разрыв SSH-соединения;
- остановку самого Herdr/tmux;
- перезагрузку или падение сервера.
Обычный detach/attach защищает прежде всего от первых двух случаев. При перезагрузке самого VPS процессы прекращаются: tmux их не восстанавливает. Herdr для поддерживаемых агентов может восстановить раскладку окон и предложить возобновить разговор, но произвольный сервер, тест или shell-процесс сам не воскреснет. Это не резервная копия проекта и не замена Git.
4. Голосовой ввод даёт больше контекста — и больше шума
О встроенной диктовке легко не узнать, даже если давно работаешь с ИИ-агентами. Коллега, который давно занимается вайб-кодингом, услышал о ней от меня только недавно. Поэтому этот пункт тоже оказался в подборке.
При наборе текста мы часто сокращаем постановку задачи: опускаем очевидные для себя условия, не описываем фон проблемы и сразу переходим к предполагаемому решению. Голосом обычно проще рассказать задачу так, как мы объясняли бы её коллеге.
В Claude Code голосовой ввод включается командой /voice. Можно использовать удержание клавиши (пробел) или режим записи по нажатию:
/voice hold
/voice tap
Язык диктовки задаётся в /config через параметр language: русский можно выбрать из списка доступных языков.
На практике голос особенно удобен для:
- первичного описания бага;
- передачи бизнес-контекста;
- комментариев к уже показанному набору изменений (diff);
- постановки исследовательской задачи;
- фиксации мысли, пока агент выполняет другую операцию.
Но длинный голосовой запрос не становится хорошим автоматически. Распознавание может путать названия файлов, аббревиатуры и смешанную русско-английскую терминологию. В моей демонстрации README.md был распознан неправильно — без проверки агент мог начать искать несуществующий файл.
Поэтому после диктовки я использую «голосовую контрольную сумму»:
До изменения файлов кратко повтори:
1. цель задачи;
2. какие файлы и компоненты затрагиваются;
3. ограничения;
4. критерий готовности.
Если в постановке есть неоднозначность, сначала задай вопрос.
Саму голосовую постановку удобно строить в одном и том же порядке:
Цель U94; контекст U94; наблюдаемая проблема U94; ограничения U94; критерий готовности.
Есть и вопрос конфиденциальности. В Claude Code аудио отправляется на сервер для распознавания, поэтому голосом нельзя бездумно произносить пароли, токены (ха, представил как кто-то токен диктует), персональные данные и сведения о клиентах. Само распознавание речи не расходует сообщения или токены модели; отправленный после него текст обрабатывается как обычный запрос. Диктовка требует входа через Claude.ai и локального микрофона: непосредственно в удалённой SSH-сессии она недоступна.
5. Проверять одного агента другим — но не устраивать голосование моделей
Даже сильная модель иногда выдаёт категоричный, хорошо аргументированный и неверный ответ. Особенно это опасно в архитектурных вопросах, где результат нельзя проверить одной командой.
В одном из проектов первый агент пришёл к выводу, что из-за архитектурного ограничения публикация возможна только через поддомен, а нормальное решение потребует большого рефакторинга. Вместо немедленной переделки я открыл свежую сессию и попросил другого агента проверить вывод по коду проекта. Второе мнение позволило выбрать значительно более локальный вариант.
Ключевые слова здесь — «по коду проекта». Если просто задать двум моделям один абстрактный вопрос, они могут уверенно повторить одну и ту же ошибку. Другая модель — не источник истины, а ещё один способ искать контрпример.
Для независимого ревью я стараюсь:
- использовать свежий контекст без истории самооправдания первого агента;
- не показывать ревьюеру вывод предыдущей модели до его собственной оценки;
- запретить ревьюеру сразу менять код;
- требовать ссылки на конкретные файлы, строки, тесты или документацию;
- отдельно разделять блокирующие замечания и пожелания;
- просить способ доказать или опровергнуть каждый важный вывод.
Пример запроса для ревьюера:
Проведи независимое ревью решения. Не считай вывод первого агента верным.
1. Проверь факты по коду и конфигурации проекта.
2. Найди контрпример или сценарий отказа.
3. Перечисли допущения и уровень уверенности.
4. Раздели замечания на блокирующие и необязательные.
5. Предложи тесты или команды, которые различают варианты.
Файлы не изменяй. Сначала верни только отчёт.
Для важных изменений я иногда делаю несколько кругов проверки: ревьюер находит проблему, исполнитель исправляет, затем свежий ревьюер проверяет новый diff. Это может быть даже та же модель, но в новой сессии без истории предыдущих решений. Число кругов должно быть ограничено. Если два агента спорят или замечания перестали сходиться, решение принимает человек.
Остановка после третьего круга авторевью в моём конвйере сопровождения
И главное: модельное ревью дополняет, но не заменяет детерминированные проверки. Для проекта 1С это могут быть:
- сборка внешней обработки или расширения;
- проверка синтаксиса и диагностика BSL Language Server;
- тесты Vanessa Automation, xUnitFor1C или собственного стенда проекта;
- проверка запросов на тестовой информационной базе;
- просмотр git diff и списка затронутых объектов;
- запуск установленного в проекте линтера и проверок непрерывной интеграции (CI).
Если агент написал «тесты прошли», но не показал команду и её вывод, задача ещё не доказана.
В идеале обязательные проверки собираются в одну воспроизводимую команду — например, task verify, make verify или PowerShell-сценарий проекта. Тогда и человек, и любой агент запускают один и тот же набор проверок.
6. Разводить параллельные задачи по Git worktree
Одно из главных преимуществ терминальных ИИ-агентов — возможность выполнять независимые задачи параллельно. Пока один агент занимается обработкой для 1С, второй может исследовать ошибку в сервисе, а третий — готовить тесты для бота.
Но фраза «открою десять агентов и ускорюсь в десять раз» обычно не работает. Каждый поток нужно поставить, проверить и интегрировать. Если пять агентов одновременно попросят решения, узким местом окажется уже человек.
Я начинаю с двух-трёх параллельных потоков и увеличиваю их число только тогда, когда задачи:
- имеют чёткие границы;
- редко требуют обратной связи;
- не меняют одни и те же файлы;
- обладают собственными критериями приёмки;
- могут быть проверены независимо.
Параллельные сессии также параллельно расходуют лимиты. Поэтому экономию стоит считать не по цене одного запроса, а по полной стоимости принятого изменения: исполнитель, ревью, повторные исправления и время человека.
Для параллельной работы внутри одного репозитория полезен Git worktree. Это не полный независимый клон проекта, а отдельная рабочая директория, связанная с тем же репозиторием. У неё свои HEAD и индекс, а обычно — и своя ветка.
Минимальный пример:
# Создать отдельное рабочее дерево и новую ветку
git worktree add -b fix/b18 ../project-fix-b18
# Посмотреть активные рабочие деревья
git worktree list
# После слияния удалить ненужное рабочее дерево
git worktree remove ../project-fix-b18
В Herdr рабочее дерево можно создать из интерфейса проекта. В актуальном Claude Code также есть запуск изолированной сессии через claude --worktree, а для отдельных вложенных агентов можно настроить worktree-изоляцию.
Моё базовое соответствие выглядит так:
одна задача = одна ветка = один worktree = одна основная сессия = свои критерии готовности
Каждому агенту выдаётся своя ветка и рабочая директория. Изменения одного агента не появляются немедленно в файлах второго, поэтому они могут независимо запускать сборку и менять разные части проекта.
Однако файловая изоляция — не полная изоляция окружения. Два worktree всё ещё могут использовать:
- один порт локального сервера;
- одну информационную базу 1С;
- общую схему БД;
- одинаковый каталог кеша или временных файлов;
- одинаковые настройки из .env и общие внешние сервисы;
- пересекающиеся миграции и remote-ветки.
Поэтому для действительно параллельного запуска я задаю разные порты, отдельные тестовые базы или схемы и уникальные каталоги временных данных. А перед слиянием проверяю не только каждую ветку отдельно, но и их совместный результат.
Есть ещё бытовая ловушка: новый worktree содержит отслеживаемые Git файлы, но локальные зависимости, .env и другие игнорируемые файлы туда автоматически не попадают. Окружение нужно подготовить отдельно. Claude Code умеет копировать выбранные игнорируемые файлы через .worktreeinclude, но реальные продуктивные секреты лучше не размножать — для параллельных задач безопаснее выдавать тестовые значения.
Worktree уменьшает вероятность конфликтов во время работы, но не отменяет конфликты при слиянии. Если два агента меняют один общий модуль, лучше заранее назначить одного владельца этого файла или выделить отдельную интеграционную задачу.
Важная оговорка
Ни один из этих лайфхаков сам по себе не делает работу безопасной. tmux сохранит и полезный процесс, и ошибочную команду. Worktree разделяет файлы, но не изолирует сеть, базы и секреты. Ответ второго агента остаётся гипотезой, пока её не подтвердили код, тесты или документация.
Без дополнительной защиты я не разрешаю агенту:
- работать с продуктивной базой на запись;
- самостоятельно выполнять миграции и массовое изменение данных;
- публиковать изменения или делать push в защищённую ветку;
- читать и передавать секреты, токены и персональные данные;
- устанавливать непроверенные плагины и зависимости.
Запрет в промпте — это инструкция, а не техническая граница. Для рискованных действий нужны минимальные права, изолированная тестовая среда и подтверждение человека.
Короткая памятка
- Небольшая обратимая задача с быстрой проверкой — кандидат для дешёвой модели.
- Сложное изменение сначала стоит исследовать и превратить в проверяемый план.
- Долгую работу на VPS лучше запускать в tmux или менеджере постоянных сессий.
- Голосом удобно передавать контекст, но имена файлов и команды нужно перечитать.
- Важный вывод полезно проверить в свежей сессии, не подсказывая ей ответ первого агента.
- Параллельным задачам в одном репозитории нужны отдельные ветки и worktree, а иногда также порты, базы и каталоги сборки.
Вместо вывода
Если все шесть пунктов вам уже знакомы — отлично, значит, часы сверили. Если хотя бы один поможет сохранить сессию, лимит или полчаса работы, подборка уже выполнила задачу.
На этом первая, намеренно базовая часть заканчивается. Здесь собраны отдельные приёмы, каждый из которых можно применять сам по себе.
Прошу комментировать, в спорах рождаются не только грибы, но и новые статьи.
Вполне возможно, что упомянутые вам лайфхаки в комментах войдут в следующую часть.
Ну и видео версия, если хочется посмотреть вживую
Вступайте в нашу телеграмм-группу Инфостарт