На прошлой неделе Саймон Уиллисон — создатель Datasette и один из самых авторитетных голосов в мире ИИ-инструментов — признался в том, что вслух говорят немногие: он перестал проверять код, который пишет Claude Code. Не потому что стало лень, а потому что код правильный. И это его пугает. Вайб-кодинг, который мы привыкли считать забавой для непрограммистов, и серьёзная агентная инженерия, основанная на 25-летнем опыте, начали сливаться. И никто толком не понимает, что с этим делать.

Что такое vibe coding и чем он отличается от агентной инженерии

Vibe coding (вайб-кодинг) — это стиль работы с ИИ, при котором вы просите модель написать код, не вчитываясь в результат. Если работает — отлично, если нет — просите исправить. Термин популяризировал Андрей Карпаты в начале 2025 года, и с тех пор он стал чем-то вроде ярлыка для «несерьёзного» ИИ-программирования.

Агентная инженерия (agentic engineering) — это то, чем занимаются профессиональные разработчики с ИИ-помощниками. Вы понимаете архитектуру, безопасность, производительность. ИИ выступает как усилитель вашего опыта: вы направляете, он генерирует, вы проверяете. Ключевое слово — проверяете.

Уиллисон сам провёл границу между этими подходами в марте 2025 года, написав эссе «Not all AI-assisted programming is vibe coding». Его аргумент был прост: vibe coding прекрасен для личных проектов, где баг навредит только вам. Но для продакшена, где от вашего кода зависят другие люди, — это безответственность.

Когда граница начала размываться

В подкасте High Leverage Уиллисон рассказал о моменте, который его обеспокоил. Он поймал себя на том, что при работе с Claude Code над продакшен-проектами больше не проверяет каждую строчку. Раньше разница была чёткой: vibe coding — не смотришь на код, агентная инженерия — проверяешь всё. Теперь? Он просит Claude Code написать JSON API endpoint с SQL-запросом, тот добавляет тесты и документацию, и Уиллисон просто знает, что всё сделано правильно.

Это не наивная доверчивость. За 25 лет в индустрии он выработал стандарты качества, и Claude Code стабильно им соответствует. Проблема в другом: модель не несёт ответственности. У неё нет «профессиональной репутации», которую можно было бы разрушить плохой работой. Она просто раз за разом выдаёт хороший код — пока однажды не выдаст плохой.

Уиллисон проводит параллель с работой в крупных компаниях: когда другая команда отдаёт вам сервис для работы с изображениями, вы не читаете каждую строчку их кода. Вы читаете документацию, используете API и идёте дальше. Если что-то ломается — вот тогда лезете в репозиторий. С ИИ-агентами происходит то же самое: они становятся «командой», которой вы доверяете по умолчанию.

Нормализация отклонений — скрытая ловушка

Уиллисон ссылается на концепцию «нормализации отклонений» (normalization of deviance) — термин, пришедший из авиационной безопасности. Суть: каждый раз, когда вы нарушаете правило и ничего не ломается, ваш мозг нормализует это нарушение. Пилот садился в плохую погоду 20 раз и ничего не случилось? Значит, можно и в 21-й. До тех пор, пока не случится.

С ИИ-кодингом то же самое. Каждый раз, когда вы не проверяете сгенерированный код и он работает, вы ослабляете внутренний контроль. И в какой-то момент агент выдаст код с уязвимостью, а вы его не заметите — потому что уже привыкли не смотреть.

Новая проблема: как оценить качество ПО, если код пишет ИИ

Вторая часть озарения Уиллисона касается того, как мы вообще оцениваем качество программного обеспечения. Раньше всё было просто: GitHub-репозиторий со ста коммитами, красивым README и автотестами — признак вдумчивой работы. Сейчас он может сгенерировать такой же репозиторий за полчаса. Внешне неотличимо.

Даже для собственных проектов Уиллисон уже не может определить по коду, насколько он качественный. Решение, к которому он пришёл, элегантно в своей простоте: важен не код, а использование. Если кто-то vibecode-ил инструмент и пользовался им две недели каждый день — это ценнее, чем идеально оформленный проект, который никто не открывал.

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

Узкие горлышки сместились — и это меняет всё

Если раньше разработчик писал 200 строк кода в день, а теперь может 2000 — что ещё ломается в процессе разработки? Уиллисон указывает, что весь цикл разработки ПО — от проектирования до деплоя — был рассчитан на медленную скорость генерации кода. Когда код пишётся в 10 раз быстрее, дизайн-процессы, код-ревью, тестирование, CI/CD — всё становится узким горлышком.

Особенно интересный пример — из мира дизайна. Дженни Вэнь, руководитель дизайна в Anthropic, рассказывала, как традиционные дизайн-процессы построены вокруг идеи «сделай правильно с первого раза, потому что инженерам понадобится три месяца на реализацию». Но если реализация занимает три дня, а не три месяца, весь тяжеловесный процесс проектирования можно упростить. Ошибка стоит дешевле — а значит, можно позволить себе больше экспериментов.

Это касается не только дизайна. Код-ревью, который раньше занимал полдня, теперь может превратиться в многочасовую марафонскую сессию, потому что пулл-реквест содержит не 50, а 500 изменений. Системы непрерывной интеграции, рассчитанные на десятки прогонов в день, вдруг получают сотни. Архитектурные решения, которые раньше принимались на недельных встречах, нужно принимать за часы — потому что ИИ-агент уже написал три варианта реализации и ждёт вашего выбора.

Практический вывод: самое ценное, что может сделать команда прямо сейчас — пересмотреть свои процессы с учётом скорости генерации кода. Если ваш код-ревью всё ещё рассчитан на 200 строк в день, а приходит 2000, — не ругайте разработчиков за «слишком большие» PR. Измените сам формат ревью. Возможно, имеет смысл проверять не код, а спецификацию, которую вы дали ИИ-агенту, и тесты, которые он написал.

Почему профессия в безопасности — но ненадолго

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

Уже сейчас видно, как это происходит. Инструменты вроде Claude Code, Cursor, Copilot Workspace не просто генерируют код — они создают целые файловые структуры, пишут тесты, документацию, конфигурации CI/CD. Роль человека смещается от «напиши функцию» к «опиши, что должна делать система, и проверь, что она это делает». Это качественно иной навык, и он требует не меньше, а больше экспертизы — просто другого рода.

Уиллисон не боится за свою карьеру, и вот почему: он смотрит на свои диалоги с ИИ-агентами и понимает, что для неподготовленного человека это «лунный язык». Модели — усилители существующего опыта. Если вы знаете, что делаете, с ИИ вы летите. Если нет — вы просто быстрее генерируете плохой код.

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

Метафора Уиллисона точная: «Я могу проложить трубы в доме, если посмотрю достаточно видео на YouTube. Но я лучше найму сантехника». Ровно то же самое с ИИ-кодингом: непрофессионал может собрать работающий прототип, но для надёжной системы по-прежнему нужен профессионал.

Что делать прямо сейчас

Практический вывод из наблюдений Уиллисона не в том, чтобы перестать доверять ИИ, и не в том, чтобы проверять каждую строку. Истина где-то посередине, и она зависит от контекста.

Для личных инструментов и прототипов — vibecode сколько влезет. Ошибки будут, но цена их невелика. Для продакшена — установите чёткие границы доверия: рутинные операции (CRUD-эндпоинты, мидлвары, типовые SQL-запросы) можно делегировать без проверки, а вот бизнес-логику, авторизацию и работу с деньгами — проверяйте как раньше.

Самое полезное, что можно сделать: тестируйте свои инструменты в реальной работе. Не доверяйте красивому коду и автотестам. Доверяйте тому, что вы сами использовали систему и она не сломалась за разумный срок. Это новый стандарт оценки качества — и он работает как для vibe-coded пет-проектов, так и для энтерпрайз-решений.

Часто задаваемые вопросы

Что такое vibe coding простыми словами?

Vibe coding — это стиль программирования с ИИ, при котором вы описываете задачу на естественном языке и не проверяете сгенерированный код. Подходит для прототипов и личных инструментов, но рискованно для продакшена, где от качества кода зависят другие люди.

Чем агентная инженерия отличается от vibe coding?

При агентной инженерии вы — профессиональный разработчик, который использует ИИ как помощника: направляете, задаёте архитектуру, контролируете качество. При vibe coding вы просто просите «сделай мне X» и надеетесь на лучший результат. Разница — в уровне ответственности и экспертизы.

Стоит ли проверять код, который пишет ИИ?

Зависит от контекста. Для критичных частей — авторизация, бизнес-логика, работа с данными пользователей — проверять обязательно. Для типовых операций, где ИИ ошибается редко, можно ослабить контроль, но помнить о риске «нормализации отклонений».

Итог

Vibe coding и агентная инженерия сливаются — и это не теоретический прогноз, а реальность, в которой уже живут тысячи разработчиков. Когда Claude Code стабильно пишет правильный код, а вы перестаёте его проверять, — вы занимаетесь чем-то посередине между двумя подходами. Это не хорошо и не плохо. Это новый этап эволюции разработки, к которому нужно адаптироваться сознательно, а не оказываться в нём случайно.

Самый надёжный сигнал качества в мире ИИ-кода — не автотесты и не красивый README. Это реальное использование. Если вы vibecode-или инструмент и он проработал у вас две недели без сбоев — это больше говорит о его качестве, чем тысяча строк модульных тестов.