251 lines
30 KiB
Markdown
251 lines
30 KiB
Markdown
# 1 Год Вайбкодинга и за его пределами
|
||
|
||
Ровно год назад, 2 февраля 2025 года, Андрей Карпати опубликовал свой твит про вайбкодинг.
|
||
|
||
https://x.com/karpathy/status/1886192184808149383
|
||
|
||
Термин «Вайбкодинг» стал невероятно популярным для обозначения разработки с помощью AI. В 2025 году "vibe coding" стал [словом года по версии Collins Dictionary](https://www.collinsdictionary.com/us/woty). Уже появляются производные — 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 по завершению работы
|
||
|
||
С другой стороны, есть и подводные камни. 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](https://github.com/github/spec-kit), сентябрь 2025)
|
||
- Вошло в [Thoughtworks Technology Radar](https://www.thoughtworks.com/en-us/radar) Volume 33 (ноябрь 2025)
|
||
- Профессиональные инструменты: [AWS Kiro](https://aws.amazon.com/startups/prompt-library/kiro-project-init) (public preview июль 2025), [Tessl Framework](https://tessl.io/blog/tessl-launches-spec-driven-framework-and-registry/) (closed beta сентябрь 2025)
|
||
- Community-решения: [BMAD Method](https://recruit.group.gmo/engineer/jisedai/blog/the-bmad-method-a-framework-for-spec-oriented-ai-driven-development/) (21 специализированный агент), [OpenSpec](https://mcpmarket.com/server/openspec) (lightweight CLI)
|
||
- Используется: Claude Code, enterprise-команды, GitHub Copilot Workspace
|
||
|
||
**Как это работает:**
|
||
|
||
Пишешь детальную спецификацию ДО кода. Спека включает требования, архитектуру, API-контракты, обработку ошибок, edge cases. AI выполняет по спеке. Спека становится живой документацией — часто сохраняется как `CLAUDE.md` или `.spec` файлы в корне проекта.
|
||
|
||
Человек фокусируется на ЧТО. AI разбирается с КАК.
|
||
|
||
По факту это мой основной способ работы над крупными проектами. Особенно для добавления нового раздела или функционала, которого ещё не было в проекте. Время на написание спеки часто довольно значительно. Однако это даёт хороший контроль — современные модели довольно неплохо следуют инструкциям. Ты можешь варьировать степень свободы для агента: хочешь — задаёшь сам названия файлов и папок, а хочешь — только даёшь аутлайн решения.
|
||
|
||
После того как потратил полдня на спецификацию, ты смотришь как Claude Code заканчивает имплементацию за 10 минут. Кажется несправедливым, но результаты солидные.
|
||
|
||
Спека становится референсом для будущей работы. Месяцы спустя новая сессия начинается с «прочитай спеку, найди код» — и агент сразу имеет полный контекст.
|
||
|
||
**Сложности в долгосрочной перспективе:**
|
||
|
||
Чтобы продолжить разработку спустя какое-то время, необходимо держать документацию в актуальном состоянии. Спеки часто начинают расходиться с реальным кодом даже на этапе изначальной имплементации. Детали меняются, при рефакторингах пути переименовываются. Поддержание спеки актуальной добавляет когнитивную нагрузку. Моё решение: коммитить изменения спеки вместе с изменениями кода. Относиться к документации как к части кодовой базы. Давать AI-агенту инструкцию всегда обновлять документ после выполнения задачи.
|
||
|
||
**Pro tip:**
|
||
|
||
Используй Claude Desktop для разработки спеки: дай ему Filesystem MCP для доступа к коду, включи веб-поиск для актуальной документации. Брейнштормь решение вместе с AI, определи архитектуру — и только потом проси написать спеку.
|
||
|
||
---
|
||
|
||
## Agentic Coding: высокая автономность
|
||
|
||
[IMAGE: комикс. Женщина спрашивает у строителя: «А вы уверены, что ваши автономные андроиды подходят для строительства нашей детской площадки?» Она показывает ему схему, где нарисована детская качеля и карусель. Строитель в каске отвечает: «О да, я дал им чёткие инструкции и свободу действий на 24 часа. Давайте посмотрим как они справились». Финальная картинка: женщина и строитель стоят в недоумении, разинув рот, глядя на мега-футуристический развлекательный центр]
|
||
|
||
**Credentials:**
|
||
- Академические исследования: [arXiv 2508.11126](https://arxiv.org/abs/2508.11126) «AI Agentic Programming: A Survey» (UC San Diego, Carnegie Mellon, август 2025), [arXiv 2512.14012](https://arxiv.org/abs/2512.14012) «Professional Software Developers Don't Vibe, They Control» (University of Michigan, декабрь 2025)
|
||
- Ralph Loop создан Geoffrey Huntley (публичный запуск май 2025, [viral wave январь 2026](https://venturebeat.com/technology/how-ralph-wiggum-went-from-the-simpsons-to-the-biggest-name-in-ai-right-now))
|
||
- Инструменты: Claude Code, [Cursor 2.0 Composer](https://cursor.com/blog/2-0) (октябрь 2025, до 8 параллельных агентов), [GitHub Copilot Agent Mode](https://github.blog/ai-and-ml/github-copilot/agent-mode-101-all-about-github-copilots-powerful-mode/) (preview февраль 2025)
|
||
- Официальный [ralph-wiggum плагин](https://ralph-wiggum.ai) от Anthropic (Boris Cherny)
|
||
|
||
**Что это:**
|
||
|
||
Агент работает с высокой степенью автономности. Человек ставит высокоуровневые цели, агент разбирается с имплементацией. Агент может планировать, выполнять, дебажить, итерировать без постоянного одобрения.
|
||
|
||
Отличие от вайб-кодинга: агентный кодинг систематичен. Агент создаёт план, выполняет его методично, может корректировать курс. Вайб-кодинг — реактивный промптинг без структуры.
|
||
|
||
Моё отношение? Пока что скептичное.
|
||
|
||
Я бы хотел верить в такой подход. Идея длительных автономных сессий звучит потрясающе. Но вот мой вопрос: какие задачи оправдывают столько автономной работы?
|
||
|
||
Написание детальной спеки занимает у меня больше времени, чем её выполнение. Если Claude Code заканчивает за 10 минут после того, как я потратил часы на спецификацию, зачем мне 14 часов автономности?
|
||
|
||
Я скептичен насчёт применений в моих проектах. Возможно это работает для определённых доменов — большие рефакторинги, обширное тестирование, генерация документации по огромным кодовым базам? Но даже тут я не представляю, чтобы Claude Code не справился за час работы.
|
||
|
||
**Крайность Ralph Loop:**
|
||
|
||
Названо в честь Ральфа Виггума из Симпсонов. Концепция: даёшь агенту задачу, уходишь, возвращаешься к готовой работе. Geoffrey Huntley сообщал о 14-часовых автономных сессиях.
|
||
|
||
Если вы нашли отличные применения для Ralph Loop, мне правда интересно. Поделитесь своими победами в комментариях.
|
||
|
||
**Реальность с permissions:**
|
||
|
||
Агентный кодинг упирается в стену на практике: permissions. Claude Code спрашивает одобрение на каждую запись файла, API-вызов, терминальную команду. Полностью ломает поток. Убивает обещание автономности.
|
||
|
||
Мои обходные пути: прошу Claude добавить все MCP-инструменты в `.claude/settings.json` проактивно — это уменьшает прерывания. Иногда запускаю с `--dangerously-skip-permissions`, но поглядываю что происходит.
|
||
|
||
Старайтесь организовать окружение так, чтобы агент не смог сделать ничего такого, что git reset не смог бы исправить. Это проблема, которая явно ждёт своего решения. Нам нужны более удобные способы контроля за действиями coding-агентов.
|
||
|
||
---
|
||
|
||
## AI Pair Programming: работаем вместе
|
||
|
||
[IMAGE: комикс. Программист с наушниками сидит за компьютером. Из наушников вылетают подсказки AI в виде пузырей: «может быть map?», «добавь проверку на null», «тут лучше async». Программист смотрит на них с раздражением. Подпись: «Когда AI знает лучше, но ты хочешь сделать по-своему»]
|
||
|
||
**Credentials:**
|
||
- Официальное позиционирование GitHub: «Your AI pair programmer» (маркетинг Copilot с 2021)
|
||
- Документация Microsoft Learn
|
||
- Инструменты: GitHub Copilot, Cursor, Windsurf
|
||
- 720 поисковых запросов в месяц по «ai pair programming»
|
||
|
||
**Обещание:**
|
||
|
||
AI как коллаборативный партнёр, а не просто автокомплит. Непрерывные подсказки во время кодинга. Контекстно-зависимые дополнения. Обратная связь и альтернативы в реальном времени. Больше чем tab-completion — понимание контекста проекта.
|
||
|
||
**Мой честный опыт:**
|
||
|
||
Я пробовал AI-автокомплит несколько раз. Каждый раз в итоге полностью его отключал.
|
||
|
||
Почему? Когда я пишу код, я уже мысленно проработал что хочу получить. AI, предлагающий мне следующую строку, просто прерывает мой мыслительный процесс. Стандартных подсказок IDE мне всегда хватало.
|
||
|
||
Знаю, что многим разработчикам нравится. Просто не подходит под мой воркфлоу.
|
||
|
||
**Где я нахожу настоящий 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 production-код
|
||
|
||
**Как это работает:**
|
||
|
||
Пишешь тесты ДО имплементации (классический 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.
|
||
|
||
Твой подход может быть другим. Если ты делаешь что-то по-другому — другие инструменты, другие подходы, другие комбинации — поделись своими победами в комментариях. Что работает для тебя как инженера?
|