Разработчик может использовать одного агента для написания кода, другого — для ревью, третьего — для тестирования. Но если сведения о принятых решениях остаются в отдельных чатах, каждому следующему исполнителю приходится заново разбираться в задаче. Особенно часто это происходит при передаче работы от разработки к ревью и тестам.
Как договоренности теряются между этапами
Во время разработки человек и агент уточняют поведение функции, обсуждают ограничения и согласуют решение. Если оно осталось только в чате, ревьюер получит diff, документацию и тикет без объяснения, почему выбран именно такой вариант. Он может предложить изменить уже принятое поведение, даже если ошибки нет. Затем с тем же пробелом столкнется агент, который пишет или запускает тесты.
Выход — хранить материалы изменения вместе и дополнять их по ходу работы. Сначала в них фиксируют цель, требования, сценарии и критерии приемки. При проектировании добавляют технические решения и их обоснования, при разработке — код, тесты и согласованные уточнения, на ревью — замечания и результаты проверок. Изменились требования — обновили спецификацию. Изменился код — повторили затронутые проверки.
Почему ревью становится узким местом
Отдельный вопрос — кто успеет проверить весь написанный агентами код. Агенты помогают писать больше кода, но ревью, валидация и тестирование сами по себе не ускоряются. Когда изменений становится больше, на проверку выстраивается очередь. Разработчикам нужно восстановить контекст каждого PR, а под давлением объема ревью может стать поверхностным. Поэтому сквозному процессу нужны проверки между этапами и понятные условия, при которых агент останавливается и обращается к человеку.
Для описания степени самостоятельности агентов эксперт и преподаватель курса AI SDLC Алексей Могильников использует уровни L0–L5. На первых уровнях агент помогает внутри роли разработчика, аналитика или тестировщика. На L3 он может выполнить согласованную задачу по спецификации, а человек проверяет результат. На L4 несколько специализированных агентов работают в общем пайплайне. На L5 большинство знакомых задач может проходить автономно, но люди разбирают спорные и рискованные ситуации и контролируют изменение правил. Это рабочая модель описания зрелости, а не единый отраслевой стандарт.
Как перестроили процесс в команде CRM
Команда из шести человек разрабатывала кастомную CRM. Агенты уже помогали писать код и тесты, но задач целиком им не поручали: актуальных спецификаций не было. Для нескольких компонентов агент подготовил первичные спецификации, PM уточнил сценарии и ограничения. Затем ввели карточки инкрементов с контекстом и критериями приемки. Агент готовил код, тесты и merge request, разработчики проверяли техническое решение, тестировщик — сценарии и регрессии, PM — соответствие требованиям. После приемки обновляли спецификации и журнал решений. По замерам сопоставимых небольших задач среднее время от готовой постановки до принятого MR на этих компонентах сократилось с четырех до двух дней. Финальную проверку оставили людям.
На бесплатном вебинаре Хекслета «Как выстроить сквозной SDLC для ИИ-агентов» 26 октября в 19:00 разберем, как составлять спецификации, передавать контекст между агентами и проверять результат до принятого PR.
