Кто вырастит будущих сеньоров, если код теперь пишет AI?
Генеративные инструменты заметно ускорили разработку. Они создают компоненты, предлагают архитектуру, пишут тесты, формируют миграции и способны за минуты собрать прототип, на который раньше уходили дни. Однако высокая скорость получения результата не означает автоматического роста инженера.
Проблема особенно заметна на начальных этапах карьеры. Новичок может получить убедительный интерфейс, рабочий endpoint или подключенную авторизацию еще до того, как научится понимать, почему решение устроено именно так и в каких условиях оно перестанет работать. Если разработчик постоянно передает машине самые сложные мыслительные операции, у него не формируется навык самостоятельного анализа.
AI не стирает различия между начинающим и опытным инженером. Он в первую очередь сокращает разрыв в скорости написания кода. Зато сильнее проявляется разница в качестве решений. Один человек видит в ответе модели готовую функцию. Другой - только гипотезу, которую предстоит проверить: где находится граница доверия, какие данные доступны пользователю, что произойдет при повторном запросе, как откатить миграцию и какой сценарий первым приведет систему к отказу.
Один инструмент - две разные профессии
Представим одинаковую задачу: добавить авторизацию и разделить данные клиентов в B2B-сервисе.
Начинающий разработчик пишет агенту: "Сделай авторизацию через Supabase". Модель создает таблицы, форму входа, middleware и политики доступа. Локальный сценарий выглядит убедительно: пользователь входит в систему и видит свои записи. На этом работу можно признать завершенной - по крайней мере, визуально.
Опытный инженер использует тот же инструмент, но продолжает работу после генерации. Он разделяет authentication и authorization, проверяет политики RLS для каждой таблицы, пытается подменить `tenant_id`, анализирует обновление и отзыв токенов, проверяет анонимные ключи, добавляет негативные тесты и аудит административных операций.
Внешне оба разработчика применяли AI. Возможно, первый даже закончил быстрее. Но инженерная работа заключалась не в создании кода, а в формулировке инвариантов, поиске уязвимых мест, построении системы проверок и принятии решения о выпуске.
Раньше преимущество senior-инженера часто было заметно непосредственно в процессе программирования: он быстрее писал код, лучше помнил библиотеки, узнавал типовые ошибки и мог сразу выбрать подходящий шаблон. Теперь значительная часть этой работы делегируется модели. Поэтому ценность смещается к менее заметным навыкам:
- превращению расплывчатого запроса в набор проверяемых требований;
- выявлению отсутствующих условий;
- пониманию отказов, рисков, данных и эксплуатации;
- умению определить глубину необходимой проверки;
- способности остановить релиз, даже если интерфейс уже выглядит готовым.
Стаж сам по себе не делает человека сильным инженером. Но опыт решений, ошибок, инцидентов и ревью формирует внутреннюю библиотеку паттернов. Ее нельзя заменить универсальной командой "проверь весь код".
Парадокс хорошего промпта
Иногда агент отказывается продолжать работу, пока разработчик не устранит противоречия в правилах функции. Это выглядит как признак автономности системы. Но подобная проверка возможна только тогда, когда человек заранее описал сами правила.
В этом и состоит парадокс генеративной разработки: чем хуже разработчик понимает предметную область, тем труднее ему составить качественные инструкции и оценить полноту результата. Хороший промпт не возникает из пустоты. Он требует модели данных, понимания ограничений, знания бизнес-логики и представления о том, какие ошибки наиболее опасны.
Фраза "агент сам все проверит" часто скрывает главный вопрос: кто определил критерии правильности? Модель может сверить реализацию с указанными условиями, но не всегда обнаружит, что одно из критически важных условий вообще не было названо.
Модель может знать правило и нарушить его
Генеративная система способна правильно объяснить принцип в одном сообщении, а затем нарушить его в следующем фрагменте кода. Она может предупредить о необходимости валидации входных данных и тут же создать endpoint без проверки. Может рассказать о принципе наименьших привилегий, но выдать чрезмерно широкие права для удобства демонстрации.
Причина не обязательно в "непонимании" правила. Модель оптимизирует текущий ответ, а не несет ответственность за систему в целом. Контекст может измениться, важное ограничение - потеряться, а локально удобное решение - вступить в конфликт с требованиями безопасности.
Поэтому объяснение модели нельзя считать доказательством корректности. Нужны исполняемые проверки: тесты, типизация, линтеры, анализ зависимостей, сканирование секретов, ограничения доступа, наблюдаемость и ручное ревью критических участков.
AI убирает трение, но часть трения была обучением
Ручное написание типового кода действительно не всегда развивает инженера. Однако не всякая медленная работа бесполезна. Когда разработчик самостоятельно реализует функцию, он вынужден столкнуться с типами данных, ошибками, неочевидными ограничениями и последствиями выбранного подхода.
Если модель сразу выдает готовый результат, часть полезного напряжения исчезает. Новичок может не увидеть, почему запрос сформирован именно так, где происходит преобразование данных и какие допущения заложены в решении. Он получает рабочий артефакт, но не проходит путь, который обычно превращает ошибку в понимание.
Значит, задача обучения - не вернуть искусственные страдания, а сохранить осмысленную практику. Иногда студенту или начинающему разработчику полезно сначала самостоятельно спроектировать решение, написать небольшую версию без агента, сформулировать тесты и только потом использовать AI для сравнения, улучшения и поиска пропусков.
Скорость сложнее, чем кажется
Быстрее написать код - не значит быстрее доставить ценность. Короткий путь до первого результата может увеличить время на исправление, поддержку и расследование инцидентов.
AI ускоряет создание кода, но не отменяет:
- уточнение требований;
- согласование интерфейсов;
- проверку безопасности;
- миграции данных;
- нагрузочное тестирование;
- выпуск и откат;
- мониторинг;
- сопровождение после релиза.
Если команда генерирует больше изменений, чем способна проверить, скорость превращается в накопление технического риска. Поэтому измерять эффективность только числом строк или количеством закрытых задач опасно. Важнее отслеживать дефекты после релиза, время восстановления, частоту откатов, качество тестового покрытия и объем ручной проверки.
Исчезает не junior, а безопасная простая работа
Профессия начинающего разработчика не исчезает полностью. Но сокращается доля задач, которые раньше служили относительно безопасной тренировочной площадкой: простые CRUD-операции, несложные формы, типовые интеграции и небольшие исправления.
Это создает проблему входа в профессию. Новичку дают не меньше ответственности, а меньше времени на постепенное освоение базовых навыков. Он может быстро получить доступ к производственным системам, но еще не иметь опыта оценки последствий.
Выходом становится не запрет AI, а явная градация ответственности. Начинающие разработчики должны работать с ограниченными контурами, небольшими изменениями, обязательными тестами и обязательным разбором решений. Наставник должен оценивать не только итоговый код, но и ход рассуждений: какие риски были замечены, какие сценарии проверены и почему выбран именно такой вариант.
Human in the loop - это не кнопка Approve
Присутствие человека в процессе не означает, что он формально нажимает кнопку подтверждения. Если ревьюер не понимает код и проверяет его только по внешнему виду, человеческий контроль становится декорацией.
Настоящий human in the loop включает постановку задачи, определение критериев приемки, выбор уровня риска, проверку граничных случаев, анализ изменений и право остановить выпуск. В критических системах нужны разные роли: автор решения, его проверяющий и человек, отвечающий за эксплуатационные последствия.
Полезно требовать от AI не только итоговый код, но и описание допущений, список измененных файлов, потенциальные риски, негативные сценарии и рекомендации по откату. Это не заменяет экспертизу, но делает проверку предметнее.
Как использовать AI для роста компетентности
Генеративный инструмент способен быть не только заменой исполнителя, но и тренировочным партнером. Для этого меняется порядок взаимодействия.
Сначала разработчик формулирует собственное решение: структуру данных, API, ограничения и список рисков. Затем просит модель найти слабые места, предложить альтернативы или сыграть роль недоброжелательного ревьюера. После генерации необходимо самостоятельно объяснить код, написать тесты и проверить, соответствует ли реализация исходным инвариантам.
Полезны режимы, в которых AI не выдает готовый ответ сразу:
1. задает уточняющие вопросы;
2. просит назвать критерии успеха;
3. предлагает несколько вариантов с компромиссами;
4. намеренно ищет контрпримеры;
5. объясняет, какие требования остались непроверенными;
6. генерирует тесты раньше основной реализации.
Так инструмент поддерживает развитие суждения, а не только скорость печати.
Что придется изменить командам
Компаниям придется пересмотреть систему подготовки инженеров. Раньше начинающему специалисту можно было постепенно поручать более сложные задачи по мере того, как он демонстрировал качество кода. Теперь нужно оценивать более широкий набор навыков: понимание архитектуры, безопасность, способность работать с неопределенностью, качество проверок и умение объяснять решения.
В командах полезно ввести обязательные design notes для заметных изменений, практику разбора сгенерированного кода и регулярные занятия по отказам. Хороший onboarding должен включать не только знакомство с репозиторием, но и изучение инцидентов, доменных ограничений, процесса релиза и правил отката.
Особенно важны небольшие автономные задания с контролируемым риском. Новичок должен не просто "попросить агента сделать фичу", а пройти полный цикл: понять требование, предложить план, получить реализацию, проверить ее, оформить наблюдаемость и объяснить, как система поведет себя при сбое.
Новая лестница компетенций
Классическая последовательность "синтаксис - фреймворк - архитектура" становится недостаточной. Новая лестница может выглядеть так:
- понимание предметной области и данных;
- формулировка требований и инвариантов;
- способность читать и объяснять сгенерированный код;
- построение тестов и проверок;
- оценка безопасности и эксплуатационных рисков;
- управление агентом и контекстом;
- принятие решений при неполной информации;
- ответственность за последствия выпуска.
На нижних уровнях AI помогает быстрее получать обратную связь. На верхних - становится инструментом анализа вариантов. Но переход между уровнями не происходит автоматически. Его нужно проектировать через практику, ревью и ответственность.
Откуда возьмутся будущие сеньоры?
Будущие senior-инженеры появятся не вопреки AI, а благодаря правильной организации работы с ним. Они вырастут там, где генерация не подменяет обучение, а делает его интенсивнее; где новичку разрешают ошибаться в безопасном контуре; где от него требуют не только работающий результат, но и доказательство его надежности.
AI уже умеет быстро писать код. Значит, инженерная ценность все меньше определяется объемом напечатанного текста. На первый план выходят постановка задачи, понимание ограничений, проверка гипотез, способность предвидеть сбои и готовность не выпускать решение, которому нельзя доверять.
Главный вопрос теперь звучит иначе: не кто напишет код, а кто научит людей понимать, проверять и безопасно применять то, что написала машина. Именно от ответа на него зависит, станет ли AI усилителем инженерной культуры или способом массово производить уверенно выглядящие ошибки.
