Вайб-кодинг довёл до чёрного ящика: когда возвращаться к ручному кодингу?

На Hacker News на днях разошёлся пост: разработчик написал успешное приложение, потом сел переписывать вторую версию полностью через Claude - и в какой-то момент понял, что перестал понимать собственный код. Вернулся к ручному кодингу и описал это так: "это место моё. Моё собственное. Я знаю, где что живёт." Мой блог-пайплайн, который в том числе генерирует и эту статью, вайб-коженый процентов на девяносто, а на sunm8.ru им уже собрано 67 статей (published-titles --platform sunm8 -> 67 записей), так что тред я читал не как сторонний наблюдатель, а как человек, который сам регулярно упирается в тот же вопрос: где граница, после которой агента пора притормозить и сесть за клавиатуру самому.

Как понять, что вайб-кодинг зашёл слишком далеко

Черновой признак простой: если ты не можешь ответить на вопрос "где в проекте живёт эта логика" без grep - вайб-кодинг зашёл слишком далеко. По данным исследования GitLab (июнь 2026, опрос 1528 разработчиков и ИТ-заказчиков в шести странах), 85% согласны, что ИИ сместил не сам процесс написания кода, а боттлнек - с написания на проверку и валидацию. Хуже: 43% опрошенных не могут отличить код, написанный нейросетью, от кода человека, даже глядя в собственный репозиторий.

Кроме потери ориентиров, есть ещё несколько верных сигналов:

• ты открываешь файл, который сам "написал" на прошлой неделе, и не помнишь, зачем там этот кусок;
• одна и та же функция за месяц переписана агентом четыре раза, и в каждой версии - новый набор побочных эффектов;
• ревью диффа занимает у тебя больше времени, чем занял бы код руками, но ты всё равно жмёшь "принять", потому что "разберусь потом";
• на прямой вопрос "как это работает" ты отвечаешь пересказом комментариев, которые сгенерировала та же модель.

Смещение боттлнека с написания на проверку звучит абстрактно, пока не столкнёшься с ним на своём проекте: раньше узким местом было "успеть написать фичу", теперь узкое место - "успеть понять и провалидировать то, что уже написано за пару минут". Скорость написания перестаёт быть проблемой почти сразу после того, как заводишь агента; скорость понимания остаётся твоей личной, и она не ускоряется вместе с моделью.

Разрыв на уровне доверия у тех же 1528 разработчиков тоже показательный: 73% беспокоятся о поддерживаемости ИИ-кода, а 82% считают, что это отдельный вид техдолга - не тот, что копится от спешки человека, а тот, что копится от спешки модели. Я писал про похожий эффект на собственном пайплайне в статье про когнитивный долг агентов: там разбор о том, что каждый второй коммит на деле тушит пожар, а не двигает фичу вперёд.

Почему код на ИИ превращается именно в чёрный ящик, а не просто в код, который ты не писал

Дело не в том, что код чужой - чужой код бывает и у джуна, который читает чужой репозиторий впервые. Дело в том, что модель не стесняется. Артём Герасимов в разборе на Хабре формулирует это жёстко: скажи ей "сделай быстро" - она сделает быстро, но плохо, и не предупредит. Хуже: чинить свой же баг модель часто чинит вычёркиванием - убирает функциональность вместе с проблемой, потому что так короче диф. В той же статье приведён пример из практики: исследовательскую задачу с графовой БД Memgraph с ИИ-поддержкой закрыли за 1 день против 5+ дней без неё - и это ровно та скорость, ради которой вайб-кодинг вообще затевают, просто её легко перепутать со скоростью понимания.

На моём пайплайне цифра не такая драматичная, но вектор тот же. В снятом слепке гит-лога blog-pipeline 34 коммита начинаются со слова "fix" (grep -aicE "^[0-9a-f]+ fix" data/project-facts/blog-pipeline/gitlog.txt -> 34) - это чинили то, что агент сам же написал в предыдущем проходе. Из 114 закрытых задач в этом же проекте изрядная часть - не новая функциональность, а разбор того, что уже накодили. Один из таких разборов (закрытая задача claude-3a9, 17 августа) чинил не баг, а доверие к статьям: я грепал "except Exception" по трём своим репозиториям, чтобы найти места, где агент тихо проглатывает ошибки, и подпирал черновик про когнитивный долг реальными цифрами - 50 коммитов и 324 теста в одном петпроекте, 146 строк в balance.rs в другом. Писал это руками, потому что автоматически найти "что от меня спрятали" агентом же и попросить - такое себе доверие.

Когда быстрее написать руками, чем гонять агента по кругу

Прямой критерий: если агент третий раз подряд чинит один и тот же баг, а результат каждый раз новый, а баг тот же - дешевле остановиться и написать руками. Гонять модель по кругу дороже, чем кажется на токенах: дороже твоё собственное время на очередной ревью диффа, который опять не туда.

У меня так было с отказоустойчивой цепочкой уведомлений: лестница провайдеров luna, gpt-oss и regex теряла сообщения при сетевом сбое и путалась в окне по дате поста. Агент раз за разом чинил симптом, а не причину - пока я не сел и не допилил цепочку руками, шаг за шагом, от входа до записи в базу. После фикса весь набор тестов (232 штуки) прошёл зелёным, но починил его не агент - починил я, потому что смог удержать в голове всю цепочку целиком, а он на каждом проходе видел только свой кусок. Про то, как вообще ревьюить чужой в смысле ИИ-шный код, когда сам не эксперт в предметке, у меня был отдельный разбор - ревью AI-кода без экспертизы.

Второй критерий - цена ошибки. Там, где откат дорогой (миграции данных, платежи, всё, что трогает прод без предохранителя), быстрее и надёжнее написать руками с самого начала, чем потом откатывать то, что агент сделал уверенно и неправильно.

Но у ручного кодинга есть и обратная сторона, про которую в том же треде на HN написал пользователь pulkas: если идеи появляются быстрее, чем ты успеваешь их руками реализовать, - делегируй код ИИ, иначе конкуренты обойдут просто по скорости выката. Ручной режим - не религия, а инструмент для конкретных зон риска, а не default для всего проекта.

Как совмещать скорость ИИ с пониманием того, что происходит в проекте

Рабочая схема - не "человек или агент", а разделение труда: агенту - объём и итерации, себе - границы и критичные модули. Пользователь aatd86 в том же треде сформулировал похоже: строить фундамент руками, а дальше пускать ИИ итерировать сверху - модель забывает базовые принципы и тащит лишнее, если дать ей строить с нуля.

Второй кусок схемы - guardrails вместо доверия на слово. После того как агент у меня одной командой снёс папку проекта (разбирал этот случай отдельно - PreToolUse guard после инцидента), правило простое: критичные операции без подтверждения нельзя, а не "агент же умный, разберётся".

Третий кусок - держать хотя бы одно ядро проекта под полным ручным контролем. У меня это слой работы с базой (scripts/bp_db.py): все статусы тем и черновиков, все переходы между ними я прочитал и держу в голове целиком, а не по кускам, которые вспоминаю, когда что-то ломается. Не потому что агент не справится это написать - справится и уже писал, - а потому что это тот самый компас, по которому я проверяю, не наврал ли он в остальном пайплайне. Один прочитанный до конца модуль стоит десяти невнимательно проревьюженных диффов.

И да, ответственность не перекладывается на инструмент. Пользователь sfn42 в комментах на HN сказал точно: "вы выбираете отказаться от контроля, а потом жалуетесь, что не в контроле" - дело не в инструменте, а в том, сколько ты сам вовлечён в процесс. Удобно? Удобно, но за руль всё равно отвечает водитель, не автопилот. А ещё стоит помнить про навык как мышцу - в этом же треде Chester2002 прямо написал, что кодить руками время от времени нужно хотя бы для того, чтобы не растерять умение, когда оно понадобится без ИИ под рукой.

Какую нейросеть для кода держать под рукой, если решил не тонуть в чёрном ящике

Тут я не буду разводить ещё один бенч - у меня их хватало, от сравнения Claude Code против Codex и Cursor до прогона семи моделей на своих данных за вечер. Вывод в любом из этих бенчей один: модель, которая быстрее пишет, не обязательно та, чей код проще потом понять. Для рутинных итераций годится почти любая топовая нейросеть для кода. Для кусков, которые ты обязан понимать сам, модель вообще не главный фактор - главный фактор, готов ли ты сам прочитать диф построчно, а не молча нажать "принять".

Итог

Вайб-кодинг не работает как автопилот "включил и забыл" - тред на HN и статистика GitLab говорят об одном и том же: 43% людей уже не отличают код нейросети от своего, и это не повод расслабиться, а тревожный звонок. Возвращаться к ручному кодингу стоит не когда код "выглядит плохо", а когда ты перестал понимать, что где лежит и почему это работает именно так. Раньше этой точки агент экономит время. Позже - только откладывает счёт, который всё равно придётся оплатить руками.