В предыдущих постах мы разобрались с моделями, настройкой и практическими промптами. Теперь поговорим о том, как выжать максимум из локальных LLM с помощью специализированных инструментов. Не агенты в абстрактном смысле, а конкретные программы, которые вы можете установить сегодня и начать использовать.

Почему локальные модели + специализированные инструменты — это мощно

Облачные сервисы вроде ChatGPT удобны, но имеют ограничения: задержка сети, ограничения на длину контекста, невозможность работы с приватными данными. Локальные модели решают эти проблемы, но у них есть своя: они менее «умные» в общем смысле и требуют правильного подхода к промптингу.

Специализированные инструменты (OpenCode, Pi, Claude Code, Codex CLI) строятся на идее, что LLM — это не оракул, а исполнитель в конвейере. Они добавляют:

Контекст проекта — инструмент видит ваш код, структуру файлов, зависимости
Планирование — разбивает большую задачу на шаги и выполняет их последовательно
Интеграцию с окружением — запускает тесты, читает логи, делает git commit
Повторные попытки — если тест упал, анализирует ошибку и пробует исправить

И когда такой инструмент работает с локальной моделью — вы получаете всё это без риска утечки данных и без зависимости от интернета.

OpenCode

OpenCode — открытый терминальный кодинг-агент от команды SST, по духу ближайший аналог Claude Code. Работает в терминале, понимает структуру вашего проекта, умеет редактировать файлы, запускать команды, анализировать ошибки.

Установка

# macOS (Homebrew)
brew install sst/tap/opencode

# или через npm
npm install -g opencode-ai

# или официальным скриптом
curl -fsSL https://opencode.ai/install | bash

Подключение локальной модели

OpenCode поддерживает разных провайдеров, включая Ollama:

# ~/.config/opencode/opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "model": "ollama/qwen3.5:9b",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": { "qwen3.5:9b": { "tools": true } }
    }
  }
}

Важный нюанс: Ollama по умолчанию даёт модели контекст в 4096 токенов — для агентной работы этого мало, tool calling начнёт молча отваливаться. Поднимите num_ctx до 16-64K (через /set parameter num_ctx в сессии Ollama или PARAMETER в Modelfile). Если Ollama свежая (v0.15+), можно вообще пропустить ручную настройку: ollama launch opencode --model qwen3.5 сконфигурирует всё сама.

Реальные сценарии использования

Сценарий 1: Написание автотеста для новой фичи

$ opencode

> Напиши Playwright-тест для проверки добавления товара в избранное.
> Фича реализована в src/features/favorites/
> API эндпоинт: POST /api/v1/favorites
> На фронте кнопка с data-testid="add-to-favorites"

OpenCode:
1. Читает структуру проекта
2. Находит существующие тесты в tests/
3. Анализирует паттерны (POM, fixtures)
4. Создаёт tests/favorites/add-to-favorites.spec.ts
5. Запускает тест: npx playwright test favorites
6. Если упал — читает ошибку, исправляет, повторяет
7. Делает git diff для review

На Qwen 3.5 9B это занимает 2-3 минуты. На облачной модели — 30-40 секунд, но вы отправляете в облако код своего проекта.

Сценарий 2: Рефакторинг существующих тестов

> Перепиши тесты в tests/checkout/ на использование нового API helpers.
> Примеры использования helpers в tests/utils/api-helper.ts

OpenCode:
1. Читает все файлы в tests/checkout/
2. Анализирует api-helper.ts
3. По одному обновляет файлы
4. Запускает тесты после каждого изменения
5. Если тест упал — откатывает и пробует другой подход
6. В конце показывает summary: "Обновлено 5 файлов, все тесты проходят"

Сценарий 3: Анализ падения CI

> Почему упал последний прогон на Jenkins?
> Логи: https://jenkins.company.com/job/qa/123/console

OpenCode:
1. Загружает логи (через curl или MCP-интеграцию)
2. Находит FAILED тесты
3. Анализирует stack trace
4. Проверяет, не связано ли с недавними изменениями (git log)
5. Предлагает фикс или создаёт баг-репорт

Почему OpenCode хорошо работает с локальными моделями

Контекст проекта — модель видит реальные файлы, а не догадывается о структуре
Итеративность — если первый вариант не работает, инструмент даёт модели обратную связь (ошибка компиляции, падение теста)
Ограниченная область — задачи конкретны («напиши тест», «исправь баг»), модель не пытается решить всё и сразу
Tool use — модель вызывает конкретные функции (read_file, write_file, run_command), а не генерирует текст наудачу

На практике Qwen 3.5 9B справляется с 70-80% задач, которые я ему кидаю через OpenCode. Оставшиеся 20-30% — либо слишком сложные (архитектурные изменения), либо требуют знания бизнес-логики, которой нет в коде.

Pi (pi.dev)

Pi — минималистичный кодинг-агент для терминала от Mario Zechner. Сразу оговорка, потому что название путают: к чат-боту Pi от Inflection он отношения не имеет, это совсем другой проект.

Философия Pi противоположна комбайнам: из коробки минимум фич (никаких саб-агентов и план-режимов), зато всё расширяется — скиллы, шаблоны промптов, свои провайдеры, пакеты через npm. Агент подстраивается под ваш процесс, а не наоборот.

npm install -g @mariozechner/pi-coding-agent

Провайдеров поддерживается больше пятнадцати: Anthropic, OpenAI, Google, OpenRouter, Kimi и, что важно для нас, Ollama. Свои модели и провайдеры добавляются через models.json или расширения. Для связки с локальной моделью это самый простой путь после OpenCode.

Где я его использую: быстрые одношаговые задачи в терминале — сгенерить тест, объяснить кусок кода, сделать мелкий рефакторинг. Для длинных агентных цепочек с воркфло беру OpenCode, а для «запустил — получил — закрыл» Pi удобнее за счёт минимализма.

Claude Code (Anthropic)

Claude Code — терминальный агент от Anthropic: редактирует код, запускает команды, анализирует ошибки. Давно вышел из беты и сейчас фактически эталон жанра, с которым сравнивают всё остальное.

Особенности

Агентные возможности — Claude может самостоятельно исследовать кодовую базу, находить релевантные файлы
Git-интеграция — создаёт ветки, коммитит, делает diff
Тест-цикл — пишет тест, запускает, исправляет, повторяет

Подключение локальной модели

Официально Claude Code работает только с API Anthropic. Обходной путь — прокси, которые эмулируют Anthropic API поверх локального сервера: LiteLLM или claude-code-router, за которыми стоит ваша Ollama. Схема рабочая, но с оговоркой: небольшие локальные модели нестабильно держат сложный tool calling Claude Code. Для простых задач («найди все тесты, которые используют устаревший API», «добавь data-testid ко всем кнопкам в компоненте») — сгодится, для серьёзных агентных цепочек надёжнее OpenCode, где промпты и обвязку можно подстроить под слабую модель.

Codex CLI (OpenAI)

Codex CLI — терминальный агент от OpenAI: пишет код, запускает команды, анализирует ошибки. Открытый проект, исходники на GitHub.

Особенности

Full-context — Codex видит весь проект и может ссылаться на любые файлы
Approval mode — каждое изменение требует подтверждения (по умолчанию)
Sandbox — запускает команды в изолированном окружении

Локальный аналог

Полностью локальный Codex CLI невозможен — он привязан к API OpenAI. Но вы можете использовать OpenCode или Claude Code с локальной моделью для аналогичных задач. Качество будет ниже, но приватность — выше.

Сравнение инструментов

Инструмент	Локальная модель	Сложность	Лучше всего для
OpenCode	✅ Нативно	Средняя	Написание тестов, рефакторинг
Claude Code	⚠️ Через прокси	Высокая	Исследование кодовой базы
Pi	✅ Нативно	Низкая	Быстрые одношаговые задачи, кастомизация
Codex CLI	❌ Облако	Средняя	Быстрые правки, прототипирование

Практический пример: рабочий день с OpenCode + локальная модель

Вот как выглядит мой типичный день:

Утро: планирование

$ opencode

> Какие тесты нужно написать для задачи EC-1234?
> Описание: Добавить возможность оплаты криптовалютой

OpenCode:
1. Читает Jira-тикет (через MCP-интеграцию)
2. Анализирует связанные PR
3. Предлагает план:
   - Тест-кейсы: 8 штук (happy path, негативные, граничные)
   - Автотесты: 3 критических пути
   - Интеграционные тесты: проверка webhook'ов
4. Создаёт draft в Confluence

День: написание автотестов

> Напиши автотест для сценария "Оплата Bitcoin, недостаточно средств"
> Документация API: docs/payments/crypto.md

OpenCode:
1. Читает документацию
2. Находит существующие тесты оплаты
3. Копирует паттерны
4. Создаёт tests/payments/crypto-insufficient-funds.spec.ts
5. Запускает: npx playwright test crypto-insufficient-funds
6. Тест проходит
7. Предлагает commit message

Вечер: анализ прогона

> Проанализируй логи сегодняшнего прогона на staging
> Логи: /var/log/jenkins/qa-staging-456.log

OpenCode:
1. Читает логи (через read_file)
2. Находит 2 FAILED теста
3. Анализирует причины:
   - test/checkout/guest-checkout.spec.ts: timeout на загрузке страницы
   - test/payments/wallet.spec.ts: изменился ответ API (новое поле)
4. Предлагает фиксы:
   - Добавить waitForLoadState('networkidle')
   - Обновить моки в wallet.spec.ts
5. Применяет фиксы
6. Запускает тесты повторно — проходят
7. Коммитит: "fix: stabilize guest checkout and update wallet mocks"

Почему это работает именно с локальными моделями

Может показаться, что облачные флагманы (Claude, GPT, Kimi K3) дадут лучший результат. И да, они умнее в общем смысле. Но для QA-автоматизации локальные модели имеют критические преимущества:

1. Контекст проекта

Когда OpenCode читает ваши файлы, эти файлы не покидают вашу машину. С облачной моделью вы отправляете в API исходный код, тестовые данные, возможно — конфиги с паролями (даже если это «только тестовые стенды»).

2. Скорость итераций

Локальная модель отвечает за 10-20 секунд. Облачная — за 5-10 секунд. Но когда инструмент делает 20-30 итераций (написал код → запустил → ошибка → исправил → повторил), разница в 10 секунд на итерацию превращается в 3-5 минут на задачу. А если интернет прервался — облачная модель вообще не работает.

3. Стоимость

Облачные флагманы стоят сейчас $3-5 за миллион входных токенов и $15-25 за миллион выходных. Звучит дёшево, но когда инструмент отправляет весь контекст проекта при каждом запросе, счёт растёт быстро. Подробно экономику облака я разбирал в обзоре Kimi K3 — там же схема, как я совмещаю локалку и облако.

Локальная модель — фиксированная стоимость (железо, которое у вас уже есть). Никаких сюрпризов в конце месяца.

4. Независимость

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

Ограничения и честность

Не всё так радужно. Вот с чем я сталкиваюсь регулярно:

Сложная архитектура — локальная модель не справится с рефакторингом всей тестовой инфраструктуры. Только конкретные, локальные задачи.
Новые технологии — если фреймворк вышел неделю назад, модель о нём не знает. Придётся объяснять вручную.
Бизнес-логика — модель не знает, почему именно так реализована фича. Она может предложить «логичное» решение, которое противоречит требованиям.
Галлюцинации — иногда модель уверенно утверждает, что метод существует, хотя его нет. Всегда проверяйте.

Но даже с этими ограничениями экономия времени — 30-50% на рутинных задачах. А это часы каждую неделю.

Что дальше

Эта серия постов — не финальная точка, а отправная. Локальные LLM развиваются стремительно: модели становятся умнее, инструменты — удобнее, интеграции — глубже.

Возможные темы для продолжения:

Настройка собственного MCP-сервера для внутренних инструментов
Дообучение (fine-tuning) моделей под конкретный проект
Мульти-агентные системы: несколько моделей, каждая со своей ролью
Сравнение производительности на новых моделях (Qwen 3.6, Llama 4, Gemma 5)

Если тема интересна — пишите в комментариях, что разобрать подробнее.

И помните: LLM — это инструмент, не замена. Критическое мышление, опыт и интуиция QA-инженера остаются незаменимыми. Но инструмент хороший — берите и пользуйтесь.

Продвинутый уровень: агенты, skills и полная автоматизация QA