Инженерное суждение становится главным дефицитом

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

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

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

Новый на вид сервис уже может быть production-critical. Старый endpoint может выглядеть как мусор, но обслуживать важного клиента. Миграция может быть частью реальной истории данных, а может быть следом вчерашнего прототипа. Зелёный тест может быть достаточным доказательством для одного изменения и почти ничего не значить для другого.

Эти различия существуют не только в коде. Они живут в бизнес-контексте, договорённостях, стоимости ошибки, текущем состоянии системы и знаниях людей вокруг неё.

Поэтому всё важнее становится не способность лично выполнить работу, а способность ответить на вопросы вроде:

• что здесь является настоящим контрактом;
• что можно безопасно сломать;
• какой риск допустим;
• где достаточно автоматической проверки, а где нужен человек;
• когда стандартный workflow помогает, а когда начинает мешать;
• какой контекст агенту действительно нужен;
• какое решение можно принять локально, а какое требует эскалации.

Отсюда меняется и смысл seniority.

Разница между junior и senior может всё меньше заключаться в том, что senior быстрее пишет сложный код. Код всё чаще будет писать одна и та же машина.

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

Junior работает внутри уже заданной области и должен понимать, когда результат агента подозрителен.

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

Lead или staff-инженер отвечает уже не только за отдельное решение, а за то, чтобы команда вообще принимала такие решения безопасно: где нужны guardrails, какие ошибки должны автоматически становиться новыми правилами, где автономию можно расширить, а где её нужно ограничить.

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

При этом сегодняшние способы организации агентной разработки сами могут быстро устареть.

Через несколько лет могут исчезнуть отдельные playbook-файлы, ручные MCP-настройки и явное переключение между агентами. Контекст начнёт собираться автоматически, policies станут частью платформы, а большая часть оркестрации уйдёт под интерфейс.

Это не так важно.

Если гипотеза верна, сохранится другое: кто-то всё равно должен понимать, когда default перестал быть правильным.

Именно здесь остаётся человеческая работа, которую сложнее всего стандартизировать. Хорошая корпоративная среда сможет закрыть множество повторяемых ошибок, но она не сможет заранее описать все будущие исключения. Более того, слишком успешный playbook сам рискует превратиться в новый ритуал: правило продолжают соблюдать уже после того, как исчезла причина, ради которой оно появилось.

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

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