От станка к промпту: что искусственный интеллект делает с профессией разработчика

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

Дальше произошло то, что обычно упускают, когда рассказывают эту историю как притчу о вытеснении. Мастера не исчезли. Изменилось содержание их работы: точность руки перестала быть дефицитом, а дефицитом стали конструкция, допуски, оснастка и понимание того, что именно мы производим и для кого. Ценность сместилась с исполнения на замысел и контроль.

Сегодня то же самое происходит с кодом.

Что именно изменилось

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

Сейчас эта часть стремительно дешевеет. Модель пишет типовой обработчик быстрее, чем вы вспомните точное имя параметра. Как и станок, она берёт на себя воспроизводимую операцию — ту, где результат заранее известен, а от человека требуется лишь аккуратность.

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

Где аналогия со станком ломается

Дальше начинается важное различие, из-за которого сравнение нельзя принимать целиком.

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

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

Отсюда практический вывод: чем больше кода вы генерируете, тем дороже становится ваша способность его прочитать и опровергнуть. Это ровно обратное тому, что обещает «вайб».

Что становится дефицитом

Если исполнение дешевеет, ценность перетекает к тому, что моделью пока не покрывается:

• Постановка задачи. Модель отвечает на заданный вопрос, а не на правильный. Сформулировать, что мы вообще строим и какие ограничения существенны, по-прежнему обязан человек.
• Архитектура и границы. Решения о том, где проходят границы модулей, что можно менять независимо и какой ценой мы платим за связность, живут в масштабе всей системы — там, где контекста модели не хватает.
• Верификация. Тесты, типы, инварианты, метрики. Умение доказать, что код делает заявленное, а не выглядит правдоподобно.
• Ответственность. За инцидент на проде отвечает инженер, а не генератор. Это несимметрично и вряд ли изменится.

Как работать с этим на практике

Разумная стратегия — не отказ и не безоглядное доверие, а разделение задач по цене ошибки.

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

Читайте построчно там, где ошибка дорогая: авторизация, работа с деньгами, миграции данных, всё, что касается персональных данных и безопасности. Здесь сгенерированный код — это черновик от незнакомого человека без контекста вашей системы, и относиться к нему следует соответственно.

Хороший рабочий приём — просить у модели не только реализацию, но и опровержение: перечислить пограничные случаи, предположения и условия, при которых код сломается. Формулировка «что здесь может пойти не так» даёт заметно больше пользы, чем «напиши функцию».

Что в итоге

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

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