Театр трудоустройства: почему разработчики вычитывают AI-код глазами вместо написания критериев

Театр трудоустройства: почему разработчики вычитывают AI-код глазами вместо написания критериев

Три часа ночи. Старший разработчик сидит перед монитором, глаза наливаются кровью. На экране — гигантский diff: нейросеть сгенерировала пятьсот строк кода за три секунды. Наш герой полчаса честно вычитывает каждую строчку, проверяя скобочки, названия переменных, логические отступы. В голове — гордая мысль: «Вот она, настоящая инженерная работа».

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

Этот паттерн везде.

Парадокс

Умные, опытные инженеры выбирают усердный и неэффективный микроменеджмент чужого машинного кода вместо эффективного целеполагания. Организации внедряют AI-инструменты и ждут 10x-прироста. Получают разработчика, ставшего человеческим линтером для нейросети.

Разрыв огромен. Есть кейс: фаундер с глубокой доменной экспертизой в складской логистике в одиночку переписал 10-летнюю кодовую базу. За шесть месяцев — ноль падений системы, 10–15 деплоев в день прямо во время рабочей смены, задача на двухнедельный спринт команды закрывается за 10–30 минут.

Ключевое: он умел ставить задачи точно. Знал домен изнутри — поэтому мог формулировать требования так, что агент выдавал правильный результат с первого раза.

Вычитывал ли он потом код глазами? Нет. Строил критерии и системы проверки.

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

Причина первая: театр трудоустройства

Десятилетиями профессиональная ценность программиста измерялась физическими действиями: стуком по клавишам, изучением файлов в IDE, поиском опечаток, строгим ревью в pull request.

Когда инженер сдвигает брови и всматривается в строки кода, он посылает сигнал окружению и — главное — самому себе: «Я занят тяжелым умственным трудом, я работаю, я приношу пользу».

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

Чтение кода глазами становится безопасной гаванью. Идеальная имитация бурной деятельности, защищающая от страха наказания за «ничегонеделание». Это и есть театр трудоустройства — видимая занятость вместо невидимой, но реальной работы.

Причина вторая: кризис идентичности

Есть слой глубже.

В IT-культуре годами ковался культ технаря. Программисты привыкли считать себя единственными настоящими творцами, а людей, которые пишут задачи, формулируют ТЗ и собирают требования, — кем-то вроде обслуживающего персонала второго сорта. В кулуарах ходили шутки про «бесполезных эффективных менеджеров», которые ничего не создают руками, а только двигают карточки в Jira.

И вот наступает эпоха AI. Разработчику говорят: «Писать базовый код теперь умеет машина. Твоя новая роль — четко декомпозировать проблему, сформировать контракты взаимодействия, написать критерии успеха и валидировать результат».

В этот момент в голове разработчика происходит короткое замыкание.

Принять эту роль означает признать: теперь нужно заниматься ровно тем, что презиралось всю жизнь. Инженерное эго сопротивляется: «Я создатель, я пишу код. Я не буду писать какие-то бумажки для машины — я лучше сам посмотрю строчка за строчкой, что она там навыдавала».

Это защитная реакция идентичности, не рациональный выбор.

Ловушка

Ревьюить AI-код глазами — иллюзия контроля.

Человеческий мозг устроен так, что легко пропускает тонкие архитектурные баги и утечки памяти в красиво отформатированном тексте от ИИ. Наступает синдром галлюцинации доверия: выглядит красиво — значит работает. AI-генерированный код часто выглядит лучше написанного человеком — единый стиль, конвенциональные имена, никаких авторских странностей в структуре. Мозг читает «аккуратность» как «корректность». Это и есть механизм ловушки.

В итоге разработчик оказывается в худшем из миров:

  • Выгорает от бесконечного вычитывания чужого кода.
  • Теряет ту самую скорость, ради которой покупал AI-инструменты.
  • Продолжает выполнять работу человеческого линтера — самую неблагодарную функцию в системе.
  • Пропускает баги, которые автоматический тест поймал бы немедленно.

Замкнутый круг: страх написать критерии → чтение кода вместо → пропуск реальных багов → разочарование в AI → ещё больше ручного контроля → ещё больше выгорания.

Что на самом деле является инженерной работой

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

Что ценнее: разработчик, который сам напишет правильный код? Или разработчик, который опишет проблему так точно, что любой инструмент — нейросеть, джун, аутсорс — выдаст правильный код с первого раза?

Второй вариант масштабируется. Первый — нет.

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

Инженерная идентичность не исчезает — она апгрейдится.

Инструмент вырос. Роль выросла вместе с ним.

Leave a Reply

Your email address will not be published. Required fields are marked *