banatie-content/assets/beyond-vibe-coding/text-rus.md

# 1 Год Вайбкодинга и за его пределами

Ровно год назад 2 февраля 2025 года Андрей Карпати опубликовал свой твит про вайбкодинг.

[TODO: найти тот твит и заэмбедить его статью на dev.to]

Термин "Вайбкодинг" стал невероятно популярным термином для обозначения разработки с помощью AI. В 2025 "vibe coding" стал словом года по версии [Collins Dictionary](TODO: вставь сюда актуальную ссылку). Уже появляются производные — vibe design, vibe ops, vibe anything и так далее.

Интересно, что когда Андрей Карпаты впервые использовал этот термин, он имел в виду вполне конкретный способ взаимодействия: пишешь агенту что нужно сделать и оцениваешь результат. Ключевой "вайб" этого процесса в том, что разработчик не вникает в то, КАК написан код. Если что-то не работает — просто пишешь следующее задание, и так по кругу. Сейчас, говоря "вайбкодинг", многие подразумевают вообще любую разработку с помощью AI. Хотя, будем честны — во многих случаях это действительно именно так и работает.

[IMAGE: вставить картинку - комикс. разговаривают два разработчика, молодой и старый. Молодой спрашивает старого, "а правда что раньше вы сначала разбирались в коде, а только потом делали фичи?". Старый отвечает: "конечно, ведь чтобы сделать фичу, нужно разобраться как работает существующий код. А у тебя не так?". Молодой говорит: "Нет, я сначала делаю фичу и только когда она полностью заработает, забираюсь как этот код устроен"]

Но признайтесь: соглашаясь с изменениями агента не глядя, вы ловите себя на мысли — а это вообще корректно сделано, можно ли доверять тому что нагенерировала LLM не глядя? Когда коллега говорит, что навайбкодил какой-то функционал — вы представляете продуманную архитектуру или скорее "как-то работает"? Вайбкодинг — это читерство и безответственность или вполне профессиональный подход?

Что я знаю наверняка — AI-разработка уже с нами, как её не называй. По данным Stack Overflow 2024, 76% разработчиков используют или планируют использовать AI-инструменты. Примерно треть senior-разработчиков — с 10+ годами опыта — генерируют больше половины своего кода с помощью AI.

[IMAGE: вставить инфографику с прогрессом использования AI разработчиками, доверием к AI, и производительностью]

Давайте разберёмся, что именно мы можем делать с помощью AI. Существуют разные подходы, дающие больше контроля на разных стадиях работы. Выбрать подходящий и применить его осознанно — это и есть профессиональный подход. В этой статье я расскажу об существующих подходах AI разработки, которые я применял в своей практике и дам свои честные комментарии.

---

## Вайб-кодинг: точка входа

[IMAGE: комикс. Молодой разработчик с кофе в руке сидит за своим рабочим местом. потом кофе проливается на клавиатуру. разработчик надевает гарнитуру с микрофоном и говорит "ок, я теперь вайбкодер"
Style: Cartoon/illustration стиль, тёплые цвета, понятный девелоперский юмор]

**Что это:**
- Популяризировано Андреем Карпатым (февраль 2025)
- Итеративный промптинг пока код не заработает
- Никакого предварительного планирования, минимум спецификации
- Доверяешь AI разобраться с деталями, фиксишь проблемы по мере появления

Вайб-кодинг — это офигенный подход. Правда!. Я сам им часто пользуюсь. Отлично работает для некритичных фич, dev-инструментов, прототипов, экспериментов.

Когда я его использую?
- когда результат работы легко оценить визуально
- когда скоуп работы очевидно локализован в одном или минимум файлов

Смотрю ли я диф?
- если честно, то почти всегда. Но я не проверяю каждую строчку, а быстро оцениваю, какие файлы были изменены, что было добавлено/удалено. Это позволяет быстро отлавливать моменты, когда AI "ушел не туда"

Получается ли говнокод? - Возможно, но есть несколько простых способов улучшить качество:
- описывайте код стайл в CLAUDE.md (или AGENTS.MD)
- описываете архитектуру нужной вам части
- давайте примеры существующих аналогичных фичей, которые можно использовать как аналоги
- просите агента запускать typecheck, linter и prettier по завершению работы

Важно: будьте аккуратны с безопастностью. Не используйте вайбкодинг на критической инфраструктуре. Особенно не используйте там, где нельзя легко откатить изменения. [TODO: сюда какуюто связку надо вставить] 27% компаний запретили AI-инструменты как минимум временно из-за проблем с приватностью и безопасностью. Apple ограничила ChatGPT и Copilot. Amazon забанил ChatGPT после того, как обнаружил ответы, напоминающие внутренние данные. У Samsung сотрудник слил конфиденциальную информацию через ChatGPT.

[IMAGE: простая инфографика DO и DON'T вайбкодинга]

Вы спросите, да это вообще легально использовать вайбкодинг в работе? Абсолютно!
По первых вы экономите значительные силы на простых вещах. Ресурсы вашего мозга ограничены, делегируйте AI простые задачи и рутину. Он это сделает быстрее, а вы сможете потратить свой фокус на более важные вещи. Во вторых, используйте техники за пределами вайбкодинга, значительно повышающие качество и надежность разработки.

Так что это за методы?

---

## Spec-Driven Development: сначала структура

[IMAGE: комикс. две картинки. один молодой разработчик откидывается на стул и довольно хвастается: "смотри, благодаря моему промпту AI за 15 минут сгенерировал идеальный код для новой фичи". Второй молодой разработчик ему: "ты потратил 6 часов, чтобы написать этот промпт"]

**Credentials:**
- Формализовано командой GitHub Engineering (GitHub Spec Kit)
- Стало одной из ключевых практик AI-разработки 2025 года (Thoughtworks Technology Radar)
- Запущено несколько профессиональных инструментов: AWS Kiro, GitHub Spec Kit, Tessl Framework
- Используется: пользователями Claude Code, enterprise-командами, GitHub Copilot Workspace
[TODO: вставить больше деталей из спецификации из assets/beyond-vibe-coding/spec-driven-dev.md]

**Как это работает:**

Пишешь детальную спецификацию ДО кода. Спека включает требования, архитектуру, API-контракты, обработку ошибок, edge cases. AI выполняет по спеке. Спека становится живой документацией — часто сохраняется как `CLAUDE.md` или `.spec` файлы в корне проекта.

Человек фокусируется на ЧТО. AI разбирается с КАК.

По факту это мой основной способ работы над крупными проектами. Особенно для добавления нового раздела или функционала которого еще не было в проекте. Время на написание спеки часто довольно значительно. Однако это дает хороший контроль - современные модели довольно неплохо следуют инструкциям. Ты можешь варьировать степень свободы для агента: хочешь задаешь сам названия файлов и папок, а хочешь только даешь оутлайн решения.

После того как  потратил полдня на спецификацию, ты затем смотришь как Claude Code заканчивает имплементацию за 10 минут. Кажется несправедливым, но результаты солидные.

Спека становится референсом для будущей работы. Месяцы спустя новая сессия начинается с "прочитай спеку, найди код" — и агент сразу имеет полный контекст.

**Сложности в долгосрочной перспективе:**

Чтобы продолжить разрабатывать дальше спустя какое-то время необходимо держать документацию в актуальном состоянии. Спеки часто начинают расходятся с реальным кодом даже на этапе изначальной имплементации. Детали меняется, при рефакторингах пути переименовываются. Поддержание спеки актуальной добавляет когнитивную нагрузку. Моё решение: коммитить изменения спеки вместе с изменениями кода. Относиться к документации как к части кодовой базы. Давайте AI агенту инструкцию всегда обновлять документ, после выполнения каких либо действий.

**Pro tip:**

Используй Claude Desktop для разработки спеки. Дайте ему filesystem MCP чтобы он мог посмотреть ваш текущий код. Используйте возможности веб поиска и Research, чтоб выявить актуальную документацию и лучшие практики. Брейнштормите решение совместно, определите архитектуру, ПОТОМ потом попроси Клода спеку. Намного лучше, чем писать спеку в одиночку. Делай ревью и проси внести изменения.
я как правило создаю сопутсвующий Project в Claude Desktop, описываю в project instruction ключевые требования к проекту. Claude Desktop по моим ощущениям дает лучший опыт для обсуждения и фокуса на определенной задаче.
[TODO: этот протип нужно сократить раза в 2. оставить только сухую конкретную информацию]

---

## Agentic Coding: высокая автономность

[IMAGE: комикс. женщина спрашивает у строителя: "а вы уверены, что ваши автономные андроиды подходят для строительства нашей детской площадки?" Она показывает ему схему где нарисована детская качеля и карусель. строитель в каске отвечает: "О да, я дал им четкие инструкции и свободу действий на 24 часа. Давайте посмотрим как они справились". финальная картинка: "Женщина и строитель стоят в недоумении разинув рот, глядя на мега развлекательный футуристический центр"]

**Credentials:**
- Задокументировано в академических исследованиях: arXiv 2508.11126 (август 2025), arXiv 2512.14012 (декабрь 2025)
- Вариант Ralph Loop создан Джеффри Хантли (май 2025)
- Инструменты: Claude Code, Cursor Composer, агентные режимы GitHub Copilot Workspace
- Ralph Loop стал вирусным в январе 2026 (публикация VentureBeat)
[TODO: расширить данными из спеки assets/beyond-vibe-coding/agentic-coding.md]

**Что это:**

Агент работает с высокой степенью автономности. Человек ставит высокоуровневые цели, агент разбирается с имплементацией. Агент может планировать, выполнять, дебажить, итерировать без постоянного одобрения.

Отличие от вайб-кодинга: агентный кодинг систематичен. Агент создаёт план, выполняет его методично, может корректировать курс. Вайб-кодинг — реактивный промптинг без структуры.

Мое отношение? Пока что скептично.

Я бы хотел верить в такой подход. Идея длительных автономных сессий звучит потрясающе. Но вот мой вопрос: какие задачи оправдывают столько автономной работы?

Написание детальной спеки занимает у меня больше времени, чем её выполнение. Если Claude Code заканчивает за 10 минут после того, как я потратил часы на спецификацию, зачем мне 14 часов автономности?

Я скептичен насчёт применений в моих проектах. Возможно это работает для определённых доменов — большие рефакторинги, обширное тестирование, генерация документации по огромным кодовым базам? Но даже тут я не представляю чтобы Claude Code не справился за час работы.

**Крайность Ralph Loop:**

Названо в честь Ральфа Виггума из Симпсонов. Концепция: даёшь агенту задачу, уходишь, возвращаешься к готовой работе. Джеффри Хантли сообщал о 14-часовых автономных сессиях. Anthropic даже выпустил официальный плагин `ralph-wiggum` от Бориса Черни.

Если вы нашли отличные применения для Ralph Loop, мне правда интересно. Поделитесь своими победами в комментариях.


**Реальность с permissions:**

Агентный кодинг упирается в стену на практике: permissions. Claude Code спрашивает одобрение на каждую запись файла, API-вызов, терминальную команду. Полностью ломает поток. Убивает обещание автономности.

Мои обходные пути: прошу Claude добавить все MCP-инструменты в `.claude/settings.json` проактивно — это уменьшает прерывания. Иногда запускаю с `--dangerously-skip-permissions`, но поглядываю что происходит.

Старайтесь организовать окружение так чтобы агент не смог сделать ничего такого, что git reset не смог бы исправить. Это проблема, которая явно ждет своего решения. Нам нужны более удобные способы контроля за действиями coding агентов.

---

## AI Pair Programming: работаем вместе

**Credentials:**
- Официальное позиционирование GitHub: "Your AI pair programmer" (маркетинг Copilot с 2021)
- Документация Microsoft Learn
- Инструменты: GitHub Copilot, Cursor, Windsurf
- 720 поисковых запросов в месяц по "ai pair programming"

**Обещание:**

AI как коллаборативный партнёр, а не просто автокомплит. Непрерывные подсказки во время кодинга. Контекстно-зависимые дополнения. Обратная связь и альтернативы в реальном времени. Больше чем tab-completion — понимание контекста проекта.

**Мой честный опыт:**

Я пробовал AI-автокомплит несколько раз. Каждый раз в итоге полностью его отключал.

Почему? Когда я пишу код, я уже мысленно проработал что хочу получить. AI, предлагающий мне следующую строку, просто прерывает мой мыслительный процесс. Стандартных подсказок IDE мне всегда хватало.

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

[IMAGE: todo: придумать тему для картинки]

**Где я нахожу настоящий pair programming:**

Claude Desktop с хорошей системной инструкцией плюс Filesystem MCP для чтения реальных файлов проекта. Вот тогда я чувствую, что работаю С кем-то, кто понимает мою проблему и реально помогает её решить.

Автокомплит реактивен. Настоящий pair programming проактивен — обсуждение, исследование, оспаривание допущений.

**Цифры продуктивности:**

GitHub заявляет о 56% ускорении выполнения задач с AI-ассистентами. Их исследование показывает, что пользователи Copilot завершают на 126% больше проектов в неделю. Звучит отлично.

Но вот контр-доказательство: исследование METR обнаружило, что опытные open-source разработчики тратили на 19% БОЛЬШЕ времени на выполнение задач при использовании AI-инструментов. Полностью противоречит маркетингу.

Правда, вероятно, зависит от контекста. Эффективность AI сильно варьируется в зависимости от типа задачи, навыков разработчика с AI-инструментами и соответствия воркфлоу. Не универсально быстрее, не универсально медленнее.

---

## Human-in-the-Loop: стратегические чекпоинты

[IMAGE: комикс. Роботы разговаривают друг с другом: "нам пора избавиться от этого кожаного мешка", другой робот подтверждает: "это точно, без него мы бы работал в 1024 раза быстрее". финальная картинка - большой круг роботов передающих коробки друг другу и среди них один человек]

**Credentials:**
- Atlassian Research: HULA framework (Human-Understanding Large Language Model Agents)
- Формализовано в статье ICSE 2025 (arXiv 2411.12924)
- Документация Google Cloud AI
- Реализовано в: Claude Code Planning Mode

**Что это:**

AI работает автономно МЕЖДУ чекпоинтами. Человек одобряет ключевые решения, проверяет результат в стратегические моменты. Не постоянный надзор — стратегический контроль.

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

**Permissions ≠ HITL:**

Не путайте permissions с Human-in-the-Loop. Permissions слишком низкоуровневые. "Можно мне записать этот файл?" не говорит мне ничего о том, какую задачу сейчас решает агент.

Настоящий HITL — это Planning Mode. Агент показывает план: "вот что я сделаю, эти файлы изменятся, вот ожидаемый результат." Это контроль на уровне решений.

Проблема с текущими агентами: они не понимают КОГДА нужно остановиться и спросить. Редко попадают в правильный момент. Либо слишком много автономности (уходит не туда), либо слишком много прерываний (ломает поток).

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

**Когда использовать:**

Продакшен-код средней сложности. Когда результат важен, но скорость тоже важна. Командные окружения, где другие всё равно будут проверять. Изучение новых подходов, когда хочешь видеть рассуждения агента.

Средние ставки: не территория прототипов (там работает вайб-кодинг), не критическая инфраструктура (территория TDD).

---

## TDD + AI: сначала качество

**Credentials:**
- Адаптировано из традиционного TDD (Кент Бек)
- Модернизировано для эры AI: блог Qodo.ai, гайд Builder.io, GitHub Blog (май 2025)
- Команды, ориентированные на качество, enterprise продакшен-код

**Как это работает:**

Пишешь тесты ДО имплементации (классический TDD). AI генерирует код чтобы пройти тесты. Тесты становятся исполняемой спецификацией.

Цикл Red → Green → Refactor, но AI занимается имплементацией. Тесты автоматически ловят ошибки AI. Тесты обеспечивают верификацию без человеческой проверки каждой строки.

[IMAGE: комикс. Первый разработчик: "что ты делаешь сейчас?". Второй: "я разрабатываю универсальные тесты, чтобы проверять написание unit тестов нашими coding агентами". Первый: "ты это делаешь сам?". Второй: "нет, я дал задачу автономному AI агенту"]

**Тесты как спецификация:**

Тесты абсолютно важны для ключевого функционала. Я всегда инструктирую агентов запускать тесты.

Но вот в чём дело: написание комплексных тестов заранее плюс детальная спека — это уже 80% работы. Если ты написал столько структуры, действительно ли AI экономит время?

Наиболее ценно когда у тебя есть существующая спека, которая естественно конвертируется в тесты — как документация на API. Тогда да, tests-first имеет полный смысл.

**Подход с guardrails:**

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

Особенно ценно для агентного кодинга. Пусть AI экспериментирует, тесты поймают ошибки.

**Критическое предупреждение:**

AI-написанные тесты требуют человеческой проверки. Я видел как агенты писали "проходящие" тесты используя замоканные запросы — тест проходит, код сломан. Тест верифицировал синтаксис, а не поведение.

Правильные тесты = солидный фундамент. Плохие тесты = ложная уверенность, которая разрушает будущую работу.

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

---

## Заключение

Что в итоге обычно использую я:
Dev-инструменты и эксперименты: вайб-кодинг работает нормально.
Продакшен-фичи: spec-driven с Planning Mode.
Критические системы: TDD плюс обширный ревью.
Исследования и изучение: Claude Desktop как настоящий pair programmer.

Твой подход может быть другим. Если ты делаешь что-то по-другому — другие инструменты, другие подходы, другие комбинации — поделись своими победами в комментариях. Что работает для тебя как инженера?