Код напишет агент. А кто объяснит ему, как у вас всё работает?

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

Раньше команда разбиралась с этим по ходу работы. Спрашивали коллег, читали код, спорили на ревью. Часть решений так и оставалась в переписке и головах. 🤔

Что произойдёт, если основным исполнителем станет агент?

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

И здесь начинается интересное: «У каждого артефакта есть владелец, область применимости (scope), срок актуальности (validity) и покрытие проверками (eval coverage)».

Стр. 22.

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

Получается, у команды меняется само содержание работы. 😱

Разработчику нужно уметь объяснить ограничения системы так, чтобы ими мог пользоваться другой исполнитель. Техлиду — добиваться согласованности архитектурных решений. Знаниям из обсуждений нужно находить место в поддерживаемом контексте. А при изменении системы придётся проверять, какие инструкции и спецификации теперь устарели.

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

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

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

И вот тут у меня вопрос к переходу на новую модель. Время на написание кода мы рассчитываем сократить. А время на подготовку и поддержание контекста уже учли? Кто отвечает за него на стыке нескольких команд? Что перестанут делать эти люди, чтобы взять новые обязанности?

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

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

[Подписывайся t.me/teamrocknrolla]

Всем контекста 🫰