Андрей Карпати в январе 2026 года ввёл термин agentic engineering: вы не пишете код 99% времени, вы оркестрируете агентов и выступаете в роли надзора. Борис Черныш, руководитель Claude Code в Anthropic, с ноября не правил ни одной строки кода вручную и отгружает более двадцати пул-реквестов в день — весь код пишет агент. Но никто из них не объясняет, чем именно занят человек в эти 99% времени и что происходит, когда процесс не выстроен.
В предыдущей статье я приводил цифры своего рабочего дня: 60% времени — формулировка задач и сбор контекста, 30% — проверка результатов, 10% — сопровождение процесса. На написание кода — 0%. Цифры субъективные, но за ними стоит сдвиг, который и разбирает эта статья.
Потеря привычного якоря
Об этом в статьях про разработку с агентами обычно молчат: тема неудобная и плохо ложится в маркетинг.
В январе 2026 года на Hacker News появился тред Ask HN: Identity crisis as a software engineer because of AI, собравший за сутки около тысячи комментариев. Суть одна: я в основном прокси для Claude Code; навык, который развивал годами, обесценен; это как потерять профессию при живой профессии. Разработчики с десятилетним стажем описывают ощущение пустоты — не карьерной, а профессиональной. Код пишется, продукт работает, но исчез момент, в котором ты был нужен.
Самооценка разработчика долгие годы держалась на одной способности: открыть любой файл, разобрать любую строку, написать с нуля всё, что нужно. Это не просто умение — это часть личности. Фраза я пишу код содержит многое. Когда из неё уходит пишу, остаётся неуютный зазор. Ты рядом с работой, но не внутри неё.
У меня этот период занял три недели. Вытащили меня из него не уговоры, а собственные метрики. Доля задач, закрытых с первой попытки, выросла. Дефектов стало меньше. Время от формулировки до работающего кода сократилось. Всё это улучшилось, как только я перестал параллельно писать код сам.
Отказываться от привычки было неуютно: нужно было перестать открывать файлы «просто посмотреть», перестать рефлекторно лезть в код при сложной задаче, и довериться процессу, который сам же и построил. Со временем новая позиция перестала ощущаться как потеря и стала ощущаться как концентрация: меньше энергии на механику, больше на замысел. Работа другая, и её не меньше.
А чем тогда занят человек
Когда я говорю, что полтора года не правил код вручную, первая реакция почти всегда одна: «Ок, а чем ты тогда вообще занимался весь этот год?»
По привычке мы меряем труд инженера часами, проведёнными над кодом. Если человек не сидит над строчками, со стороны кажется, что он и не работает. На самом деле работы стало больше — просто она другая. Покажу это на примере одного рабочего дня.
Один рабочий день
Открываю очередь задач на Сортуле — мой личный проект для сохранения ссылок и заметок, где LLM сам категоризирует контент и ищет по смыслу. С вечера там лежит жалоба: ВК-пост с каруселью сохраняет только одно фото. Пользователь переслал пост с четырьмя фотографиями, а в интерфейсе видно одну.
По старым меркам на это ушло бы полчаса-час: залезть в нормализатор ВК, найти баг, починить. Но я начинаю не с кода, а с воспроизведения на dev-среде. Пересылаю тот же пост локальному боту, смотрю базу — и вижу странность: ВК прислал все четыре фото, нормализатор их распарсил, фоновый воркер скачал. Код отработал чисто. Но в таблице медиафайлов четыре записи указывают на один и тот же путь в хранилище.
Без шага «сначала воспроизвести» я бы пошёл чинить нормализатор. Агент сделал бы то же самое — с идеальным обоснованием и зелёными тестами. Два часа выброшены, ничего не починено: проблема на другом уровне.
Настоящая причина — на два этажа глубже. Слой сохранения собирал имя файла из идентификатора закладки: для одной фотки — ок, для четырёх — имя повторялось. Хранилище, получая один ключ, молча перезаписывало файл. Остался только последний. И второй, независимый баг: нормализатор не выставлял тип содержимого у фото, фронт в галерее фильтровал по правилу «начинается на картинку», и ВК-фотки выбрасывались из интерфейса.
Одна задача, три слоя: нормализатор, слой сохранения, фронт. Ни один не знал о двух других, и в каждом баг выглядел правдоподобной частью его ответственности.
Переписываю постановку. Теперь это три подзадачи: уникальные имена для файлов карусели, корректный тип содержимого в нормализаторе, и добор для уже сломанных закладок в боевой базе. У каждой — свои критерии приёмки и хотя бы один негативный сценарий. Например: пост с одним фото не должен давать лишние записи; если API соцсети вернёт ошибку — не падаем, используем то, что пришло.
На постановку ушло 40 минут. Агенту на реализацию — 20. На ревью и тесты — ещё 10. Коммит уходит в основную ветку.
Дальше — выкладка на прод. Сборка срывается на старом нестабильном тесте, не связанном с моей задачей. Пропускать проверку или откатывать — плохие варианты. Я беру тег свежего образа, обновляю манифест и прохожу цикл выкладки вручную. Восемнадцать контейнеров поднимаются здоровыми.
И третий сюрприз: добор для сломанной закладки не срабатывает, задача в очереди, в логах — тишина. Смотрю конфигурацию: очередь не слушается ни одним воркером. Для нового модуля забыли прописать маршрут. Правка заняла бы минуту, но я уже третий раз ловлю это за месяц. Останавливаюсь и прошу агента сохранить в память проекта запись типа gotcha: «Любой фоновый таск без явного маршрута садится в очередь по умолчанию, которую никто не слушает. При добавлении нового таска — проверять маршрут обязательно». В следующий раз эта заметка всплывёт рядом с задачей. Маршрут добавлен, добор прошёл, четыре фото встают на страницу.
К моменту, когда я встаю налить чаю, часы показывают начало шестого. За день закрыто 12 задач: карусель с двумя доборами, три мелких фикса, одна большая фича (напоминания о сроке годности закладок), три теста, две записи в память проекта. Ни одной строки кода, написанной вручную.
Такой плотности в старой модели у меня не было никогда: каждые 40–50 минут — готовый кусок. Это не марафон и не героизм, а ровный ход вперёд без рывков.
Устаёшь по-другому. Не от печати, а от того, что весь день держишь в голове продукт, архитектуру, постановку, границы, места, куда агенту лучше не заглядывать. К вечеру ноет голова, а не спина.
И одна вещь, которую я не сразу разрешил себе назвать вслух. В классической модели, где между замыслом и кодом — команда людей, 12 задач за день невозможны. Постановка, реализация, ревью, возврат на доработку — тот же объём растянулся бы на три недели. Не потому что разработчики медленные, а потому что из цикла убрано всё, что его тормозило: согласования, ожидание, недопонимание. Весь мыслительный ресурс, который раньше уходил на управление людьми и удержание контекста между встречами, теперь идёт туда, где нужен: на архитектуру, продукт, приёмку результата.
Не промпт-инженер
Стоит отдельно сказать, кем человек в этой модели не становится. Он не становится промпт-инженером — не в смысле профессии, а в смысле мема, под которым сегодня ходит каждый, кто пару раз внятно написал в ChatGPT «сделай лендинг» или «напиши скрипт на Python». От самого словосочетания правильно передёргивает. Внятно формулировать запрос — это навык, а не профессия. Инженерной работы в этом ремесле не видно вовсе.
Из этой подмены вырастает вредное упрощение: раз дело в промптах, то опыт не нужен, порог упал, рынок можно брать штурмом после трёхдневного курса. Эта картина — одна из самых растиражированных и самых вредных.
На практике всё наоборот. Адди Османи из команды Google Chrome в декабре 2024 опубликовал эссе The 70% problem: ИИ уверенно закрывает 70% задачи, и именно эта уверенность опасна. Оставшиеся 30% — это архитектурные решения, негативные сценарии, системные связи — то, что нельзя делегировать. Чем сложнее проект, тем больше инженерной работы ложится на человека. Просто она другого рода.
Данные подтверждают жёстче. В отчёте 2025 GenAI Code Security Report компания Veracode проверила более сотни моделей на 80 задачах с известными уязвимостями: в 45% случаев ИИ-код содержал дыру. Против XSS и log injection модели защищались в 14% и 12% случаев. Не потому что модели плохие — у них нет контекста продукта, истории решений, понимания, чего делать нельзя. Этот контекст держит человек. Если его нет, тесты зелёные, а уязвимость есть.
Тот день с 12 задачами был возможен не потому, что я умел хорошо формулировать промпты. Он был возможен потому, что за плечами годы работы с архитектурой и продуктами. Знание, где плоская модель прав лучше иерархической. Понимание, что негативный сценарий важнее позитивного. Привычка ограничивать зону изменений.
Без этого багажа те же задачи дали бы 12 формально работающих решений, в половине которых сидели бы архитектурные мины.
Есть ходовая аналогия: человек как менеджер, агент как исполнитель. Она удобная и неточная. Менеджер не обязан разбираться в коде. В полностью агентной разработке — без этого нельзя. Если человек не читает сгенерированный код, он проспит и архитектурную ошибку, и ложную уверенность. Код можно не писать. Читать его — обязательно.
По характеру это работа архитектора или техлида: решить, что строить, поставить границы, принять результат, ответить за целое. Только совещания и код-ревью сменились спецификациями и воротами качества, а команда людей — агентом, которому каждый раз заново подаёшь контекст и который никогда не спорит. Как выясняется, молчаливое согласие бывает опаснее человека, который спорит всегда.
Пять навыков, которые определяют новую роль
За полтора года через меня прошло более 30 проектов. Список сложился не из теории, а из мест, где проекты скрипели: где-то в спецификации, где-то в контексте, где-то в забытом негативном сценарии. К восьмому-девятому проекту стало ясно: это одни и те же пять точек. Пропустишь хотя бы одну — результат плывёт.
Декомпозиция
Большая задача для агента почти всегда — плохая задача. В ней слишком много скрытых зависимостей, недосказанных решений, мест, где нужно самому понять, что имелось в виду.
Большая задача, отданная целиком, возвращается красивым, формально работающим результатом, в котором не хватает половины нюансов. Агент честно реализует самый прямой сценарий. Всё остальное, что я держал в голове и забыл проговорить, в реализацию не попадает. Разница с живым разработчиком в этом: тот задаст вопрос. Агент дорисовывает сам — и дорисовывает не туда.
Декомпозиция — не про нарезку на мелкие части. Она про то, чтобы каждая часть была понятной, ограниченной и проверяемой. Плохая задача, нарезанная на десять, даёт десять плохих подзадач. У хорошей декомпозиции другой признак: у каждой части есть ясные входы, выходы и критерий «готово».
Один признак хорошей декомпозиции: если при описании подзадачи приходится писать «с учётом того, что в соседней будет сделано вот это», значит, границы проведены неправильно. Подзадача должна быть автономной.
Сборка контекста
Контекст — не про то, чтобы дать агенту побольше файлов. Он про то, чтобы отобрать именно ту информацию, которая нужна для задачи, и убрать всё лишнее.
На Сортуле за шесть недель накопилось около сорока записей в памяти проекта (в TAUSIK, с типами dead_end, gotcha, pattern, convention, context). Каждая экономит от 15 минут до часа. Но все сорок сразу — это слишком: контекст, заваленный нерелевантной информацией, вредит не меньше, чем пустой. Агент честно читает всё, что ему дали, и тащит в решение даже то, что к делу не относится. Поэтому в стандарте SENAR логика подбора записей вынесена в отдельную часть. Без этого любая накопленная память превращается в балласт.
Архитектурные границы
Агент не видит архитектуры за горизонтом задачи. Он оптимизирует локально — в пределах доступных файлов и задания.
Показательный случай: во время рефакторинга агент начал подтягивать внутренние функции одного модуля из соседнего. Импорт работал, тесты зеленели, но между пакетами, которым знать о друге не положено, выросла тонкая ниточка связи. Поймать её удалось только потому, что эти границы я когда-то прочерчивал сам и помнил, где они проходят. Иначе мне об этом никто бы не напомнил: в проекте, где архитектор — один человек, эта память живёт только в его голове.
После этого случая во всех проектах появилась отдельная секция: что от чего зависит, что с чем не должно пересекаться, и главное — почему. Не общими словами вроде «придерживайтесь разделения ответственности», а конкретно: «этот модуль не использует код из того-то, потому что...». В SENAR это стало обязательным слоем контекста. Когда агент знает, почему нельзя, он нарушает правило заметно реже.
Критерии приёмки
Формулировка «сделай сброс пароля» для человека — рабочий старт. Для агента — лотерея. Без явных критериев он напишет позитивный сценарий и остановится. Негативный (например, на запрос с несуществующим адресом возвращать такой же ответ, как на существующий, чтобы нельзя было перебором узнать, кто зарегистрирован) — не добавит, если не записан.
Классическая ситуация: шесть тестов, все зелёные, а в безопасности — дыра, потому что сценарий, который её закрывает, не был описан. Ошибка — не агента, а постановщика. Из таких ошибок выросло правило: задача не берётся в работу, пока не записаны цель, критерии приёмки и хотя бы один негативный сценарий.
И снова данные из отчёта Veracode: ИИ-модели не защитили код от XSS в 86% случаев, от log injection — в 88%. Не потому что не умеют. Потому что никто не написал это в критериях.
Диагностика системных сбоев
Самый неочевидный навык — уметь отличить «здесь баг» от «здесь система постановки устроена так, что будет регулярно рождать такие баги».
На Сортуле три задачи подряд по новым веб-методам ломались одинаково: клиент получал неожиданный редирект из-за мелкого расхождения в формате адреса. Агент каждый раз аккуратно правил конкретный обработчик — и задача закрывалась. Соблазн был понятный: поправить и в третий раз, и идти дальше. Вместо этого я сел и разобрал причину. В архитектуре не было единого правила про формат адресов. Пять минут на одну запись. После этого правки по этому классу задач пришли к нулю.
В моменте казалось, что три быстрые правки экономнее, чем пять минут на запись. На самом деле — три потерянных сигнала о системной дыре. Именно здесь проходит граница между «использую ИИ-агента для кодирования» и «строю систему производства кода». Первое осилит любой, кто умеет внятно попросить. Второе требует инженера.
Почему ручная правка — это плохой рефлекс
Один из самых сильных рефлексов старой модели: если что-то не так, быстро поправь руками. В обычной разработке это часто лучший путь. В режиме, где весь код пишет агент, этот рефлекс вредит сразу с двух сторон.
Первая сторона очевидна: если человек регулярно дочинивает за агентом, значит, в системе постановки и контекста что-то не так. И этот непорядок не починится, пока его не заметить. Каждая ручная правка — сигнал.
Вторая сторона менее очевидна: агент помнит только то, что сгенерировал сам. Тихая правка над его кодом — для него как будто её не было. На следующей итерации он снова опирается на свой прежний вариант. На второй-третьей итерации — странный микроконфликт: я правлю, агент перезаписывает, я правлю снова. Решается одной привычкой: каждую ручную правку сопровождать короткой репликой агенту — что поменял и почему. Эти реплики попадают в память проекта и больше не собьют.
Во второй статье я рассказывал о метрике MIR — доле задач, в которых потребовалась ручная правка после работы агента. Смысл не в том, чтобы MIR был нулём. Нулевой MIR — либо враньё, либо работа только с тривиальными задачами. Смысл — в том, чтобы каждую ручную правку замечать.
Допустим, агент сгенерировал решение с архитектурной ошибкой. Самый быстрый путь — зайти в код и поправить. После этого остаётся нерабочая система производства. Локально хороший результат, но причина, по которой система породила плохой вариант, не устранена.
Пример: на проекте по кадастровым утилитам агент допустил ошибку в формуле пересчёта координат. Ошибка давала отклонение в несколько сантиметров — половина допустимого бюджета точности. Я заметил, исправил руками, пошёл дальше. Через три дня обнаружил ту же ошибку ещё в двух утилитах: агент использовал тот же неверный паттерн везде, где требовался пересчёт.
Правильнее было бы сразу разобраться, почему ошибка возникла. В контексте не было описания формул и требуемой точности. Агент реконструировал формулу из общедоступных данных — правдоподобно, но с ошибкой. Одна запись в контексте с правильными формулами предотвратила бы все три ошибки.
За первый месяц на Сортуле MIR был около 20%. Каждый случай я разбирал: почему агент промахнулся, что было не так в спецификации или контексте. Через месяц, когда накопился архитектурный контекст, MIR упал до 5–7% на серверной части. Не потому что модель стала умнее. Потому что среда, в которой она работала, стала точнее.
Для меня это граница честности. Если человек регулярно дописывает и чинит код сам, значит, либо система ещё не собрана, либо нарушены собственные правила. Оба варианта значат одно: чинить систему, а не код.
Как ощущается новая роль изнутри
Снаружи может казаться, что такая работа проще: не надо часами сидеть над синтаксисом, дебажить строчку за строчкой, вручную собирать фрагменты. У этой модели своя тяжесть.
Приходится держать в голове несколько слоёв: продукт, архитектуру, постановку, ограничения агента. Видеть за отдельным багом тип ошибки, а за типом — процесс, который эти ошибки регулярно выдаёт. И каждый раз ловить себя на соблазне быстро поправить руками и забыть.
Проверка становится узким местом. Автоматические тесты, линтеры, проверка типов ловят синтаксические ошибки. Но не ловят главное: решена ли задача по существу и не нарушает ли сгенерированный код архитектурный замысел, который существует только в голове человека. Ни один линтер не поймает логическую ошибку в бизнес-правиле. Поймает только человек.
Проверка требует другого типа концентрации — не созидательного, а критического: не строишь решение, а ищешь в нём трещины. Это изматывает быстрее, чем написание кода. К пятому часу кажется, что проверяешь быстро и точно. На деле начинаешь пропускать.
И последняя, неприятная часть. Если результат вышел плохой, в девяти случаях из десяти виноват не агент. Виновата моя система работы с ним: пробел в спецификации, дыра в контексте, пропущенный критерий приёмки. Позиция жёсткая по отношению к себе. Но только с такой позиции разработка с агентами и превращается в инженерную практику.
Ближе к продукту
В классической разработке между замыслом и кодом — пять этажей: требования, аналитика, проектирование, реализация, тестирование. На каждом что-то теряется, искажается, додумывается. От идеи до кода — недели, спринты.
В этой модели этажей почти не осталось. Между замыслом и кодом — только агент. Решение превращается в работающий модуль за минуты. Обратная связь мгновенная: поставил задачу, получил, посмотрел, переформулировал.
В проекте кадастровых утилит это было особенно заметно. Предметная область сложная: форматы ГКН и ЕГРН разные, пограничные случаи на каждом шагу. Чтобы проверить гипотезу, раньше нужно было поставить задачу, ждать, обнаружить, что гипотеза неверна, возвращаться. Цикл — от часов до дней. Здесь — 15–20 минут. Не потому что агент быстрее. Потому что убрана координация между людьми.
Из этого не следует, что один человек с агентом лучше команды. У команды есть чужие глаза, коллективный опыт, распределение ответственности. Но на задачах, где один человек хорошо понимает предметную область и владеет архитектурой, короткое расстояние от замысла до результата становится решающим преимуществом.
Где я в этом не уверен
Всё выше — опыт одного человека с конкретным багажом. Не оправдание, а описание границ применимости: где мой опыт заканчивается, дальше — «не знаю».
Самый болезненный вопрос — постепенная деградация архитектуры. Каждая задача по отдельности сделана корректно. Но через полсотни задач модуль, который начинался тонким слоем, обрастает логикой. Границы размываются. У агента нет ощущения модуля как целого. Часть проблемы я закрываю стандартом SENAR и фреймворком TAUSIK: они описывают регулярный архитектурный пересмотр как обязательный шаг. Дрейф замедляется, но не исчезает. Раз в две-три недели я всё равно сажусь и прохожу архитектуру глазами. Это до сих пор единственное, что реально её удерживает.
Второй вопрос — масштаб. Всё, что я описал, — работа одного человека над проектом. Как устроена эта роль в команде из десяти инженеров, где каждый управляет агентами? Открытых данных мало. Я этого не знаю. Горизонт — один-два года. Индустрия выясняет это прямо сейчас.
Третий — начинающие. Пять навыков, которые я описал, опираются на накопленный опыт. Умение декомпозировать задачу так, чтобы агент не додумал лишнего, приходит только после сотен задач, поставленных живым людям. Умение проектировать границы — из многолетнего наблюдения за тем, как они размываются. Можно ли вырастить эти навыки без традиционного ручного этапа? Вопрос без ответа. Математику до сих пор учат без калькулятора — возможно, не случайно.
Четвёртый — не все типы задач одинаково поддаются этой модели. На серверной части — работает хорошо. На задачах с интерфейсами — хуже. На Сортуле я потратил два вечера, формализуя «кнопка должна ощущаться отзывчивой»: параметры анимации, задержки, полторы страницы текста. Агент реализовал безупречно по спецификации. Субъективно — не то. Переделывал три раза. Доля успеха с первой попытки на UI-задачах у меня — 30–40%, против 75–80% на серверной части.
Границы стоит знать. Именно в них формируется честное понимание модели. Без границ остаётся только маркетинг.
Если унести из статьи одну мысль
Человек в режиме полностью агентной разработки — не программист, переставший писать код. Это человек, который держит рамку: постановку, декомпозицию, контекст, границы, критерии — и отвечает за то, чтобы вся эта машина продолжала выдавать пригодный код.
Меньше ручной работы над кодом. Больше инженерного проектирования процесса, внутри которого этот код производится.
Пять навыков (декомпозиция, контекст, архитектурные границы, критерии приёмки, диагностика сбоев) со временем перестали быть личными привычками. Они сложились в систему. И на тридцать первой задаче за неделю личная дисциплина начала проседать. Тесты зелёные, следующая.
Когда я это заметил, стало ясно: личных навыков мало. Нужен внешний контур, который не даёт пропустить шаг, даже когда устал. По ходу статьи я несколько раз ссылался на пару, которую мы с Вадимом Соглаевым собираем именно ради этого: стандарт SENAR и фреймворк TAUSIK. Стандарт описывает, как должна быть устроена инженерная дисциплина работы с агентами: формат спецификации, слои контекста, архитектурные границы как обязательная секция, критерии приёмки как входное условие, диагностика сбоев через метрики MIR и FPSR. Фреймворк встраивает это в рабочий цикл: память проекта, постановки, ворота качества, которые не дают закрыть задачу без выполненных критериев.
В следующей статье я разберу, как этот внешний контур устроен изнутри: спецификация, ворота качества, метрики. Не как набор рекомендаций, а как обязательный шаг, который не получится пропустить даже в пятницу вечером. Подробнее — на senar.tech.