Сейчас все обсуждают Claude Code, Antigravity, Codex, спорят, коллекционируют “скиллы” для агентов. Но на практике у большинства все ломается на первом шаге: люди пишут “сделай мне приложение” - и получают либо кашу, либо минус лимиты.
Если вы напишете “сделай мне приложение” или “напиши код” - вряд ли вы что-то получите внятное, только лимиты потратите, а уж если вы в Claude Code работаете, то они у вас испарятся с высокой скоростью. А если вы еще и на тарифе за 20$ в месяц, то точно не для больших проектов, скорее больше для теста, а 100-200$ в месяц звучит уже более реалистично. Поэтому многие выбирают Codex от OpenAI или Antigravity от Google как более дешевые альтернативы.
Вайбкодинг работает, когда вы управляете процессом, а не просите сразу все. Базовый рабочий пайплайн простой:
спецификация → план → маленькие итерации → тесты/ревью → фиксация изменений (git)
Ниже — тот самый скелет, который можно повторить почти для любого проекта.
1) Не просите код сразу. Сначала - спецификация
Сначала опишите идею и попросите LLM задавать вопросы, пока вы не согласуете требования и крайние случаи. На выходе вам нужен документ: что делаем, что не делаем, ограничения, риски, тест-подход.
Сохраните это все в специальный файл spec.md и сохраняем- это наша спецификация.
Пример минимального spec.md (очень короткий):
# spec.md — Mini (MVP)
## Goal
CLI-утилита, которая читает CSV и делает сводку (кол-во строк, пустые поля, топ-значения по колонке).
## Inputs/Outputs
- Input: path to .csv
- Output: stdout + опционально report.json
## Constraints
- Python 3.11
- Без pandas (только csv модуль)
- Память: файл может быть до 500MB (стриминг)
## Edge cases
- Ра��ные разделители (, ; \t)
- Кавычки, переносы строк внутри полей
- Пустые строки / битые строки → логируем и продолжаем
## Tests (минимум)
- маленький CSV (happy path)
- CSV с пустыми значениями
- CSV с “битой” строкой2) Делаем план проекта.
Скармливаем spec.md в LLM и просим ее сгенерировать план проекта: разбить реализацию на логичные, небольшие задачи или этапы. Я для этого использую ChatGPT 5.2 Thinking, в редких случаях 5.1 Thinking. Вы можете приспособить для этого дела любую думающую модель LLM. Наличие четкого ТЗ и плана означает, что ИИ не будет додумывать за вас и добавлять от себя, а будет следовать общей договоренности и ограничениям.
3) Разбиваем работу на маленькие шаги (тикеты), и решаем поэтапно.
Если сразу делать фундаментальные запросы к ИИ, это ведет к сбою в работе модели и путанице.
4) Даем Контекст и ограничения.
ИИ должен видеть:
какие файлы менять,
на какие части кода ссылаться,
версии/архитектурные запреты,
“подводные камни” проекта,
и “как принято” в команде.
В этом плане подключение репо GitHub в Codex и Claude Code очень удобно, можно подтягивать контекст из проекта. Еще нужны ограничения проекта (версии, архитектура, правила, что нельзя), какие подводные камни (где раньше ломалось, какие есть нюансы), предпочтительные подходы (как уже принято в команде). А если нужны актуальные доки библиотек, можно еще MCP подключать, или просто вставлять куски доки вручную.
MCP (Model Context Protocol) - это способ подключить к модели внешние источники/инструменты (например, актуальную документацию библиотек или внутренние файлы) так, чтобы она опиралась на них, а не гадала по памяти.
5) Подбираем модель под задачу, а лучше несколько.
Одна лучше в кодинге, другая в объяснении, третья в рефакторинге или анализе логов. А еще можно дать одной модели проверить вывод другой, чтобы поймать ошибки, слепые зоны и получить второе мнение.
6) Подключаем агентные инструменты (CLI/IDE), когда есть спека и план.
Claude Code, Codex, Antigravity - это инструменты, которые удобно применять после того, как у вас есть spec.md и план тикетов. Тогда агент:
читает файлы проекта,
делает изменения итеративно,
запускает тесты,
и исправляет ошибки по результатам.
Без спеки и тикетов агент часто галлюцинирует и делает не то.
Claude Code, Antigravity, Codex - ИИ-агенты, ИИ-CLI или инструменты командной строки, с которыми вы можете общаться напрямую в каталоге вашего проекта, они могут читать файлы, запускать тесты и даже исправлять ошибки в несколько этапов. Они ускоряют механику: генерацию шаблонного кода, внесение повторяющихся изменений, автоматический запуск тестов.
7) Тесты и контроль качества на каждом шаге.
Можно еще составить список тестов или план тестирования для каждого шага, тем более, если используете Claude Code, даете ему указание запустить набор тестов после выпо��нения задачи и отлаживать ошибки, если таковые возникнут. Код тоже лучше проверять, можно даже в другую ии вставить и проверить.
8) Коммиты (save points)
Это ваши точки сохранения, позволяющие исправлять ошибки ИИ и понимать изменения. Если вы что-то поменяли в файлах и по тестам все ок, делаете commit, и Git запоминает: что изменилось, когда и зачем (с вашим комментарием). Так можно откатиться назад, если что-то пошло не так, посмотреть историю изменений, передать изменения другим (через GitHub/GitLab), аккуратно разделять работу на шаги. Для экспериментов с агентом удобно делать отдельную ветку (или worktree), чтобы не мешать стабильный код с экспериментальным.
9) Нужны Правила для модели (чтобы не повторять одно и то же)
заводим файл-инструкцию проекте: стиль, линтеры, запреты/ ограничения, как принято в команде, команды для тестов/сборки. У разных инструментов это может называться по-разному (например, CLAUDE.md, GEMINI.md и т.п.).
Если кратко: вайбкодинг — это не дай мне приложение, а управляемый цикл: спека → план → тикеты → контекст → тесты → коммиты. Тогда Claude Code, Codex, Antigravity реально ускоряют работу, а не увеличивают хаос.
Про отдельные инструменты и как упаковывать контекст (включая MCP-серверы и шаблоны промптов под агента) разберу продолжением у себя в телеграм-канале, кстати, там много полезного.
