В последние месяцы индустрия разработки переживает тектонический сдвиг благодаря концепции «вайб-кодинга» (vibe coding) — созданию программных продуктов с помощью искусственного интеллекта на основе текстовых и голосовых запросов. Партнер стартап-акселератора Y Combinator Том поделился результатами своего месячного эксперимента по запуску сайд-проектов в таком режиме, доказав, что этот навык поддается измерению и планомерному улучшению. В данном материале собраны как личные инсайты Тома, так и тактические лайфхаки от фаундеров весеннего батча YC, трансформирующие хаотичный промптинг в системный инженерный процесс.
🎸 Феномен «вайб-кодинга» и лайфхаки от фаундеров YC 0:01
По определению Тома, вайб-кодинг напоминает феномен промпт-инжиниринга двухлетней давности, когда пользователи еженедельно открывали новые трюки и делились ими в соцсетях. Однако лучшие техники сегодня совпадают с методами, которые используют профессиональные разработчики. На старте весеннего батча YC (YC Spring Batch) фаундеры новых стартапов выделили несколько критически важных приемов взаимодействия с нейросетями:
- Выход из бесконечных циклов отладки: Если встроенный ИИ в вашей среде разработки (IDE) застрял и не может исправить баг, один из фаундеров рекомендует скопировать код вручную в веб-интерфейс языковой модели (например, ChatGPT или Claude) и повторить запрос. По его опыту, веб-версии часто находят решения там, где локальная IDE пасует.
- Параллельная работа в Cursor и Windsurf: Другой предприниматель советует запускать обе среды разработки одновременно на одном проекте. Он использует Cursor для быстрой работы над фронтендом и фулстек-задачами, а Windsurf — для более сложных, длительных размышлений. Пока один инструмент обрабатывает тяжелый запрос, разработчик переключается на другой, исключая простои. Также можно отправлять одинаковый промпт в обе среды и выбирать лучшую итерацию интерфейса.
- Программирование на естественном языке: Один из участников батча предлагает относиться к ИИ как к новому типу языка программирования, где вместо кода используется обычная речь, требующая максимально детального контекста для хорошего результата.
- Разработка через тестирование (TDD) наоборот: Фаундер рассказал о практике ручного написания тест-кейсов без участия LLM перед генерацией кода. Это задает жесткие правила (guardrails), в рамках которых ИИ может свободно писать код; когда тесты загораются зеленым, задача считается решена без микроменеджмента кодовой базы.
- Проектирование до кодинга: Крайне важно тратить значительное время в «чистой» LLM на проработку архитектуры и рамок (scope) проекта до того, как отдавать его специализированным инструментам вроде Cursor. По мнению фаундера, это предотвращает хаотичную генерацию ИИ неработающего кода.
- Контроль «кроличьих нор»: Необходимо отслеживать моменты, когда модель уходит в тупик, бесконечно регенерируя странный код. В таких случаях стоит сделать шаг назад и прямо попросить ИИ проанализировать причины неудачи.
🛠️ Выбор стека инструментов и важность планирования 4:07
Том подчеркивает, что выбор инструмента зависит от опыта пользователя: для новичков без навыков программирования отлично подойдут платформы с визуальным интерфейсом, такие как Replit или Lovable. Сегодня многие продакт-менеджеры и дизайнеры создают работающие прототипы в коде напрямую, минуя этап макетов в Figma. Тем не менее, партнер YC отмечает, что подобные low-code инструменты начинают сбоить при усложнении логики бэкенда. Пользователям, имеющим хотя бы базовый или устаревший опыт программирования, Том рекомендует сразу переходить к Cursor, Windsurf или Claude Code.
По мнению спикера, первым шагом работы над проектом должен быть не кодинг, а создание детального плана:
- План разрабатывается совместно с LLM и сохраняется в файле формата Markdown прямо в папке проекта.
- Из черновика следует безжалостно удалять лишнее, явно помечая слишком сложные фичи маркером «won't do» (делать не будем).
- Полезно вести раздел идей «на будущее», чтобы зафиксировать их, но временно исключить из контекста модели.
- Реализация должна происходить строго по разделам (например: «давай делать только секцию 2»), после чего запускаются тесты, фиксируется Git-коммит, а ИИ отмечает пункт в плане как выполненный.
Том считает, что современные модели пока не способны качественно создавать сложные продукты за один запрос (oneshot), поэтому пошаговая сборка остается единственным надежным методом.
🔄 Религиозный Git-контроль и высокоуровневые тесты 6:19
Контроль версий — главный союзник вайб-кодера. По признанию Тома, он не доверяет встроенным функциям отмены изменений в ИИ-инструментах и полагается исключительно на Git. Перед созданием любой новой фичи необходимо иметь чистую рабочую копию. Если ИИ зашел в тупик, лучшим решением будет жесткий сброс команды (git reset --hard) и повторная попытка.
Спикер предостерегает от многократных последовательных промптов для исправления одной ошибки, так как это приводит к накоплению слоев некачественного кода (craft/crust). Если решение было найдено лишь на пятый или шестой промпт, Том рекомендует скопировать его, сделать git reset кодовой базы до чистого состояния и скормить ИИ итоговое решение, чтобы оно было внедрено без лишнего «мусора».
Что касается тестирования, ИИ отлично справляется с написанием тестов, но по умолчанию склонен к низкоуровневым юнит-тестам. Том рекомендует переламывать этот тренд и заставлять модели писать сквозные (end-to-end) интеграционные тесты, имитирующие клики пользователя по сайту. Языковые модели имеют вредную привычку вносить случайные изменения в несвязанную логику. Наличие высокоуровневого тестового покрытия позволяет моментально отлавливать такие регрессии, сбрасывать изменения через Git и начинать заново.
🖥️ ИИ в роли DevOps, дизайнера и эксперта по баг-фиксингу 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), так как они часто сильны в разных аспектах. После нахождения причины сложного бага кодовая база снова сбрасывается, и ИИ получает точечную инструкцию по чистому исправлению.
📝 Правила ИИ, локальная документация и новая архитектура 11:12
Эффективность ИИ-агентов многократно возрастает при использовании конфигурационных файлов с инструкциями (.cursorrules, правила Windsurf или markdown-файлы Claude). По наблюдениям Тома, некоторые успешные фаундеры составляют инструкции объемом в сотни строк, что кардинально улучшает автономность агентов.
Работа ИИ с онлайн-документацией веб-сервисов до сих пор остается нестабильной. Использование серверов MCP (Model Context Protocol) партнер YC считает избыточным (overkill) для простых задач. Вместо этого он предлагает простой лайфхак: скачать нужную документацию по API целиком в локальную поддиректорию проекта и прописать в инструкциях для ИИ требование обязательно изучить эти локальные файлы перед внедрением функций.
Кроме того, ИИ можно использовать как персонального преподавателя. Попросите модель построчно объяснить сгенерированный код — это, по мнению Тома, намного эффективнее для изучения новых технологий, чем привычный поиск ответов на Stack Overflow.
Сложные или экспериментальные функции спикер рекомендует реализовывать в изолированных репозиториях. Достаточно создать минимальный рабочий пример (reference implementation) или скачать готовый шаблон с GitHub, показать его LLM, а затем поручить ей перенести логику в основной крупный проект.
Вайб-кодинг меняет и подход к проектированию систем. Маленькие файлы и модульность становятся ключевыми факторами успеха. Том прогнозирует глобальный сдвиг от огромных монорепозиториев со сложными внутренними зависимостями к сервисно-ориентированной архитектуре с жесткими границами API. В такой архитектуре ИИ может безопасно менять внутренности модуля, не ломая систему, пока проходят тесты внешних интерфейсов.
🏗️ Секрет Ruby on Rails и свежий бенчмарк нейросетей от YC 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 разочаровала эксперта во время недавних тестов, поскольку модель задавала слишком много уточняющих вопросов и регулярно ошибалась в коде. Тем не менее, учитывая темпы развития индустрии, ситуация может измениться уже в ближайшие дни.
