Что я понял за год vibe-кодинга - и что мне за это стыдно
Год назад я считал, что программировать уже не нужно. Потом я потратил неделю на отладку кода, который модель сгенерировала за пятнадцать минут. Личный разбор.
В июне прошлого года я собрал первый «серьёзный» продукт в vibe-режиме. Это был внутренний инструмент для одного клиента - бот, который забирал письма из одной почты, суммировал их, и отправлял суммаризацию в одну таблицу. Я собрал его за субботу. Шестнадцать часов, не считая еды и одной прогулки с собакой. В воскресенье я посмотрел на него, понял, что он работает, и довольный лёг спать.
В понедельник мне позвонил клиент и сказал, что бот «как-то странно себя ведёт». В основном - начал приписывать в суммаризации факты, которых в письмах не было. Бот галлюцинировал, как положено хорошему студенту первого курса философии.
Я сел отлаживать. За следующие пять дней я понял четырнадцать вещей, которые мне модель не сказала, пока писала код. Основное: я, собственно, сам не знал, что я строю. Я знал, что хочу, чтобы работало. Но это, как выясняется, не одно и то же.
Про vibe-кодинг пишут примерно два типа людей. Первый - восторженные: «теперь я за выходные делаю то, на что раньше уходил месяц!». Второй - разочарованные: «это всё фикция, AI ничего не умеет, пока нам платят настоящим программистам, всё будет хорошо». Мимо главного, мне кажется, проходят и те и другие.
Главное в том, что vibe-кодинг не убирает программирование. Он убирает его механическую часть. Набивание циклов. Разбор шаблонного JSON. Десятую в жизни пагинацию. Если ты думал, что работа разработчика - это в основном набивать - ты получаешь огромный прирост. Если ты думал, что работа разработчика - это принимать решения, - модель тебе не помощник, она тебе собеседник. И собеседник, если честно, не очень умный. Он умеет делать, но не умеет понимать, зачем.
Тот бот летом - классический пример. Я формулировал задачи примерно так: «сделай функцию, которая забирает письма из Gmail API и возвращает массив». Модель делала. Работала. Потом я формулировал: «суммаризируй каждое письмо». Модель делала. Тоже работала.
А проблема была в том, что я не сформулировал никакого критерия корректности суммаризации. Я предполагал, что «суммаризировать» - значит «вытащить ключевые моменты письма без искажений». Модель предполагала, что «суммаризировать» - это «перефразировать так, чтобы короче». Первая часть совпадала. Вторая - нет.
К пятнице я понял, что переделывать надо не код, а промпт внутри модели-суммаризатора. Я переформулировал его на языке, который нельзя было интерпретировать по-разному: «Вытащи факты из письма. Факт = утверждение с субъектом, глаголом и объектом. Не добавляй ничего, чего нет в письме. Если сомневаешься, пиши "не упомянуто".». После этого галлюцинации ушли. Код - остался тем же. Промпт - решил.
И вот это - то, что я понял за год. Vibe-кодинг работает у того, кто умеет формулировать. Не программировать и даже не писать промпты, а ставить задачу так, чтобы на неё нельзя было дать неправильный ответ.
(Впрочем, «нельзя было дать» - это гипербола. Можно. Модели иногда изобретательны.)
За этот же год я собрал в vibe-режиме примерно двенадцать вещей. Из них:
Четыре - прототипы для клиентов, которые пошли в прод без переписывания. Это были лендинги, небольшие админки, служебные утилиты. Они работают до сих пор. Для таких задач vibe-кодинг идеален. Я бы не стал писать такое вручную. Это одна из тех ситуаций, где «традиционная разработка» превращается в бытовое зло.
Три - интеграции. Принимаешь вход из одного API, делаешь что-то, отправляешь в другое API. В 2026 это часто одна формулировка, а не спринт. Для интеграций модель хороша, потому что контекст публичных API - это то, на чём её и учили.
Две - рефакторинги. Я даю модели чужой код, описываю, чего хочу, она предлагает, я принимаю. Это моё любимое применение, потому что здесь модель работает как коллега-младший, у которого бесконечный запас терпения и ноль эго.
Две - полные провалы. Это были попытки сделать вещи, которые я не до конца понимал сам. Одна - сложный бэкенд с асинхронной очередью и распределёнными блокировками. Модель мне написала код, который компилировался, казался правильным, и содержал тонкую гонку на уровне Redis-блокировок, которую я обнаружил только в продакшене, когда два разных пользователя одновременно заказали одно и то же. Модель такого не ловит, потому что она не видит причинно-следственных связей в распределённых системах. Она видит код. Код выглядит правильно.
Одна - попытка сделать собственный SDK с уникальной бизнес-логикой, аналогов которой в интернете нет. Модель додумала логику по отраслевому среднему, и то, что я получил, было «обычным SDK для типичной задачи», а не моей специфической. Я потом переписал вручную. Быстрее было бы сразу.
Три правила, которые я вывел за этот год, коротко.
Первое. Формулируй результат, а не код. «Добавь endpoint POST /orders, который принимает { id, items[], total }, валидирует, пишет в БД, возвращает 201» - это запрос. «Сделай, чтобы заказы работали» - это молитва. Между ними - 80% успеха.
Второе. Тестируй руками каждую итерацию. Не после пяти запросов. После каждого. У меня есть жестокое правило: если я не проверил, что код работает, я не принимаю следующий запрос. Иначе модель строит башню из предположений, каждое следующее опирается на предыдущее, и когда она падает - падает вся целиком.
Третье. Читай код, не только принимай. Если строки 40-60 непонятны - задавай вопрос модели. Если модель не может объяснить так, чтобы ты понял, - значит, ты не готов это принимать в прод. Дело тут не в недоверии: твоя работа теперь - ревью. И ревью чужого кода, даже если чужой - это языковая модель, - требует понимания.
Те, кто говорит, что разработчики больше не нужны, либо никогда не чинили чужой код в три часа ночи, либо продают курс за 49 990 рублей.
Модель работает рычагом. Опереть его есть на что только у того, кто понимает, что строит, зачем и что будет, когда пойдёт не так.
В июне прошлого года я считал, что программировать уже не нужно. В июне этого года я считаю, что программировать нужно ещё больше. Только головой, а не руками.