# Как выжать максимум из вайб-кодинга: гид от Y Combinator

Источник: https://www.youtube.com/watch?v=BJjsfNO5JTo
Канал: Y Combinator
Опубликовано: 25.04.2025

---

В последние месяцы индустрия разработки переживает тектонический сдвиг благодаря концепции «вайб-кодинга» (vibe coding) — созданию программных продуктов с помощью искусственного интеллекта на основе текстовых и голосовых запросов. Партнер стартап-акселератора Y Combinator Том поделился результатами своего месячного эксперимента по запуску сайд-проектов в таком режиме, доказав, что этот навык поддается измерению и планомерному улучшению. В данном материале собраны как личные инсайты Тома, так и тактические лайфхаки от фаундеров весеннего батча YC, трансформирующие хаотичный промптинг в системный инженерный процесс.

## 🎸 Феномен «вайб-кодинга» и лайфхаки от фаундеров YC
[[JUMP:0:01]]

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

* **Выход из бесконечных циклов отладки:** Если встроенный ИИ в вашей среде разработки (IDE) застрял и не может исправить баг, один из фаундеров рекомендует скопировать код вручную в веб-интерфейс языковой модели (например, ChatGPT или Claude) и повторить запрос. По его опыту, веб-версии часто находят решения там, где локальная IDE пасует.
* **Параллельная работа в Cursor и Windsurf:** Другой предприниматель советует запускать обе среды разработки одновременно на одном проекте. Он использует Cursor для быстрой работы над фронтендом и фулстек-задачами, а Windsurf — для более сложных, длительных размышлений. Пока один инструмент обрабатывает тяжелый запрос, разработчик переключается на другой, исключая простои. Также можно отправлять одинаковый промпт в обе среды и выбирать лучшую итерацию интерфейса.
* **Программирование на естественном языке:** Один из участников батча предлагает относиться к ИИ как к новому типу языка программирования, где вместо кода используется обычная речь, требующая максимально детального контекста для хорошего результата.
* **Разработка через тестирование (TDD) наоборот:** Фаундер рассказал о практике ручного написания тест-кейсов без участия LLM перед генерацией кода. Это задает жесткие правила (guardrails), в рамках которых ИИ может свободно писать код; когда тесты загораются зеленым, задача считается решена без микроменеджмента кодовой базы.
* **Проектирование до кодинга:** Крайне важно тратить значительное время в «чистой» LLM на проработку архитектуры и рамок (scope) проекта до того, как отдавать его специализированным инструментам вроде Cursor. По мнению фаундера, это предотвращает хаотичную генерацию ИИ неработающего кода.
* **Контроль «кроличьих нор»:** Необходимо отслеживать моменты, когда модель уходит в тупик, бесконечно регенерируя странный код. В таких случаях стоит сделать шаг назад и прямо попросить ИИ проанализировать причины неудачи.

## 🛠️ Выбор стека инструментов и важность планирования
[[JUMP:4:07]]

Том подчеркивает, что выбор инструмента зависит от опыта пользователя: для новичков без навыков программирования отлично подойдут платформы с визуальным интерфейсом, такие как Replit или Lovable. Сегодня многие продакт-менеджеры и дизайнеры создают работающие прототипы в коде напрямую, минуя этап макетов в Figma. Тем не менее, партнер YC отмечает, что подобные low-code инструменты начинают сбоить при усложнении логики бэкенда. Пользователям, имеющим хотя бы базовый или устаревший опыт программирования, Том рекомендует сразу переходить к Cursor, Windsurf или Claude Code.

По мнению спикера, первым шагом работы над проектом должен быть не кодинг, а создание детального плана:

* План разрабатывается совместно с LLM и сохраняется в файле формата Markdown прямо в папке проекта.
* Из черновика следует безжалостно удалять лишнее, явно помечая слишком сложные фичи маркером «won't do» (делать не будем).
* Полезно вести раздел идей «на будущее», чтобы зафиксировать их, но временно исключить из контекста модели.
* Реализация должна происходить строго по разделам (например: «давай делать только секцию 2»), после чего запускаются тесты, фиксируется Git-коммит, а ИИ отмечает пункт в плане как выполненный.

Том считает, что современные модели пока не способны качественно создавать сложные продукты за один запрос (oneshot), поэтому пошаговая сборка остается единственным надежным методом.

## 🔄 Религиозный Git-контроль и высокоуровневые тесты
[[JUMP:6:19]]

Контроль версий — главный союзник вайб-кодера. По признанию Тома, он не доверяет встроенным функциям отмены изменений в ИИ-инструментах и полагается исключительно на Git. Перед созданием любой новой фичи необходимо иметь чистую рабочую копию. Если ИИ зашел в тупик, лучшим решением будет жесткий сброс команды (`git reset --hard`) и повторная попытка.

Спикер предостерегает от многократных последовательных промптов для исправления одной ошибки, так как это приводит к накоплению слоев некачественного кода (craft/crust). Если решение было найдено лишь на пятый или шестой промпт, Том рекомендует скопировать его, сделать `git reset` кодовой базы до чистого состояния и скормить ИИ итоговое решение, чтобы оно было внедрено без лишнего «мусора».

Что касается тестирования, ИИ отлично справляется с написанием тестов, но по умолчанию склонен к низкоуровневым юнит-тестам. Том рекомендует переламывать этот тренд и заставлять модели писать сквозные (end-to-end) интеграционные тесты, имитирующие клики пользователя по сайту. Языковые модели имеют вредную привычку вносить случайные изменения в несвязанную логику. Наличие высокоуровневого тестового покрытия позволяет моментально отлавливать такие регрессии, сбрасывать изменения через Git и начинать заново.

## 🖥️ ИИ в роли DevOps, дизайнера и эксперта по баг-фиксингу
[[JUMP:8:18]]

Возможности ИИ выходят далеко за рамки написания кода. Том успешно делегирует моделям рутинные задачи, которые сам всегда ненавидел. Так, Claude Sonnet 3.7 выступила для него в роли DevOps-инженера: настроила DNS-серверы и развернула хостинг на Heroku через консольную утилиту CLI, что ускорило прогресс примерно в 10 раз. Для создания визуальных элементов партнер YC задействовал ChatGPT, сгенерировав favicon для сайта, после чего Claude написала скрипт для автоматического изменения размера картинки под 6 различных платформ. Таким образом, ИИ закрывает потребности стартапа в дизайне и системном администрировании.

При разборе багов Том использует следующий алгоритм:

* **Прямой копипаст ошибок:** Текст ошибки из логов сервера или JavaScript-консоли браузера отправляется в LLM без дополнительных объяснений. Зачастую этого достаточно для мгновенного исправления. По прогнозу Тома, вскоре ручной копипаст уйдет в прошлое — инструменты кодинга научатся самостоятельно читать логи и тестировать интерфейсы через headless-браузеры.
* **Анализ причин перед кодингом:** Для сложных багов следует просить ИИ расписать 3–4 потенциальные причины неисправности до того, как генерировать код.
* **Сброс после неудачи:** Каждая неудачная попытка исправления должна завершаться командой `git reset`, чтобы избежать накопления программного мусора.
* **Логирование и смена моделей:** Логи — лучшие друзья разработчика. Если одна модель буксует, Том советует переключиться на альтернативу (Claude Sonnet 3.7, модели OpenAI или Gemini), так как они часто сильны в разных аспектах. После нахождения причины сложного бага кодовая база снова сбрасывается, и ИИ получает точечную инструкцию по чистому исправлению.

## 📝 Правила ИИ, локальная документация и новая архитектура
[[JUMP:11:12]]

Эффективность ИИ-агентов многократно возрастает при использовании конфигурационных файлов с инструкциями (`.cursorrules`, правила Windsurf или markdown-файлы Claude). По наблюдениям Тома, некоторые успешные фаундеры составляют инструкции объемом в сотни строк, что кардинально улучшает автономность агентов.

Работа ИИ с онлайн-документацией веб-сервисов до сих пор остается нестабильной. Использование серверов MCP (Model Context Protocol) партнер YC считает избыточным (overkill) для простых задач. Вместо этого он предлагает простой лайфхак: скачать нужную документацию по API целиком в локальную поддиректорию проекта и прописать в инструкциях для ИИ требование обязательно изучить эти локальные файлы перед внедрением функций.

Кроме того, ИИ можно использовать как персонального преподавателя. Попросите модель построчно объяснить сгенерированный код — это, по мнению Тома, намного эффективнее для изучения новых технологий, чем привычный поиск ответов на Stack Overflow.

Сложные или экспериментальные функции спикер рекомендует реализовывать в изолированных репозиториях. Достаточно создать минимальный рабочий пример (reference implementation) или скачать готовый шаблон с GitHub, показать его LLM, а затем поручить ей перенести логику в основной крупный проект.

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

## 🏗️ Секрет Ruby on Rails и свежий бенчмарк нейросетей от YC
[[JUMP:13:13]]

Выбор технологического стека играет решающую роль в качестве работы ИИ. Том выбрал для своего проекта Ruby on Rails, поскольку имел опыт работы с ним в прошлом. Результаты ИИ в написании кода для Rails превзошли все ожидания спикера. По его оценке, причина кроется в том, что Rails — это 20-летний фреймворк со строгими устоявшися конвенциями (conventions). Большинство кодовых баз на Rails похожи друг на друга, и опытному разработчику (как и обученной модели) очевидно, где именно должна лежать конкретная функция. В интернете накоплен огромный массив качественных и единообразных данных для обучения. В то же время знакомые Тома сообщают о гораздо меньшем успехе при попытках использовать вайб-кодинг с языками Rust или Elixir, для которых в сети банально не хватает однородных обучающих выборок.

Спикер также советует использовать мультимодальные возможности: копировать скриншоты в интерфейс ИИ-агентов для демонстрации багов верстки или заимствования чужого дизайна. Для ввода инструкций Том использует инструмент Aqua (портфельная компания YC), который переводит речь в текст непосредственно в рабочей среде. Это позволяет надиктовывать промпты со скоростью 140 слов в минуту, что вдвое быстрее ручного набора. ИИ легко прощает мелкие грамматические ошибки транскрипции. Весь доклад Тома для Startup School был надиктован через Aqua.

В заключение партнер YC призывает к регулярному рефакторингу кодовой базы силами ИИ (что является стандартом для профессиональной разработки) и постоянному экспериментированию с моделями, чья эффективность меняется каждую неделю. Том поделился своим актуальным внутренним рейтингом ИИ-моделей:

* **Gemini** на текущий момент показывает наилучшие результаты при индексации всей кодовой базы проекта и составлении планов реализации фич.
* **Claude Sonnet 3.7** признана спикером безусловным лидером для непосредственного внедрения изменений в код.
* **GPT 4.1** разочаровала эксперта во время недавних тестов, поскольку модель задавала слишком много уточняющих вопросов и регулярно ошибалась в коде. Тем не менее, учитывая темпы развития индустрии, ситуация может измениться уже в ближайшие дни.