wip - article
This commit is contained in:
parent
12ee807ebe
commit
fc643f06c2
|
|
@ -2,9 +2,9 @@
|
||||||
slug: beyond-vibe-coding
|
slug: beyond-vibe-coding
|
||||||
title: "Beyond Vibe Coding: Professional AI Development Methodologies"
|
title: "Beyond Vibe Coding: Professional AI Development Methodologies"
|
||||||
author: henry-technical
|
author: henry-technical
|
||||||
status: validation_complete
|
status: drafting
|
||||||
created: 2026-01-22
|
created: 2026-01-22
|
||||||
updated: 2026-01-23
|
updated: 2026-01-24
|
||||||
content_type: explainer
|
content_type: explainer
|
||||||
primary_keyword: "ai coding methodologies"
|
primary_keyword: "ai coding methodologies"
|
||||||
secondary_keywords: ["spec driven development", "ai pair programming", "human in the loop ai", "ralph loop"]
|
secondary_keywords: ["spec driven development", "ai pair programming", "human in the loop ai", "ralph loop"]
|
||||||
|
|
@ -88,7 +88,7 @@ All working files for this article:
|
||||||
| [research-index.md](assets/beyond-vibe-coding/research-index.md) | Methodology clusters, verified sources, interview questions | ✅ Complete |
|
| [research-index.md](assets/beyond-vibe-coding/research-index.md) | Methodology clusters, verified sources, interview questions | ✅ Complete |
|
||||||
| [validation-results.md](assets/beyond-vibe-coding/validation-results.md) | Fact-checking results for all statistical claims | ✅ Complete |
|
| [validation-results.md](assets/beyond-vibe-coding/validation-results.md) | Fact-checking results for all statistical claims | ✅ Complete |
|
||||||
| [log-chat.md](assets/beyond-vibe-coding/log-chat.md) | Activity log and agent comments | ⏳ Needs update |
|
| [log-chat.md](assets/beyond-vibe-coding/log-chat.md) | Activity log and agent comments | ⏳ Needs update |
|
||||||
| [text.md](assets/beyond-vibe-coding/text.md) | Article draft | ⏳ Pending @writer |
|
| [text.md](assets/beyond-vibe-coding/text.md) | Article draft | ✅ Draft complete |
|
||||||
| [seo-metadata.md](assets/beyond-vibe-coding/seo-metadata.md) | SEO title, description, keywords | ⏳ Pending @seo |
|
| [seo-metadata.md](assets/beyond-vibe-coding/seo-metadata.md) | SEO title, description, keywords | ⏳ Pending @seo |
|
||||||
|
|
||||||
## External Research
|
## External Research
|
||||||
|
|
@ -103,4 +103,4 @@ All working files for this article:
|
||||||
|
|
||||||
See [log-chat.md](assets/beyond-vibe-coding/log-chat.md)
|
See [log-chat.md](assets/beyond-vibe-coding/log-chat.md)
|
||||||
|
|
||||||
**Latest:** @architect completed revisions based on @validator feedback (2026-01-23). All false claims removed, citations added. Outline ready for @writer.
|
**Latest:** @writer completed draft (2026-01-24). 2,650 words, 8 image placeholders for @image agent. No code snippets per user request.
|
||||||
|
|
@ -19,6 +19,52 @@
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## @writer. 24 Jan 2026. 10:15
|
||||||
|
|
||||||
|
**Action:** Draft creation
|
||||||
|
|
||||||
|
**Changes:**
|
||||||
|
- Created `text.md` — complete article draft
|
||||||
|
- Moved article from `2-outline/` to `3-drafting/`
|
||||||
|
- Updated main file status to `drafting`
|
||||||
|
|
||||||
|
**Draft details:**
|
||||||
|
- Word count: ~2,650 words
|
||||||
|
- Code snippets: NONE (per user request)
|
||||||
|
- Image placeholders: 8 total
|
||||||
|
|
||||||
|
**Image placeholders added:**
|
||||||
|
1. `hero-spectrum.png` — Infographic: methodology spectrum from vibe to professional
|
||||||
|
2. `meme-vibe-coder.png` — Meme: developer with "it works, I don't know why"
|
||||||
|
3. `infographic-spec-driven.png` — Comparison: vibe coding vs spec-driven flow
|
||||||
|
4. `illustration-agentic-spectrum.png` — Autonomy scale showing methodology positions
|
||||||
|
5. `meme-ralph-loop.png` — Meme: Ralph Loop "results may vary"
|
||||||
|
6. `illustration-pair-programming.png` — Autocomplete vs true pair programming
|
||||||
|
7. `infographic-hitl.png` — Timeline showing HITL checkpoint approach
|
||||||
|
8. `infographic-tdd-cycle.png` — TDD cycle with AI integration
|
||||||
|
9. `summary-landscape.png` — 2x2 matrix of all methodologies by autonomy/structure
|
||||||
|
|
||||||
|
**Voice notes:**
|
||||||
|
- Integrated all interview insights in Henry's voice
|
||||||
|
- Statistics woven naturally (76%, 2.5x difference, etc.)
|
||||||
|
- Honest skepticism about Ralph Loop preserved
|
||||||
|
- Direct, pragmatic tone throughout
|
||||||
|
- No corporate speak, no filler
|
||||||
|
|
||||||
|
**For @editor:**
|
||||||
|
- Check voice consistency with henry-technical style guide
|
||||||
|
- Verify image placeholder descriptions are actionable for @image
|
||||||
|
- Review transitions between sections
|
||||||
|
|
||||||
|
**For @image:**
|
||||||
|
- 9 images needed (hero + 8 in-article)
|
||||||
|
- Mix of: infographics (4), illustrations (2), memes (2), summary visual (1)
|
||||||
|
- Style notes included in each placeholder
|
||||||
|
|
||||||
|
**Next:** @editor review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## 2026-01-22 @strategist — Session 2
|
## 2026-01-22 @strategist — Session 2
|
||||||
|
|
||||||
**Action:** Keyword research & Brief creation
|
**Action:** Keyword research & Brief creation
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,307 @@
|
||||||
|
# За пределами вайб-кодинга: профессиональные методологии 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.
|
||||||
|
|
||||||
|
Твой контекст может быть другим. Твои выборы могут быть другими. Это нормально.
|
||||||
|
|
||||||
|
Смысл не в том, чтобы следовать моему точному воркфлоу. Смысл в том, чтобы знать что выборы существуют за пределами вайб-кодинга, и понимать что предлагает каждая методология.
|
||||||
|
|
||||||
|
Если ты делаешь что-то по-другому — другие инструменты, другие подходы, другие комбинации — поделись своими победами в комментариях. Что работает для тебя как инженера?
|
||||||
|
|
||||||
|
Вот что существует. Вот что я использую. Иди посмотри что работает для тебя.
|
||||||
|
|
@ -1,3 +1,307 @@
|
||||||
# Article Text
|
# Beyond Vibe Coding: Professional AI Development Methodologies
|
||||||
|
|
||||||
*pending — will be written after outline approval*
|
Collins Dictionary named "vibe coding" their Word of the Year for 2025. Finally, we have a term for that thing we all do — prompting AI until the code works, fixing issues as they pop up, trusting the model to handle the details.
|
||||||
|
|
||||||
|
I remember when vibe coding meant something different. Now the term is everywhere, and that's both good and bad.
|
||||||
|
|
||||||
|
Good because it captured a real phenomenon. Bad because it lumps all AI-assisted development into one bucket — and that bucket has negative connotations. Unprofessional. Unreliable. A toy for juniors who don't know better.
|
||||||
|
|
||||||
|
Here's the thing: 76% of developers are using or planning to use AI tools in their development process. That's not a niche anymore. That's mainstream adoption. So either three-quarters of the industry has collectively lost their minds, or the "AI coding is unprofessional" narrative misses something important.
|
||||||
|
|
||||||
|
[IMAGE: hero-spectrum.png]
|
||||||
|
Type: infographic
|
||||||
|
Concept: Visual spectrum showing progression from "Vibe Coding" on one end to "Professional AI Development" on other end, with methodology names (Spec-Driven, Agentic, HITL, TDD) positioned along the spectrum
|
||||||
|
Style: Clean, modern, abstract tech aesthetic with Banatie brand colors (Indigo #6366F1, Cyan #22D3EE, Dark #0F172A)
|
||||||
|
|
||||||
|
The real issue is the underlying question many developers face: "Can I use AI and still be a real engineer?"
|
||||||
|
|
||||||
|
Let me show you some data that might surprise you. About a third of senior developers — those with 10+ years of experience — generate over half their code with AI. Only 13% of junior developers do the same. That's a 2.5x difference.
|
||||||
|
|
||||||
|
Professionals use AI MORE than beginners, not less.
|
||||||
|
|
||||||
|
The difference isn't the tool. It's the methodology. And that's what this article is about — what comes after vibe coding. Six approaches that treat AI as a professional tool, not a magic wand.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Vibe Coding: The Entry Point
|
||||||
|
|
||||||
|
[IMAGE: meme-vibe-coder.png]
|
||||||
|
Type: meme / illustration
|
||||||
|
Concept: Developer at desk with AI chat open, relaxed pose, coffee in hand. Caption: "It works. I don't know why, but it works." Humorous but not mocking.
|
||||||
|
Style: Cartoon/illustration style, warm colors, relatable developer humor
|
||||||
|
|
||||||
|
**What it is:**
|
||||||
|
- Popularized by Andrej Karpathy (February 2025)
|
||||||
|
- Collins Dictionary definition: "A method of computer programming that relies heavily on artificial intelligence"
|
||||||
|
- Iterative prompting until code works
|
||||||
|
- No upfront planning, minimal specification
|
||||||
|
- Trust AI to handle details, fix issues as they appear
|
||||||
|
|
||||||
|
Vibe coding isn't wrong. I've used it plenty. Works great for dev tools that won't hit production, prototypes, experiments, weekend projects where the stakes are low and you just want something working.
|
||||||
|
|
||||||
|
But here's the catch. It breaks down at scale. Hard to maintain. Impossible to hand off. No documentation, no structure, quality all over the place.
|
||||||
|
|
||||||
|
And there's the security angle. Research shows 45-62% of AI-generated code contains security vulnerabilities. Georgetown CSET found that out of 21 AI-generated programs across 5 languages, only 5 were initially secure. Veracode and industry reports from late 2024 and 2025 confirm similar numbers.
|
||||||
|
|
||||||
|
This isn't theoretical risk. 27% of companies have banned AI tools at least temporarily over privacy and security concerns. Apple restricted ChatGPT and Copilot. Amazon banned ChatGPT after discovering responses resembling internal data. Samsung had an employee leak confidential information through ChatGPT.
|
||||||
|
|
||||||
|
Vibe coding isn't the problem. Using vibe coding for production systems without methodology — that's the problem.
|
||||||
|
|
||||||
|
So what do professionals use instead?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Spec-Driven Development: Structure First
|
||||||
|
|
||||||
|
[IMAGE: infographic-spec-driven.png]
|
||||||
|
Type: infographic
|
||||||
|
Concept: Two-panel comparison. Left: "Vibe Coding" - chaotic arrows, back-and-forth prompting, question marks. Right: "Spec-Driven" - clean flow from Spec document → AI execution → Result. Shows time investment: 80% planning, 20% execution.
|
||||||
|
Style: Clean diagram, contrasting colors for the two approaches
|
||||||
|
|
||||||
|
**The credentials:**
|
||||||
|
- Formalized by GitHub Engineering Team (GitHub Spec Kit)
|
||||||
|
- Emerged as one of 2025's key AI-assisted engineering practices (Thoughtworks Technology Radar)
|
||||||
|
- Multiple professional tools launched: AWS Kiro, GitHub Spec Kit, Tessl Framework
|
||||||
|
- Used by: Claude Code users, enterprise teams, GitHub Copilot Workspace
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
Write detailed specification BEFORE code. Spec includes requirements, architecture, API contracts, error handling, edge cases. AI executes against the spec. The spec becomes living documentation — often saved as `CLAUDE.md` or `.spec` files in project root.
|
||||||
|
|
||||||
|
Human focuses on WHAT. AI handles HOW.
|
||||||
|
|
||||||
|
I can confirm this approach from my own work. Time writing spec often exceeds time coding. I've spent half a day on specification, then watched Claude Code finish implementation in 20 minutes. Feels unfair, but the results are solid.
|
||||||
|
|
||||||
|
The spec becomes reference for future work. Months later, new session starts with "read the spec, find the code" — and the agent has full context immediately.
|
||||||
|
|
||||||
|
**The challenge:**
|
||||||
|
|
||||||
|
Specs drift from implementation. Architecture changes, paths rename, approaches shift mid-development. Keeping the spec current adds cognitive load. My solution: commit spec changes alongside code changes. Treat documentation as part of the codebase, not separate artifact.
|
||||||
|
|
||||||
|
**Pro tip:**
|
||||||
|
|
||||||
|
Use Claude Desktop for spec development, not just execution. Research, brainstorm, find architecture, THEN write spec. Much better than solo spec writing. I've started doing this consistently — the AI helps me think through edge cases I'd miss on my own.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Agentic Coding: High Autonomy
|
||||||
|
|
||||||
|
[IMAGE: illustration-agentic-spectrum.png]
|
||||||
|
Type: illustration
|
||||||
|
Concept: Scale/dial showing autonomy levels. Left side: "You drive" (human controls everything). Right side: "AI drives" (full autonomy). Middle markers: Pair Programming, HITL, Agentic. Ralph Loop shown at extreme right with a question mark.
|
||||||
|
Style: Technical illustration, clean lines
|
||||||
|
|
||||||
|
**The credentials:**
|
||||||
|
- Documented in academic research: arXiv 2508.11126 (August 2025), arXiv 2512.14012 (December 2025)
|
||||||
|
- Ralph Loop variant created by Geoffrey Huntley (May 2025)
|
||||||
|
- Tools: Claude Code, Cursor Composer, GitHub Copilot Workspace agent modes
|
||||||
|
- Ralph Loop went viral January 2026 (VentureBeat coverage)
|
||||||
|
|
||||||
|
**What it is:**
|
||||||
|
|
||||||
|
Agent operates with high degree of autonomy. Human sets high-level goals, agent figures out implementation. Agent can plan, execute, debug, iterate without constant approval.
|
||||||
|
|
||||||
|
Different from vibe coding: agentic coding is systematic. Agent creates a plan, executes it methodically, can course-correct. Vibe coding is reactive prompting with no structure.
|
||||||
|
|
||||||
|
**The Ralph Loop extreme:**
|
||||||
|
|
||||||
|
Named after Ralph Wiggum from The Simpsons. The concept: give agent a task, walk away, return to finished work. Geoffrey Huntley reported 14-hour autonomous sessions. Anthropic even released an official `ralph-wiggum` plugin by Boris Cherny.
|
||||||
|
|
||||||
|
Controversial? Absolutely.
|
||||||
|
|
||||||
|
I want to believe in Ralph Loop. The idea of extended autonomous sessions sounds amazing. But here's my question: what tasks justify that much autonomous work?
|
||||||
|
|
||||||
|
Writing a detailed spec takes me longer than executing it. If Claude Code finishes in 20 minutes after I've spent hours on specification, why would I need 14 hours of autonomy?
|
||||||
|
|
||||||
|
I'm skeptical about use cases in my projects. Maybe it works for certain domains — large refactors, extensive testing, documentation generation across huge codebases?
|
||||||
|
|
||||||
|
If you've found great Ralph Loop applications, genuinely curious. Share your wins in comments.
|
||||||
|
|
||||||
|
[IMAGE: meme-ralph-loop.png]
|
||||||
|
Type: meme
|
||||||
|
Concept: Two-panel meme. Panel 1: Developer sets up task, walks away confidently. Panel 2: Returns to find either (a) perfect result, or (b) complete chaos — leave it ambiguous which outcome. Caption: "Ralph Loop: Results may vary"
|
||||||
|
Style: Simple meme format, humorous
|
||||||
|
|
||||||
|
**The permissions reality:**
|
||||||
|
|
||||||
|
Agentic coding hits a wall in practice: permissions. Claude Code asking approval for every file write, API call, terminal command. Breaks flow completely. Defeats the autonomy promise.
|
||||||
|
|
||||||
|
My workarounds: I ask Claude to add all MCP tools to `.claude/settings.json` proactively — that reduces interruptions. Sometimes I run with `--dangerously-skip-permissions` but keep an eye on what's happening. Nothing git reset can't fix.
|
||||||
|
|
||||||
|
This is an evolving UX challenge that tools are still figuring out. Current implementations aren't quite there yet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AI Pair Programming: Working Together
|
||||||
|
|
||||||
|
**The credentials:**
|
||||||
|
- GitHub official positioning: "Your AI pair programmer" (Copilot marketing since 2021)
|
||||||
|
- Microsoft Learn documentation
|
||||||
|
- Tools: GitHub Copilot, Cursor, Windsurf
|
||||||
|
- 720 monthly searches for "ai pair programming"
|
||||||
|
|
||||||
|
**The promise:**
|
||||||
|
|
||||||
|
AI as collaborative partner, not just autocomplete. Continuous suggestions during coding. Context-aware completions. Real-time feedback and alternatives. More than tab completion — understanding project context.
|
||||||
|
|
||||||
|
**My honest experience:**
|
||||||
|
|
||||||
|
I've tried AI autocomplete multiple times. Each time, I ended up disabling it completely.
|
||||||
|
|
||||||
|
Why? When I'm writing code, I've already mentally worked out what I want. The AI suggesting my next line just interrupts my thought process. Standard IDE completions always worked fine for me.
|
||||||
|
|
||||||
|
I know many developers love it. Just doesn't fit my workflow.
|
||||||
|
|
||||||
|
[IMAGE: illustration-pair-programming.png]
|
||||||
|
Type: illustration
|
||||||
|
Concept: Split image. Left side: "Autocomplete" - developer typing, AI finishing their sentence (reactive). Right side: "True Pair Programming" - developer and AI figure facing each other, discussing architecture diagram between them (proactive dialogue).
|
||||||
|
Style: Simple illustration, contrasting the two modes
|
||||||
|
|
||||||
|
**Where I find real pair programming:**
|
||||||
|
|
||||||
|
Claude Desktop with good system instructions plus Filesystem MCP to read actual project files. That's when I feel like I'm working WITH someone who understands my problem and helps solve it.
|
||||||
|
|
||||||
|
Autocomplete is reactive. Real pair programming is proactive — discussion, exploration, questioning assumptions.
|
||||||
|
|
||||||
|
**The productivity numbers:**
|
||||||
|
|
||||||
|
GitHub claims 56% faster task completion with AI assistants. Their study shows Copilot users complete 126% more projects per week. Sounds great.
|
||||||
|
|
||||||
|
But here's the counter-evidence: METR study found experienced open-source developers took 19% LONGER to complete tasks when using AI tools. Contradicts the marketing entirely.
|
||||||
|
|
||||||
|
The truth is probably context-dependent. AI effectiveness varies wildly by task type, developer skill with AI tools, and workflow fit. Not universally faster, not universally slower.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Human-in-the-Loop: Strategic Checkpoints
|
||||||
|
|
||||||
|
[IMAGE: infographic-hitl.png]
|
||||||
|
Type: infographic
|
||||||
|
Concept: Timeline/flowchart showing HITL approach. AI works autonomously (green zone) → hits checkpoint (yellow, human reviews) → continues (green) → final review (yellow). Contrast with: constant permission prompts (red, interrupting) vs no oversight at all (gray, risky).
|
||||||
|
Style: Process diagram, color-coded zones
|
||||||
|
|
||||||
|
**The credentials:**
|
||||||
|
- Atlassian Research: HULA framework (Human-Understanding Large Language Model Agents)
|
||||||
|
- Formalized in ICSE 2025 paper (arXiv 2411.12924)
|
||||||
|
- Google Cloud AI documentation
|
||||||
|
- Implemented in: Claude Code Planning Mode
|
||||||
|
|
||||||
|
**What it is:**
|
||||||
|
|
||||||
|
AI operates autonomously BETWEEN checkpoints. Human approves key decisions, reviews output at strategic moments. Not constant supervision — strategic oversight.
|
||||||
|
|
||||||
|
Agent proposes approach, human confirms direction. Then agent executes freely until next checkpoint.
|
||||||
|
|
||||||
|
**Permissions ≠ HITL:**
|
||||||
|
|
||||||
|
Don't confuse permissions with Human-in-the-Loop. Permissions are too low-level. "Can I write this file?" tells me nothing about what the agent is actually solving.
|
||||||
|
|
||||||
|
Real HITL is Planning Mode. Agent shows the plan: "here's what I'll do, these files will change, here's the expected outcome." That's decision-level control.
|
||||||
|
|
||||||
|
The problem with current agents: they don't understand WHEN to stop and ask. Rarely hits the right moment. Either too much autonomy (goes off track) or too many interruptions (breaks flow).
|
||||||
|
|
||||||
|
Future improvement area: agents that know when they're uncertain and should consult human. Like "I don't know" responses — current models aren't good at this in practice.
|
||||||
|
|
||||||
|
**When to use:**
|
||||||
|
|
||||||
|
Production code with moderate complexity. When outcome matters but speed also matters. Team environments where others will review anyway. Learning new approaches where you want to see the agent's reasoning.
|
||||||
|
|
||||||
|
Medium stakes: not prototype territory (vibe coding works there), not critical infrastructure (TDD territory).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## TDD + AI: Quality First
|
||||||
|
|
||||||
|
**The credentials:**
|
||||||
|
- Adapted from traditional TDD (Kent Beck)
|
||||||
|
- Modernized for AI era: Qodo.ai blog, Builder.io guide, GitHub Blog (May 2025)
|
||||||
|
- Quality-focused teams, enterprise production code
|
||||||
|
|
||||||
|
**How it works:**
|
||||||
|
|
||||||
|
Write tests BEFORE implementation (classic TDD). AI generates code to pass tests. Tests become executable specification.
|
||||||
|
|
||||||
|
Red → Green → Refactor cycle, but AI handles the implementation. Tests catch AI mistakes automatically. Tests provide verification without human review of every line.
|
||||||
|
|
||||||
|
[IMAGE: infographic-tdd-cycle.png]
|
||||||
|
Type: infographic
|
||||||
|
Concept: Circular diagram showing TDD cycle with AI. Step 1: Human writes test (RED). Step 2: AI implements to pass (GREEN). Step 3: Human/AI refactor together. Arrow showing the loop. Note: "Tests = Safety boundaries for AI"
|
||||||
|
Style: Circular process diagram, traffic light colors (red/green)
|
||||||
|
|
||||||
|
**Tests as specification:**
|
||||||
|
|
||||||
|
Tests are absolutely important for key functionality. I always instruct agents to run tests.
|
||||||
|
|
||||||
|
But here's the thing: writing comprehensive tests upfront plus detailed spec — that's already 80% of the work. If you've written that much structure, is the AI really saving time?
|
||||||
|
|
||||||
|
Most valuable when you have existing spec that converts to tests naturally — like API documentation. Then yes, tests-first makes perfect sense.
|
||||||
|
|
||||||
|
**The guardrails approach:**
|
||||||
|
|
||||||
|
Tests become safety boundaries for the agent. Agent can iterate freely within test constraints. No need to review every implementation detail. Just verify: tests pass, coverage maintained.
|
||||||
|
|
||||||
|
Especially valuable for agentic coding. Let the AI experiment, tests catch the mistakes.
|
||||||
|
|
||||||
|
**Critical warning:**
|
||||||
|
|
||||||
|
AI-written tests need human review. I've seen agents write "passing" tests using mocked requests — test passes, code is broken. The test verified syntax, not behavior.
|
||||||
|
|
||||||
|
Correct tests = solid foundation. Bad tests = false confidence that destroys future work.
|
||||||
|
|
||||||
|
Review test logic before trusting it. Make sure tests verify actual behavior, not just that code runs.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Landscape
|
||||||
|
|
||||||
|
[IMAGE: summary-landscape.png]
|
||||||
|
Type: infographic
|
||||||
|
Concept: Summary visual showing all 6 methodologies positioned by two axes: Autonomy level (low to high) and Structure level (low to high). Vibe Coding: low structure, medium autonomy. Spec-Driven: high structure, medium autonomy. Agentic: medium structure, high autonomy. Pair Programming: medium structure, low autonomy. HITL: medium structure, medium autonomy. TDD: high structure, low autonomy.
|
||||||
|
Style: 2x2 matrix or scatter plot style, clean labels
|
||||||
|
|
||||||
|
So that's what exists beyond vibe coding.
|
||||||
|
|
||||||
|
Six methodologies, each with serious foundation — GitHub Spec Kit, academic papers, enterprise adoption. Not random hacks or Twitter trends. Real approaches with real backing.
|
||||||
|
|
||||||
|
Vibe coding caught mainstream attention because it resonated. Everyone who's used ChatGPT to debug something recognizes that feeling of "just prompt until it works." But it's the entry point, not the destination.
|
||||||
|
|
||||||
|
The landscape is richer than "vibe vs not vibe." Spec-driven for structure. Agentic for autonomy. Pair programming for collaboration. HITL for control. TDD for quality. Different tools for different contexts.
|
||||||
|
|
||||||
|
And it's still evolving. Ralph Loop emerged last year. Planning Mode is relatively new. These methodologies will keep developing as AI tools mature.
|
||||||
|
|
||||||
|
**The legitimacy question:**
|
||||||
|
|
||||||
|
Back to the underlying concern: "Is using AI unprofessional?"
|
||||||
|
|
||||||
|
No. The data says otherwise.
|
||||||
|
|
||||||
|
76% of developers are using or planning to use AI tools. About a third of senior developers — those with 10+ years experience — generate over half their code with AI. Only 13% of junior developers do the same. That's a 2.5x difference.
|
||||||
|
|
||||||
|
Professionals use AI MORE than beginners. Google writes 25% of their code with AI. Major companies have adopted AI coding tools across their engineering organizations. That's not unprofessional. That's the new normal.
|
||||||
|
|
||||||
|
But HOW you use it matters. Vibe coding for production systems isn't professional. Spec-driven with tests and review? Absolutely professional.
|
||||||
|
|
||||||
|
**What makes it professional:**
|
||||||
|
|
||||||
|
The difference isn't the tool. It's the approach.
|
||||||
|
|
||||||
|
Clear requirements — spec, tests, or planning phase. Appropriate oversight — human review, HITL checkpoints, verification steps. Quality controls — tests, linting, security scans. Maintainability — documentation, handoff-ready structure. Context awareness — knowing when vibe coding isn't enough.
|
||||||
|
|
||||||
|
Seniors achieve 2.5x more value from the same AI tools because they apply methodology, not better prompts. That's the skill that matters.
|
||||||
|
|
||||||
|
Professional AI coding means choosing the right approach for the stakes. Weekend prototype? Vibe away. Production payment system? Tests first, spec-driven, reviewed.
|
||||||
|
|
||||||
|
**What I actually use:**
|
||||||
|
|
||||||
|
Dev tools and experiments: vibe coding works fine.
|
||||||
|
Production features: spec-driven with Planning Mode.
|
||||||
|
Critical systems: TDD plus extensive review.
|
||||||
|
Research and exploration: Claude Desktop as true pair programmer.
|
||||||
|
|
||||||
|
Your context might be different. Your choices might be different. That's fine.
|
||||||
|
|
||||||
|
The point isn't to follow my exact workflow. The point is knowing that choices exist beyond vibe coding, and understanding what each methodology offers.
|
||||||
|
|
||||||
|
If you're doing something different — different tools, different approaches, different combinations — share your wins in the comments. What's working for you as an engineer?
|
||||||
|
|
||||||
|
This is what exists. This is what I use. Go see what works for you.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue