🧭 Andrej Karpathy

По формулировке Karpathy, vibe coding — это когда ты описываешь желаемый результат на высоком уровне, доверяешь AI написать код целиком и сознательно не вычитываешь каждую строку и каждый шаг. Ты остаёшься в потоке идеи, а не в деталях реализации.

Это не халтура — это осознанный выбор режима работы под конкретную задачу. Ключевое слово «сознательно»: ты заранее решаешь, что для этой задачи вычитка построчно не нужна, потому что цена ошибки низкая и результат легко откатить.

Пример небрежного, но уместного vibe-запроса для быстрого прототипа:

Сделай мне лендинг для идеи стартапа: калькулятор
чаевых с разными настроениями (жадный/щедрый/по-братски).
Пусть будет весело, с анимациями. Не важно как названы
переменные, просто чтобы работало и выглядело прикольно.

Это нормальный промпт — для одноразового прототипа, демо на хакатоне или обучающего эксперимента. Проблема начинается, когда тот же стиль запроса применяют к сервису, который завтра пойдёт в продакшн.

Karpathy проводит жёсткую границу между двумя разными эффектами, которые LLM-агенты оказывают на разработку, и путать их — источник большинства недоразумений вокруг «AI пишет весь код за меня».

Это не два конца одной шкалы «доверия к AI» — это две разные оси с разной аудиторией, разной целью и разными критериями успеха. Смешение этих режимов — когда профессионал работает в стиле «поднятия пола» на задаче, которая требует «поднятия потолка» — и есть корень большинства инцидентов с AI-сгенерированным кодом в проде.

Таблица ниже — рабочий инструмент, а не философия: перед началом задачи с CC реально стоит спросить себя «в каком я сейчас режиме» и свериться со столбцом.

Разделение «пол vs потолок» превращается в практическое правило выбора режима под задачу. Ошибка — не в самом vibe coding, а в применении его там, где нужен другой режим.

Практический тест на переключение режима: если ошибка в этом коде может стоить денег, данных пользователей или репутации — ты уже не в vibe coding, независимо от того, как ты формулировал промпт.

По мысли Karpathy, переход от vibe coding к agentic engineering требует роста в четырёх направлениях одновременно: лучше спецификации, лучше тесты, лучше инфраструктура и лучше суждение (judgment) о том, где агенту доверять, а где — нет. Ни один инструмент не заменяет это автоматически.

Контраст в промптах — та же задача, два режима:

# VIBE CODING (для прототипа — нормально)
"Добавь эндпоинт для смены пароля пользователя"


# AGENTIC ENGINEERING (для продакшн-сервиса — обязательно)
"""
Задача: эндпоинт смены пароля для продакшн API.

Спецификация:
- POST /api/users/{id}/password
- Требует текущий пароль для подтверждения (re-auth)
- Новый пароль: минимум 12 символов, проверка через zxcvbn
- Инвалидировать все текущие сессии кроме текущей после смены
- Rate limit: не более 5 попыток в час на пользователя
- Логировать факт смены (без самого пароля) в audit log

Тесты которые должны пройти (напиши тесты первыми):
- Успешная смена с верным текущим паролем
- Отказ при неверном текущем пароле (401, без утечки в тексте ошибки)
- Отказ при слабом новом пароле с понятным сообщением
- Все остальные сессии становятся невалидными
- Rate limit блокирует 6-ю попытку в течение часа
- SQL-инъекция и XSS в поле пароля не проходят как валидный ввод

После реализации: покажи план изменений и жди подтверждения
перед применением к коду. Не удаляй существующие тесты
аутентификации.
"""

Модель для второго промпта — claude-sonnet-5 с Plan Mode: агент показывает план файлов и изменений до выполнения, а тесты пишутся до реализации, чтобы у агента не было соблазна подогнать код под удобный, а не правильный результат.

Переход — не единовременное решение «теперь я серьёзный инженер», а постепенное наращивание дисциплины по мере роста ставок задачи. Ниже — как это выглядит на практике при работе с CC.