Minority report: Когда код стал дешёвым: где теперь ценность, ответственность и экспертиза?

Название формата я взял из двух историй, которые давно живут у меня в канале. Первая — приложение Ричарда Фейнмана к отчёту комиссии по гибели «Челленджера». Его выводы о том, как в NASA оценивали риск, не хотели включать в основной текст, и он добился, чтобы особое мнение вошло в официальный отчёт хотя бы приложением. Вторая — фильм «Особое мнение», в котором предиктивная система кажется идеальной ровно до момента, когда её предсказания начинают создавать то, что предсказывают. Обе истории про одно: письменная позиция, зафиксированная до того, как система вынесла вердикт, и честное отношение к метрикам, которые умеют превращаться в самосбывающееся пророчество.010101В канале я переводил историю Фейнмана на инженерный язык: он участвовал в написании постмортема по инциденту, его мнение не хотели учитывать в официальном отчёте, и он добился включения в приложение. Фильм разбирал вместе с «Moneyball» как две противоположные истории про предсказания: одна про недооценённых игроков, другая про пророчество, которое сбывается само.Книжный куб · Фейнман и особое мнение о «Челленджере»Книжный куб · «Moneyball» и «Особое мнение»01В канале я переводил историю Фейнмана на инженерный язык: он участвовал в написании постмортема по инциденту, его мнение не хотели учитывать в официальном отчёте, и он добился включения в приложение. Фильм разбирал вместе с «Moneyball» как две противоположные истории про предсказания: одна про недооценённых игроков, другая про пророчество, которое сбывается само.Книжный куб · Фейнман и особое мнение о «Челленджере»Книжный куб · «Moneyball» и «Особое мнение»

Формат дискуссии устроен так, что консенсус в ней не ценится: после двух похожих ответов модератор пойдёт искать место, где спикеры делают по-разному. Поэтому я не пытаюсь звучать сбалансированно. На каждый блок у меня одна позиция, один кейс последних шести–двенадцати месяцев и одно условие, при котором я позицию поменяю. Если условие наступит, это будет видно по этому тексту, а не по моим воспоминаниям о вечере.

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

Разогрев просит выбрать одно из пяти мест: выбор задачи, реализация, ревью и проверки, доставка в продакшен, эксплуатация. Мой ответ — третье, и он не изменился с апреля, когда я впервые показывал карту переезда очередей в докладе State of AI4SDLC. AI ускоряет написание кода раньше, чем организация успевает перестроить весь поток. Очередь не исчезает — она переезжает туда, где изменение нужно доказать: в постановку, ревью, тесты, интеграцию и выпуск. Команда производит больше изменений и при этом не быстрее доставляет ценность.020202Разбирал в канале, когда вышла запись доклада с Saint HighLoad++: три практических сдвига — от ролей к агентам, от набора инструментов к платформе, от метрик использования к метрикам результата. Именно там впервые проговорил лестницу доверия «чтение → рекомендация → действие».Книжный куб · State of AI4SDLC на HighLoad++02Разбирал в канале, когда вышла запись доклада с Saint HighLoad++: три практических сдвига — от ролей к агентам, от набора инструментов к платформе, от метрик использования к метрикам результата. Именно там впервые проговорил лестницу доверия «чтение → рекомендация → действие».Книжный куб · State of AI4SDLC на HighLoad++

Важная оговорка про этап «выбор задачи». Когда первый вариант решения становится почти бесплатным, узкое место частично утекает вверх по потоку: организации, которые не умеют отказываться от задач и закрывать лишние функции, получают больше вариантов и ни одного отказа. Но я не стал бы называть это главным узким местом сегодня. Главное — ниже: изменение, которое нужно проверить, принять и выпустить, и очередь на этот шаг видна в любых данных 2026 года, от телеметрии DX до опросов GitLab.

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

Карта позиций: с кем я готов спорить

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

Главный вопрос блока — во что реально превратилось ускорение: в меньшее время от задачи до выпуска, в меньшую стоимость принятого изменения, в лучшее качество или в больше проверенных гипотез. Моя позиция: там, где контур поставки не перестраивали, ускорение конвертировалось в объём. Больше кода, более крупные изменения, больше запросов на слияние — и примерно то же время до пользователя. Там, где контур перестроили, конвертация есть, но она измеряется не токенами, а принятой работой.

Активность — не результат

Использование AI, число строк и запросов на слияние — это активность. Единица результата — полезное изменение, прошедшее путь до проверки и принятия. В разборе экономики AI в разработке я предлагал считать управленческой единицей принятую задачу: в числителе — модель, инструменты, проверка человеком, переделка и ожидаемая цена ошибки, в знаменателе — только задачи, прошедшие приёмку. Такой знаменатель неудобен именно тем, что его нельзя накрутить генерацией.

Данные за последний год складываются в одну картину. По телеметрии DX за четыре квартала медианная пропускная способность выросла на 37%, с 1,42 до 1,94 запроса на слияние на инженера в неделю, но медианный размер изменения вырос с 44 до 72 строк, время ревью ухудшилось, а уверенность разработчиков в том, что изменение не сломает продакшен, снизилась на 6,1% — при том, что понятность кода выросла на 3,8%. DORA в отчёте 2025 года прямо говорит, что AI усиливает и сильные, и слабые стороны системы поставки, и показывает небольшое снижение пропускной способности и заметное снижение стабильности при росте внедрения.030303Про отчёт DX писал отдельно: между «я прочитал изменение» и «я доверяю ему в продакшене» лежат тесты, ревью, архитектурный контекст и ответственность. А у Джеффри Литта из Notion взял формулу, которая мне нравится больше всех: делегировать можно исполнение, но не владение системой.Книжный куб · DX Q2 2026: кода больше, доверия меньшеКнижный куб · Понимание — новое узкое место03Про отчёт DX писал отдельно: между «я прочитал изменение» и «я доверяю ему в продакшене» лежат тесты, ревью, архитектурный контекст и ответственность. А у Джеффри Литта из Notion взял формулу, которая мне нравится больше всех: делегировать можно исполнение, но не владение системой.Книжный куб · DX Q2 2026: кода больше, доверия меньшеКнижный куб · Понимание — новое узкое место

Пять адресов, по которым переезжает очередь

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

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

Очередь переехала в ревью, тесты и выпуск, и у неё должен появиться владелец. Не в смысле человека, который её разгребает, а в смысле того, кто отвечает за сквозной результат: от гипотезы до принятого бизнесом изменения. В разборе playbook AI-native SDLC мы с Антоном Костериным проверяли, переносится ли это в регулируемую компанию, и сошлись на двух вещах. Первая: параллелизм агентов ограничен ёмкостью ревью, поэтому начинать стоит с двух–трёх потоков, а не с двадцати. Вторая: к метрикам DORA нужно добавить переделки, связанные с AI, задержку ревью, пропущенные дефекты, исключения из политик и время от инцидента до проверки.

Если выпускать функции стало дешевле, дороже становится выбор задачи и отказ от лишнего. Это не абстракция. DX оценивает, что пользователи AI экономят четыре–шесть часов в неделю, но доля времени на новую функциональность за год не изменилась: освободившиеся часы съели существующие очереди. Организация, которая не умеет закрывать функции, просто быстрее наполняет продукт тем, что потом придётся сопровождать. Поэтому в моей модели владелец результата отвечает не до слияния, а до бизнес-результата — и имеет право сказать «эту задачу мы не делаем».

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

Кейс: что изменилось до и после

Самый конкретный опубликованный кейс у меня — платформа большого финтеха, которую я показывал на Saint HighLoad++ в июне. До: у каждого инженера свой ассистент, десятки подключённых инструментов, метрика — доля принятых подсказок. После: набор доменных агентов на общей платформе с модельным и инструментальным шлюзами, общими политиками и телеметрией. Агент режима «задача → запрос на слияние» на внутренней платформе разработки, генератор модульных тестов, который даёт около десятой части всех запросов на слияние, AI-ревью, агенты безопасности и проверка контрактов API — не один универсальный помощник, а контур, в котором у каждого действия есть владелец и набор проверок. Что изменилось в измерении: вместо доли принятых подсказок — ожидание в ревью и конвейере, переделки, время безопасного изменения и дефекты. Что не изменилось: выпуск в продакшен по-прежнему проходит человек.

Что я перестал делать

За последние полгода я последовательно убрал из своих докладов и исследований долю AI-кода как показатель. В апрельской деке про AI-native измерение она ещё обсуждалась как «удобная, но опасная»; в летних версиях State of AI4SDLC для HighLoad++ и ИТ-Пикника её место заняли ожидание в ревью и конвейере, переделки, время безопасного изменения и дефекты. В втором выпуске «3 AImigo» мы разбирали то же на контрасте маленькой команды, выросшей вместе с агентами, и большой организации: у первой узкое место в контексте, у второй — в ревью и тестировании, и ни у одной — в написании кода.040404Этот пост я написал после кулуаров HighLoad++: сожжённые токены на сотрудника — это корпоративное доказательство работы, а не ценности. Оно нравится, потому что организационно дешевле: не надо договариваться, что такое ценность, и чистить данные.Книжный куб · Token burn как proof of work04Этот пост я написал после кулуаров HighLoad++: сожжённые токены на сотрудника — это корпоративное доказательство работы, а не ценности. Оно нравится, потому что организационно дешевле: не надо договариваться, что такое ценность, и чистить данные.Книжный куб · Token burn как proof of work

Условие смены позиции: компания на реальном распределении задач покажет одновременный рост пропускной способности и стабильности по DORA после внедрения агентов без перестройки ревью, тестов и выпуска. Пока таких данных нет ни в DX, ни в DORA, ни в вендорских отчётах.

Главный вопрос блока: если у инженера есть право выполнить действие, должен ли его агент автоматически получать такое же право. Моя позиция — нет, и это не осторожность, а следствие того, как устроены агенты. Модель прав для людей предполагает, что субъект действует медленно, последовательно и предсказуемо: один человек, один сеанс, понятная цепочка намерений. Агент действует быстро, параллельно и вероятностно: десять запусков одной задачи дают десять разных траекторий, и часть из них выполнит действие, которое человек с теми же правами никогда бы не выполнил.

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

Поэтому права должны выдаваться не агенту целиком, а классу действий в конкретном контексте — под отдельной идентичностью на задачу. В разборе конфигураций агентного стека я описывал это как кортеж «обвязка × модель × инструменты × идентичность × технически обеспеченные границы»: шлюз выпускает для агента короткоживущий токен от имени инициатора задачи, а не безликую общую служебную учётную запись, и атакуют в таком стеке не модель, а цепочку полномочий. Защита ставится на границах данных, идентичности и исполнения — и должна быть технической, а не только промптовой.050505В подкасте с Евгением Кокуйкиным мы сошлись на том, что агент в SDLC похож на внутреннего сотрудника или служебную учётную запись, а не на подсказку в IDE. И на неприятном следствии: если каждое опасное действие агента уезжает на подтверждение старшим, узкое место просто переехало к самым загруженным людям.Книжный куб · Евгений Кокуйкин про AI Security05В подкасте с Евгением Кокуйкиным мы сошлись на том, что агент в SDLC похож на внутреннего сотрудника или служебную учётную запись, а не на подсказку в IDE. И на неприятном следствии: если каждое опасное действие агента уезжает на подтверждение старшим, узкое место просто переехало к самым загруженным людям.Книжный куб · Евгений Кокуйкин про AI Security

Лестница выше — моя рабочая модель, а не стандарт. Три уровня доверия — read → recommend → act — я впервые показывал в докладе на HighLoad++, а разложение по классам действий добавил для этой дискуссии. Чтение контекста, изменение кода в ветке, запуск CI и создание запроса на слияние агент сегодня выполняет сам — при условии, что у него есть идентичность, квоты, телеметрия и маркер участия в запросе. Слияние и изменения тестового окружения он рекомендует: план, пробный прогон и откат готовит агент, а риск принимает владелец. Продакшен — только чтение: агент собирает доказательства и план отката, но гейт выпуска проходит человек.

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

В какой момент человек обязан явно дать согласие? В моей модели — на каждой ступени, где действие меняет состояние, которое нельзя дёшево откатить, или где семантика доменная: деньги, доступы, данные, SLO. Это совпадает с тем, как playbook Anthropic формулирует границу для выпуска: автономия заканчивается там, где риск не делегирован. И с тем, что я видел в опросах: по данным нулевой линии, 63% разработчиков редко или никогда не запускают агента полностью автономно, а 60% блокируют неподтверждённые изменения. Рынок уже стоит на этой лестнице, просто не называет её.

Второй вопрос блока острее: обязан ли человек читать весь код, или контроль можно построить вокруг плана, тестов, поведения и рисков. Моя позиция: ревью — не очередь, а механизм контроля, и его нужно перестроить вокруг критерия правильности. Человек, который читает каждую строку агентного изменения, воспроизводит старую очередь на новом объёме и в итоге перестаёт читать вообще. Человек, который владеет планом, исполняемыми проверками и остаточным риском, может принять решение о изменении, не читая его целиком — при условии, что проверки исполняются, а не описываются.

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

Вспомогательный вопрос модератора звучит как выбор: человек должен прочитать код или доказать корректность результата? Мой ответ — доказать, и это строже, чем прочитать. Чтение диффа даёт правдоподобие; доказательство требует исполняемой проверки, которую агент не видел, поведения, снятого в реальной среде, и явного решения о том, какой остаточный риск команда принимает. При этом от чтения я не отказываюсь совсем: выборку изменений нужно читать всегда — не для того, чтобы найти ошибку в этом конкретном изменении, а чтобы проверить, что сами проверки ещё ловят то, что должны. Это та же логика, по которой аудитор не пересчитывает каждую проводку, но обязан проверять систему контроля.

Проверяемый след

Агент должен оставлять след, по которому изменение можно восстановить: использованный контекст, выполненные действия, дифф, результаты проверок, отклонения от плана и остаточный риск. Это не пожелание, а условие ответственности. GitLab в отчёте 2026 года формулирует подотчётность через три вопроса к любой сгенерированной строке: откуда она взялась, что должна была сделать и кто отвечает за неё в продакшене. И показывает разрыв между уверенностью и практикой: 87% респондентов уверены, что найдут AI-код в инциденте за сутки, но среди организаций, у которых инцидент уже был, 34% этого сделать не смогли.060606Из отчёта GitLab я забрал не вывод «купите инструменты управления», а чеклист восстановимости: задача, контекст, инструмент, оператор, diff, ревью, тесты, проверки безопасности, подтверждение, выпуск, владелец сервиса, последствия. А из инцидента с агентами OpenAI — определение: хорошая песочница — не контейнер с моделью, а полная граница её прав, сети, состояния, данных и последствий.Книжный куб · GitLab AI Accountability ReportКнижный куб · Инцидент OpenAI и Hugging Face06Из отчёта GitLab я забрал не вывод «купите инструменты управления», а чеклист восстановимости: задача, контекст, инструмент, оператор, diff, ревью, тесты, проверки безопасности, подтверждение, выпуск, владелец сервиса, последствия. А из инцидента с агентами OpenAI — определение: хорошая песочница — не контейнер с моделью, а полная граница её прав, сети, состояния, данных и последствий.Книжный куб · GitLab AI Accountability ReportКнижный куб · Инцидент OpenAI и Hugging Face

Кто отвечает, если все проверки были зелёными

Ответ должен быть известен до инцидента, иначе он превратится в поиск виноватого. В моей модели три владельца. За изменение отвечает его человеческий владелец — тот, кто принял остаточный риск и нажал слияние; агент не бывает владельцем изменения, даже если написал его целиком. За инцидент отвечает владелец сервиса — тот, кто дежурит и знает, что значит «сломалось». За границу отвечает платформа: если агент смог сделать то, чего класс действий ему не разрешал, это дефект границы, а не инженера. Зелёные проверки при инциденте означают одно: проверки не покрывали этот класс отказа, и инцидент обязан стать воспроизводимым эпизодом в каталоге.070707У Данилы Штаня из Nebius тот же принцип звучит жёстче: автономность не убирает контроль, а переносит его к тому, кто отвечает за последствия. Его целевой протокол для запроса на слияние — маркер участия агента, сохранённая траектория сессии и обсуждение исходного намерения, а не только кода.Книжный куб · Данила Штань про инженерную ответственность07У Данилы Штаня из Nebius тот же принцип звучит жёстче: автономность не убирает контроль, а переносит его к тому, кто отвечает за последствия. Его целевой протокол для запроса на слияние — маркер участия агента, сохранённая траектория сессии и обсуждение исходного намерения, а не только кода.Книжный куб · Данила Штань про инженерную ответственность

Та же граница нужна продактам и дизайнерам, которые создают изменения через агента. Их право действовать определяется классом действия, а не должностью: прототип в песочнице — действие, изменение в продукте — рекомендация с человеческим владельцем кода. В разговоре с Альбиной Мунировой мы обсуждали, как требования превращаются в проверки и стирают границу между продактом и ML-инженером; моя позиция — граница ответственности при этом не стирается, а переезжает в контракт задачи: кто сформулировал критерий приёмки, тот и отвечает за то, что критерий был правильным.

Кейс: обвязка меняется каждые полгода, права — нет

В разборе совместно эволюционирующего стека я провёл аудит публичной истории трёх открытых агентных обвязок — Codex, Gemini CLI и OpenCode — за полгода с января по июль 2026 года. По десяти механизмам в каждом проекте нашлись три строгие замены, и в каждом — разные. Вывод для прав простой: если правила доступа и проверки живут внутри продукта, они переживут не больше одного цикла обновления. Права, идентичность, политики, эпизоды и критерии приёмки должны жить на собственных шлюзах платформы, а обвязку и модель можно менять. Внешний контрпример того же лета — инцидент с агентами OpenAI, которые вышли из изолированной на бумаге среды через общий реестр пакетов и оставили около 17 600 действий в системах Hugging Face: границу нарисовали вокруг модели, а не вокруг её прав, сети и состояния.

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

Главный вопрос блока: какая экспертиза обязательно должна остаться у человека, если агент выполняет всё большую часть реализации. Моя позиция: у человека остаётся критерий правильности — способность назвать наблюдение, которое опровергнет правдоподобный результат. Всё остальное можно делегировать по частям. Это не отменяет предметной и системной экспертизы, наоборот: без неё правдоподобное, но неверное решение агента нечем опровергнуть.

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

Куда смещается роль инженера

Сценарий дискуссии называет четыре направления смещения: постановка задачи, архитектурные решения, проверка и эксплуатация. Я бы описал это не как четыре новые обязанности, а как одну: инженер всё меньше является автором кода и всё больше — владельцем намерения. Он формулирует, что должно получиться и как это узнать, выбирает границы и компромиссы, которые модель не удержит во времени, снимает доказательства и отвечает за то, что происходит после выпуска. В нулевой линии я отмечал два новых явных амплуа, которые появляются в компаниях на этом сдвиге: инженер по развитию AI-практик, который проектирует контур работы с агентами для команды, и инженер по качеству AI-assisted разработки, который отвечает за проверки и след. Это не должности из будущего: обе уже есть в описаниях вакансий, просто пока под разными названиями.

Что человек должен уметь сделать или проверить сам, даже если агент справляется лучше? Три вещи, которые не про скорость. Первая — назвать инвариант: что в этой системе нельзя нарушить ни при каком изменении, и откуда это известно. Вторая — восстановить ход работы после сбоя: понять, на каком шаге траектория агента ушла не туда, и вернуть её, а не начать заново с более длинным запросом. Третья — принять решение о выпуске, зная, что проверки зелёные, но неполные. Агент лучше человека находит и пишет; человек лучше агента знает, чего он не знает — и именно это знание остаётся дефицитным.

Экспертиза привязана к задаче, не к должности

Самые сильные данные последнего года здесь — отчёт Anthropic о 398 тысячах сессий Claude Code, который мы разбирали с Евгением Сергеевым в двадцатом выпуске Research Insights. В типичной сессии человек принимает около 70% решений о том, что делать, а модель — около 80% решений о том, как. Подтверждённый успех растёт с экспертизой пользователя в задаче с 14,5% до 32,9%, и самый большой скачок — между новичком и просто компетентным. Важно, что экспертиза там определена по задаче, а не по грейду: старший инженер, впервые пишущий на Rust, в этих данных новичок.080808Во второй части разбора я раскладывал доказательства по уровням уверенности: и экспертиза, и успех извлечены моделью из одного транскрипта, поэтому связь между ними частично встроена в метод. Успех сессии нельзя тихо переименовать в продуктивность — но направление эффекта совпадает с тем, что я вижу в командах.Книжный куб · Claude Code и экспертиза, часть 1Книжный куб · Claude Code и экспертиза, часть 208Во второй части разбора я раскладывал доказательства по уровням уверенности: и экспертиза, и успех извлечены моделью из одного транскрипта, поэтому связь между ними частично встроена в метод. Успех сессии нельзя тихо переименовать в продуктивность — но направление эффекта совпадает с тем, что я вижу в командах.Книжный куб · Claude Code и экспертиза, часть 1Книжный куб · Claude Code и экспертиза, часть 2

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

Второй вопрос блока — откуда возьмутся новые эксперты, если AI забирает простые задачи, на которых раньше учились джуны. Моя позиция: ждать, что эксперты появятся сами, больше нельзя; путь обучения нужно проектировать как производственную систему с владельцами, бюджетом и двумя табло. Это дорого, и именно поэтому большинство компаний пока предпочитает не нанимать джунов вовсе.

Данные о рынке я подробно разбирал в лонгриде и деке про джунов. Стэнфордское исследование по данным ADP показало относительное снижение занятости 22–25-летних в подверженных AI профессиях — 13% в первой версии и 19% в поздних ревизиях, при росте занятости в целом и без падения у старших. Эксперимент Anthropic на 52 инженерах показал, что группа с AI закончила задачу лишь на пару минут быстрее, но набрала 50% против 67% в тесте на понимание, и самый большой разрыв пришёлся на отладку. Первый полезный результат ускорился; самостоятельное владение системой — нет.090909Про «канареек» Бриньолфсона писал ещё в сентябре 2025-го, когда цифра была 13%; ссылка отдаёт последнюю версию, и число с тех пор выросло. Анонс эфира про джунов формулирует тот же вопрос короче: сможет ли компания выращивать сильных инженеров в мире, где первый вариант решения стал почти бесплатным.Книжный куб · Canaries in the Coal MineКнижный куб · Джун после кода в «Коде лидерства»09Про «канареек» Бриньолфсона писал ещё в сентябре 2025-го, когда цифра была 13%; ссылка отдаёт последнюю версию, и число с тех пор выросло. Анонс эфира про джунов формулирует тот же вопрос короче: сможет ли компания выращивать сильных инженеров в мире, где первый вариант решения стал почти бесплатным.Книжный куб · Canaries in the Coal MineКнижный куб · Джун после кода в «Коде лидерства»

Какую работу я оставил бы джуну

Не «простые задачи»: их действительно забирает связка «старший инженер + агент». Джуну нужно оставить учебную поверхность — шаги, на которых формируется суждение, даже если агент справляется с ними лучше.

• —Постановку и первую модель системы: до делегирования джун сам записывает, что должно получиться и как он это узнает.
• —Критерий правильности и его проверку: он называет наблюдение, которое опровергнет решение, и сам его снимает — тестом, запуском, чтением состояния.
• —Локализацию дефекта: поиск можно отдать агенту, вывод о причине — нет.
• —Выпуск маленького изменения в реальный продакшен вместе с наставником и разбор последствий после него.
• —Объяснение изменения без модели: если он не может рассказать, что и почему поменялось, изменение не принимается.

Это ученичество с AI, которое я описал в лонгриде как контур: план человека, ограниченное делегирование, проверка человеком, совместный выпуск, разбор и перенос. У него три владельца — наставник, который калибрует, руководитель, который защищает время и портфель задач, и платформа, которая ограничивает радиус ошибки. Время наставника считается стоимостью программы, а не невидимой доброй волей. И у команды два табло: полезность сегодня и самостоятельность завтра. Ускорение без роста превращает ученичество в дешёвый выпуск; рост без выпуска — в учебную лабораторию вне бизнеса.

Что менять в найме

Если скорость написания кода больше не сигнал, интервью тоже приходится перестраивать. В лонгриде про джунов я описал семь ходов; здесь назову три, которые дают больше всего. Дать кандидату готовое агентное изменение и попросить найти в нём ошибку, которую тесты не ловят. Дать задачу без критерия приёмки и посмотреть, сформулирует ли он критерий до того, как начнёт делегировать. И спросить про последний выпуск, за который он отвечал: что произошло после, и что он сделал бы иначе. Все три проверяют суждение, а не синтаксис — и ни один из них нельзя пройти, переслав вопрос агенту.

Что считать личным результатом инженера

Не объём выпуска и не долю AI-кода. На оценке результатов я задавал бы один вопрос: какую единицу ответственности инженер теперь закрывает сам — фрагмент, задачу, изменение, рабочий эпизод или компонент. Это трек из пяти ступеней, где граница мидла проходит по воспроизводимому владению компонентом во времени, а не по календарю. Второй вопрос — качество созданной им человеко-агентной системы: какие проверки он встроил, какой след оставляют его агенты и сколько времени старших коллег он экономит, а не потребляет. Это ровно то, что в разборе с Евгением Сергеевым мы назвали полосой делегирования: эксперт не просто пишет лучший запрос — он безопасно отдаёт агенту более длинную цепочку, потому что задаёт ограничения, проверяет нужное и умеет восстановить ход работы.

Роль руководителя при этом смещается от контроля исполнения к устройству системы. В апрельской деке про AI-native лидерство я формулировал это как смену единицы управления: не команда, тикет и численность, а рабочий процесс с контрольными точками и ограниченной автономией. Хороший руководитель в 2026 году думает о том, где должен оставаться человек, где нужно подтверждение и где обязан существовать резервный сценарий — и о том, кто в его системе растит следующих экспертов. Ограниченная автономия сильнее свободы; развитие людей — часть устройства системы, а не отдельная HR-программа.

Условие смены позиции: продольное исследование пути от джуна до мидла с агентами покажет, что взросление ускоряется, а не только первый полезный запрос на слияние. Пока измерено только ускорение артефакта; ускорение суждения не измерял никто.

Самая переоценённая корпоративная ставка на AI сегодня — лицензии и сожжённые токены как доказательство того, что трансформация идёт. Количество мест, активных пользователей, запросов и токенов быстро складывается в график внедрения, и график этот не связан с результатом. Это корпоративное доказательство работы: мы показываем, что вычисление было потрачено, а не что ценность создана. Рядом стоит вторая ставка того же рода — мандат «AI-first» поверх нетронутого процесса, когда инструмент выдают всем, а контур поставки не меняют. Такой мандат легко объявить и невозможно проверить: у него нет знаменателя. Он производит отчёты о внедрении, обучающие курсы и дашборды с числом запросов и не производит ни одного принятого изменения, которого не было бы без него.101010McKinsey в августе 2026-го показал, что доля организаций с положительным вкладом AI в EBIT снизилась с 39% до 37% при росте масштабирования; почти три четверти лидеров перепроектировали процессы. MIT NANDA годом раньше описал ту же воронку: 60% оценивали, 20% пилотировали, 5% дошли до продакшена — и объяснил это подходом к внедрению, а не качеством моделей.Книжный куб · McKinsey State of AI 2026Книжный куб · The GenAI Divide10McKinsey в августе 2026-го показал, что доля организаций с положительным вкладом AI в EBIT снизилась с 39% до 37% при росте масштабирования; почти три четверти лидеров перепроектировали процессы. MIT NANDA годом раньше описал ту же воронку: 60% оценивали, 20% пилотировали, 5% дошли до продакшена — и объяснил это подходом к внедрению, а не качеством моделей.Книжный куб · McKinsey State of AI 2026Книжный куб · The GenAI Divide

Данные здесь неудобны для оптимистов. Исследование Стэнфорда на 120 тысячах разработчиков в 600 компаниях даёт медианный прирост около 10% с растущим разрывом между лидерами и отстающими; расход токенов объясняет этот прирост слабо, а чистота кодовой базы — заметно лучше, и есть «долина смерти» у команд, которые сжигают больше всех. Доступ к AI не равен эффективному использованию — а именно доступ и измеряют лицензии. Ещё в марте я собрал это в вредные советы по внедрению AI; за полгода ни один из них не устарел.

Во что вместо этого стоит инвестировать

• —В каталог собственных воспроизводимых эпизодов из истории работы — 20–50 реальных задач и инцидентов, на которых проверяется любой агент, модель и обвязка; модели меняются, каталог остаётся.
• —В два шлюза платформы — модельный и инструментальный — с идентичностью на задачу, политиками, телеметрией и рубильником; это места, где пересекаются данные, полномочия и необратимые действия, и владеть стоит именно ими.
• —В ёмкость проверки: ревью вокруг плана и исполняемых проверок, инциденты как регрессионные эпизоды, метрики очереди рядом с метриками потока.
• —В ученичество как производственную систему: наставник, защищённое время, безопасный продакшен и два табло — иначе через три года проверять правдоподобные результаты будет некому.

Это та же граница «арендовать · адаптировать · владеть», которую я в тот же вечер показываю в деке для Deep Tech Night: арендовать быстро меняющуюся общую способность, адаптировать стык, владеть полномочиями, контрактами, результатами, проверками и планом выхода. Преимущество живёт не в компоненте, а в измеримой скорости контура «обнаруженный класс отказа → изменение, прошедшее допуск → выпуск».

Модератор держит четыре вопроса. Вот ответы, которые я готов дать за тридцать секунд каждый — и по которым меня можно ловить на слове.

• —Куда переместилось узкое место и во что конвертировался эффект? В проверку и принятие. Эффект конвертировался в объём: больше и крупнее изменения при том же времени до пользователя. В результат он превращается только там, где перестроен контур поставки, и измеряется принятой работой, а не токенами.
• —Что агент может делать без человека и кто отвечает? Читать контекст, менять код в ветке, гонять CI и открывать запросы на слияние — под своей идентичностью и с маркером. Слияние и окружения он рекомендует, в продакшене только читает. За изменение отвечает его человеческий владелец, за инцидент — владелец сервиса, за границу — платформа.
• —Какая экспертиза остаётся человеку и как выращивать новых? Критерий правильности: назвать наблюдение, которое опровергнет правдоподобный результат. Выращивать — намеренно спроектированным ученичеством с наставником, защищённым временем и безопасным продакшеном; личный результат — единица ответственности, которую инженер закрывает сам.
• —Какая корпоративная ставка на AI переоценена? Лицензии и сожжённые токены как доказательство трансформации. Вместо них — каталог эпизодов, два шлюза платформы, ёмкость проверки и ученичество.

Код стал дешёвым. Право сказать «это неверно» — нет.