Кто вырастит будущих сеньоров, если код теперь пишет ИИ?

В комментариях к статье на Habr о генеративной разработке развернулась дискуссия, которая оказалась содержательнее исходного текста. Читатели заметили: дело не в самом вайбкодинге, а в опыте человека, который им занимается. Опытный инженер может открыть Cursor, Claude Code, Copilot или Codex, сформулировать задачу и принять большой кусок сгенерированного кода, иногда печатая руками меньше новичка. Противопоставление «настоящая разработка против ИИ» перестало описывать реальность: граница проходит не между инструментами, а между подходами к результату.

Один человек получает правдоподобный ответ и видит готовую фичу. Другой видит гипотезу, которую нужно проверить: где проходит trust boundary, что произойдет при повторном запросе, кто владеет данными, как откатится миграция, что попадет в метрики и какой сценарий сломается первым. ИИ не уравнивает новичка и опытного инженера — он убирает разницу в скорости набора кода и делает заметнее разницу в качестве суждения. Возникает вопрос: если начинающие разработчики получают правильноподобный результат до того, как научились разбирать собственные ошибки, откуда через пять лет возьмутся люди, способные этот результат проверять?

Рассмотрим пример из обсуждения: двум разработчикам дали задачу добавить авторизацию и разделить данные клиентов в B2B-сервисе. Первый пишет: «Сделай авторизацию через Supabase». Агент создает таблицы, middleware, форму входа и несколько политик доступа. Локально все работает, один пользователь видит свои записи — задача закрыта. Второй начинает с того же запроса, но его работа начинается после генерации: он спрашивает, где заканчивается authentication и начинается authorization, проверяет RLS для каждой таблицы, пробует подменить tenant_id, разбирает refresh и revoke токенов, смотрит, какие endpoints доступны анонимному ключу, добавляет негативные тесты и аудит административных действий. Внешне оба использовали ИИ, первый мог получить результат быстрее, но второй выполнил инженерную работу: сформулировал инварианты, обнаружил границы доверия, построил проверку и взял на себя решение о выпуске.

Раньше часть этой разницы была видна в самом коде: senior писал быстрее, знал библиотеки, помнил синтаксис и узнавал типичные ошибки. Теперь синтаксическая фора уменьшается, ценность смещается к тому, что трудно увидеть на демо: умению превратить размытое пожелание в проверяемые требования, способности заметить отсутствующее условие, пониманию failure modes, данных, безопасности и эксплуатации, калиброванному недоверию и готовности остановить релиз, когда интерфейс уже выглядит готовым. Это не романтизация стажа: двадцать лет работы сами по себе ничего не гарантируют, но опыт, накопленный через решения, ошибки, инциденты и review, создает библиотеку паттернов, которую невозможно заменить общим промптом «проверь все».

В обсуждении первой части один читатель описал агентный workflow, который второй день отказывался продолжать, пока автор не устранит противоречия в правилах фичи. Ему ответили: ключевые слова — «которые я ему задал». Чтобы агент нашел противоречие, человек сначала должен знать, какие правила вообще существуют. Отсюда парадокс генеративной разработки: чем меньше разработчик понимает предметную область, тем сложнее ему сформулировать хороший запрос, а чем лучше понимает, тем меньше магии остается в запросе. Хороший промпт превращается в компактную техническую спецификацию. Для атомарного счетчика мало написать «увеличивай count безопасно» — нужно определить конкурентные записи, транзакционную границу, семантику повторной доставки, допустимость lost update, поведение при retry и источник истины. Для платежа мало попросить «не списывать дважды» — нужны idempotency key, состояние операции, срок хранения ключа, правила reconciliation и ответ на вопрос, что делать после timeout неизвестного исхода.

Спецификация без противоречий при этом может быть полностью неправильной: можно безупречно описать систему, которая теряет деньги. Модель способна проверить соответствие кода тексту, но ей труднее сообщить о требовании, которого нет ни в тексте, ни в контексте. Чтобы задать ИИ правильный вопрос, часто нужно уже знать значительную часть ответа. Поэтому prompt engineering не заменяет предметную экспертизу — он делает ее интерфейсом. Если за интерфейсом пусто, модель получает красиво сформулированную неопределенность.

Для индустрии это означает сдвиг в обучении и найме. Учебные программы, ориентированные на синтаксис и типовые задачи, устаревают быстрее, чем раньше. Вместо этого нужно учить проверять гипотезы, искать отсутствующие условия, работать с безопасностью и данными. Компании, которые полагаются на ИИ как на способ сэкономить на старших инженерах, рискуют через несколько лет остаться без людей, способных оценить качество сгенерированного кода. Пока же рынок находится в переходной фазе: инструменты развиваются быстрее, чем методики подготовки кадров, и ответ на вопрос «кто вырастит будущих сеньоров» остается открытым.