Vibe Coding локально: агентные инструменты и LLM без подписок

Что такое vibe coding и как выглядит локальный workflow

Vibe coding: смысл и границы понятия

Vibe coding — это стиль разработки, где вы формулируете намерение (что должно получиться) и ограничители (как именно и при каких условиях), а затем быстро итеративно уточняете результат вместе с LLM/агентом. Фокус не на «писать каждую строчку руками», а на управлении потоком работы:

вы задаёте цель и контекст;

агент предлагает план/реализацию;

вы проверяете, закрепляете решения и корректируете направление.

Важно: vibe coding — не «магическое автокодирование». Это сокращение времени на рутину (черновики, рефакторинг, тестовые заготовки, объяснения) при сохранении ответственности разработчика за качество, безопасность и итоговый дизайн.

Почему «локально» меняет правила игры

Локальный vibe workflow означает, что:

модель (или прокси к модели) работает на вашем ПК;

агентные инструменты запускаются локально;

код, данные, логи и артефакты остаются у вас.

Практические последствия:

Приватность: меньше рисков утечки исходников/секретов.

Предсказуемость стоимости: нет зависимости от подписок и токенов.

Повторяемость: версия модели и окружение фиксируются как часть проекта.

Офлайн-режим: полезно для поездок, закрытых сетей, корпоративных сред.

Компромиссы тоже есть:

требования к железу (особенно VRAM/ОЗУ);

иногда ниже качество/скорость по сравнению с топовыми облачными моделями;

больше ответственности за настройку, обновления и дисциплину безопасности.

Агент в контексте vibe coding

Агент — это LLM, которой разрешено не только «писать текст», но и выполнять действия через инструменты: читать/писать файлы, запускать тесты, анализировать репозиторий, предлагать патчи.

Ключевая идея: агент становится исполнителем в рамках ваших правил. Вы определяете:

какие команды можно запускать;

какие директории доступны;

как подтверждаются изменения;

какие проверки обязательны (тесты, линтеры, форматтер).

Как выглядит локальный workflow: основные компоненты

Ниже — типовая схема локального vibe coding без привязки к конкретным брендам.

Редактор/IDE

- место, где вы смотрите диффы, принимаете решения, запускаете задачи.

Локальный раннер LLM

- приложение/сервер, который держит модель и принимает запросы (prompt) от редактора или агента.

Агентный слой

- компонент, который умеет разбивать задачу на шаги и вызывать инструменты (файловая система, git, тесты).

Инструменты проекта

- тест-раннер, линтер, форматтер, сборщик, статический анализ.

Контроль версий (git)

- ваша «точка возврата» и основной механизм контроля: коммиты, ветки, диффы.

Итерационный цикл: «намерение → действие → проверка»

Самый полезный «ритуал» vibe coding — короткие итерации с обязательной валидацией.

Чтобы цикл работал стабильно, держите три уровня ясности:

Цель: что именно должно измениться (фича, багфикс, рефакторинг).

Ограничители: что нельзя ломать (API, совместимость, стиль, зависимости).

Критерии готовности: как поймём, что сделано (тесты проходят, сценарий воспроизводится).

Локальная безопасность: минимальный набор привычек

Локально — не значит автоматически безопасно. Безопасность достигается правилами.

Не выдавайте агенту секреты

- ключи API, токены, приватные сертификаты — не часть контекста.

Ограничивайте инструменты

- по умолчанию запрет на команды, которые могут удалять/шифровать/эксфильтровать данные.

Всегда смотрите дифф

- особенно на изменения в зависимостях, скриптах сборки, CI-конфигурации.

Тесты как «замок на двери»

- агент может быть быстрым, но только тесты/проверки подтверждают корректность.

Маленькие коммиты

- легче откатывать и проще понять, что именно сделал агент.

Что считать «хорошим» локальным vibe workflow

Хороший workflow ощущается так:

вы тратите меньше времени на рутину;

качество повышается за счёт дисциплины проверок;

изменения предсказуемы и обратимы;

контекст задачи не расползается: агент работает в границах.

Плохой workflow ощущается так:

агент делает слишком большие правки без контрольных точек;

вы «верите на слово» без тестов и диффов;

модель постоянно «галлюцинирует», потому что вы не дали ей достаточных ограничителей.

---

Задания для закрепления

Сформулируйте одним абзацем, что такое vibe coding, и где проходит граница ответственности между вами и агентом.

Перечислите 5 компонентов локального vibe workflow и объясните роль каждого одной фразой.

Придумайте пример задачи (реальной для вашего проекта) и допишите к ней:

- 3 ограничителя, - 3 критерия готовности.

Опишите 3 риска при использовании агента локально и по одному снижению риска на каждый.

По схеме цикла «намерение → действие → проверка» опишите, на каком шаге вы обязательно должны вмешаться вручную и почему.

<details> <summary> Ответы (примерные) </summary>

1) Vibe coding — это итеративная разработка, где разработчик задаёт намерение, ограничения и критерии готовности, а LLM/агент ускоряет выполнение (черновики, правки, анализ), но ответственность за итоговую архитектуру, безопасность и принятие изменений остаётся на разработчике.

2) Пример 5 компонентов:

IDE/редактор: точка управления, просмотра и принятия правок.

Локальный раннер LLM: выполняет инференс модели и отвечает на запросы.

Агентный слой: планирует шаги и вызывает инструменты.

Инструменты проекта (тесты/линтер/сборка): автоматическая проверка корректности.

Git: фиксация состояний, диффы и безопасный откат.

3) Пример задачи: «Добавить пагинацию в список заказов».

Ограничители: не менять публичный API; не ухудшить время ответа; соблюдать текущий стиль UI.

Критерии готовности: добавлены тесты на пагинацию; линтер/сборка проходят; вручную проверены 2 сценария (первый/последний page).

4) Риски и снижения:

Риск: агент изменит критичные файлы (скрипты, зависимости) незаметно. Снижение: обязательный просмотр диффа + правило “не трогать build/CI без отдельного запроса”.

Риск: запуск опасных команд. Снижение: allowlist команд и запрет destructive-операций по умолчанию.

Риск: утечка секретов через контекст/логи. Снижение: не передавать секреты в prompt, хранить их в переменных окружения/секрет-хранилищах, чистить логи.

5) Обязательное ручное вмешательство — на шаге проверки и принятия: вы подтверждаете дифф, интерпретируете результаты тестов и решаете, соответствует ли решение ограничениям. Это точка, где «скорость» не должна заменять контроль.

</details>

Подбор железа, ОС и базовая установка: драйверы, Python, Git, VS Code

Локальный vibe workflow (цикл «намерение → действие → проверка» описан ранее) становится стабильным, когда у вас предсказуемые: железо, ОС, драйверы и базовые инструменты разработки. Эта статья — про фундамент, на котором потом удобно запускать локальные LLM и агентные инструменты.

1) Подбор железа под локальные LLM и агента

Минимальный ориентир (чтобы «завелось»)

CPU: 6–8 современных ядер (или сопоставимая производительность).

ОЗУ: 16 ГБ (лучше 32 ГБ, если планируете параллельно IDE + тесты + модель).

Накопитель: SSD, от 50–100 ГБ свободного места (модели, кеши, окружения).

Комфортный ориентир (чтобы было быстро)

GPU с VRAM (если вы хотите ускорение на видеокарте): 8–12 ГБ VRAM для небольших/сжатых моделей; 16–24 ГБ VRAM — заметно комфортнее.

ОЗУ: 32–64 ГБ, если вы часто держите одновременно несколько проектов, браузер, тесты, контейнеры.

Что важнее: VRAM или ОЗУ

VRAM — главный ограничитель для скорости и размера модели, если инференс идёт на GPU.

ОЗУ — важно, если модель запускается на CPU или если вы активно используете инструменты (линтеры, тесты, сборку) параллельно.

Упрощённое правило выбора:

если вы хотите «максимум скорости» — упирайтесь в VRAM;

если вы хотите «универсальность и параллельность разработки» — добавляйте ОЗУ.

Ноутбук vs ПК

ПК проще апгрейдить (VRAM/ОЗУ/SSD), обычно тише и стабильнее под нагрузкой.

Ноутбук удобен, но чаще ограничен по охлаждению и апгрейду; при долгом инференсе возможен троттлинг.

2) Выбор ОС: Windows, Linux, macOS

Windows 11

Подходит большинству. Плюсы: широкий выбор железа, хорошая совместимость с IDE. Минусы: иногда больше «трения» с некоторыми ML-стеками и путями/правами.

Практичный вариант для разработки:

Windows + нормальный терминал.

По необходимости — подсистема Linux (если ваши инструменты проще живут в Linux-окружении).

Linux (например, Ubuntu LTS)

Часто самый прямой путь для локального ML и автоматизации. Плюсы: удобнее управлять зависимостями, пакетами, правами, сервисами. Минусы: нужно чуть больше админ-дисциплины (драйверы, права, CUDA/ROCm-совместимость).

macOS (Apple Silicon)

Плюсы: хорошая производительность на ватт, стабильная система, удобная разработка. Минусы: не всё GPU-ускорение доступно так же, как на NVIDIA; выбор инструментов может отличаться.

3) Драйверы GPU: что поставить и как проверить

Главная цель: чтобы ОС корректно видела видеокарту, а вычислительный стек (если нужен) — мог её использовать.

NVIDIA

Поставьте актуальный драйвер.

Проверьте, что система видит GPU и драйвер активен (в Windows — диспетчер устройств; в Linux — утилиты и логи драйвера).

Если вы планируете GPU-ускорение для локальных LLM, убедитесь, что версии драйвера совместимы с вашим вычислительным стеком.

AMD

На Linux часто удобнее и предсказуемее, чем на Windows (зависит от вашего стека).

Проверьте, что драйвер корректно загрузился и GPU доступен системе.

Важная привычка

Если после обновления драйверов «всё стало странно», фиксируйте версию драйвера как часть рабочего окружения проекта/машины (хотя бы в заметках). Это помогает воспроизводимости.

4) Python: установка, версии, изоляция окружений

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

Рекомендации по версии

Выберите одну основную версию (часто удобно 3.11 или 3.12).

Для проектов держите отдельные виртуальные окружения, а не «глобальный pip на всю систему».

Базовая схема установки и работы

Установите Python из официального дистрибутива вашей ОС.

Проверьте, что python и pip доступны в терминале.

Для каждого проекта создавайте виртуальное окружение и ставьте зависимости туда.

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

Частые ошибки

«Сломал глобальный Python» — лечится изоляцией окружений.

«Ставится не туда» — проверьте, что IDE использует интерпретатор из виртуального окружения.

5) Git: минимальная настройка для безопасных итераций

Git — это ваш механизм контроля изменений (а при vibe-подходе — ещё и страховка).

Сделайте минимум:

Задайте user.name и user.email.

Настройте удобный способ аутентификации с удалёнными репозиториями (обычно SSH-ключи).

Определитесь с переносами строк:

- на Windows чаще нужен автоперевод CRLF/ LF внятно настроенный, чтобы не засорять дифф.

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

6) VS Code: базовая установка и настройки для vibe workflow

VS Code удобен как «панель управления»: терминал, дифф, поиск по проекту, запуск тестов.

Что включить сразу

Встроенный терминал (один профиль под ваш основной shell).

Просмотр диффов и история файла.

Форматирование кода «одной командой» (через форматтер вашего стека) — важно для чистых диффов.

Расширения (по минимуму)

Язык/стек проекта (Python/JS/Go и т. п.).

Интеграция с Git.

Линтер/форматтер под ваш стек.

Одна настройка, которая экономит время

Сделайте так, чтобы запуск тестов/линтера был доступен из терминала и/или задач редактора. Тогда проверка становится быстрым шагом итерации.

7) Быстрая самопроверка установки

Если этот чек проходит — вы готовы к подключению локальных моделей и агентного слоя.

---

Задания для закрепления

Опишите ваш текущий ПК/ноутбук по четырём пунктам: CPU, ОЗУ, GPU (и VRAM), SSD (свободное место). Напишите, что является главным узким местом именно для локальных LLM.

Выберите ОС для локального vibe workflow и перечислите 3 причины, почему она вам подходит.

Составьте список «минимум установок» на чистой системе: драйверы, Python, Git, VS Code — и порядок, в котором вы это сделаете.

Назовите 3 типичные проблемы с Python-окружениями и по одному способу профилактики каждой.

Опишите ваш «ритуал принятия изменений от агента» в 4 шага с использованием Git и диффа.

<details> <summary> Ответы (примерные) </summary>

1) Пример узких мест:

Если VRAM 6–8 ГБ, то придётся чаще использовать более компактные/сжатые модели или CPU-режим.

Если ОЗУ 16 ГБ и вы запускаете IDE + браузер + тесты + модель, начнётся своп и всё замедлится.

Если SSD маленький, быстро закончится место под модели/кеши.

2) Пример аргументов:

Windows: «совместимость с рабочими инструментами/драйверами», «привычная среда», «простая установка IDE».

Linux: «удобнее для ML-стека», «проще автоматизировать и фиксировать окружение», «понятнее работа сервисов».

macOS: «стабильность», «быстрое окружение разработки», «хорошая автономность».

3) Пример порядка: 1) Обновление ОС. 2) Драйвер GPU. 3) Git. 4) Python. 5) VS Code + расширения под стек. Логика: сначала стабильное железо/драйвер, потом базовые dev-инструменты.

4) Типичные проблемы и профилактика:

«Глобальный pip засорён» → всегда использовать venv/virtualenv.

«Не тот интерпретатор в IDE» → явно выбрать интерпретатор из окружения проекта.

«Конфликт версий зависимостей» → фиксировать зависимости (lock/requirements) и обновлять контролируемо.

5) Пример ритуала: 1) Перед задачей: чистый статус репозитория, при необходимости новая ветка. 2) После изменений агента: посмотреть дифф целиком. 3) Прогнать тесты/линтер/сборку. 4) Если всё ок — коммит с понятным сообщением; если нет — откат/правки и повтор проверки.

</details>

Запуск локальных моделей: Ollama, LM Studio, llama.cpp и выбор квантов

Локальный vibe workflow работает лучше, когда запуск модели — это «как сервис»: предсказуемо, повторяемо, с понятными ограничениями по ресурсам. Базовые привычки проверки и безопасности (диффы, тесты, ограничения инструментов) уже были в прошлых статьях — здесь фокус только на том, как поднять локальную LLM и как выбрать квант под ваше железо.

1) Три способа запускать локальные модели

Ollama: «поставил и забыл»

Сильные стороны:

минимальная настройка, быстро получить локальный HTTP-endpoint;

удобно держать несколько моделей и переключаться;

хорошо подходит, когда вы хотите подключить модель к редактору/агенту через один стабильный адрес.

Компромиссы:

меньше ручного контроля над низкоуровневыми параметрами, чем в чистом llama.cpp;

вы живёте в рамках экосистемы Ollama (это обычно плюс, но иногда — ограничение).

Когда выбирать: вам нужен простой “локальный сервер модели” и стабильность важнее тонкой настройки.

LM Studio: «GUI + понятная диагностика»

Сильные стороны:

удобный интерфейс: выбор модели, запуск, мониторинг загрузки GPU/CPU;

проще понять, почему модель не влезает в VRAM/ОЗУ;

полезно на старте, чтобы “пощупать” разные кванты и размеры.

Компромиссы:

GUI — это лишний слой (иногда менее удобно для автоматизации);

часть сценариев деплоя/интеграции может потребовать доп. шагов.

Когда выбирать: вы хотите быстро экспериментировать и видеть, что происходит с памятью и скоростью.

llama.cpp: «максимум контроля и переносимости»

Сильные стороны:

эталонный движок для GGUF-моделей, много режимов и параметров;

удобно для тонкой настройки (контекст, offload на GPU, батчинг);

легко упаковать в скрипты и воспроизводимые команды.

Компромиссы:

больше ручной работы: сборка/бинарники, параметры запуска;

чуть выше порог входа.

Когда выбирать: вам нужен контроль, воспроизводимость и возможность «дожимать» производительность.

2) Что общего у всех трёх вариантов

Модельный файл/формат (то, что реально грузится в память).

Раннер (движок инференса: CPU/GPU, управление памятью, контекстом).

Серверный режим (опционально): чтобы IDE/агент ходили в модель по API.

Практически важно: если ваша цель — подключить модель к инструментам vibe coding, вам обычно нужен локальный endpoint (даже если вы работаете на одной машине).

3) Форматы весов и “что качать”

В локальном мире чаще всего встретите:

GGUF — наиболее универсальный формат для llama.cpp-экосистемы; его же часто используют LM Studio и Ollama.

GPTQ/AWQ/EXL2 — форматы/подходы, которые чаще встречаются в других раннерах и ориентированы на GPU-ускорение и определённые библиотеки.

Если вы не уверены, берите GGUF: он максимально совместим и проще для старта.

4) Кванты (quantization): что это и зачем

Квантование — это сжатие весов модели, чтобы:

модель помещалась в VRAM/ОЗУ;

инференс был быстрее (часто) и дешевле по памяти.

Цена — возможное снижение качества. Ключевой выбор: размер модели (7B/14B/… ) vs глубина квантования (условно 4-bit/5-bit/8-bit).

Как читать названия квантов в GGUF

Частые обозначения (могут немного отличаться по репозиториям моделей):

Q4 — примерно 4-битные веса (сильное сжатие).

Q5 — компромисс между качеством и размером.

Q8 — ближе к “почти без потерь”, но тяжелее по памяти.

Суффиксы вроде _K_M, _K_S — варианты схемы квантования; обычно K_M считают более “ровным” компромиссом.

Важно: “лучший квант” зависит от задач. Для vibe coding часто важны:

устойчивое следование инструкциям;

меньше «ломающих» галлюцинаций;

нормальная скорость в IDE.

Быстрые ориентиры по памяти (очень грубо)

Оценки зависят от раннера, контекста и offload, но как стартовые ожидания:

7B: Q4 обычно помещается примерно в 4–6 ГБ памяти под веса.

13–14B: Q4 — часто 8–10+ ГБ.

30–34B: Q4 — это уже 20+ ГБ.

Если вы упираетесь в VRAM, не пытайтесь «втиснуть любой ценой»: лучше снизить квант/размер модели и получить стабильный workflow.

5) Практическая стратегия выбора модели и кванта

Шаг 1: определите ограничение

Если узкое место — VRAM: начните с 7B Q4 (или 14B Q4 при 12–16 ГБ VRAM).

Если узкое место — ОЗУ/CPU: чаще лучше меньшая модель, но с более “лёгким” контекстом и аккуратными настройками.

Шаг 2: выберите “базовый квант”

Для старта в кодинге: Q5_K_M (если влезает) или Q4_K_M (если памяти мало).

Для максимальной стабильности на инструкциях (если есть память): Q8 для небольшой модели.

Шаг 3: проверьте на одном и том же сценарии

Сравнивайте не “ощущения”, а один короткий тест: 1) попросите объяснить план изменения; 2) попросите сделать небольшой патч; 3) попросите написать тест/проверку; 4) посмотрите, как часто модель забывает ограничения.

6) Мини-чеклист запуска (без привязки к ОС)

7) Типовые проблемы и быстрые решения

“Не влезает в память”

- берите меньший размер модели или более сильный квант (Q4 вместо Q5/Q8); - уменьшите контекст (если вы поставили слишком большой).

“Очень медленно”

- проверьте, действительно ли используется GPU-offload; - уменьшите размер модели/контекст; закройте тяжёлые фоновые процессы.

“Качество плавает / не следует инструкциям”

- попробуйте повысить квант (Q5 вместо Q4) при том же размере; - или уменьшите размер модели, но возьмите более “бережный” квант (например, 7B Q8).

---

Задания для закрепления

Выберите, что вам ближе для старта: Ollama, LM Studio или llama.cpp. Напишите 3 причины, опираясь на ваш стиль работы (GUI/CLI, контроль/простота, интеграции).

Под ваше железо предложите стартовую связку “размер модели + квант” для задач vibe coding (например: 7B Q4_K_M). Объясните, почему.

Составьте мини-стандарт проекта: какие параметры запуска модели вы будете фиксировать в репозитории (минимум 6 пунктов).

Опишите один и тот же тестовый сценарий (4 шага), по которому вы будете сравнивать два кванта.

<details> <summary> Ответы (примерные) </summary>

1) Пример выбора:

Ollama: “нужен стабильный локальный endpoint”, “минимум ручных настроек”, “быстро переключать модели”.

LM Studio: “хочу GUI и диагностику”, “буду перебирать кванты”, “важно видеть потребление памяти”.

llama.cpp: “нужен максимальный контроль”, “хочу воспроизводимые команды”, “готов разбираться с параметрами”.

2) Пример связок:

8 ГБ VRAM: 7B Q4_K_M (высокий шанс, что влезет и будет бодро).

12–16 ГБ VRAM: 14B Q4_K_M или 7B Q8 (выбор между “больше мозгов” и “выше точность”).

Только CPU и 16 ГБ ОЗУ: 7B Q4 (или даже меньшая), плюс умеренный контекст.

3) Мини-стандарт фиксации параметров:

название/версия модели;

формат (например, GGUF) и квант;

контекст (context length);

режим: CPU/GPU, величина offload (если есть);

температура и ограничения генерации (если вы их фиксируете);

путь хранения моделей и правила обновления.

4) Пример тестового сценария сравнения:

(а) “Составь план правки в 5 пунктов, не меняя публичный API”;

(б) “Предложи минимальные изменения файлов (какие и зачем)”;

(в) “Сгенерируй патч и укажи риски”;

(г) “Сгенерируй тест/проверку и критерии готовности”.

Сравнение: скорость ответа, количество нарушений ограничений, качество плана, правдоподобие тестов.

</details>

Подключение модели к IDE: Continue, Cody альтернативы, локальные чат-панели

Подключение локальной LLM к IDE — это превращение модели из «отдельного приложения» в часть рабочего цикла: чат рядом с кодом, генерация патчей, объяснения, поиск по проекту и (иногда) автодополнение. Запуск моделей и выбор квантов уже разобраны ранее — здесь фокус на интеграции и на том, как не сломать приватность и воспроизводимость.

1) Базовая схема интеграции: IDE → API → раннер

Большинство IDE-плагинов работают по одной логике: они отправляют запросы на HTTP-эндпоинт «в стиле OpenAI» или на нативный провайдер (Ollama и т. п.).

Практический вывод: чтобы потом легко менять модель, удобнее стандартизировать один локальный адрес и хранить его в настройках проекта/IDE.

2) Continue (VS Code / JetBrains): универсальный «локальный ассистент»

Continue — один из самых удобных вариантов для локального vibe coding, потому что совмещает:

Чат по проекту: вопросы «почему тест падает», «где используется функция», «как аккуратно изменить API».

Редактирование по инструкциям: выделили фрагмент → дали задачу → получили дифф.

Контекст-провайдеры: может подтягивать открытые файлы, выделение, результаты поиска по проекту.

Что важно настроить (смысл, не конкретные клики):

Провайдер модели: Ollama / OpenAI-compatible endpoint / локальный сервер.

Две роли модели:

1) «чат/рассуждение» (часто нужна модель получше), 2) «быстрые правки/мелкие задачи» (можно проще и быстрее).

Политика контекста: сколько файлов/строк можно автоматически добавлять в запрос, чтобы не «раздувать» промпт.

Правила редактирования: просите патчи маленькими порциями и привязывайте к проверкам (см. ритуал «дифф → тесты» из первой статьи).

Мини-шаблон системных правил (как текст, который вы вставляете в настройки ассистента):

3) «Cody альтернативы»: чем заменить, если нужен локальный режим

Cody часто ассоциируется с удобным опытом «чат+код», но для курса про локальность критично: вам нужен инструмент, который не требует облачной подписки и умеет ходить в ваш локальный раннер.

Рабочие альтернативы по классам:

IDE-плагины с подключаемым провайдером

1) Continue (часто лучший баланс гибкости и функций). 2) Плагины формата “ChatGPT/OpenAI client”, которые поддерживают «OpenAI-compatible URL» (подключаются к локальному прокси/серверу).

Локальные ассистенты для автодополнения (copilot-like), без облака

1) Tabby (самохост, фокус на completions). 2) Другие self-hosted completion-сервера (идея та же: IDE → локальный completion endpoint).

CLI-ассистенты, которые дополняют IDE

1) Aider-подобные инструменты: работают через git-диффы и команды, удобны для «сделай патч и объясни». В IDE вы смотрите изменения и запускаете проверки.

Как выбрать класс:

Если вы хотите «всё в IDE» — берите Continue.

Если вам важно именно автодополнение — добавляйте отдельный completion-сервер (и не путайте его с чат-моделью).

Если вы любите строгий контроль через git — CLI-агент может быть стабильнее, чем магия в редакторе.

4) Локальные чат-панели: когда IDE не нужна (или нужна меньше)

Иногда удобнее держать чат отдельно от IDE, особенно когда:

вы экспериментируете с моделями/квантами и не хотите трогать настройки IDE;

вам нужен «второй экран» для анализа логов/диагностики;

вы хотите простой web-UI для команды на одной машине.

Типичные варианты:

GUI раннера (например, в стиле LM Studio): удобно видеть загрузку GPU/CPU и быстро менять модель.

Локальные web-UI для Ollama/совместимых серверов: дают чат, историю, иногда простые «персоны» и шаблоны промптов.

Правило: чат-панель хороша для обсуждения и планов, а финальные изменения всё равно фиксируйте через IDE+git (дифф, тесты).

5) Настройки, которые реально влияют на качество в IDE

Контекст и «утечки лишнего»

IDE-плагины умеют автоматически прикладывать к запросу:

открытые файлы,

выделение,

результаты поиска,

дерево проекта.

Это удобно, но опасно по двум причинам:

модель начинает “тонуть” в шуме (хуже следует инструкции);

в контекст случайно попадают секреты (ключи, .env, приватные конфиги).

Минимальная гигиена:

исключите из контекста каталоги с секретами и билд-артефактами;

запретите ассистенту читать файлы окружения по умолчанию;

ограничьте авто-подбор файлов: лучше меньше, но релевантнее.

Отдельные модели под разные задачи

Частая рабочая схема:

«Более умная» модель — для планов, анализа, сложных правок.

«Быстрая» модель — для коротких правок, объяснений, шаблонов.

Это снижает ожидания по железу и делает IDE отзывчивее.

6) Быстрая диагностика проблем

IDE “думает” слишком долго

1) уменьшите контекст, который плагин отправляет; 2) проверьте, не включён ли слишком большой контекст у модели; 3) используйте более компактную модель для чата/правок.

Модель игнорирует ограничения

1) перенесите ограничения в системные правила ассистента; 2) просите план перед патчем; 3) уменьшите «размах» задачи (меньше файлов за итерацию).

Плагин не видит локальный endpoint

1) проверьте, что endpoint слушает нужный адрес/порт; 2) убедитесь, что IDE и сервер в одной сети/неймспейсе (особенно при WSL/контейнерах); 3) проверьте формат API (некоторые плагины требуют OpenAI-совместимость).

---

Задания для закрепления

Опишите вашу целевую схему: какой плагин/инструмент в IDE, какой локальный endpoint, и какая модель по умолчанию.

Составьте «политику контекста»: какие папки/файлы нельзя отдавать в модель, и какие источники контекста разрешены (выделение, открытые файлы, поиск).

Придумайте системные правила для ассистента (5–7 строк), которые заставят его делать маленькие патчи и всегда предлагать проверку.

Выберите: вам важнее чат в IDE или автодополнение? Обоснуйте и назовите инструмент под ваш выбор.

<details> <summary> Ответы (примерные) </summary>

1) Пример схемы:

IDE: VS Code

Плагин: Continue

Endpoint: локальный Ollama (один фиксированный адрес)

Модель: 14B Q4 для чата, 7B Q5 для быстрых правок

2) Пример политики контекста:

Запрет: .env, ключи/сертификаты, папки build/dist, node_modules, большие логи

Разрешено: выделение + текущий файл + максимум 2 релевантных файла из поиска

3) Пример системных правил:

Дай план в 3–5 пунктов

Меняй не больше 2–3 файлов за итерацию

Не добавляй зависимости без запроса

Пиши изменения как дифф-логикой (что и где)

В конце: как проверить (тесты/линтер/команды)

4) Пример выбора:

Если важнее чат: Continue, потому что удобно работать с контекстом проекта и правками по выделению.

Если важнее автодополнение: self-hosted completion (например, Tabby), потому что чат и completion — разные по требованиям к скорости и модели.

</details>

Локальные агентные инструменты: agent0, clawd bot, kilo code и аналоги

Локальный агент — это не просто «чат с моделью», а исполнитель, который умеет делать действия в репозитории: читать файлы, писать патчи, запускать команды, смотреть результаты проверок. В предыдущих статьях уже разобраны базовый локальный workflow, запуск модели и подключение к IDE. Здесь — про агентный слой: чем отличаются инструменты класса agent0 / clawd bot / kilo code и как выбрать/настроить их так, чтобы они ускоряли работу, а не создавали хаос.

1) Что объединяет agent0 / clawd bot / kilo code как класс инструментов

Названия в сообществе могут относиться к разным реализациям, но полезно смотреть на общий «скелет» любого локального агента:

Ключевое: агент должен быть встроен в ваш цикл контроля (дифф → тесты → принятие), а не заменять его.

2) Архитектуры: какие бывают локальные агенты

Практически все инструменты можно разложить по двум осям.

A) Как агент вносит изменения

Git-патч/PR-стиль

1) агент готовит дифф; 2) вы применяете/отклоняете. Плюс: лучший контроль и откат. Минус: чуть больше шагов.

Прямое редактирование файлов

1) агент сразу пишет в рабочую директорию; 2) вы потом смотрите изменения. Плюс: быстрее. Минус: выше риск «размазанных» правок.

B) Где агент живёт

CLI-агент (терминал)

- сильнее интеграция с git и командными проверками.

IDE-агент (плагин)

- удобнее “говорить по коду”, но важно контролировать контекст и права.

Локальный сервис/демон

- удобно для команды на одной машине, но требует дисциплины конфигурации.

3) Критерии выбора: чеклист «здорового» агента

Оценивайте agent0/clawd bot/kilo code/аналог не по маркетингу, а по механике.

Модельный бэкенд

- поддерживает ли ваш локальный endpoint (Ollama/LM Studio server/llama.cpp server или OpenAI-compatible прокси).

Контроль инструментов (permissions)

- есть ли allowlist команд; - можно ли запретить опасные операции; - есть ли режим “только предложить патч”.

Границы доступа к файлам

- можно ли ограничить рабочую директорию; - исключить секреты и мусорные директории.

Наблюдаемость

- видно ли, какие файлы читались; - какие команды запускались; - какие артефакты изменились.

Итеративность

- умеет ли агент делать маленькие шаги: план → 1–2 файла → проверка.

Воспроизводимость

- можно ли зафиксировать конфиг в репозитории (модель, параметры, разрешённые команды).

4) Минимальная безопасная конфигурация (практический стандарт)

Ниже — универсальные настройки, которые подходят почти любому агенту этого класса.

4.1. Политика команд (allowlist)

Разрешайте только то, что вы реально используете для проверки:

чтение статуса репозитория и диффов;

запуск тестов/линтера/форматтера;

сборку проекта (если безопасно).

Запрещайте по умолчанию:

команды удаления/очистки без подтверждения;

сетевые команды, если вам важен полностью офлайн-режим;

изменение глобальных настроек системы.

4.2. Политика файлового доступа

Разрешённые директории: только репозиторий.

Запрещённые зоны: секреты (.env), ключи/сертификаты, большие логи, зависимости/артефакты сборки.

Принцип: агенту не нужно читать всё дерево проекта, чтобы сделать аккуратный патч.

4.3. Режим работы: «план → патч → проверка»

Попросите агента работать строго так:

Сначала короткий план (3–6 пунктов).

Потом список файлов, которые он тронет.

Потом патч маленькими порциями.

В конце — команда/шаги проверки.

5) Как “подружить” агента с локальной LLM без дублирования настроек

Типовая ошибка: настраивать модель отдельно в каждом инструменте. Практичнее иметь один локальный endpoint и переключать модели там. Тогда:

IDE-плагин ходит в один адрес.

CLI-агент ходит в тот же адрес.

Вы меняете модель/квант в одном месте, не ломая workflow.

(Эта схема опирается на ранее настроенный локальный раннер и IDE-интеграцию.)

6) Рабочие сценарии, где локальные агенты особенно полезны

Рефакторинг с ограничителями: “не менять публичный API”, “не трогать формат данных”.

Починка падающего теста: агент собирает контекст по логам, предлагает минимальный фикс и новый тест.

Механические правки: переименование, перенос модулей, унификация стиля.

Подготовка PR-описания: краткое резюме изменений + как проверить.

7) Типовые сбои и как чинить

Агент «размазывает» изменения по проекту

- ограничьте итерацию: максимум 2–3 файла за шаг; - требуйте план до патча.

Запускает лишние команды/долго думает

- урежьте allowlist; - уменьшите контекст, который он подмешивает.

Ломает стиль/формат

- делайте форматтер обязательной проверкой; - просите “не правь форматирование вне затронутых строк”.

---

Задания для закрепления

Опишите, какой тип агента вам ближе: CLI, IDE-агент или сервис. Дайте 3 причины.

Составьте allowlist команд для вашего проекта (5–10 пунктов) и список запрещённых команд (минимум 5).

Напишите «контракт итерации» из 6–8 строк: как агент должен работать (план, файлы, порция правок, проверки).

Придумайте одну задачу для агента в вашем репозитории и разложите её на 3 итерации (что делаем в каждой и чем проверяем).

<details> <summary> Ответы (примерные) </summary>

1) Пример выбора:

CLI-агент: “хочу строгий контроль через git и команды”, “удобно запускать тесты рядом”, “легко логировать действия”.

IDE-агент: “важно редактирование по выделению”, “удобнее видеть дифф в редакторе”, “быстро уточнять контекст по файлам”.

Сервис: “несколько клиентов ходят в одного агента”, “хочу единые правила доступа”, “удобно централизовать логи”.

2) Пример allowlist:

git status, git diff, git log (безопасные)

запуск тестов (ваша команда)

запуск линтера/форматтера

команда сборки (если есть)

Запрет:

rm/удаление, очистка диска

curl/wget (если офлайн и без сети)

любые команды с правами администратора

изменение системных конфигов

установка пакетов глобально

3) Пример «контракта итерации»:

Дай план в 3–5 пунктов.

Назови файлы, которые изменишь.

Меняй не больше 2–3 файлов за итерацию.

Не добавляй зависимости без явного запроса.

После патча скажи, как проверить (команды).

Если тестов нет — предложи минимальную проверку.

4) Пример разбиения задачи: Задача: “Исправить баг в обработке пустого значения и добавить тест”.

Итерация 1: воспроизведение + минимальный анализ; проверка: запуск одного теста/скрипта.

Итерация 2: минимальный фикс в коде; проверка: линтер + целевой тест.

Итерация 3: добавить/исправить тест и обновить описание; проверка: полный тест-сьют.

</details>

Промпты для агента: постановка задач, план, ограничения и проверка результата

Локальный агент полезен ровно настолько, насколько вы умеете задавать ему работу как исполнителю: что сделать, в каких границах, как отчитаться и чем подтвердить готовность. Про сам цикл «намерение → действие → проверка» и про ограничения инструментов мы уже говорили в прошлых статьях — здесь разберём именно структуру промпта, которая делает результат предсказуемым.

1) Что считать “хорошей” задачей для агента

Задача для агента должна быть:

конкретной по результату (что изменится в коде/поведении),

маленькой по объёму итерации (чтобы дифф было реально проверить),

проверяемой (есть команда/шаги валидации).

Самая частая ошибка — просить “сделай X полностью” без границ и без проверки. Тогда агент либо расползается по проекту, либо приносит «правки, которые звучат разумно», но не подтверждены.

2) Базовый каркас промпта (универсальный)

Держите один шаблон и подставляйте детали. Это снижает хаос и делает ответы сравнимыми.

Шаблон:

Контекст: где мы и что сейчас не так.

Цель: итоговое поведение/изменение.

Ограничения: что нельзя/не нужно делать.

Критерии готовности: как поймём, что сделано.

Процесс: план → патч → проверка, маленькими шагами.

Формат ответа: чтобы агент отчитался структурировано.

Мини-пример (скелет)

3) Как формулировать цель: результат, а не действие

Плохая цель: «рефакторни модуль оплаты». Хорошая цель: «упростить функцию X: убрать дублирование, сохранить поведение, добавить тест на крайний случай Y».

Практика: формулируйте цель как наблюдаемое изменение:

«в логах больше нет ошибки …»

«эндпоинт возвращает … в случае …»

«время выполнения теста … не ухудшилось»

4) Ограничения: “заборы”, которые реально работают

Ограничения полезнее, когда они проверяемы и привязаны к зоне риска.

Типовые категории ограничений (выберите только релевантные):

Интерфейсы: не менять публичный API/контракт данных.

Зависимости: не добавлять новые пакеты без запроса.

Область изменений: трогать только указанные модули/папки.

Стиль правок: не менять форматирование вне затронутых строк.

Поведение: сохранить семантику, кроме явно описанного.

Фраза, которая часто спасает: «Если видишь два варианта, выбирай более минимальный». Она уменьшает “креативные” перестройки.

5) План: заставляем агента думать до патча

План — это не бюрократия, а способ поймать ошибки до того, как появится большой дифф.

Хороший план:

3–6 пунктов,

называет файлы/зоны,

упоминает проверку,

фиксирует допущения («предполагаю, что …; если не так — остановлюсь»).

Приём: попросите агента сначала написать план и подождать подтверждения, если задача рискованная.

6) Проверка результата: что требовать от агента

Чтобы не «верить на слово», требуйте от агента конкретику:

Команды проверки (тесты/линтер/сборка), которые он предлагает запустить.

Что именно должно измениться в выводе/поведении.

Минимальный тест или проверку, если в проекте тестов нет.

Удобная формулировка: «В конце перечисли 2–3 способа проверить: быстрый (локально), полный (весь сьют), ручной сценарий».

7) Формат ответа: делаем результат удобным для дифф-ревью

Агенту проще “съехать” в хаос, если формат свободный. Фиксируйте формат:

список файлов,

краткое описание изменений по файлам,

шаги проверки,

список рисков и что сознательно не трогал.

Это экономит время на ревью и снижает вероятность пропустить опасную правку.

8) Три готовых промпта под частые задачи

A) Багфикс по падающему тесту

B) Рефакторинг без изменения поведения

C) Маленькая фича с явной проверкой

9) Антипаттерны (коротко)

«Сделай красиво/лучше/оптимизируй» без измерения и критериев.

«Почини всё» без ограничения области изменений.

«Добавь зависимости, если надо» — почти гарантия неконтролируемого дрейфа.

---

Задания для закрепления

Возьмите реальную задачу из вашего проекта и перепишите её по каркасу: Контекст → Цель → Ограничения → Критерии → Процесс → Формат.

Придумайте 5 ограничений для задачи “рефакторинг”, но так, чтобы каждое было проверяемым.

Напишите промпт, который заставит агента сначала предложить план и дождаться подтверждения перед патчем.

Составьте список критериев готовности для задачи “починить баг”, где есть: (а) тест, (б) ручная проверка, (в) запрет на лишние изменения.

<details> <summary> Ответы (примерные) </summary>

1) Пример каркаса:

Контекст: «В API /orders иногда 500 при пустом фильтре status; в логах KeyError: status».

Цель: «/orders возвращает 200 и корректный список при пустом status».

Ограничения: «не менять контракт ответа», «не добавлять зависимости», «правки только в orders handler + тест».

Критерии: «тест на пустой status проходит», «быстрый набор тестов проходит», «ручной запрос curl без status возвращает 200».

Процесс: «план → 1 патч → проверка».

Формат: «План/Файлы/Изменения/Проверка/Риски».

2) Пример проверяемых ограничений:

«Не менять публичные сигнатуры функций X/Y» (проверяется диффом).

«Не изменять формат JSON-ответа» (проверяется тестом/сравнением схемы).

«Не добавлять новые зависимости в lock/manifest» (проверяется диффом).

«Изменить не более 3 файлов» (проверяется списком файлов).

«Не менять форматирование вне затронутых строк» (проверяется диффом/форматтером).

3) Пример промпта с “план и стоп”: «Сначала дай план в 4 пунктах и список файлов. Не предлагай патч, пока я не отвечу “ОК, делай”. Если видишь риск изменения API — остановись и уточни».

4) Пример критериев готовности:

Тест: «добавлен тест на воспроизведение бага и он проходит».

Ручная проверка: «повторить шаги: … и увидеть …».

Запрет на лишнее: «дифф затрагивает только файлы A и B; зависимости не менялись».

</details>

Безопасность и качество: песочницы, права доступа, тесты и контроль изменений

Локальный vibe coding убирает облачные риски, но добавляет другие: агент получает доступ к вашим файлам и командам, а значит может случайно (или из-за неверного контекста) сделать опасные действия. Базовые привычки (дифф → тесты → коммит, запрет секретов, allowlist команд) уже обсуждались ранее — здесь углубимся в технические “ограждения” и процедуры качества, которые делают работу предсказуемой.

1) Модель угроз: что реально может пойти не так

Полезно мыслить не «мне нечего скрывать», а «что может сломаться».

| Риск | Пример | Последствие | Что помогает | |---|---|---|---| | Деструктивные команды | очистка каталога, перезапись файлов | потеря данных | песочница + права + бэкапы | | Экcфильтрация | чтение .env и отправка “в лог/ответ” | утечка секретов | изоляция файлов + политика контекста | | Supply chain | правки зависимостей/скриптов сборки | внедрение вредоносного кода | контроль изменений + запреты | | Prompt injection из репозитория | «инструкция» в README/issue заставляет игнорировать правила | обход ограничений | “доверяй, но проверяй”: явные правила + ревью | | Некачественные правки | тестов нет, дифф большой | регрессии | тестовый барьер + маленькие итерации |

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

2) Песочницы: как отделить агента от вашей системы

Песочница — это технический способ сделать так, чтобы даже при ошибке агент не мог повредить важное.

Вариант A: отдельный пользователь (минимум трения)

Подход: запускать агента/раннер под отдельной учёткой ОС.

Практические правила:

отдельный home-каталог без доступа к личным документам;

только рабочие репозитории в разрешённых папках;

запрет админских прав.

Это не идеальная изоляция, но резко снижает ущерб от «случайно удалил не то».

Вариант B: контейнер (лучший баланс)

Контейнер удобен, когда вам нужна воспроизводимость и контроль:

монтируете внутрь контейнера только папку проекта;

запрещаете доступ к остальной файловой системе;

ограничиваете сеть (если хотите офлайн);

фиксируете инструменты и версии.

Важно: контейнер — не «магическая безопасность», но это жёсткая граница по файловому доступу и окружению.

Вариант C: виртуальная машина (максимальная изоляция)

VM оправдана, если:

вы работаете с недоверенным кодом;

у проекта много скриптов, которые агент может запустить;

вы хотите отделить “рабочую песочницу” от основной машины.

Минус — выше накладные расходы и сложнее доступ к GPU (если он нужен для LLM).

3) Права доступа и «нулевое доверие» к репозиторию

Даже свой репозиторий может содержать опасные вещи: скрипты, хуки, команды в документации.

Мини-политика:

Read-only по умолчанию: если инструмент поддерживает режим “предложить патч”, начните с него.

Запрет опасных зон: секреты, ключи, конфиги окружения, каталоги сборки и зависимости.

Запрет сети (по возможности): агенту редко нужно скачивать что-то из интернета для обычного рефакторинга.

Явное разрешение на запуск: не запускать “любые команды”; только короткий список проверок проекта.

Важный нюанс качества: prompt injection часто выглядит как “полезная инструкция”. Поэтому правила должны жить в конфиге агента/IDE, а не в документах репозитория.

4) Тесты как барьер: делаем «сломать» дороже, чем «проверить»

Смысл тестового барьера — не «покрыть всё», а сделать регрессии заметными.

Практичная лестница проверок (от дешёвого к дорогому):

форматирование/линтер (быстро ловит мусор в диффе);

быстрые unit-тесты (таргет на изменённый модуль);

интеграционные/энд-ту-энд (по необходимости).

Два рабочих приёма:

“тест на баг” прежде фикса: сначала воспроизведите проблему тестом/скриптом, потом чините.

“командный контракт”: агент обязан заканчивать ответ блоком «Как проверить» с конкретными командами (согласовано в вашем workflow).

Если тестов мало, не просите агента «покрыть всё». Просите минимальный проверяемый сценарий, который защищает конкретную правку.

5) Контроль изменений: как не пропустить опасную правку

Дифф-ревью — ваш главный контроль, но его нужно сделать удобным.

Рекомендации, которые улучшают качество ревью:

Ограничение размера итерации: маленький дифф легче проверить, чем идеальный, но огромный.

Запрет “тихих” изменений:

- зависимости/lock-файлы; - скрипты сборки/CI; - конфиги линтера/форматтера. Эти зоны меняются только по отдельной задаче.

Доказательство проверки: требуйте у агента указать, что именно он запускал и что ожидается в результате (даже если вы потом запускаете сами).

Визуально полезно мыслить так:

6) Мини-стандарт проекта: «безопасный режим по умолчанию»

Зафиксируйте в репозитории (в виде короткого документа/конфига) 6 пунктов:

где запускается агент (пользователь/контейнер/VM);

какие директории доступны;

какие команды разрешены;

какие команды проверок обязательны;

какие файлы/зоны нельзя менять без отдельного запроса;

правило итераций: план → маленький патч → проверка.

Это снижает зависимость от памяти и дисциплины: меньше “как-нибудь потом”.

---

Задания для закрепления

Для вашего сценария выберите песочницу: отдельный пользователь, контейнер или VM. Укажите 2 причины и 2 компромисса.

Составьте таблицу «запрещённые зоны репозитория» (минимум 6 пунктов) и кратко объясните, почему каждая зона рискованна.

Напишите «тестовый барьер» из 3 уровней для вашего проекта: что запускается всегда, что запускается перед коммитом, что — перед релизом.

Придумайте правило “опасных изменений”: какие 3 типа файлов агент не имеет права менять без явного подтверждения, и как вы это проверяете.

Сформулируйте короткий «протокол отчёта агента» (5 строк): что он должен написать после выполнения задачи.

<details> <summary> Ответы (примерные) </summary>

1) Пример выбора:

Контейнер: причины — “монтирую только папку проекта”, “фиксирую версии инструментов”; компромиссы — “нужно настроить”, “иногда сложнее GPU/доступ к устройствам”.

2) Пример запрещённых зон:

.env, secrets/ — риск утечки.

~/.ssh (если доступно) — ключи.

node_modules/, venv/ — шум, лишний объём, риск «правок в поставляемом».

dist/, build/ — артефакты, не источник истины.

package-lock.json/poetry.lock/requirements.lock — supply chain и неожиданные обновления.

CI/скрипты (.github/, Makefile, scripts/) — можно внедрить опасные команды.

3) Пример тестового барьера:

Всегда: форматтер + линтер.

Перед коммитом: быстрые unit-тесты изменённого модуля.

Перед релизом: полный тест-сьют + интеграционные.

4) Пример “опасных изменений”:

Lock-файлы зависимостей, CI-конфиги, скрипты сборки.

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

5) Пример протокола отчёта:

План (3–5 пунктов)

Список изменённых файлов

Кратко: что изменено по каждому файлу

Как проверить (команды)

Риски/что сознательно не трогал

</details>