Полтора года без ручного кода: почему инструкции ИИ-агенту не заменяют инженерную дисциплину

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

Кто я

Андрей Юмашев. Много лет в IT, последние годы — руководитель верхнего звена: продуктовое управление, инфраструктура, стратегия. Нагруженные системы. Решения о том, куда движется продукт, как устроена платформа, какие команды под какие задачи собираются. Код я при этом давно не писал и даже не ревьюил в ежедневном режиме. У меня для этого были люди.

Полтора года назад всё изменилось. Не потому, что я вдруг захотел вернуться в разработчики, а потому, что ИИ-агенты позволили мне снова делать продукт руками, не теряя времени на рутину. Теперь я могу сесть и за вечер собрать работающий сервис: описать продукт, границы, критерии качества, архитектурные решения, а весь типовой код, тесты, мелкие правки и локальный рефакторинг делает агент. Я занимаюсь тем же, чем занимался как руководитель: продуктом, архитектурой, решениями о готовности. Только теперь результат на выходе — не ТЗ для команды, а живая работающая система. Работаю в основном с Claude Code (агент от компании Anthropic, живущий в командной строке) и Cursor (редактор кода со встроенным ИИ-помощником), иногда с другими агентами. За эти полтора года через меня прошло тридцать с лишним проектов на разных языках и технологиях: от небольших экспериментов на выходные до боевых систем в длительной эксплуатации. По итогам этого опыта ^[1] я написал инженерный стандарт SENAR и сделал фреймворк TAUSIK, который этот стандарт реализует. Но сначала о том, зачем они вообще понадобились.

Зачем всё это нужно, если уже есть файл правил

Небольшое пояснение для тех, кто не в теме. Почти у каждого современного ИИ-агента для программирования есть свой файл с инструкциями от пользователя, который агент читает каждый раз перед работой. У Claude Code это файл CLAUDE.md, у других инструментов похожие файлы, называются по-разному. Кладёшь его в корень проекта, пишешь туда правила: какой стиль кода принят, какие библиотеки разрешены, на что обращать внимание ^[2]. Агент это учитывает. Дальше для краткости я буду говорить просто “CLAUDE.md”, потому что сам работаю в основном с Claude Code, но всё сказанное в равной степени относится и к файлам правил других агентов.

Вопрос по делу. Claude Code читает код проекта, помнит предыдущие разговоры, сам запускает тесты. Можно написать хороший CLAUDE.md, и агент будет ему следовать. На простых задачах этого действительно хватает.

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

Три случая, после которых я понял, что одного файла с правилами мало. И здравого смысла тоже.

Задача на один модуль, правки в семи. Агент получил задачу на один конкретный модуль (модуль — это отдельный кусок программы, отвечающий за одну понятную функцию, например “отправка писем” или “вход в личный кабинет”). Выполнил, и заодно навёл порядок в общей вспомогательной библиотеке, которой пользовались ещё несколько модулей. Вынес повторяющийся код, переписал связи между файлами. Технически всё корректно, тесты зелёные. Изменений было много, я проглядел правки во вспомогательной библиотеке при проверке. Через день посыпались ошибки ^[3] в трёх модулях, которые эту библиотеку использовали. Два часа разбора.

Агент сделал ровно то, что сделал бы инициативный новичок: увидел повторение ^[4], вынес общий код в отдельную функцию, никого не спросил. Опытный разработчик в такой ситуации остановился бы и написал в чат: “я тут вижу, что можно вынести, но это тронет три модуля. Делать?”. Агент так не поступает. Он просто делает.

Уверенные выдумки. Интеграция с чужим сервисом (то есть мне надо было научить свою программу “разговаривать” с чужим сервером через его интерфейс, так называемый API). Документация три страницы, половина устарела. Агент сгенерировал весь нужный код: как формировать запрос, как разобрать ответ, что делать, если ответ не пришёл (повторить попытку через секунду, потом через две, потом через четыре, стандартный приём). Я посмотрел, выглядит профессионально. Запустил. Два из пяти запросов возвращают не то, что ждали.

Агент додумал поведение ^[5] чужого сервиса там, где документация молчала. Додумал правдоподобно, неправильно и молча. Осторожный разработчик в такой ситуации вручную отправляет тестовые запросы на чужой сервер через специальный инструмент и потом пишет в комментарии к своему коду: “в документации непонятно, я проверил руками”. Не каждый так делает. Но у человека есть хотя бы шанс остановиться и спросить. У агента этого шага нет: он заполняет пробел сам и уверенно.

Тесты, которые тестируют фантазию. Сброс пароля, шесть тестов, все зелёные. Через три дня обнаружил дыру. На запрос сброса пароля для существующего адреса сервер отвечает “ок, письмо отправлено”. На несуществующий отвечает “такого адреса нет”. Два разных ответа, и любой желающий может по очереди перебрать тысячу адресов и узнать, кто из них зарегистрирован в системе. Это известная уязвимость, её описывает OWASP (международная организация, которая публикует справочники по безопасности веб-приложений). Правильно отвечать одинаково в обоих случаях: одно и то же сообщение, такое же время ответа, никакой разницы.

Тест на этот сценарий? Нет. Ни я не описал его в задании, ни агент не добавил от себя, хотя сценарий базовый.

Здесь честно: это в первую очередь моя дыра в техническом задании, а не провал агента. Толковый коллега-человек тоже мог бы забыть про такую уязвимость, если не напомнить. Но именно в этом и фокус: с агентом такие пробелы больнее, потому что рядом нет второй пары глаз, которая при проверке кода спросит “а ты на несуществующий адрес проверял?”. В CLAUDE.md можно написать “всегда проверяй негативные сценарии”. Агент прочитает. И в половине случаев проверит. В другой половине решит, что текущих тестов достаточно. Узнаёшь об этом, когда уже полез проверять руками.

Три случая, одна причина. Любые инструкции агенту это рекомендация, а не ограничение. Неважно, где они записаны: в CLAUDE.md, в файле правил Cursor, в системном промпте. Агент может учесть, может не учесть. Нет механизма, который заставляет работать в рамках. Есть только надежда, что правила прочитаны и соблюдены. На простом проекте это не проблема. На сложном начинаешь считать дыры.

Как строился процесс

Методологию я не придумал за один присест. Процесс нарастал от проекта к проекту, каждый следующий провал заставлял что-то добавлять к прошлому набору правил. В итоге из этих добавлений и сложился стандарт, но в этом разделе я хочу показать именно путь, а не конечный результат. Так видно, какая боль ^[6] вызвала какое решение.

Первые проекты: формализация задач

На нормальном проекте первое, чему учат, это формальная спецификация задачи. Но с агентом есть тонкость. Человеку можно ответить на “а что ты имел в виду?” посреди работы, и он запомнит эту поправку на следующие задачи. Агент тоже умеет спрашивать, Claude Code и Cursor задают уточняющие вопросы. Но ответ живёт только внутри текущего разговора. В следующий раз он снова будет додумывать с нуля. Всё, что не записано в постоянное место, для него не существует. (Про встроенную память ^[7] современных агентов расскажу чуть ниже, она частично закрывает эту проблему, но не полностью.)

Я стал перед каждой задачей записывать формально: цель, критерии приёмки, какие файлы трогать, какие нет, какие негативные сценарии (что должно происходить при неправильном вводе, пустом поле, несуществующем идентификаторе) покрыть. Доля задач, решённых с первого раза, выросла примерно вдвое: с сорока процентов примерно до семидесяти пяти-восьмидесяти на задачах серверной части в знакомой мне предметной области. В серии я буду называть эту метрику FPSR, от английского First-Pass Success Rate, “доля успеха с первой попытки”. Ранний уровень тут оценка по памяти и истории правок, поздний уже реальный замер на ведущемся журнале. Оговорка про природу всех моих цифр будет в разделе “Честное предупреждение”.

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

Сортула: память проекта

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

Важно другое. Это был первый проект, где я столкнулся с проблемой, которой не бывает в работе с людьми: агент не помнит провалы.

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

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

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

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

По состоянию на весну 2026 у Claude Code, Cursor и других популярных агентов между отдельными запусками действительно копится встроенная память. Агент сам откладывает важные детали на будущее. Но откладывает он в основном то, что сработало: принятые правила, команды сборки, найденные решения ошибок. А журнала тупиков, “пробовал такое-то, не работает, не возвращайся”, ни один из них по умолчанию не ведёт. Решение ошибки сохранится, “этот путь тупиковый” не сохранится.

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

Полевой учёт: контекст как документ

Следующим проектом было веб-приложение, которое работает как мобильное: ставится на телефон, умеет работать без интернета. Бригадиры заполняют отчёты в поле, где связи нет, а когда связь появляется, данные сами уезжают на сервер. Система большая: больше восьмидесяти разных операций (то есть разных команд, которые клиент может послать серверу, например “создать отчёт”, “прикрепить фотографию”, “получить список задач на день”), шесть ролей пользователей, двадцать восемь накопленных изменений структуры базы данных.

Агент ломал синхронизацию данных с сервером каждый раз, когда задача касалась конфликтов (конфликт ^[8] в этом смысле возникает, когда два человека с разных устройств одновременно меняют одну и ту же запись, и нужно решить, чьи изменения оставить). И каждый раз ломал новым способом. Спецификация отдельной задачи помогала, но всю подсистему синхронизации со всеми её правилами и особенностями в одну спецификацию не впихнёшь.

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

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

Зрелые проекты: автоматическая блокировка

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

Когда я добавил автоматические ворота качества (проверки, которые блокируют задачу на входе и выходе, если условия не выполнены), доля дефектов, найденных уже после закрытия задачи, упала примерно с пятнадцати до шести процентов. Эту метрику я тоже буду использовать в серии, сокращение DER, от английского Defect Escape Rate, “доля сбежавших дефектов”. Под DER я понимаю простое: доля закрытых задач, по которым в следующий месяц пришлось заводить отдельную задачу на исправление. Логическая ошибка, пропущенный редкий случай, поломка в соседнем модуле от твоей же правки. Всё, что потребовало возврата к уже “готовому”.

Это не я стал внимательнее. Просто пропустить шаг стало технически невозможно.

Где процесс не помог

Это не история успеха на всех фронтах. Есть типы задач, где спецификации, память и ворота не вытягивают.

Интерфейсы и ощущение от продукта. На Сортуле я потратил два вечера, формализуя “кнопка должна ощущаться отзывчивой”: параметры анимации, задержки, полторы страницы текста. Агент реализовал безупречно по спецификации. Субъективно “что-то не то”. Переделывал три раза. На задачах про интерфейс доля успеха с первой попытки у меня стабильно ниже, порядка тридцати-сорока процентов против семидесяти пяти-восьмидесяти на серверной части. Понимаю, что эта метрика для интерфейсов в принципе сомнительна (там результат по определению доводится за несколько итераций), но других цифр у меня нет. Три проекта тоже не выборка, но закономерность устойчивая.

Чужие сервисы с кривой документацией. Документация платёжного сервиса обещала, что в уведомлении об успешной оплате будет поле “orderId”. В одних примерах документации оно и правда писалось так, в других как “OrderID”, а приходило на деле как “order_id”. Поиск в коде по одному написанию ничего не находит, по другому находит, реальность не совпадает ни с тем, ни с другим. Полтора дня разбирательств с тремя вариантами одного и того же имени. Когда чужая документация сама себе противоречит, ни спецификация, ни ворота не помогают. Приходится руками разбираться, как чужой сервис работает на самом деле, и только потом ставить задачу агенту.

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

Постепенное разложение архитектуры. Каждая задача по отдельности сделана корректно. Но через полсотни задач модуль, который начинался тонким аккуратным слоем, обрастает логикой ^[9], границы размываются. У агента нет ощущения модуля как целого, он видит только ту задачу, которую ему дали прямо сейчас. Раз в две-три недели я сажусь и вручную прохожу архитектуру глазами. Это до сих пор единственное лекарство, которое я знаю.

---

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

Мой ответ: стандарт SENAR и фреймворк TAUSIK

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

Так появился SENAR, от английского Supervised Engineering & Normative AI Regulation, “контролируемая инженерия и нормативное регулирование ИИ”. Это открытый стандарт инженерного процесса для разработки с ИИ-агентами. Восемь правил, ворота качества на входе и выходе задачи, набор метрик, структура памяти проекта. Всё, что описано в этой статье (формальная спецификация, журнал тупиков, контекстный документ подсистемы, автоматическая блокировка), в SENAR собрано в единый свод и формализовано так, чтобы по нему можно было работать на любом проекте, независимо от языка, стека и выбранного агента. Лицензия CC BY-SA 4.0, полные детали на сайте senar.tech ^[10] и на GitHub ^[11].

Сам по себе стандарт это бумага, которую всё равно никто не соблюдает на тридцать первой задаче за неделю, поэтому я сделал и инструмент. TAUSIK ^[12], от английского Task Agent Unified Supervision, Inspection & Knowledge, это мой фреймворк, который реализует стандарт SENAR на практике. Он автоматически собирает контекст задачи, проверяет ворота качества на входе и выходе, ведёт структурированную память проекта (вместе с тем самым журналом тупиков, о котором шла речь на Сортуле) и считает метрики: долю успеха с первой попытки, долю сбежавших дефектов, и ещё несколько служебных показателей. Фреймворк можно подключить к Claude Code, к Cursor и к другим совместимым агентам.

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

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

Честное предупреждение

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

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

SENAR работает для меня в том числе потому, что за спецификациями стоит многолетний опыт управления разработкой. Я знаю, какие граничные случаи прописать, какие архитектурные решения удержат проект, а какие его через полгода уронят. Это не интуиция ^[14] из воздуха, это двадцать лет шишек и чужих провалов, на которых я учился. У человека, который только начинает, такого багажа нет, и сработает ли у него SENAR так же, я не знаю. Это один из открытых вопросов, на которые я честно отвечаю в шестой статье серии.

И последнее. Я не претендую на то, что SENAR это единственно правильный стандарт инженерной работы с ИИ-агентами. Я претендую ровно на одно: он существует, он открыт, он работает у меня, и он уже больше, чем всё, что мне удалось найти в индустрии на эту тему. Если он окажется для вас полезен полностью, я буду рад. Если вы возьмёте из него половину, а остальное перепишете по-своему, я буду рад не меньше: лицензия CC BY-SA 4.0 (международная открытая лицензия: можно свободно использовать и переделывать с указанием авторства, производные работы должны распространяться на тех же условиях) ровно для этого и нужна.

О чём серия

1. Эта статья. Обзор: кто, зачем, как менялся процесс.

2. ИИ-агент — не программист. Почему отличие качественное и что из него следует.

3. От задачи до готового кода. Пошаговый разбор реальной задачи.

4. Двенадцать способов, которыми разработка с ИИ ломается. Каталог типичных провалов.

5. Один рабочий день с ИИ-агентом. Практика и инструментарий TAUSIK.

6. Где это не работает. Ограничения, открытые вопросы, честные пробелы.

Словарь терминов

Собрал в одном месте термины, которые встречаются в статье, чтобы не приходилось объяснять их заново в следующих частях серии. По порядку от собственных названий к общим понятиям.

SENAR (от английского Supervised Engineering & Normative AI Regulation, “контролируемая инженерия и нормативное регулирование ИИ”). Методология, описанная в этой серии. Лицензия CC BY-SA 4.0.

TAUSIK (от английского Task Agent Unified Supervision, Inspection & Knowledge, “единая система наблюдения, проверки и знаний для задач и агентов”). Открытый набор инструментов, который автоматизирует ворота качества, метрики и память проекта по методологии SENAR.

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

Cursor. Редактор кода со встроенным ИИ-помощником. Технически это отдельный редактор на основе кодовой базы Visual Studio Code, именно отдельный, а не дополнение к нему. За счёт этого его ИИ-помощник умеет больше, чем обычное дополнение.

CLAUDE.md. Простой текстовый файл с инструкциями для агента Claude Code. Кладётся в корень проекта, автоматически читается агентом перед каждой работой. Содержит правила: какой стиль кода принят, какие библиотеки разрешены, на что обращать внимание. Аналогичные файлы есть у других агентов, называются по-разному.

Спецификация задачи. Формальное описание задачи до того, как агент начнёт писать код: цель, критерии приёмки, какие файлы можно трогать, какие нельзя, какие нестандартные ситуации нужно покрыть.

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

FPSR (от английского First-Pass Success Rate, “доля успеха с первой попытки”). Доля задач, которые агент решает сразу, без возвратов на доработку. Метрика качества входа в процесс: чем лучше спецификация, тем выше FPSR.

DER (от английского Defect Escape Rate, “доля сбежавших дефектов”). Доля закрытых задач, по которым в течение месяца после закрытия пришлось заводить отдельную задачу на исправление. Метрика качества выхода из процесса: чем лучше финальная проверка, тем ниже DER.

Память проекта. Хранилище, которое переживает отдельные запуски агента: принятые решения, особенности архитектуры, записи о тупиках. У разных инструментов устроена по-разному, общая идея одна: агент не должен забывать ^[15] выводов предыдущих разговоров.

Журнал тупиков. Часть памяти проекта, в которой хранятся неудачные попытки: что пробовали, почему не сработало, какая альтернатива нашлась. В TAUSIK записи о тупиках лежат в той же базе, что и принятые решения, и связаны между собой: агент перед каждой задачей получает на руки и то и другое. Встроенная память популярных ИИ-агентов журнал тупиков по умолчанию не ведёт, она хранит то, что сработало, а не список “не ходи сюда снова”.

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

Российский кадастр (ЕГРН, ГКН, ЕГРП). Государственная система учёта недвижимости. До 2017 года существовали два отдельных реестра: ГКН (Государственный кадастр недвижимости, отвечал за сами объекты) и ЕГРП (Единый государственный реестр прав, отвечал за права собственности). В 2017 году их объединили в ЕГРН (Единый государственный реестр недвижимости). Форматы файлов (XML-схемы) старого ГКН и нового ЕГРН отличаются, на практике разработчикам приходится уметь читать оба.

Выборка из одного наблюдателя (по-английски записывается как N=1). Статистическая оговорка, которая означает, что результаты получены на одном-единственном человеке. Это личный опыт, а не доказанная закономерность.

---

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