Вайб-кодинг: почему ощущение скорости врёт

После каждой сессии с Claude Code я открываю голосовые заметки и наговариваю пару минут. Что делал, что получилось, что бесило, сколько пришлось переписывать. Потом воркфлоу на n8n расшифровывает запись и раскладывает по таблице. Через пару недель такого логирования я обнаружил неприятную вещь: сессии, которые ощущались как самые продуктивные, по факту чаще всего заканчивались кодом, который я потом переписывал. А тихие, «скучные» сессии давали результат, который уходил в прод без правок.

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

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

В 2025-м METR (организация, которая занимается оценкой AI-систем) провела рандомизированное исследование: опытные open-source разработчики на знакомых кодовых базах с AI-инструментами выполняли задачи в среднем на 19% дольше. При этом сами участники оценивали своё ускорение в +20%. И что интересно, этот разрыв не осознавался. Люди искренне верили, что стали быстрее.

Это не баг отдельных людей. Это свойство самого инструмента: AI создаёт ощущение прогресса. Код появляется быстро, экран заполняется, что-то компилируется. Мозг считывает это как «я молодец, дело идёт». А потом два часа на верификацию, исправление edge cases и восстановление контекста, который агент потерял на третьей итерации.

Я сам на это попадался. Помню сессию, где Claude за 20 минут нагенерил мне целый модуль: тесты, обработку ошибок, всё красиво. Ощущение было: ну вот, вот так и надо работать. А потом я два вечера чинил логику, потому что агент сделал архитектурное допущение, которое на первый взгляд выглядело разумно, но ломало всю модель данных. Двадцать минут генерации, четыре часа исправлений. Формально минус по времени. Субъективно лучшая сессия недели.

Каждый раз, когда вижу тред «AI ускоряет разработку или нет», там все про разное. Я для себя выделил три уровня, и путать их значит делать неверные выводы.

Уровень сессии. Конкретные 30-90 минут работы с агентом. Дошёл ли я до результата? Сколько пришлось переделывать?

Уровень личного процесса. Стал ли я за месяц работать лучше с AI? Научился ли формулировать задачи так, чтобы rework уменьшался? Или я просто привык к быстрому дофамину и теперь мне скучно писать код руками?

Уровень команды/продукта. Это DORA-метрики: deployment frequency, lead time, change failure rate, time to restore. Здесь AI – один из десятков факторов, и изолировать его вклад почти невозможно.

Проблема в том, что большинство обсуждений скачут между уровнями. «AI ускоряет разработку» – это про что? Про то, что первый драфт появляется за секунды? Или про то, что фичи быстрее доезжают до прода с меньшим количеством багов?

DORA прямо пишет в отчёте по AI-assisted development: AI в основном выступает как усилитель. Он усиливает уже существующие сильные и слабые стороны. Если у вас хороший процесс, хорошая документация и понятная архитектура, AI ускорит. Если бардак, AI ускорит бардак. (Хотя, если честно, я ни разу не видел компанию, которая реально применяла DORA для оценки AI-вклада. Либо не показывают, либо не считают.)

Для оценки сессии DORA бесполезен. Он слишком высокоуровневый. Вы не будете после каждой 40-минутной работы с агентом считать deployment frequency. Нужно что-то ближе к телу.

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

Не «сколько кода написано», а:

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

Time to first draft: как быстро AI выдал первый вариант. Эта цифра почти всегда красивая. Claude выдаёт код за секунды-минуты, и каждый раз кажется: «ну вот, вот оно».

Time to verified solution: сколько прошло от начала до момента, когда результат реально можно принять. Эта цифра обычно в 3-5 раз больше первой. И именно она говорит правду.

В своих логах я записываю обе. И когда потом смотрю на данные за неделю, картина бывает отрезвляющая. На рутинных задачах (бойлерплейт, тесты, миграции) разрыв небольшой: AI выдал, я проверил, готово. На задачах с нетривиальной логикой first draft появляется мгновенно, а verified solution может занять дольше, чем если бы я писал руками.

Все считают, сколько AI написал. Мало кто считает, сколько пришлось исправить.

Я оцениваю грубо: низкий / средний / высокий. Низкий: принял код почти без изменений. Средний: поправил логику, переименовал, убрал лишнее. Высокий: переписал больше половины или откатил целиком.

Код появляется быстрее, а вот живёт меньше. Я это вижу и на себе: чем «умнее» выглядит предложение агента, тем дольше я его проверяю и тем чаще в итоге переписываю.

После каждой сессии я фиксирую субъективное ощущение: было легко или тяжело, был ли поток, чувствую ли уверенность в результате. А потом, отдельно, фактические данные: время, rework, результат.

Фреймворк SPACE (satisfaction, performance, activity, communication, efficiency) и подход DevEx давно говорят: субъективный опыт разработчика – это не шум, это важный сигнал. Если AI снимает когнитивную нагрузку, помогает не зависнуть на пустом экране, удерживает в потоке, то это реальная ценность, даже если по секундомеру не быстрее. Ранние исследования Copilot это подтверждали: разработчики отмечали снижение ментального усилия.

Но есть ловушка. Иногда «стало легче» означает: AI убрал рутину, и я сфокусировался на сути. А иногда «стало легче» означает: я просто перестал думать и начал соглашаться. Разница огромная, и заметить её в моменте тяжело. Зато в логах за две недели видно сразу. Если субъективная оценка стабильно «кайф, всё круто», а rework стабильно высокий, то это красный флаг. Значит, AI создаёт иллюзию прогресса, а я ведусь.

Расскажу конкретно, потому что абстрактные советы «ведите дневник» не работают. Я пробовал, забрасывал через три дня. Работает только то, что стоит почти нуль усилий.

Шаг 1: голосовая заметка. Сразу после сессии (неважно, 30 минут это было или 5 часов) открываю голосовые заметки и наговариваю 1-3 минуты. Тип задачи, результат, сколько переделывал, ощущения. Никакой структуры в голове, просто поток.

Шаг 2: автоматическая расшифровка. Заметка летит в воркфлоу на n8n. Там расшифровка (Whisper) и извлечение структурированных данных через LLM с JSON output. У части полей детерминированные значения: тип задачи из фиксированного списка, rework на шкале 1-3, результат из трёх вариантов. Свободный текст тоже сохраняется, но для аналитики важны именно фиксированные поля.

Шаг 3: таблица. Всё падает в Google Sheets. Ничего модного, просто строки с датами и значениями. Можно было бы в Notion или Supabase, но sheet проще для быстрого просмотра глазами.

Шаг 4: периодический анализ. Когда набирается 15-20 записей, кидаю таблицу в ещё один LLM-воркфлоу, который вытаскивает паттерны: на каких типах задач rework стабильно высокий, где расхождение ощущений и реальности максимальное, какие сессии самые «дорогие» по соотношению время/результат. Но (и это важно) потом обязательно смотрю исходные данные сам. LLM хороша для первичного скрининга, но выводы я делаю своими глазами.

Весь этот конвейер стоит мне 2-3 минуты на сессию. Это ключевое: если бы нужно было заполнять форму или писать текстом, я бы забросил. Голосовая заметка + автоматизация = единственный способ, который реально выжил дольше двух недель.

Rework зависит от типа задачи намного больше, чем от «качества» агента. На бойлерплейте, тестах, простых рефакторингах rework стабильно низкий. На архитектурных решениях и сложном дебаге стабильно высокий. Звучит очевидно, но пока не видишь это в таблице с конкретными цифрами, не осознаёшь масштаб разницы.

Субъективное ощущение «крутой сессии» слабо коррелирует с реальным результатом. Самые приятные сессии: длинные, с кучей генерации, где AI «понимает с полуслова». Самые результативные: короткие, где я чётко формулирую задачу, получаю драфт, быстро правлю и коммичу. Скучно, но работает.

Ещё вылезло, что вечерние сессии хуже утренних, но не из-за AI, а из-за меня. Вечером я менее критичен, чаще соглашаюсь с первым вариантом, реже перепроверяю. Rework на следующий день выше. Это, пожалуй, самый полезный инсайт из всей затеи: эффективность AI-сессии зависит от состояния человека не меньше, чем от качества модели.

И самое обидное. Главный источник rework – не баги, а архитектурные допущения, которые я не оспорил. Про типовые паттерны таких ошибок я писал отдельно. AI уверенно выбирает подход, я киваю, через два дня выясняется, что подход не масштабируется или конфликтует с тем, что уже есть. Фиксить баги – это минуты. Фиксить архитектуру – это вечера. И чем дольше откладываешь, тем больнее.

Первое и главное: я измеряю только то, что осознаю. Если AI тихо внёс скрытый баг, который вылезет через месяц, я его не зафиксирую. Мои метрики ловят очевидный rework, но пропускают отложенный технический долг. Как с этим жить, пока не придумал (пока что просто смотрю на динамику задач с типом: "рефаткоринг/техдолг").

Второе: голосовые заметки субъективны. Я говорю «rework средний», но это моя интуиция, а не diff в гите. Можно было бы автоматизировать точнее, считать реальные изменения в коде после AI-генерации, но это уже инженерная задача, до которой руки не дошли. Может, когда-нибудь. Пока работает и грубая оценка.

Третье: 15-20 записей – это не big data. Выводы, которые я делаю, могут быть артефактами маленькой выборки. Я это понимаю и стараюсь не строить генеральных теорий на основе пары недель логов. Но даже грубая картина лучше, чем никакой.

И ещё один момент, который меня напрягает: сам процесс измерения может искажать поведение. Зная, что я буду оценивать rework, я стал внимательнее проверять код. Это хорошо для качества, но значит, что мои «улучшенные» метрики частично отражают не рост навыков работы с AI, а рост осознанности проверки. Впрочем, если задача писать лучший код, то какая разница, за счёт чего.

Если вам не хочется строить целый конвейер с n8n и LLM, это и не обязательно. Суть не в инструментах, а в привычке задавать себе четыре вопроса после каждой сессии:

Записывайте хоть в блокнот, хоть в заметки в телефоне. Главное делать это сразу после сессии, пока свежо. Через 2-3 недели у вас будет картина, которая, скорее всего, отличается от того, что вы думаете сейчас.

Вот что я понял за эти месяцы: AI ломает старую интуицию о продуктивности. Раньше было проще: если ты много сделал руками и довёл до результата, день был хорошим. С AI можно быстро двигаться и создавать долг. Чувствовать прогресс и на самом деле замедляться. Экономить усилие на написании, но тратить вдвое больше на сомнение в результате.

Хорошая AI-сессия – это не когда агент много написал. Это когда после неё у меня меньше неопределённости и меньше будущей работы. Вот это, по моему опыту, и есть настоящая эффективность. Всё остальное – дофамин.

Как вы оцениваете свои сессии с AI? Ведёте какой-нибудь лог или полагаетесь на ощущения? Интересно, у кого какие паттерны вылезают, делитесь в комментариях.