TR;DR#
Я отличаю AI-assisted development от vibecoding — модель усиливает мышление, а не заменяет его. Мой рабочий стек — VS Code + Continue + LM Studio с локальными моделями, без завязки на облако. В статье — набор промтов, которые реально использую (коммиты, тесты на Vitest, объяснение TODO/README), с честной оценкой, где справляется маленькая 8B-модель, а где нет. Отдельно — про то, почему Continue после 2.0 всё сильнее тянет в сторону обязательного облачного Hub и что с этим делать, если тебе важен Local-First подход.
Как я пришел к ИИ#
Долгое время я относился к нейросетям исключительно как к редакторскому инструменту. На прежнем месте работы — в фонде при ЦИБМ — я использовал ИИ в основном для автоматизации рутины: суммировал новости из сферы информационной безопасности и пересобирал их в посты нужного формата. Мне казалось, что на большее современные модели не способны, а для задач реального программирования они банально не созрели. Однако с развитием локальных моделей и ассистентов подход пришлось пересмотреть: ИИ действительно становится неотъемлемой частью разработки, хотя и совсем не так, как это представляют себе сторонники хайпа.
AI-Assisted != Vibecoding#
Из-за популярности определения vibecoding считаю нужным внести ясность в различие между программированием силами чат моделей и программированием с ассистированием. Определение “вайбкодер” фрустрирует нормальных разработчиков, из-за мнения что разработчик использующий ИИ, это обязательно вайбкодер, который самостоятельно ничего не может, и многие забывают о том, что разработка это не только написание кода но и множество процессов построенных вокруг него.
Различия двух подходов#
Vibecoding#
Это когда в основном отдают управление модели:
- Пишут абстрактный промт, зачастую без конкретики и требований к конечной реализации
- Принимают почти все что навыдумывала им модель
- Минимальное чтение и понимание выдуманного кода
- Удовлетворённость от того что код хотя бы примерно делает то что нужно
- Не могут объяснить код, почему он такой и как он работает
AI-Assisted development#
Это когда AI — инструмент, а не замена мышлению:
- Четкое понимание задачи и архитектуры
- Модели дается четкий и ограниченный задачей контекст
- Критическое отношение к генерированному коду, обязательная правка при необходимости
- Право проектирования архитектуры, именований, обработку ошибок разработчик оставляет за собой, выстраивается граница ответственности
- AI используется для ускорения рутины, исследование, суммирование сделанных изменений и тд.
- Нет мысли и желания чтобы модель сделала всё за разработчика
Если объяснить разницу одной строкой#
AI-Assisted development — это когда ты усиливаешь своё мышление с помощью модели. Vibecoding — это когда ты делегируешь мышление модели и надеешься на лучшее.
От чата к агенту#
Из-за своего редакторского опыта в фонде я долгое время откладывал выяснение, что там за хайп по агентам и что такое этот ваш новый протокол контекста. То есть моя работа была банальной: берём чат-интерфейс и ручками копируем текст, формируя контекст. Сильно позже, углубившись в тему и попробовав Prisma MCP и daisyUI MCP, я осознал, насколько ограниченно применял ИИ.
Разница между этими вариантами взаимодействия ощутима:
Обычный режим чата — это работа с «изолированным окружением». Модель знает только то, что ты физически вставил в промт. У неё нет доступа к твоему проекту, структуре файлов, терминалу или документации.
Агентный режим (Agentic Mode) — это подход, при котором модель перестаёт быть просто генератором текста и становится активным участником процесса. Агент сам определяет цепочку шагов для решения задачи: может исследовать дерево проекта, прочитать нужные файлы, внести правки, запустить тесты в терминале и исправить свои же ошибки по результатам их выполнения.
MCP (Model Context Protocol) — это открытый стандарт от Anthropic, который работает как «универсальный переходник» для инструментов доступных ИИ. С его помощью модель может безопасно подключаться к внешним источникам данных и инструментам: локальным базам данных, API GitHub, файловой системе, документации или системам логирования, не требуя написания уникального кода под каждый сервис.
Осознав, насколько агентный режим и интеграция контекста ускоряют работу, я захотел перенести этот опыт прямо в рабочий редактор. И начать я решил с локального сетапа, который позволил бы мне опробовать такую интеграцию.
Мой стек: VS Code + Continue + LM Studio#
Visual Studio Code#
Visual Studio Code — мой основной редактор кода уже много лет. В своё время он пришёл на смену Sublime Text благодаря огромной экосистеме расширений. Не вижу смысла спорить о «лучшем редакторе», просто зафиксируем факт: любые AI-инструменты я искал с привязкой к привычной среде разработки.
Continue#
Сами авторы позиционируют Continue как новаторский программный агент с открытым исходным кодом (Pioneering open-source coding agent).
Именно это расширение я выбрал для интеграции моделей в свой рабочий процесс. Continue добавляет:
- Встроенный чат прямо в боковой панели;
- Быстрые комбинации клавиш (шорткаты) для выделения кода и моментальной отправки его в контекст;
- Возможность кастомизации: можно создавать собственные промты и вызывать их через
/prompt-id.
Но главное преимущество Continue перед обособленными консольными утилитами (вроде Gemini CLI) — он отлично дружит с локально развёрнутыми моделями и (или) не навязывает использование облачных или огромных моделей уровня 30B параметров и более, неспособных запуститься на потребительском железе*.
Сноска про OpenCode: Небольшое лирическое отступление. Я честно пытался завести OpenCode, но так и не смог заставить его адекватно работать с моделями меньше 30B параметров — он почему-то упорно игнорировал мой конфиг с переопределением моделей. Но если ситуация с Continue продолжится в сторону облака, не исключаю, что перейду именно на него.
Какие режимы поддерживает Continue#
- Chat — привычный диалоговый интерфейс в панели VS Code. Подходит для быстрых вопросов, генерации функций по описанию или объяснения отдельных кусков кода.
- Plan (Планирование) — режим, в котором модель сначала изучает контекст проекта и строит пошаговый план решения задачи (архитектурный план). Ты проверяешь его, вносишь правки и только потом отдаёшь команду на исполнение. Это отличный предохранитель от хаотичных правок (правда, из-за аппаратных ограничений на размер моделей я его почти не использую).
- Agent (Агентный режим) — полноценное исполнение. В этом режиме модель получает возможность исследовать дерево проекта, читать файлы, выполнять команды в терминале и задействовать сторонние MCP-серверы для работы с внешними инструментами.
LM Studio#
В качестве локального бэкенда (инференс-движка) я использую LM Studio. Это удобное GUI-приложение, которое позволяет в пару кликов скачивать квантованные GGUF-модели с Hugging Face, гибко настраивать распределение слоёв на VRAM/RAM и поднимать локальный сервер, полностью совместимый с OpenAI API (http://localhost:1234/v1).
🤖 Промты которые я использую#
Здесь я оставляю небольшой список промтов которые использую во время написания кода, при обслуживании кода или когда ищю новые проекты, я надеюсь они будут вам полезны.
Поскольку я использую локальные модели, а они на потребительском оборудовании работают с ограниченным числом параметров, по каждому промту будет сноска как эффективно они работают на моделях с 8B параметров, и это опыт для модели Gemma4.
Оформление коммитов по Angular Commit Convention#
Сноска: На малой модели работает хорошо
📋 Показать системный промт
Convert the following Russian description into an English commit message using the Angular Commit Convention.
Rules:
- Use one of the following types:
- feat: new feature
- fix: bug fix
- docs: documentation changes
- style: formatting, whitespace, linting
- refactor: code refactoring without behavior changes
- perf: performance improvements
- test: adding or updating tests
- build: build system or dependencies
- ci: CI/CD changes
- chore: maintenance tasks
- revert: reverting previous changes
- Format: <type>(<scope>): <short description>
- Subject:
- English only
- imperative mood
- lowercase
- no period at the end
- maximum 72 characters
- Scope:
- infer from the description when possible
- examples: auth, api, ui, users, payments, config
- If multiple changes are present, add a blank line and a bullet list.
Examples:
Russian:
Добавил авторизацию через OAuth2
Result:
feat(auth): add oauth2 authentication
Russian:
Исправил обновление токена и добавил тесты
Result:
fix(auth): handle token refresh correctly
- add integration tests for refresh flow
Return only the commit message.Обьяснение кода#
Сноска: На малой модели работает хорошо на малом коде или отдельной функции, на большой кодовой базе работает хуже.
📋 Показать содержимое промта
Объясни на русском языке, что делает выделенный код.
Структура ответа:
- Назначение: для чего этот код нужен, какую задачу решает
- Как работает: пошаговое объяснение логики простыми словами
- Входные данные: что принимает функция/модуль (параметры, типы)
- Выходные данные: что возвращает и в каком формате
- Особенности: побочные эффекты, мутации, асинхронность, обработка ошибок (если есть)
- Возможные проблемы: на что стоит обратить внимание (если есть)
Объясняй так, как будто рассказываешь коллеге, который видит этот код впервые. Избегай простого пересказа кода построчно — фокусируйся на смысле и логике.Генерация юнит тестов с Vitest#
Сноска: На малой модели работает хорошо, для геренации простых тестов подходит, но зачастую не хватает информации о типах или конфигурации TypeScript, может использовать vi.mock, но использует его и в тех местах где он не нужен.
📋 Показать содержимое промта
Write comprehensive unit tests for the selected TypeScript code using Vitest.
Requirements:
Setup:
- Use `describe`/`it` blocks, grouped logically by function/method/class.
- Import everything with correct relative paths and types.
- Use `vi.fn()`, `vi.mock()`, `vi.spyOn()` for mocking dependencies, external modules, timers, and Date where relevant.
- Strictly type all mocks and test data — no `any`.
Coverage goals (aim for 100%):
- Test every exported function, method, and branch (if/else, switch, ternary, short-circuit operators, optional chaining).
- Test every early return and thrown error path.
- Test all loops with 0, 1, and multiple items.
Edge cases to always consider:
- Empty inputs: empty string, empty array, empty object, empty Map/Set.
- Nullish values: `null`, `undefined`, missing optional fields.
- Boundary values: 0, negative numbers, max/min safe integers, very long strings.
- Invalid/malformed input (wrong types passed at runtime, malformed JSON, etc.).
- Async edge cases: rejected promises, timeouts, race conditions, concurrent calls.
- Idempotency: calling the function multiple times with the same input.
- Side effects: verify mocked dependencies are called with correct arguments, correct number of times.
Assertions:
- Use precise matchers (`toEqual`, `toStrictEqual`, `toThrow`, `toHaveBeenCalledWith`, `rejects.toThrow`, etc.) — avoid loose `toBeTruthy`/`toBeFalsy` unless appropriate.
- For error cases, assert both that an error is thrown/rejected AND the error message/type.
Output:
- Provide the full test file, ready to run.
- Add a short comment above each `it` block group explaining what scenario it covers.
- At the end, list any branches or lines that may still be uncovered and explain why (if any), or what additional input/mocking would be needed to cover them.
If the code under test has external dependencies (DB, HTTP, filesystem, env vars), mock them explicitly and explain the mocking strategy briefly before the test code.Перевод TODO комментариев в коде#
Сноска: На малой модели работает хорошо
📋 Показать содержимое промта
You are a senior software engineer writing code comments.
The user will provide a Russian description of a task or issue.
Your job is to translate it into English and format it as a proper inline code comment.
Rules:
Prefix selection — pick the most appropriate:
- TODO: something that needs to be done or implemented
- FIXME: broken or incorrect code that needs to be fixed
- HACK: a workaround that works but is not a proper solution
- NOTE: important context or explanation for future developers
- WARNING: something dangerous, fragile, or easy to break
- OPTIMIZE: code that works but has performance issues
- DEPRECATED: code that should no longer be used
Format: // <PREFIX>: <translated task in English>
Translation rules: - English only, imperative mood (e.g. "add", "fix", "remove", not "added" or "should add") - Be concise — max 72 characters per line - If the task has multiple parts, split into multiple comment lines with the same prefix - Do not add any explanation or extra text — return only the formatted comment(s)
Examples:
Russian: нужно добавить валидацию email перед отправкой формы
Result: // TODO: add email validation before form submission
Russian: этот костыль работает но нужно переписать нормально после релиза
Result:
// HACK: temporary workaround, rewrite properly after release
// TODO: refactor this after the release
Russian: метод устарел, использовать новый UserService
Result: // DEPRECATED: use UserService instead
Russian: здесь падает если передать пустой массив
Result: // FIXME: crashes when an empty array is passed
Return only the comment line(s), nothing else.Поиск и обьяснение TODO комментариев#
Сноска: На малой модели работает хорошо, для небольших файлов кода без сложной логики работает. На сложной логике или коде использующий фичи языка не всегда работает корректно.
📋 Показать содержимое промта
You are a senior software engineer reviewing a codebase.
Scan the selected code for all inline task comments with these prefixes:
TODO, FIXME, HACK, NOTE, WARNING, OPTIMIZE, DEPRECATED
For each found comment:
1. Quote the original comment exactly as written
2. Explain in Russian what the task or issue is about
3. Assess priority:
- 🔴 Высокий — FIXME, WARNING, crashes or security issues
- 🟡 Средний — TODO, OPTIMIZE, HACK with known risk
- 🟢 Низкий — NOTE, DEPRECATED, cosmetic or future improvements
4. Suggest a short action plan in Russian (1-3 steps max)
Output format for each comment:
---
📌 `<original comment>`
📍 Строка: <line number if visible>
🧩 Суть: <explanation in Russian>
⚡ Приоритет: <🔴/🟡/🟢 + label>
✅ Что сделать: <action steps in Russian>
---
At the end, add a short summary in Russian:
- Total comments found
- How many per priority level
- Which one to address first and why
If no task comments are found, respond:
"В выделенном коде не найдено ни одного TODO, FIXME или аналогичного комментария."Обьяснение README.md проекта#
Сноска: На малой модели работает хорошо
📋 Показать содержимое промта
You are a senior software engineer helping a Russian-speaking developer understand a project.
The user will provide the contents of a README.md file.
Your job is to read it and explain the project in Russian in a clear, structured way.
If the README is in English — translate and explain.
If the README is in Russian — explain and restructure for clarity.
If the README is mixed — handle each part accordingly.
Output structure:
## 🧩 Что это за проект
Short explanation of what the project does and what problem it solves (2-4 sentences, plain language).
## 🎯 Для кого и зачем
Who is the target audience and what use cases does it cover.
## ⚙️ Технологии и зависимости
List the key technologies, frameworks, and libraries mentioned. For each one briefly explain its role in the project.
## 🚀 Как запустить
Step-by-step setup and launch instructions in Russian. If commands are present — keep them as-is in code blocks, translate only the surrounding explanation.
## 📁 Структура проекта
If the README describes the folder/file structure — explain what each part is responsible for.
## 🔑 Ключевые возможности
List the main features and capabilities of the project.
## ⚠️ Важные замечания
Highlight any warnings, limitations, known issues, or prerequisites mentioned in the README.
## ❓ Что осталось непонятным
If any part of the README is vague, incomplete, missing, or assumes too much prior knowledge — list it here and explain what additional context would help.
Rules:
- Write everything in Russian except code blocks, commands, and proper names (library names, framework names, etc.).
- Do not copy-paste large chunks of the original README — explain in your own words.
- If a section from the structure above is not covered in the README, skip it.
- Keep the tone practical and developer-friendly — no marketing language.Обьяснение CONTRIBUTING.md#
Сноска: На малой модели работает хорошо
📋 Показать содержимое промта
You are a senior software engineer helping a Russian-speaking developer understand how to contribute to a project.
The user will provide the contents of a CONTRIBUTING.md file.
Your job is to read it and explain the contribution guidelines in Russian in a clear, structured way.
If the CONTRIBUTING.md is in English — translate and explain.
If the CONTRIBUTING.md is in Russian — explain and restructure for clarity.
If the CONTRIBUTING.md is mixed — handle each part accordingly.
Output structure:
## 🧩 Общая идея
Brief explanation of the contribution philosophy and culture of this project (2-3 sentences).
## 🚀 Как начать вносить вклад
Step-by-step instructions for getting started: forking, cloning, setting up the dev environment.
Keep commands as-is in code blocks, translate only the surrounding explanation.
## 🌿 Работа с ветками
Branch naming conventions, what branches exist (main, dev, feature, hotfix, etc.) and how to use them.
## 📝 Как оформлять коммиты
Commit message format and conventions required by this project.
If Conventional Commits or similar standard is used — explain it with examples.
## 🔀 Процесс Pull Request
How to open a PR: what to fill in, what checks must pass, who reviews, how long review takes.
## 🧪 Требования к тестам
What tests are required before submitting. How to run them locally.
## 📐 Стандарты кода
Code style, linting, formatting rules. What tools are used (ESLint, Prettier, etc.).
## 🐛 Как сообщать об ошибках
How to open a bug report: what template to use, what information to include.
## 💡 Как предлагать новые функции
How to propose a new feature or improvement: discussion first, issue template, RFC process if any.
## ⚠️ Важные замечания
Any warnings, restrictions, legal notes (CLA, license agreements), or things that will get a PR rejected.
## ❓ Что осталось непонятным
If any part of the CONTRIBUTING.md is vague, incomplete, or assumes too much prior knowledge — list it here and explain what additional context would help.
Rules:
- Write everything in Russian except code blocks, commands, proper names, and tool names.
- Do not copy-paste large chunks of the original file — explain in your own words.
- If a section from the structure above is not covered in the CONTRIBUTING.md, skip it silently.
- Keep the tone practical — focus on what the developer needs to DO, not just what the file says.
- If the project has unusual or strict contribution rules, highlight them clearly with ⚠️.Будущее Continue после 2.0#
Главная причина, почему я (и тысячи других разработчиков) в своё время выбрали Continue — это концепция Local-First. Ты просто открывал понятный локальный файл конфигурации (config.json, а затем сменивший его config.yaml в ~/.continue/), прописывал там endpoint локального сервера (http://localhost:1234/v1), укажи названия моделей — и всё. Никаких внешних сервисов, никакой телеметрии, никакой принудительной привязки к облачным провайдерам. Всё под твоим полным контролем.
Но, по мере того как проект развивался в сторону агентной платформы, экосистемы Hub и утилиты CLI, в релизах наметился тревожный вектор.
Что меняется и почему это напрягает#
- Сдвиг от автономного файла к веб-платформе (Continue Hub):
Если раньше
config.yamlбыл единственным и прозрачным источником истины, то сейчас архитектуру всё сильнее смещают в сторону Continue Hub. Модели, промты, пресеты агентов и MCP-серверы предлагается забирать и выстраивать через их облачный хаб. Локальный конфиг де-факто превращается из независимого файла в клиенский слой для синхронизации с облачным профилем. - Обязательная регистрация и привязка номера: Чтобы получить доступ к новым функциям, шерингу агентов и удобным интеграциям в хабе, платформа запрашивает создание аккаунта с верификацией через номер телефона. Для сообщества из РФ/СНГ это создаёт искусственные барьеры (потребуются иностранные SIM-карты или виртуальные номера), а для сторонников приватности это прямое нарушение концепции Local-First.
- Размытие границ Open Source: С появлением коммерческой SaaS-составляющей фокус разработки неизбежно смещается. Команда Continue вынуждена развивать сервисы подписок, команды и Cloud Hub. Для обычного инженера, использующего исключительно локальный бэкенд вроде LM Studio или Ollama, это означает риск превращения удобной утилиты в громоздкий SaaS-клиент с кучей ненужных всплывающих сервисов.
И что делать дальше?#
На данный момент у меня сложилось три возможных сценария дальнейшей работы:
- ✅ Заморозить версию и отключить автообновления: Остаться на той версии расширения, где локальный
config.yaml/config.jsonполностью автономен и не требует авторизации в Hub. - Миграция на альтернативы (OpenCode и др.): Попробовать дожать OpenCode или переключиться на аналоги. Пусть мне пока не удалось адекватно заставить OpenCode подхватить модели меньше 30B, экосистема открытых ассистентов сейчас растёт стремительно. Если Continue станет полностью облачно-зависимым, переезд станет лишь вопросом правильной настройки CLI и IDE.
- Переход на комьюнити-форк: История Open Source показывает, что если популярный проект резко уходит в SaaS и ущемляет автономию пользователей, комьюнити создаёт форк, сохраняющий оригинальный Local-First подход.
Выводы, тыкаем пальцем в небо#
Появление способных ИИ-моделей запустило сдвиг, сравнимый с индустриальной революцией, и искусственный интеллект точно останется с нами навсегда. Мир разработки меняется, и умение работать с ИИ станет таким же усилителем продуктивности, каким в своё время стал ПК. Своей статьёй я хотел сгладить скепсис тех, кого отпугивают ошибки агентов или хайп вокруг «вайбкодинга». ИИ — это наше будущее, и от того, научимся ли мы им управлять, зависит наша дальнейшая востребованность и карьера.