308 lines
32 KiB
Markdown
308 lines
32 KiB
Markdown
# За пределами вайб-кодинга: профессиональные методологии AI-разработки
|
||
|
||
Collins Dictionary назвал "vibe coding" словом года 2025. Наконец-то у нас есть термин для того, что мы все делаем — промптим AI пока код не заработает, фиксим баги по мере их появления, доверяем модели разобраться с деталями.
|
||
|
||
Помню, когда вайб-кодинг означал что-то другое. Теперь этот термин повсюду, и это одновременно хорошо и плохо.
|
||
|
||
Хорошо — потому что он уловил реальное явление. Плохо — потому что он сваливает всю AI-разработку в одну кучу, а у этой кучи негативные коннотации. Непрофессионально. Ненадёжно. Игрушка для джунов, которые не знают лучшего способа.
|
||
|
||
Вот в чём дело: 76% разработчиков используют или планируют использовать AI-инструменты в своём рабочем процессе. Это уже не ниша. Это мейнстрим. Так что либо три четверти индустрии коллективно сошли с ума, либо нарратив "AI-кодинг непрофессионален" что-то упускает.
|
||
|
||
[IMAGE: hero-spectrum.png]
|
||
Type: infographic
|
||
Concept: Визуальный спектр, показывающий прогрессию от "Vibe Coding" на одном конце до "Professional AI Development" на другом, с названиями методологий (Spec-Driven, Agentic, HITL, TDD), расположенными вдоль спектра
|
||
Style: Чистый, современный, абстрактный tech-стиль с цветами бренда Banatie (Indigo #6366F1, Cyan #22D3EE, Dark #0F172A)
|
||
|
||
Реальная проблема — это базовый вопрос, с которым сталкиваются многие разработчики: "Могу ли я использовать AI и при этом оставаться настоящим инженером?"
|
||
|
||
Покажу данные, которые могут удивить. Примерно треть senior-разработчиков — с 10+ годами опыта — генерируют больше половины своего кода с помощью AI. Только 13% junior-разработчиков делают то же самое. Разница в 2.5 раза.
|
||
|
||
Профессионалы используют AI БОЛЬШЕ, чем новички, а не меньше.
|
||
|
||
Разница не в инструменте. Разница в методологии. И об этом эта статья — что идёт после вайб-кодинга. Шесть подходов, которые относятся к AI как к профессиональному инструменту, а не волшебной палочке.
|
||
|
||
---
|
||
|
||
## Вайб-кодинг: точка входа
|
||
|
||
[IMAGE: meme-vibe-coder.png]
|
||
Type: meme / illustration
|
||
Concept: Разработчик за столом с открытым AI-чатом, расслабленная поза, кофе в руке. Подпись: "Работает. Не знаю почему, но работает." Юмористично, но не издевательски.
|
||
Style: Cartoon/illustration стиль, тёплые цвета, понятный девелоперский юмор
|
||
|
||
**Что это:**
|
||
- Популяризировано Андреем Карпатым (февраль 2025)
|
||
- Определение Collins Dictionary: "Метод компьютерного программирования, который в значительной степени полагается на искусственный интеллект"
|
||
- Итеративный промптинг пока код не заработает
|
||
- Никакого предварительного планирования, минимум спецификации
|
||
- Доверяешь AI разобраться с деталями, фиксишь проблемы по мере появления
|
||
|
||
Вайб-кодинг — это не ошибка. Я сам им часто пользовался. Отлично работает для dev-инструментов, которые не пойдут в прод, прототипов, экспериментов, выходных проектов где ставки низкие и просто нужно чтобы что-то работало.
|
||
|
||
Но есть подвох. Он ломается на масштабе. Сложно поддерживать. Невозможно передать другому. Нет документации, нет структуры, качество скачет как попало.
|
||
|
||
И есть аспект безопасности. Исследования показывают, что 45-62% AI-сгенерированного кода содержит уязвимости безопасности. Georgetown CSET обнаружил, что из 21 AI-сгенерированной программы на 5 языках только 5 были изначально безопасны. Veracode и отраслевые отчёты конца 2024 и 2025 годов подтверждают похожие цифры.
|
||
|
||
Это не теоретический риск. 27% компаний запретили AI-инструменты как минимум временно из-за проблем с приватностью и безопасностью. Apple ограничила ChatGPT и Copilot. Amazon забанил ChatGPT после того, как обнаружил ответы, напоминающие внутренние данные. У Samsung сотрудник слил конфиденциальную информацию через ChatGPT.
|
||
|
||
Вайб-кодинг — не проблема. Использование вайб-кодинга для продакшен-систем без методологии — вот это проблема.
|
||
|
||
Так что используют профессионалы вместо этого?
|
||
|
||
---
|
||
|
||
## Spec-Driven Development: сначала структура
|
||
|
||
[IMAGE: infographic-spec-driven.png]
|
||
Type: infographic
|
||
Concept: Сравнение из двух панелей. Слева: "Vibe Coding" — хаотичные стрелки, промптинг туда-сюда, вопросительные знаки. Справа: "Spec-Driven" — чистый поток от Spec-документа → AI-выполнение → Результат. Показывает распределение времени: 80% планирование, 20% выполнение.
|
||
Style: Чистая диаграмма, контрастные цвета для двух подходов
|
||
|
||
**Credentials:**
|
||
- Формализовано командой GitHub Engineering (GitHub Spec Kit)
|
||
- Стало одной из ключевых практик AI-разработки 2025 года (Thoughtworks Technology Radar)
|
||
- Запущено несколько профессиональных инструментов: AWS Kiro, GitHub Spec Kit, Tessl Framework
|
||
- Используется: пользователями Claude Code, enterprise-командами, GitHub Copilot Workspace
|
||
|
||
**Как это работает:**
|
||
|
||
Пишешь детальную спецификацию ДО кода. Спека включает требования, архитектуру, API-контракты, обработку ошибок, edge cases. AI выполняет по спеке. Спека становится живой документацией — часто сохраняется как `CLAUDE.md` или `.spec` файлы в корне проекта.
|
||
|
||
Человек фокусируется на ЧТО. AI разбирается с КАК.
|
||
|
||
Могу подтвердить этот подход из собственной работы. Время на написание спеки часто превышает время на код. Я тратил полдня на спецификацию, а потом смотрел как Claude Code заканчивает имплементацию за 20 минут. Кажется несправедливым, но результаты солидные.
|
||
|
||
Спека становится референсом для будущей работы. Месяцы спустя новая сессия начинается с "прочитай спеку, найди код" — и агент сразу имеет полный контекст.
|
||
|
||
**Сложность:**
|
||
|
||
Спеки расходятся с имплементацией. Архитектура меняется, пути переименовываются, подходы меняются в процессе разработки. Поддержание спеки актуальной добавляет когнитивную нагрузку. Моё решение: коммитить изменения спеки вместе с изменениями кода. Относиться к документации как к части кодовой базы, а не отдельному артефакту.
|
||
|
||
**Pro tip:**
|
||
|
||
Используй Claude Desktop для разработки спеки, а не только для выполнения. Research, brainstorm, найди архитектуру, ПОТОМ пиши спеку. Намного лучше, чем писать спеку в одиночку. Я начал делать это регулярно — AI помогает продумать edge cases, которые я бы сам пропустил.
|
||
|
||
---
|
||
|
||
## Agentic Coding: высокая автономность
|
||
|
||
[IMAGE: illustration-agentic-spectrum.png]
|
||
Type: illustration
|
||
Concept: Шкала/переключатель показывающий уровни автономности. Левая сторона: "Ты за рулём" (человек контролирует всё). Правая сторона: "AI за рулём" (полная автономность). Метки посередине: Pair Programming, HITL, Agentic. Ralph Loop показан на крайнем правом с вопросительным знаком.
|
||
Style: Техническая иллюстрация, чистые линии
|
||
|
||
**Credentials:**
|
||
- Задокументировано в академических исследованиях: arXiv 2508.11126 (август 2025), arXiv 2512.14012 (декабрь 2025)
|
||
- Вариант Ralph Loop создан Джеффри Хантли (май 2025)
|
||
- Инструменты: Claude Code, Cursor Composer, агентные режимы GitHub Copilot Workspace
|
||
- Ralph Loop стал вирусным в январе 2026 (публикация VentureBeat)
|
||
|
||
**Что это:**
|
||
|
||
Агент работает с высокой степенью автономности. Человек ставит высокоуровневые цели, агент разбирается с имплементацией. Агент может планировать, выполнять, дебажить, итерировать без постоянного одобрения.
|
||
|
||
Отличие от вайб-кодинга: агентный кодинг систематичен. Агент создаёт план, выполняет его методично, может корректировать курс. Вайб-кодинг — реактивный промптинг без структуры.
|
||
|
||
**Крайность Ralph Loop:**
|
||
|
||
Названо в честь Ральфа Виггума из Симпсонов. Концепция: даёшь агенту задачу, уходишь, возвращаешься к готовой работе. Джеффри Хантли сообщал о 14-часовых автономных сессиях. Anthropic даже выпустил официальный плагин `ralph-wiggum` от Бориса Черни.
|
||
|
||
Спорно? Определённо.
|
||
|
||
Я хочу верить в Ralph Loop. Идея длительных автономных сессий звучит потрясающе. Но вот мой вопрос: какие задачи оправдывают столько автономной работы?
|
||
|
||
Написание детальной спеки занимает у меня больше времени, чем её выполнение. Если Claude Code заканчивает за 20 минут после того, как я потратил часы на спецификацию, зачем мне 14 часов автономности?
|
||
|
||
Я скептичен насчёт применений в моих проектах. Может это работает для определённых доменов — большие рефакторинги, обширное тестирование, генерация документации по огромным кодовым базам?
|
||
|
||
Если вы нашли отличные применения для Ralph Loop, мне правда интересно. Поделитесь своими победами в комментариях.
|
||
|
||
[IMAGE: meme-ralph-loop.png]
|
||
Type: meme
|
||
Concept: Мем из двух панелей. Панель 1: Разработчик настраивает задачу, уверенно уходит. Панель 2: Возвращается и находит либо (a) идеальный результат, либо (b) полный хаос — оставить неоднозначным какой исход. Подпись: "Ralph Loop: Результаты могут отличаться"
|
||
Style: Простой мем-формат, юмористично
|
||
|
||
**Реальность с permissions:**
|
||
|
||
Агентный кодинг упирается в стену на практике: permissions. Claude Code спрашивает одобрение на каждую запись файла, API-вызов, терминальную команду. Полностью ломает поток. Убивает обещание автономности.
|
||
|
||
Мои обходные пути: прошу Claude добавить все MCP-инструменты в `.claude/settings.json` проактивно — это уменьшает прерывания. Иногда запускаю с `--dangerously-skip-permissions`, но поглядываю что происходит. Ничего такого, что git reset не смог бы исправить.
|
||
|
||
Это развивающаяся UX-проблема, которую инструменты ещё решают. Текущие реализации пока не дотягивают.
|
||
|
||
---
|
||
|
||
## 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: illustration-pair-programming.png]
|
||
Type: illustration
|
||
Concept: Разделённое изображение. Левая сторона: "Автокомплит" — разработчик печатает, AI заканчивает его предложение (реактивно). Правая сторона: "Настоящий Pair Programming" — разработчик и фигура AI смотрят друг на друга, между ними диаграмма архитектуры, обсуждают (проактивный диалог).
|
||
Style: Простая иллюстрация, контраст двух режимов
|
||
|
||
**Где я нахожу настоящий 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: infographic-hitl.png]
|
||
Type: infographic
|
||
Concept: Timeline/flowchart показывающий HITL-подход. AI работает автономно (зелёная зона) → достигает чекпоинта (жёлтый, человек проверяет) → продолжает (зелёный) → финальная проверка (жёлтый). Контраст с: постоянными permission prompts (красный, прерывающий) vs никакого контроля вообще (серый, рискованно).
|
||
Style: Процессная диаграмма, цветовое кодирование зон
|
||
|
||
**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: infographic-tdd-cycle.png]
|
||
Type: infographic
|
||
Concept: Круговая диаграмма показывающая TDD-цикл с AI. Шаг 1: Человек пишет тест (RED). Шаг 2: AI имплементирует чтобы пройти (GREEN). Шаг 3: Человек/AI рефакторят вместе. Стрелка показывает цикл. Примечание: "Тесты = Границы безопасности для AI"
|
||
Style: Круговая процессная диаграмма, цвета светофора (красный/зелёный)
|
||
|
||
**Тесты как спецификация:**
|
||
|
||
Тесты абсолютно важны для ключевого функционала. Я всегда инструктирую агентов запускать тесты.
|
||
|
||
Но вот в чём дело: написание комплексных тестов заранее плюс детальная спека — это уже 80% работы. Если ты написал столько структуры, действительно ли AI экономит время?
|
||
|
||
Наиболее ценно когда у тебя есть существующая спека, которая естественно конвертируется в тесты — как документация на API. Тогда да, tests-first имеет полный смысл.
|
||
|
||
**Подход с guardrails:**
|
||
|
||
Тесты становятся границами безопасности для агента. Агент может свободно итерировать в рамках тестовых ограничений. Не нужно проверять каждую деталь имплементации. Просто верифицируй: тесты проходят, покрытие сохраняется.
|
||
|
||
Особенно ценно для агентного кодинга. Пусть AI экспериментирует, тесты поймают ошибки.
|
||
|
||
**Критическое предупреждение:**
|
||
|
||
AI-написанные тесты требуют человеческой проверки. Я видел как агенты писали "проходящие" тесты используя замоканные запросы — тест проходит, код сломан. Тест верифицировал синтаксис, а не поведение.
|
||
|
||
Правильные тесты = солидный фундамент. Плохие тесты = ложная уверенность, которая разрушает будущую работу.
|
||
|
||
Проверяй логику тестов перед тем как им доверять. Убедись что тесты верифицируют реальное поведение, а не просто что код запускается.
|
||
|
||
---
|
||
|
||
## Ландшафт
|
||
|
||
[IMAGE: summary-landscape.png]
|
||
Type: infographic
|
||
Concept: Итоговый визуал показывающий все 6 методологий, позиционированных по двум осям: Уровень автономности (низкий до высокого) и Уровень структуры (низкий до высокого). Vibe Coding: низкая структура, средняя автономность. Spec-Driven: высокая структура, средняя автономность. Agentic: средняя структура, высокая автономность. Pair Programming: средняя структура, низкая автономность. HITL: средняя структура, средняя автономность. TDD: высокая структура, низкая автономность.
|
||
Style: 2x2 матрица или scatter plot стиль, чистые подписи
|
||
|
||
Вот что существует за пределами вайб-кодинга.
|
||
|
||
Шесть методологий, каждая с серьёзным фундаментом — GitHub Spec Kit, академические статьи, enterprise-внедрение. Не случайные хаки или Twitter-тренды. Реальные подходы с реальной поддержкой.
|
||
|
||
Вайб-кодинг привлёк массовое внимание потому что резонировал. Каждый, кто использовал ChatGPT чтобы что-то отдебажить, узнаёт это чувство "просто промпти пока не заработает." Но это точка входа, а не пункт назначения.
|
||
|
||
Ландшафт богаче чем "вайб vs не вайб." Spec-driven для структуры. Agentic для автономности. Pair programming для коллаборации. HITL для контроля. TDD для качества. Разные инструменты для разных контекстов.
|
||
|
||
И он всё ещё развивается. Ralph Loop появился в прошлом году. Planning Mode относительно новый. Эти методологии будут продолжать развиваться по мере взросления AI-инструментов.
|
||
|
||
**Вопрос легитимности:**
|
||
|
||
Вернёмся к базовому беспокойству: "Непрофессионально ли использовать AI?"
|
||
|
||
Нет. Данные говорят обратное.
|
||
|
||
76% разработчиков используют или планируют использовать AI-инструменты. Примерно треть senior-разработчиков — с 10+ годами опыта — генерируют больше половины своего кода с AI. Только 13% junior-разработчиков делают то же самое. Разница в 2.5 раза.
|
||
|
||
Профессионалы используют AI БОЛЬШЕ, чем новички. Google пишет 25% своего кода с помощью AI. Крупные компании внедрили AI-инструменты для кодинга во всех своих инженерных организациях. Это не непрофессионально. Это новая норма.
|
||
|
||
Но КАК ты это используешь — имеет значение. Вайб-кодинг для продакшен-систем — непрофессионально. Spec-driven с тестами и ревью? Абсолютно профессионально.
|
||
|
||
**Что делает это профессиональным:**
|
||
|
||
Разница не в инструменте. Разница в подходе.
|
||
|
||
Чёткие требования — спека, тесты или фаза планирования. Соответствующий контроль — человеческий ревью, HITL-чекпоинты, шаги верификации. Контроль качества — тесты, линтинг, сканирование безопасности. Поддерживаемость — документация, структура готовая к передаче. Контекстная осведомлённость — понимание когда вайб-кодинга недостаточно.
|
||
|
||
Seniors получают в 2.5 раза больше пользы от тех же AI-инструментов потому что применяют методологию, а не лучшие промпты. Вот какой навык имеет значение.
|
||
|
||
Профессиональный AI-кодинг означает выбор правильного подхода для уровня ставок. Выходной прототип? Вайбь на здоровье. Продакшен платёжная система? Сначала тесты, spec-driven, с ревью.
|
||
|
||
**Что я на самом деле использую:**
|
||
|
||
Dev-инструменты и эксперименты: вайб-кодинг работает нормально.
|
||
Продакшен-фичи: spec-driven с Planning Mode.
|
||
Критические системы: TDD плюс обширный ревью.
|
||
Исследования и изучение: Claude Desktop как настоящий pair programmer.
|
||
|
||
Твой контекст может быть другим. Твои выборы могут быть другими. Это нормально.
|
||
|
||
Смысл не в том, чтобы следовать моему точному воркфлоу. Смысл в том, чтобы знать что выборы существуют за пределами вайб-кодинга, и понимать что предлагает каждая методология.
|
||
|
||
Если ты делаешь что-то по-другому — другие инструменты, другие подходы, другие комбинации — поделись своими победами в комментариях. Что работает для тебя как инженера?
|
||
|
||
Вот что существует. Вот что я использую. Иди посмотри что работает для тебя.
|