Как ИИ изменил нагрузку (и откуда взялся демпинг)

Дисклеймер: В этой статье нет названий компаний. Это собирательный образ того, во что превратился процесс найма. Если вам показалось, что вы узнали себя — вам не показалось.

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

Откуда взялся демпинг? Бизнес попал в ловушку метрик. Менеджмент видит, что скорость генерации строк кода выросла в разы, и считает, что разработка стала дешевой и простой. Раз «код пишется сам», значит, ценность программиста упала — отсюда и попытки демпинговать рынок, срезая офферы на 25%. Но это иллюзия. Бизнес не понимает, что ИИ увеличил скорость создания хаоса, а не готовых систем. И вместо проверки системного мышления ^[1] — того, как архитектор наводит порядок в ИИ-хаосе, — на техсобесах продолжают устраивать школьные викторины. Этот перекос отлично проявился на задании с «Code Review».

Мне 48. Больше 25 лет я в бэкенде: проектирование систем, интеграции, оптимизация. За плечами — платформа, прошедшая технический Due Diligence и проданная за $4.5M. Последние месяцы я не работал в найме: восстанавливался после тяжёлого периода и строил свой open-source оркестратор на PHP 8.4 / Swoole / Go с PHPStan Level 10.

Когда я вернулся на рынок, я ожидал увидеть изменившийся процесс найма. Но увидел другое: викторины, угадайки и демпинг.

Игра в угадайку

Меня собеседовала продуктовая компания. Интервью вели коллеги с опытом ^[2], но явно заточенным под другой контекст.

Само интервью превратилось в викторину, где наниматель сидел со списком «правильных ответов» и ждал, что я угадаю его ассоциативный ^[3] ряд.

Пять «платёжек»

• Интервьюер (И): Есть несколько сущностей, какой паттерн применишь?

• Я: Можно конкретнее?

• И: Есть пять ПЛАТЁЖЕК. Какой паттерн?

• Я: (такс, значит речь идёт о платёжных поручениях, но при чём тут паттерны?) Хм… Ну, наверное, интерфейс с методом «pay» и, может быть, абстрактный класс (просто ляпнул, не став задавать уточняющий вопрос второй раз).

Уже после собеседования, обсудив с DeepSeek, я понял, что речь скорее всего шла о платёжных системах (payment gateways) и паттернах «Стратегия» и «Фабрика». За 25 лет я впервые слышу слово «платёжка» в контексте платёжных систем.

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

• вот тут нужен интерфейс, чтобы не зависеть от конкретики;

• здесь — изолированный сервис, чтобы не раздувать контроллер;

• здесь — очередь, чтобы не держать синхронно;

• здесь — DTO, чтобы не таскать массив.

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

Опросник на память

Дальше — стандартный опросник на механическую память ^[4]:

• И: Какой порядок выполнения операторов в MySQL?

• Я: А что такое операторы в MySQL запросе?

• И: (объяснил про SELECT, WHERE конструкции в SQL-запросе) Если в SELECT есть alias, можно ли его использовать в WHERE?

Интервьюер проверял знание спецификации парсера СУБД на память. В реальной работе инженер не гадает у доски, как именно отработает синтаксис — он пишет предсказуемый и читаемый код, а любые тонкости реализации проверяет за секунду в консоли или через EXPLAIN. Я ответил, что можно, не став тратить время на ментальную компиляцию (в MySQL алиас из SELECT в WHERE использовать нельзя, так как WHERE выполняется раньше). Но суть в другом: этот вопрос проверяет навык зазубривания учебника, а не умение писать оптимальные запросы для highload-систем.

Очередной вопрос:

• И: Что за класс Error в PHP 8?

• Я: Я не помню, в моём последнем проекте ни разу не возникало подобных ошибок (PHPStan level 10).

Интервьюер ждал, что я начну цитировать справочник и расписывать иерархию классов, реализующих Throwable (хотя на практике любой нормальный бэкендер для отлова всех рантайм-проблем просто ставит Throwable на автомате). При строгом статическом анализе на Level 10 с кодом, вылизанным до нуля ignore-строк, ты просто забываешь о существовании внутренних фаталов языка — они отсекаются ещё до деплоя.

И снова вопрос:

• И: В чём разница между моком и стабом?

• Я: Не помню, я писал тесты последний раз руками около года назад.

Вопрос про индексы

Дальше — вопрос, который окончательно добил:

• И: В каком случае индекс в БД не будет использоваться?

• Я: Запущу EXPLAIN и посмотрю, что покажет.

• И: Ну а если там будет Full Table Scan?

• И: Например, если в запросе LIKE.

• Я: Если поиск не с начала строки, индекс не сработает. Нужен FULLTEXT индекс.

Стоп. Зачем спрашивать, когда индекс не используется? Моя задача — чтобы он использовался. Я 25 лет пишу запросы так, чтобы база не умирала. А меня спрашивают, как её убить. Это как учить хирурга оставлять скальпель в пациенте.

«Code Review»

Финалом было тестовое на «Code Review». По факту — кусок хаотичного кода, собранный из всех возможных плохих практик: запрос в контроллере без валидации, отправка уведомлений в бизнес-методе, отсутствие DTO, N+1.

Это была задача для мидлов на внимательность внутри архитектурной помойки. В нормальной команде такой пул-реквест возвращается автору с одной фразой: «Удали и перепиши с нуля».

Я начал вслух набрасывать нормальную архитектуру: вынос тяжёлых синхронных процессов в очереди, лечение N+1 через жадную загрузку (with), оптимизация выборок чанками через ORDER BY. Когда здание горит, инженер тушит пожар и перестраивает несущие конструкции, а не ищет глазами инвентарные таблички на мебели.

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

Как должно быть на самом деле

Для контраста: вчера я делал тестовое задание на Code Review, на которое потратил честные шесть часов. И это было нормально.

Это был сложный модуль каскадного удаления сущностей. Внутри — классическая боль ^[5]: рефлексия в циклах, магические массивы с числовыми индексами, сырые SQL-запросы, N+1, отсутствие DTO, слабая типизация.

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

Я не играл в угадайку. Я разбирал архитектуру:

• вынес настройки many-to-many в отдельный Value Object;

• заменил «кучку аргументов» на DTO;

• убрал рефлексию, заменил на Doctrine Metadata;

• поправил сырые SQL-запросы, добавил нормальную типизацию;

• привёл PHPDoc в порядок.

Это проверка уровня, а не тест на усидчивость.

«Для статистики»

Через день HR пишет:

«Согласились бы вы на оффер на 25% ниже ваших ожиданий? Мне просто нужно для статистики)»

Мой ответ был коротким: «Нет. Озвученная сумма была абсолютным минимумом».

Сильные инженеры не работают за еду