--- title: "Что я понял за год vibe-кодинга - и что мне за это стыдно" url: "https://www.mikefluff.com/ru/blog/vibe-coding-without-illusions" locale: "ru" author: "Mike Fluff" updated: "2026-06-20" description: "Год назад я считал, что программировать уже не нужно. Потом я потратил неделю на отладку кода, который модель сгенерировала за пятнадцать минут. Личный разбор." tags: - "vibe-coding" - "ai" - "developer" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/en/blog/vibe-coding-without-illusions.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/ru/blog/vibe-coding-without-illusions.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/pt/blog/vibe-coding-without-illusions.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/es/blog/vibe-coding-without-illusions.md" --- # Что я понял за год vibe-кодинга - и что мне за это стыдно > **Коротко:** Из двенадцати вещей, собранных за год в 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 рублей. Модель работает рычагом. Опереть его есть на что только у того, кто понимает, что строит, зачем и что будет, когда пойдёт не так. В июне прошлого года я считал, что программировать уже не нужно. В июне этого года я считаю, что программировать нужно ещё больше. Только головой, а не руками. **[Курс по vibe-кодингу](https://www.mikefluff.com/ru/vibe-coding-course)** — Шесть модулей, $19. Инструменты, промпты, процесс и трезвый разговор о том, как это работает на самом деле.