Мы доверяем машинам писать код с 1995 года.

Разработчики в 1995 году уже работали в логике вайбкодинга: они доверяли компилятору писать машинный код, который сами никогда не читали. Просто регулятор доверия сдвинулся с 80% до 95%.

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

Это неправильный вопрос. Сейчас объясню почему.

В 60-е нужно было математическое мышление и формальная логика. Код был тонкой оболочкой поверх математики, и если вы не понимали, что находится под ней, вы не могли написать эту оболочку.

В 90-е и 2000-е программирование сменилось software engineering, а на первый план вышел синтаксис: JavaScript, Python, Java. Большинство разработчиков больше никогда не открывали учебник математики. Многие даже не думают о том, что их язык — это математическая абстракция поверх другой математической абстракции, которая в итоге работает на кремнии.

Им и не нужно об этом думать. Компилятор разберётся. Стандартная библиотека разберётся. GC разберётся.

2000-е держались не на синтаксисе. Они всегда держались на доверии.

На доверии к тому, что компилятор компилирует корректно. Что библиотека делает то, что обещает документация. Что база данных сохранит то, что вы в неё записали. Что фреймворк, которым вы пользуетесь сегодня, не развалится завтра.

Разработчик из 90-х, возможно, работал на уровне 80% доверия к стеку. Это был большой скачок по сравнению с 50% в 60-е, когда абстракции постоянно протекали, и нужно было понимать, что происходит под капотом.

Просто они не называли это доверием. За десятилетия работы, все было проверено, нормализовано и стало невидимым.

Вайбкодинг не принёс доверие в разработку. Он просто повысил его требуемый уровень. "Мышца" та же, но число новое. И этот скачок привел к тому, что абсолютное большинство инженеров в наше время еще не успели адаптироваться.

Причина, по которой многие сеньоры сопротивляются вайбкодингу, не техническая. Она про идентичность. Вся их карьера строилась на позиции: «Я знаю то, чего не знает машина». Вайбкодинг переворачивает эту позицию. Теперь машина знает синтаксис, библиотеки, паттерны.

Последнее, что остается - суждение (judgement). И это необходимо рассматривать как повышение, а не понижение. По сути, благодаря вайбкодингу, инженеры смогли сэкономить 5-10 лет своей карьеры. Те кто это понял - счастливы. Кто еще не понял - в ужасе.

CTO не пишет весь код. Архитектор не пишет каждую строку. Они давно обменяли исполнение на суждение. Вайбкодинг делает эти роли доступными сейчас.

Вас не лишают навыков. Вас поднимают на уровень выше раньше, но без вашего спроса :-).

Простая картина:

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

Анна открывает IDE и начинает писать код. Она знает фреймворк и работает быстро.

Сергей пишет спецификацию: что инструмент делает, чего не делает, какие есть edge cases, кто пользователь. Передаёт это Claude. В среду релизит.

Анна релизит в пятницу. На два дня позже.

Умножьте эту разницу на каждый тикет в течение следующих шести месяцев — и вы поймёте, что прямо сейчас происходит с командами и почему мы видим так много сокращений во всех компаниях от мала до велика.

Спецификации — умение понять, чего вы на самом деле хотите, и описать это достаточно точно, чтобы машина могла попасть в цель. У большинства с этим плохо, потому что мы годами описывали «как», а не «что».

Вкус — умение узнавать хорошее, когда вы его видите. Менеджеров без вкуса команда легко переезжает. Вайбкодеры без вкуса выкатывают мусор и не понимают, что это мусор. Мы каждую неделю видим сотни новых сайтов: они вроде бы разные, но на самом деле абсолютно одинаковые.

Проверка — умение читать и оценивать код, который писали не вы. Навык code review перестаёт быть вспомогательным и становится основным.

Декомпозиция — умение разбивать задачу на куски, пригодные для спецификации. По сути, это архитектура под другим названием. С вайбкодингом она никуда не исчезает. Наоборот, становится важнее, потому что вы больше не пишете вручную весь glue code, который раньше маскировал плохую декомпозицию.

Есть одна асимметрия, о которой важно помнить: люди спорят, ИИ соглашается.

Поэтому калибровка доверия идёт от вас, а не от системы, которая будет вам сопротивляться. Проверяйте больше, а не меньше. Относитесь к агентам как к джунам в команде, а не как к сеньорам.

Те, кто останется на уровне 80% доверия, не будут уволены сразу. Они просто в какой-то момент не смогут успевать за ведущими.

Их тикеты будут занимать больше времени. Команда начнёт обходить их при распределении работы. А через шесть месяцев, когда бюджет начнут резать, нетрудно догадаться, кто окажется первым в списке.

Да, мы занимаемся вайбкодингом с 1995 года. Сейчас нам нужно лишь чуть больше доверия.

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

Сейчас это моя домашняя работа. Я собрал Atlas, чтобы отслеживать этот процесс, и выпустил его как публичный live-документ.

Берегите себя. Учитесь и растите вместе с нами. Спасибо.

Вольф Алексанян, Армения, май 2026.