С вайбкодингомя не стал быстрее.Я стал иначе ошибаться.

Когда меня спрашивают про вайбкодинг, разговор обычно очень быстро скатывается в две крайности. Либо «теперь любой за вечер соберёт стартап», либо «это фабрика технического долга».

У меня получилось как-то скучнее. И поэтому, кажется, интереснее.

Быстрее я особо не стал.

Зато изменилось другое: цена ошибки.

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

Половину из них я убивал ещё до старта.

Не потому что они точно плохие. Просто мысль «а давайте проверим» автоматически превращалась в маленький проект.

Сейчас маленький проект иногда занимает вечер.

Это сильно меняет голову.

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

Вот это, на мой взгляд, куда важнее обещания «программировать в десять раз быстрее».

Код, кстати, оказался самой простой частью.

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

И самым полезным решением в итоге оказался return null.

1// Локальные правила: без сети, без ключа, без денег.2function nameFor(frame: FrameNode): string | null {3  if (!isDefaultName(frame.name)) return null; // имя от человека не трогаем4  if (hasOnly(frame, "TEXT")) return "Label";5  if (looksLikeButton(frame)) return "Button";6  if (frame.layoutMode === "VERTICAL") return "Stack";7  return null; // не уверен — пусть решает модель8}

Последняя строка здесь важнее половины логики выше.

Если не уверен — ничего не делай.

До этого я несколько раз ловил ситуацию, когда модель очень уверенно давала объекту аккуратное, логичное и совершенно неправильное имя. И вроде мелочь. Пока потом не пытаешься понять, почему у тебя в проекте три Card, четыре Container и один загадочный SectionFinal2.

Я долго думал, что главная сила ИИ-кодинга — способность писать.

Сейчас всё больше думаю, что она в другом: код стало не жалко.

Если модуль можно пересобрать за полчаса, к нему не успеваешь привязаться. Не надо защищать решение только потому, что в него ушла неделя.

Сломал. Выкинул. Переделал.

Но тут есть неприятная граница.

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

И ещё он очень быстро показывает, где ты сам формулируешь задачу как попало.

Модель в этом смысле беспощадна. Написал мутно — она не возмутится. Не задаст вопрос. Не покрутит пальцем у виска.

Она бодро сделает не то.

Иногда очень красиво.

Поэтому три вещи я пока вообще не хочу отдавать модели полностью:

• что делать, когда всё пошло не по плану;
• деньги, доступы и чужие данные;
• саму постановку задачи.

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

Тоже, в общем, ускорение.