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