Когда код пишет агент: что остаётся инженерией

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

В докладах State of AI4SDLC я последовательно перехожу от метрик использования к метрикам результата. Принятая подсказка, число запросов и строки кода показывают активность инструмента. Для команды важнее, стало ли быстрее проходить полезное изменение через весь процесс и что произошло с качеством, переделками и стоимостью проверки. Эта позиция проходит через доклад на HighLoad++ и версию для ИТ-Пикника.

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

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

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

Мысленный пример: пользователь жалуется на двойное списание. Буквальная постановка «поставь защиту от повторного клика» может дать идеальную кнопку и сохранить ошибку на сервере. Инженерный эпизод начинается с другой проверки: какое событие повторяется, кто повторно доставляет запрос и где должна обеспечиваться однократность денежного эффекта? Основной вклад может оказаться в изменении модели задачи ещё до первой строки.

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

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

В позициях к Deep Tech Night мой основной ответ — проверка и принятие изменения. Способность производить изменения выросла быстрее способности подтверждать их полезность и безопасность. Когда в систему начинает поступать больше работы, очередь обнаруживается там, где её не успевают принять: в ревью, тестировании, интеграции или выпуске.

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

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

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

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

В лонгриде об экономике я предлагаю смотреть на стоимость принятой задачи. Её можно записать как управленческую модель:

Стоимость принятой задачи = затраты на весь поток за период / число принятых сопоставимых задач.

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

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

Возражение «но я лично ускорился в десять раз» может быть совершенно справедливым. Особенно на знакомой, локальной, легко проверяемой задаче. Оно отвечает на другой вопрос, чем скорость всего продукта. Я бы не спорил с личным опытом, а предложил проследить, во что превратилось сэкономленное время: больше проверенных гипотез, быстрее выпуск, меньше переработок или больше очереди.

Когда производство вариантов дешевеет, дорожают выбор и право сказать: эту работу мы не будем делать.

Схема — рабочая модель переноса очереди; конкретное ограничение нужно измерить в своей команде.

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

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

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

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

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

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

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

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

Цена переписывания кода падает быстрее, чем цена нарушения контракта с внешним миром.

Если человек только переносит вывод терминала в чат и нажимает «продолжить», полезность такого участия сомнительна. Хорошую повторяемую проверку стоит автоматизировать. Инженер не обязан наблюдать каждую итерацию ради сохранения своего места в процессе.

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

Проблема самопроверки не в том, что агент «не имеет права» написать тест. Он вполне может написать хороший тест и обнаружить свою ошибку. Проблема в общих слепых зонах. Если из постановки выпало ограничение, реализация и тесты могут дружно воспроизвести одну неверную модель. Смена роли с «разработчика» на «тестировщика» в следующем сообщении не гарантирует независимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы будем ревьюить обоснованность изменения: от того, зачем оно нужно, до того, что оно действительно сделало. Код остаётся одним из важных свидетельств.

Сначала зафиксирую мою уже опубликованную позицию. В материале от 5 сентября я оставлял агенту самостоятельную работу в ветке и подготовку проверок, а выпуск в продакшен поручал человеку. Для рабочей среды у агента описан режим чтения. Это моя практическая граница в том тексте, а не утверждение о технической невозможности автоматического выпуска. Источник: лестница доверия в позициях к Deep Tech Night.

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

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

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

Я предлагаю такую рабочую матрицу. Это проектная эвристика, которую нужно калибровать по конкретной системе.

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

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

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

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

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

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

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

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

Поставщик может встроить устойчивую функцию в продукт, и компании больше не потребуется собственная реализация. Это тоже форма исчезновения слоя из нашего кода. Но сама потребность, например получить действующий контракт сервиса, не исчезает. Модель не знает сегодняшнего решения команды, если оно не попало ни в один доступный источник.

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

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

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

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

В докладе на Deep Tech Night из этого вытекает стратегическое разделение: быстро меняющиеся общие возможности часто разумно покупать, интеграцию — адаптировать, собственные критерии результата и полномочия — сохранять под своим контролем. Это ориентир выбора, а не запрет разрабатывать свою обвязку, когда её преимущество можно измерить.

Я готов ставить на функцию проверки и управления действиями. На вечную ценность сегодняшней папки с навыками — нет.

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

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

Есть небольшой, но прямой экспериментальный сигнал. В исследовании Anthropic от 29 января 2026 года 52 преимущественно младших инженера осваивали незнакомую библиотеку Trio. В немедленном тесте группа с AI получила в среднем 50%, группа без него — 67%; выигрыш во времени не был статистически значимым. Это разница в 17 процентных пунктов в конкретном тесте. Работа не измеряет карьеру через год и не доказывает, что любой способ обучения с AI хуже.

Проблема возникает, когда скорость закрытия задания становится единственной целью. Самые полезные для обучения остановки — сформулировать гипотезу, прочитать исключение, сравнить ожидаемое и наблюдаемое — можно обойти одной просьбой «исправь». Задание закончится быстрее, но человек не обязательно построит модель, которая поможет в следующий раз. Эту модель нельзя заменить красивым объяснением агента, если ученик не умеет ею пользоваться.

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

1. Сформулировать ожидание. До запуска сказать, что должно произойти и почему.

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

3. Найти границу. Придумать случай, где решение может дать другой результат.

4. Проверить объяснение. Изменить условие, предсказать эффект и сопоставить с запуском.

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

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

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

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

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

Возражение «зачем учить делать то, что уже делает машина» требует разделить производство и понимание. Мы можем убрать много ручной рутины. Но пока человеку поручена проверка и ответственность, ему необходима практика, из которой возникает способность заметить неправильную модель задачи. Если в будущем эта ответственность тоже изменится, изменится и программа обучения. Нельзя заранее объявить ненужным навык, на который пока опирается весь контроль.

Нам нужно оценивать два результата отдельно: что ученик сделал с агентом и что теперь умеет сам.

Это прогноз на сентябрь 2029 года, а не описание уже известного будущего. Я бы строил его по функциям, а не по названиям инструментов. Чем сильнее функция связана с ограничениями реального мира, тем меньше оснований считать, что рост модели её отменит. Чем сильнее конкретная процедура связана с сегодняшней слабостью модели, тем вероятнее её изменение.

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

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

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

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

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

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

Через три года я бы ставил на ясные цели, проверяемый результат и управляемые последствия. Способ, которым мы сегодня объясняем это агенту, наверняка изменится.

1. Единица прогресса — полезное принятое изменение. Скорость генерации важна настолько, насколько меняет результат всего процесса.

2. Архитектура определяет цену последствий. Код можно переписать быстрее, чем отменить обязательства перед пользователями и внешними системами.

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

4. Обвязку нужно уметь упрощать. Устойчивые функции следует отличать от временных рецептов для конкретной модели.

5. Обучение становится явной инженерной задачей. Выполненная работа и приобретённая самостоятельность требуют разных способов оценки.

METR, 2025. В эксперименте с 16 опытными участниками и 246 задачами на знакомых им открытых репозиториях использование тогдашних AI-инструментов увеличило время выполнения в среднем на 19%. Это результат для определённой выборки и инструментов начала 2025 года. Он не доказывает, что агенты сентября 2026 года замедляют разработку вообще. Первичная публикация METR, 10 июля 2025.

Обновление METR, 2026. Авторы сообщили признаки ускорения, но прямо назвали новую оценку ненадёжной из-за отбора участников и задач, а также трудностей учёта времени при параллельной работе агентов. Поэтому формулировку «METR доказал ускорение на 18%» использовать нельзя. Обновление, 24 февраля 2026.

DORA. Тезис «AI усиливает сильные и слабые стороны организации» прямо сформулирован на странице отчёта 2025 года. Его достаточно для аргумента о важности системы работы. Числа −1,5% и −7,2%, встречающиеся в прежних материалах, лучше не подавать как универсальный результат этого годового отчёта: они приведены в отдельном отчёте о влиянии генеративного AI как ассоциации с ростом внедрения на 25%. Это не доказательство причинного эффекта и не прогноз для любой команды. Годовой отчёт, отдельный материал Impact of Generative AI.

Обучение с AI. 50% и 67% — результаты немедленной проверки освоения Trio; между ними 17 процентных пунктов. Это не «потеря 17% интеллекта» и не долгосрочная оценка профессии. Исследование Anthropic.

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

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

Авторская позиция о продакшен. Опубликованный 5 сентября режим строгий: выпуск через человека. Условное расширение автономии в разделе 6 — условие возможного пересмотра моей позиции, а не пересказ сентябрьской публикации.