Один файл-инструкция в корне репозитория ещё не среда
Чаще всего отвечают примерно так. В корне репозитория лежит один файл с инструкциями для агента: CLAUDE.md у Claude Code, AGENTS.md у Codex и Aider, .cursor/rules/*.mdc у Cursor, copilot-instructions.md у GitHub Copilot. Названия разные, идея одинаковая. В файле собрано всё сразу: продукт, архитектура, соглашения по коду, частые ошибки, ссылки на документацию, советы агенту вроде требования не лезть в унаследованный код без необходимости. Пока автор хорошо знает свой проект и сам удерживает границы задачи в голове, такая схема может работать долго, и не только на пет-проектах. Я сам так начинал.
Ломается она ровно в момент, когда задача упирается в детали, которых в общем файле нет.
Общие советы агенту не вытягивают, когда задача упирается в пару костылей, поставленных полгода назад в соседних модулях, в две интеграции с внешними сервисами, у каждой из которых свои причуды, в договорённость, про которую все давно забыли, что её принимали, и в архитектурное правило, лежащее в чьих-то заметках полуторагодовой давности. Ничего из этого в один общий файл инструкций физически не помещается. А если и поместится, файл превращается в свалку, в которой агент так же не находит нужного, как в живой команде, у которой все в отпусках.
Среда задачи устроена сложнее, чем один файл в корне. Она состоит из трёх слоёв, и без любого из трёх ворота из прошлой статьи стоят впустую.
Первый, контекст под задачу: пол, на котором стоит работа. Не общий рассказ про проект, а конкретный собранный пакет под текущее изменение. Второй, архитектурные границы: стены, проявленные так, чтобы их читал не только человек с десятью годами в проекте. Третий, типизированная память: потолок над всеми задачами разом, под которым копится фоновое знание команды: решения, паттерны, подводные камни, тупики и эмпирические наблюдения, в обычной команде живущие в головах.
Дальше разбираю каждый по отдельности, на эпизодах с разных проектов: чаще с Сортулы, у которой архив у меня самый плотный, реже с других, где принципиально иначе.
Контекст не приставка к задаче
Логика самая привычная: есть задача, есть агент, значит нужно дать побольше информации, и он справится лучше. Звучит разумно, поэтому ошибка долго остаётся незаметной.
Контекст начинают видеть как приложение к задаче: расширенный промпт, справку, набор пояснений, которые подкладывают перед запуском. Этого хватало бы, если бы агент работал в той же среде, что и человек. Только он в ней не работает.
У человека контекст разбросан по десятку мест сразу: код в голове, накопленный за месяцы и годы, разговоры с коллегами в коридоре, чужие коммит-сообщения, прочитанные год назад, своя интуиция, что эту часть лучше не трогать. Хорошо, когда в проекте полноценная документация и есть менеджер, который её ведёт. По моему опыту управления командами это редкость: чаще документация недотянута, то руки не дошли, то менеджер занят релизами, то отложили на потом. Тогда человек собирает картину из тех самых разговоров, коммит-сообщений и интуиции, достраивает недостающее. Это компенсация средой, и за неё индустрия привыкла не платить отдельно.
У агента ничего из этого нет. Между запусками он не помнит, что обсуждалось вчера. Ни коллег, ни интуиции, ни лет в этом проекте. Всё, на что он опирается, это контекст, который ему дали вместе с задачей. Если контекста нет, он его не достроит. Если повезёт, спросит. Чаще достроит правдоподобную догадку и пойдёт по ней, иногда не заметив, что достроил.
Первый сдвиг в мышлении случился у меня именно тут. Контекст в работе с агентом это не справка к запросу. Это та реальность, в которой агент вообще может действовать как инженер. Без неё он действует как генератор связного текста.
До меня окончательно дошло это на одном раннем проекте, ещё до Сортулы. Задача была простой на вид: подключить интеграцию с внешним сервисом для отправки уведомлений. Я приложил ссылку на официальную API-документацию и решил, что этого хватит. Агент собрал клиент строго по описанию. Локальные тесты на заглушках прошли, на тестовом окружении тоже всё выглядело нормально.
Первый реальный вызов на боевом окружении вернул 400. Описание тела запроса в документации было от прошлой мажорной версии. Актуальное в своё время вынесли в журнал изменений, но на главной странице описания так и не обновили. Я угробил вечер на эту 400. Сначала злился на агента, потом понял, что зря.
Чисто формально виновата документация сервиса. Только это я положил её в задачу как единственную опору, не сверившись с журналом изменений и не дёрнув реальный API на боевом окружении. Агент прочитал, что лежало, и реализовал то, что прочитал. Он не виноват, что у меня среда хуже, чем мне казалось.
С тех пор я перестал относиться к контексту как к фоновой подложке. Он стал отдельным артефактом, который собирается под задачу.
Шум вреднее голода. Недостаток контекста агент чаще всего честно признаёт: что-то спросит, во что-то не полезет. Противоречивые куски в одном промпте хуже: модель почти всегда выберет одну версию и пойдёт по ней уверенно, не отстроив между ними чёткий приоритет сама собой, так что две правды подряд лучше не класть.
Шесть слоёв контекста под задачу
Дальше обычно ошибаются в другом месте: контекст начинают воспринимать как нечто единое. На практике он почти всегда многослойный, и слои в нём про разное. Если их перемешать в один файл, получается тот самый раздутый общий файл инструкций, в котором агент теряется уже не от объёма. Он теряется потому, что в одном куске текста смешано шесть разных уровней.
У меня контекст под задачу разводится на шесть слоёв.
-
Продуктовый. Что вообще создаётся, для кого и в каких ключевых сценариях. Без этого агент технически решает задачу и промахивается мимо её смысла. На Сортуле я несколько раз ловил себя на том, что задача формулировалась как добавление поля в фильтр, а на деле речь шла о пользовательской привычке фильтровать закладки иначе. Поле тут уже только реализация; в продуктовом слое важно исходное поведение.
-
Архитектурный. Границы системы и контракты между модулями. Здесь ответ на вопрос: что в этой задаче можно трогать, а что относится к общему решению, которое нельзя тихо переделать под локальное удобство.
-
Реализационный. Технологии, паттерны, кодовые соглашения, способы изменения системы, которые приняты именно в этом проекте. Без этого слоя агент пишет код в принципе правильный, но не встроенный в кодовую базу. Через месяц проект становится разнобоем стилей.
-
Качества. Что считается хорошим результатом, какие проверки обязательны, какие правила нельзя нарушать. Это тот же слой, в котором живут критерии приёмки из четвёртой статьи. Если он не задан, агент гонится за видимостью завершённости вместо самой завершённости.
-
Задачи. Рабочий фокус текущего изменения: что именно нужно сделать, где границы работы, что в задачу не входит, по каким критериям результат будет принят. Это уже было в спецификации; в среду слой задачи попадает потому, что без него остальные пять не сходятся в точку.
-
Истории. Почему раньше выбрали именно такой путь, какие варианты пробовали и от каких отказались. Без этого слоя агент в третий раз приносит идею, которую команда осознанно отвергла полгода назад. И каждый раз с убедительным обоснованием.
Если эти шесть слоёв смешаны в один кусок текста, агент работает нестабильно; если разведены и собраны под конкретную задачу, управляемость заметно растёт. По моим записям шум в DER резко падал после того, как контекстный пакет переставал быть свалкой всего подряд и превращался в сборку из шести отдельных фрагментов.
Контекст не существует сам по себе
Хорошего контекста вообще не бывает. Бывает хороший контекст под конкретный тип работы.
Архитектурное изменение, локальный рефакторинг, дефект в чувствительной части системы, подключение нового внешнего сервиса. У каждого свой нужный пакет. Если в задачу кладут универсальный, агент получает шесть слоёв сразу, из них релевантны два, и три часа уходят на то, чтобы вытащить смысл из противоречий. Если пакет, наоборот, бедный, агент достраивает то, чего нет; на DER из четвёртой статьи это видно сразу: число тупиков растёт.
Поэтому у контекста появляется отдельная инженерная функция: сборка контекстного пакета под конкретную задачу. Раньше её негласно выполняла команда: на стендапе или в курилке между двумя коллегами собиралась ровно такая же сборка под задачу, быстро и без следов. Это работало, пока носители контекста на месте, и обнулялось каждый раз, когда ключевой инженер уходил. С агентами такие следы приходится оставлять с самого начала. Зато они переиспользуются.
Релевантность тоже собирается руками. Если в задачу на локальный рефакторинг кладут полный пакет всех шести слоёв сразу, получается тот самый шум, от которого DER растёт. Пакет нужно собирать руками; сам собой он не сложится.
Архитектура читается агентом или нет
С контекстом более-менее разобрался. Дальше архитектура.
В большинстве проектов, которыми я руководил, архитектура была недодокументирована. Это не норма, а системная боль индустрии: фиксировать архитектуру дорого и некогда, у менеджера релизы, а ADR на потом. Хорошо, когда в команде есть зрелая документация и человек, который её ведёт; по моему опыту такое скорее редкость. Чаще команда долго компенсирует это устно: люди держат в голове неформальные договорённости, помнят, какой модуль лучше не трогать, знают, что формально граница проходит в одном месте, а по факту система живёт чуть иначе. Компенсация не бесплатная, но она работает, пока носители контекста на месте.
С агентом она перестаёт работать почти полностью.
Агент в системе не живёт. У него нет ни чутья на хрупкие места, ни памяти про прошлые компромиссы, если только их явно не вынесли в тот самый слой истории, про который шла речь выше. Поэтому архитектура у агента получает новую роль. Она не только описывает устройство продукта, но и задаёт границы того, как с этим продуктом дальше будут работать.
На чёткой архитектуре с проявленными границами, зонами ответственности и контрактами агенту легче двигаться предсказуемо. Если она размыта и держится на человеческом понимании, в руках агента эта мутность только усиливается.
Отсюда вывод, который мне самому не понравился. Не всякая хорошая архитектура одинаково ложится на работу с агентом. Это не упрёк архитектуре и не похвала агентам, а констатация: исполнитель тут другого типа, и смотреть на него надо отдельно.
В такой работе архитектурная ясность обычно важнее архитектурной изощрённости.
Где архитектура чаще всего ломает работу агента
Три места повторяются почти на каждом проекте.
Формальные границы не совпадают с реальными. Снаружи модуль отвечает за одно, на практике половина его поведения завязана на боковые эффекты и неявные связи. Самый дорогой такой случай у меня случился на Сортуле через два месяца после запуска. Модуль закладок и модуль поиска формально были разделены: у каждого своя схема, свой API, свой набор тестов. По факту индексатор лез прямо в таблицу закладок, мимо её же собственного API. Я об этой связи знал, в архитектурных заметках она была. В задачу на закладки она не попала.
Задача звучала безобидно: переименовать поле с временем последнего визита, чтобы привести названия к единому стилю. Агент посмотрел на API закладок, увидел, что это имя наружу не выходит, и спокойно сделал миграцию. Тесты модуля закладок прошли. К концу дня мониторинг показал массовые падения индексатора: внутри он продолжал читать старое имя поля. Об этом знал только я, и в задаче этого не оказалось.
Лечилось это не точечной правкой. Пришлось вынести неявную связь в явный контракт и заставить индексатор читать закладки только через него. После этого реальная граница совпала с формальной, и тот же класс ошибок исчез.
Система держится на негласных знаниях. Команда знает, что определённый сервис лучше не трогать без крайней необходимости. Один слой меняют только через специальный механизм. Один кусок кода выглядит избыточным, на самом деле защищает от неприятного побочного эффекта. В классической разработке такие негласные правила не считаются проблемой, пока носители контекста на месте. На самом деле это отложенный риск проекта: он выстреливает при ротации команды. Человек, у которого в голове это есть, действует осторожно. Агент таких голов не читает.
В четвёртой статье я приводил пример с фоновой задачей, у которой не был прописан маршрут очереди. Это ровно эта категория. Система тихо держалась на правиле явной регистрации новых задач в маршрутизаторе, и пока это правило лежало только в голове, оно периодически терялось.
Локальное изменение имеет длинный хвост. Один шаг внутри понятной зоны порождает следствия в десяти соседних местах, и эта связность нигде не проявлена. Агент решает задачу в пределах видимой области, потому что больше ему неоткуда. И дело тут не в том, что он не подумал о хвосте. Ему просто не на что было опереться.
Все три случая объединяет одно. В каждом из них архитектура перестаёт быть надёжной картой местности. А если карта плохая, агент не превращается в осторожного исследователя сложного ландшафта. Он спокойно идёт не туда.
Иногда систему приходится упрощать специально
Это самый чувствительный момент, потому что задевает профессиональную гордость.
Простой пример. На одном из проектов я долго гордился тем, как у нас собран модуль авторизации через внешних провайдеров. Была аккуратная реализация паттерна Стратегия: интерфейс провайдера, несколько реализаций под разные внешние сервисы, фабрика, регистрация в контейнере зависимостей. Любой архитектор считывал это за пять минут и кивал. Архитектурно образцово, на собеседовании за такое кивают.
В работе с агентом этот паттерн начал стабильно сбоить. Каждый раз, когда я ставил задачу на нового провайдера или на правку поведения старого, агент находил точку расширения не там, где нужно. Выносил изменения в фабрику, хотя править нужно было конкретную реализацию. Расширял интерфейс методом, полезным только для одного провайдера и лишним для остальных. Локально решения выглядели разумно, а в целом система медленно разъезжалась.
В какой-то момент я заменил Стратегию на скучное ветвление по идентификатору провайдера и несколько изолированных функций рядом, каждая со своим контрактом. Архитектурно это прямолинейно до неприличия. Агент перестал ошибаться в этом месте. Задача на подключение очередного провайдера закрывалась с первой попытки, без архитектурных мин в отчёте.
Я бы не сказал, что Стратегия была плохим решением. Это было решение, рассчитанное на исполнителя другого типа: на команду людей, которые читают паттерн целиком и удерживают его границы интуитивно. С другим исполнителем выяснилось, что он стоит дороже, чем приносит. И это, пожалуй, самый честный тест зрелости архитектуры в этой модели разработки.
Я не призываю упрощать архитектуру под агента везде и всегда. Скучное ветвление вместо Стратегии не делает систему лучше для людей и не годится как универсальный приём. Но если архитектурный приём раз за разом порождает в работе агента одни и те же ошибки, виноват уже не агент.
Документация как часть инфраструктуры исполнения
Когда я перешёл в режим 100% ИИ-разработки, больше всего меня удивило, как изменилась роль документации.
В обычной разработке к ней относятся примерно так. Документация полезна, но не критична. Если команда сильная, ключевые люди на месте, важное держится в разговорах, проект всё равно движется. ADR пишут когда-нибудь, потом, перед увольнением, для нового сотрудника.
С агентами эта роскошь дорожает быстро. Если архитектура не зафиксирована явно, агент восстанавливает её по косвенным сигналам в коде. На простой системе это работает. На сложной даёт слишком много пространства для случайных выводов: на одном модуле агент опирается на одну неявную конвенцию, через две недели на соседнем модуле берёт другую, и через пару месяцев в проекте сосуществуют две версии одного и того же приёма. Падений может не быть, единообразие тихо уезжает.
Зато сам агент способен быстро производить документацию из живого кода, если автор рядом и проверяет результат. На чужом унаследованном коде без живого носителя контекста этот же приём не работает; разбор такого случая был во второй статье. Документация не возникает сама, но стоимость её появления упала в разы. И читает её агент очень быстро: там, где человеку нужны часы, чтобы пройти по архитектурным описаниям и истории решений, агенту для первичного охвата хватает секунд.
Я смотрю на архитектурные документы как на часть рабочей инфраструктуры. Если их нет, устарели или противоречат коду, это не эстетическая проблема, а сбой в системе разработки, который обязательно отразится в MIR из второй статьи на ближайших двух-трёх задачах. Устная архитектура для живой команды ещё норма, но агент её не наследует сам, и негласные правила остаются за кадром, пока не вынесены в артефакты.
Память проекта: пять типов записей
С третьим слоем у меня сложилось не сразу. Он работает фоном, и долго казалось, что без него можно обойтись.
В большинстве команд значительная часть рабочего знания живёт не в коде и не в документации, а в людях. Не потому, что это норма, чаще просто никто не довёл руки оформить это явно: менеджер не довёл это до записи, инженеры решили устно и забыли записать. В одной голове правило: определённый сервис трогать не надо, его выпиливают. В другой голове история про библиотеку, которую пробовали и откатили на полугоде из-за репликации. Странная конструкция в коде, прикрывающая гонку после новогоднего инцидента, существует в памяти полутора инженеров и нигде больше. В классической разработке этот долг копится годами и стреляет уходом ключевого человека. С агентом он не работает с первого дня: агент в голову не заглядывает.
С агентом этот слой нельзя оставить в головах. Агент в каждую следующую задачу заходит с нуля, и если фоновый контекст ему не передан, он раз за разом будет приносить идеи, которые команда уже отвергала, заходить в известные тупики и игнорировать договорённости, которых нигде не записано.
В опубликованных частях серии таких типов пять: dead_end, gotcha, pattern, convention, context. На каждом моём проекте обычно встречались все.
Сам стандарт SENAR оставляет категорию Запись знаний открытой и приводит четыре примера: решение, паттерн, известная проблема, тупиковый подход. Пять типов выше это рабочая разводка той же категории в TAUSIK, привязанная к моменту, в который запись должна всплыть рядом с задачей.
С шестью слоями контекста у этой памяти есть точка пересечения: слой истории собирается из записей памяти под конкретную задачу. Память лежит постоянным фоном, слой истории это её срез под текущее изменение. Одно знание в двух ролях.
Развести два близких я стараюсь так: convention держится на формулировке мы в этом проекте всегда так, это стабильное правило на всю кодовую базу; pattern живёт там, где говорится типовой каркас для задач такого класса, и один и тот же способ многократно повторять не обязан, это скорее повторяемый технический почерк под интеграции, синхронизацию, очередь и другие узнаваемые сюжеты.
-
convention. Проектная договорённость: как именно здесь принято делать однотипные вещи повсюду. То, что выбирают один раз и дальше повторяют одинаково, чтобы не спорить на каждой задаче заново. Пример записи: идентификаторы внешних сущностей всегда храним как строки, даже если внешний сервис отдаёт число: один из источников начал отдавать UUID, и мы не хотим заводить миграцию каждый раз, когда новый источник меняет тип. Такие договорённости редко попадают в основную документацию, потому что кажутся мелкими. В работе с агентом каждая незаписанная мелочь превращается в правку после реализации. -
pattern. Типовой способ пройти известный сюжет в коде не с нуля каждый раз. Не в смысле классических дизайн-паттернов; скорее в смысле когда у нас задача такого класса, делаем вот этим чертежом. Пример записи: обогащение данных из внешнего сервиса всегда делаем асинхронно через очередь, а не синхронно. Если внешний сервис недоступен, объект у пользователя сохраняем и помечаем, что обогащение будет позже. Такой чертёж в общем файле инструкций утонул бы, а как отдельную типизированную запись его легко подать в задачу про интеграцию или про очередь. -
gotcha. Подводный камень. То, что выглядит как банальность, но регулярно ловит. В четвёртой статье я приводил пример: фоновая задача без явного маршрута садится в очередь по умолчанию, которую никто не слушает, узнаёшь об этом только из мониторинга. Это типовойgotcha. Запись короткая, но при добавлении новой фоновой задачи инструмент памяти всплывает с ней и блокирует попытку положить её в дефолтную очередь. -
dead_end. Тупик. Подход, который пробовали и от которого осознанно отказались. Иногда потому, что не работает совсем; чаще потому, что в этом проекте, на этой нагрузке, в этой команде он стоит дороже, чем приносит. Пример из моей практики, формулировка приближена к реальной записи: пробовали хранить полный снимок карточки внешнего сервиса в одной колонке для скорости поиска. На шестом месяце столкнулись с распуханием таблицы и стоимостью репликации, откатили в нормализованную схему. Снова не предлагать без явного обсуждения. Если бы этой записи не было, на восьмом месяце агент в очередной задаче на ускорение поиска предложил бы то же самое, и я снова тратил бы вечер на разбор, почему мы это уже не делали. -
context. Фоновый рабочий контекст: эмпирические факты и ограничения системы, которые важно подать рядом с конкретным типом задач. Это не вечное правило, а знание об условиях, в которых система ведёт себя определённым образом. Пример записи: нагрузочное тестирование на тестовом окружении показало, что при росте частоты обращений к ВК API ответы начинают молча приходить с задержкой в несколько секунд, без HTTP 429 и без явных ошибок таймаута. Лечится группировкой запросов на стороне публикатора. В обычной команде такое знание держат один-два человека, которые делали замеры. Если не положить его вcontext, на следующей задаче по оптимизации агент снова пойдёт искать причину не там.
За пятью типами не теоретическая классификация. Они отвечают на простой вопрос: зачем запись лежит в памяти и в какой момент должна всплыть рядом с задачей. Инструмент памяти подаёт их по релевантности: в задаче про интеграцию рядом появляется нужный pattern, при повторе отвергнутого подхода всплывает dead_end, а проектные правила подтягиваются как convention.
Память тоже стареет
Это был один из самых неприятных уроков, и дался он мне дороже, чем я был готов признать.
Память проекта работает не как архив. Архив можно пополнить и забыть; он просто лежит. Память постоянно подаётся в задачи, и устаревшая запись подаётся так же, как актуальная: с тем же весом и в той же позиции. В одном случае она помогает, в другом ломает работу.
Самый дорогой случай у меня был такой. На Сортуле в первом месяце я завёл gotcha о том, что библиотека для работы с ВК API некорректно обрабатывает таймаут и его нужно явно переопределять. Запись была корректной: в тот период она помогала. Через несколько месяцев мы убрали эту библиотеку и переписали ВК-клиент с нуля; у нового клиента с таймаутом всё было в порядке. gotcha про старую библиотеку никто не убрал. В следующей задаче на новую интеграцию агент нашёл эту запись, послушно переписал таймаут поверх корректного, получил гонку с одним из эндпоинтов и закрыл задачу с зелёными тестами. На проде это всплыло позже, когда пользователи начали жаловаться на повторные уведомления.
Я уверен, что виноват тут не агент и не инструмент памяти, а тот, кто не пересмотрел память при крупном изменении. Я её и не пересмотрел.
С тех пор у меня отдельная задача-привычка. Каждый раз, когда крупное архитектурное изменение закрывает целый кусок старого кода, я отдельным шагом прохожу по памяти и помечаю всё, что про этот кусок, как устаревшее. Это занимает пятнадцать минут на изменение. Без них устаревшие записи продолжают подаваться в задачи как актуальные.
Устаревшая запись в памяти проекта работает как вредный артефакт. Она попадает в задачу с тем же весом, что и свежая, и агент добросовестно следует ей.
Где среда не помогает
Контур замыкается на трёх слоях, но не на всех задачах. Я перечислял в четвёртой статье границы для ворот; здесь добавляются специфические для среды.
Незнакомая постановщику предметная область. Никакой контекстный пакет, никакая память и никакая архитектура не закроют ситуацию, в которой автор не знает, чего он не знает. Если я первый раз в жизни пишу систему для расчёта налогов, никакая среда не спасает: я не подаю в задачу правило, которое нужно соблюдать, потому что я о нём не подозреваю. Здесь среда работает как форма, не как содержание. Лечится только погружением в домен или приглашённым экспертом; ни то, ни другое в работу с агентом автоматически не встраивается.
Перенос среды с одного человека на команду. Память, которую один автор собирает под себя, читается одним автором. Запись в стиле не предлагать снова, обсуждали в декабре работает, потому что автор помнит, что было в декабре. Когда таких людей становится двое, и тем более пятеро, такие записи становятся непрозрачными. Среда требует переоформления под коллективное чтение. Это отдельная работа, и я её только начинаю; масштабную команду на этой среде я ещё не видел.
Постепенная архитектурная деградация. Среда задачи всегда снимок, сделанный сегодня. Через год большая её часть устаревает, и если за этим отдельно не следить, агент постепенно начинает выдавать решения, которые формально согласуются со средой, но расходятся с реальной системой. Это та же проблема, что и с архитектурной документацией в классической разработке: ей нужна постоянная поддержка, и SENAR это требование не отменяет.
Среда задачи закрывает огромный кусок того, что раньше не закрывалось ничем. Но знания продукта и понимания домена она не заменяет, а сама требует постоянного контроля: не превратилась ли в архив.
Если унести из статьи одну мысль
У контура задачи из прошлой статьи два замка: ворота на входе и ворота на выходе. Среда задачи между ними даёт пол, потолок и стены комнаты, где агент работает. Без пола эти замки просто висят в пустоте.
Шестая статья развернёт оставшееся: где всё перестаёт работать, что меняется при переносе на команду, какие вопросы открыты.
Словарь терминов
SENAR (от английского Supervised Engineering & Normative AI Regulation, контролируемая инженерия и нормативное регулирование ИИ). Открытая методология инженерной работы с ИИ-агентами при разработке. Лицензия CC BY-SA 4.0. Полные тексты на senar.tech. Соавтор: Вадим Соглаев.
TAUSIK (от английского Task Agent Unified Supervision, Inspection & Knowledge, единая система наблюдения, проверки и знаний для задач и агентов). Открытый набор инструментов, который автоматизирует ворота качества, метрики и память проекта по методологии SENAR. Репозиторий: github.com/Kibertum/tausik-core.
Среда задачи. Авторская рабочая категория этой статьи: то, в чём агент работает между QG-0 и QG-2. Состоит из трёх слоёв: контекст под задачу, архитектурные границы, типизированная память проекта.
Контекстный пакет. Сборка контекста под конкретную задачу из шести слоёв (продуктовый, архитектурный, реализационный, качества, задачи, истории). Собирается каждый раз заново и подаётся в задачу по релевантности, а не общим списком. Авторская рабочая систематика этой статьи; в каноническом тексте SENAR на senar.tech перечень компонентов контекста сформулирован иначе, и его стоит читать там же.
Типизированная память проекта. Хранилище фонового знания проекта в виде записей разных типов; в этой серии используются пять: convention (проектная договорённость о том, как делать однотипные вещи), pattern (принятый способ пройти известный сюжет в коде), gotcha (подводный камень, который регулярно ловит, если его не учитывать), dead_end (подход, который пробовали и от которого осознанно отказались), context (фоновые эмпирические факты о системе). Записи подаются в задачи по релевантности. Это рабочая разводка открытой категории Запись знаний из SENAR Standard (раздел 3.10) в реализации TAUSIK.
DER (от английского Dead End Rate, доля тупиковых попыток). Доля времени и попыток, ушедших в тупиковые ветки работы над задачей. Чем плотнее память проекта, особенно dead_end, тем ниже DER. В первой статье серии та же аббревиатура расшифровывалась как Defect Escape Rate; начиная с четвёртой статьи использую DER в смысле Dead End Rate, прежнее значение перешло в служебную метрику ERR.
FPSR / MIR. Доля задач, решённых с первой попытки, и доля задач, в которых потребовалась ручная правка кода после агента. Подробно во второй и четвёртой статьях серии.
Ворота качества, спецификация задачи. Подробно разобраны в четвёртой статье серии.
Серия про инженерный процесс для разработки с ИИ-агентами:
-
Часть 1: Полтора года без ручного кода: почему инструкции ИИ-агенту не заменяют инженерную дисциплину
-
Часть 2: ИИ-агент не программист: пять наблюдений и три следствия
-
Часть 4: Спецификация, ворота, метрики: как SENAR закрывает вход и выход задачи
-
Часть 5: Среда агента: контекст, архитектурные границы, память проекта
-
Часть 6: Где это всё перестаёт работать (скоро)
ссылка на оригинал статьи https://habr.com/ru/articles/1034788/