Доводим задачи 1С до боевой базы: конвейер из семи агентов, восемь задач, шесть промахов

Полтора десятка задач заказчика прошли путь от строки в трекере до кода в боевой конфигурации - 1С:БП КОРП с БИТ.ФИНАНС с большим количеством доработок типового кода и новых подсистем. Не демо-база и не "конфигурация с нуля".

В конвейере те же роли, что в обычной разработке, от аналитика до технического писателя, только выполняют их агенты. Человек ставит задачу, утверждает решения и принимает результат. На выходе каждая задача несет полный набор документов - от ТЗ до чек-листа для QA - и набор одинаковых проверок, результат которых записан и который можно предъявить.

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

Проблема

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

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

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

Последняя строка - не об ИИ вовсе. Конфигурация редактируется с сохранением поддержки, правки идут в вендорские модули, и регламент оформления правок в команде появился задолго до меня. Теперь регламент должен соблюдать еще и агент.

Поэтому задача ставилась не как "пусть ИИ пишет код", а как довести доработку до боевой базы. С ТЗ, обоснованным выбором механизма, проверенным кодом, тестами и документацией.

Как устроен конвейер

Сначала о том, где конвейер стоит в командной цепочке. У нас она такая: аналитик готовит задание, я с агентами разрабатываю, QA проверяет результат по ТЗ, аналитик принимает. Аналитик и QA тут - живые коллеги, а конвейер целиком помещается внутрь моего звена.

Дальше названия ролей встречаются в двух смыслах, поэтому договоримся сразу: в схеме и таблицах ниже все названия - это роли конвейера, то есть агенты. Живых коллег я помечаю словом "человек".

Схематично конвейер выглядит так:

постановка из трекера

  1  аналитик
       * открытые вопросы аналитику-человеку
  2  архитектор
  3  разработчик
  4  сценарист         (параллельно с разработчиком)
       * проверка на стенде руками
       * синтаксический контроль конфигуратора
  5  ревьюер
  6  тестировщик
  7  технический писатель

приемка человеком, перенос в базу

После каждого этапа человек жмет "принято" или возвращает на доработку. Этапы разработчика и сценариста идут параллельно - так проверки пишутся вслепую, но цикл от этого не удлиняется.

Звездочками помечены три шага, которых в схеме сначала не было: каждый появился после того, как дефект прошел конвейер насквозь. Что это были за дефекты - в разделе "Где конвейер пропускал и что сделано".

На выходе с каждого этапа получаем следующие артефакты:

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

В этой схеме работают две вещи, обе неочевидные:

Изоляция сценариста. Сценарист пишет проверки параллельно с разработчиком и не видит правок кода, только постановку, ТЗ, архитектуру и код по снимку "до задачи". Поэтому сценарии проверяют замысел, а не результат: тесты, написанные по готовому коду, проверяют код на соответствие самому себе.

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

Что из этих документов читаю

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

Как изменения выглядят в коде

// {[*](фрагмент ИЗМЕНЕН), 28.07.2026, #FSK Иванов И.И. #TASK-1234

//  СтароеЗначение = Настройки.Реквизит;

    СтароеЗначение = фск_РаботаСНастройками.РеквизитНастроек(Настройки);

// } Иванов И.И., 28.07.2026

Это наш командный регламент комментирования правок. Здесь {[*] открывает вставку изменения существующего кода, // } - закрывает, #FSK - метка доработок команды, а закомментированная строка выше сохраняет то, что было до правки. Для добавления и удаления - те же метки, другой маркер: [+] и [-]. Мне важно было, чтобы агент соблюдал этот формат сам, без ручной доводки после каждой правки.

Стек

Как устроены эти серверы внутри, почему индекс собран именно так и почему мы до сих пор не на EDT - тема отдельного разговора, к ней вернусь во второй части. Здесь стек перечислен затем, чтобы было видно, чем именно получены цифры ниже.

Как правки доезжают до базы

Командная работа остается штатной: объекты захватываются в хранилище конфигурации, а принятые правки переносятся сравнением и объединением конфигураций руками. Агенты правят исходники - выгрузку конфигурации в файлы, которая лежит под git. Она нужна для двух вещей: агентам - как рабочая копия, где можно править код, ревьюеру - как способ увидеть все изменения задачи целиком в git diff. Хранилище она при этом не заменяет. Схема рабочая, но это самая ручная часть цикла. С переездом на EDT ветки на задачу станут рабочим инструментом, а не вспомогательным.

Где берется выигрыш

Задачи с оценкой в пять дней закрываются за три. Оценку ставил не я - команда разработки на PBR, до того как задача попадала ко мне. Печатает агент быстрее, это правда, но два дня экономии получаются не из-за скорости набора. Они набегают на трех этапах.

Аналитика. На вход я даю то, что пришло от аналитика-человека: функциональный дизайн или текст задачи из трекера. Дальше идет тот самый разбор, который делает разработчик перед началом работы: какие механизмы затронуты и что в задании можно понять по-разному. Раньше он съедал больше всего времени, шел в голове и не оставлял артефакта, а неясности всплывали по одной уже посреди реализации. Теперь это ТЗ за один проход плюс список вопросов ко мне. На одной из задач вопросов набралось 15 - настолько неточными оказались формулировки в описании. Сколько из них изменили объем работ, я не считал; знаю только, что изменили существенно - и до первой строки кода, а не после демонстрации заказчику.

Архитектура. Выбор механизма перестал быть решением "как привык": варианты выписываются и сравниваются. На одной задаче архитектор забраковал собственный первый вариант: правка задела бы соседние документы. Механизм поменяли до того, как под него написали хоть строку.

Разработка. Экономится сопутствующее: поиск всех мест по графу вызовов, оформление вставок по регламенту, отчет, документация. Те часы, которые обычно не оцениваются и потому кажутся бесплатными.

Чего в этих двух днях нет, разбираю в конце статьи отдельно - вместе с остальным, что я не измерял.

Модульные тесты, которых раньше не писали

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

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

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

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

Что показали измерения

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

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

Чего по таблице сравнивать нельзя. Объемы у задач сильно разные, так что строки между собой несопоставимы.

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

В "незначительные" попадает оформление вставок, именование, комментарии, пересказывающие код словами. Поодиночке мелочь, накопительно из них складывается разница между "работает" и "через год можно разобраться".

Как считал. Одно замечание - один пункт из отчета ревью; в трех счетных колонках только они. Находки других этапов туда не попали: вопросы аналитика, забракованные архитектором варианты, сценарии тестировщика. Колонка "Возврат" шире - она про сам факт разворота, а развернуть задачу мог и аналитик-человек, уже увидев работающую доработку. То есть счет - про то, что поймало ревью, а не про все, что поймал конвейер.

А вот что из этих цифр следует, по самой таблице не увидишь.

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

Так я разбирал только критичные - важные и незначительные остались тем, как их оценил ревьюер.

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

Ревьюер ловит не только разработчика. Задания ролям раздает оркестратор - главная сессия, которая ведет задачу целиком. Ошибается и он, причем его ошибка опаснее: разработчик выполняет указание, не оспаривая, и она въезжает в код не как дефект, а как поставленная задача.

Один раз это выглядело так. Оркестратор увидел в вендорском модуле проверку Структура.Свойство("X") И ЗначениеЗаполнено(Структура.X) и счел ее небезопасной: решил, что правая часть вычислится даже тогда, когда свойства нет, и код упадет. На деле во встроенном языке 1С логические выражения вычисляются слева направо и только в необходимой части - это прямо написано в синтакс-помощнике: свойства нет - левая часть уже дала Ложь, до правой дело не дойдет. Конструкция безопасна.

Дорого тут не само заблуждение, а то, куда оно вело: разработчик пошел переписывать чужой код там, где повода не было вовсе - ровно то, чего регламент велит избегать. Поймал ревьюер, правку откатили.

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

Мне это важно не как довод "ИИ нельзя доверять". Ошибиться тут может кто угодно, в том числе тот, кто раздает задания остальным и сводит их результат.

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

Дело было так. Доработка убирала из отчета несколько уровней группировки. Сам по себе код правки был верным, но рядом, в соседнем методе, лежало обращение к этим полям. После доработки отчет открывался нормально, а при попытке расшифровки падал с "Поле объекта не обнаружено".

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

А соседний дефект, наоборот, поймало ревью - он был виден прямо в diff: в новом запросе не хватало 13 из 26 полей в СГРУППИРОВАТЬ ПО - и в выборке их тоже не было. Отчет от этого не падает и выглядит правдоподобно. Просто строки, которые раньше различались по этим полям, теперь сливаются в одну, а суммы по ним складываются. Замечает такое обычно бухгалтер на квартальной сверке.

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

Где конвейер пропускал и что сделано

Отдельно от замечаний ревью я считаю промахи: дефекты, которые нашли люди уже после того, как этап был принят. Замечание означает, что проверка сработала. Промах означает, что проверка не сработала - ее не было, она не покрывала случай или ее просто никто не выполнил.

За восемь задач промахов набралось шесть, а видов ошибок - четыре: два вида выстрелили по два раза.

Первый вид - интерфейсный: сначала не отобразился элемент формы, потом отчет отказался строить расшифровку - жаловался на незаполненный отбор, хотя отбор стоял. Оба раза дефект находил человек за минуту работы на стенде.

Второй вид - то, что не ловится чтением кода и линтером. Один раз это был вызов функции, которой нет ни в модуле, ни в конфигурации, - он и доехал до боевой базы. Другой раз - переменная, не объявленная перед использованием; ее разберу сразу после таблицы. Третий и четвертый виды выстрелили по одному разу - они в таблице ниже.

Начну с обещанного разбора. Вот код, который не компилируется:

Если Не Настройки.Свойство("КлючВарианта", КлючВарианта) Тогда

А вот тот же код, который компилируется:

КлючВарианта = Неопределено;
Если Не Настройки.Свойство("КлючВарианта", КлючВарианта) Тогда

Разница в одной строке выше. Кажется, что вторым параметром переменная объявляется - а она там только используется, объявить ее должно присваивание или Перем. Не поймал никто: разработчик так написал, ревьюер прочитал diff и не отметил, диагностика промолчала. Нашлось на синтакс-контроле в конфигураторе. Проверка простая: если имя переменной впервые встретилось не слева от знака равенства, а внутри вызова метода - ищите присваивание выше. Нет ни присваивания, ни Перем - не будет и переменной.

Поиском по diff такое ловится грубо: параметр метода регулярка примет за необъявленную переменную, многострочный вызов пропустит. Как подсказка ревьюеру годится, гарантией не является. Гарантия тут одна - синтаксический контроль конфигуратора, и вопрос был только в том, когда его запускать.

Но интереснее не сам дефект, а обе потери.

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

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

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

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

Как конвейер чинит сам себя

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

Последний шаг каждой задачи - зафиксировать, что пошло не так. Это обязанность оркестратора, который ведет задачу целиком: после приемки, до закрытия, он проходит по задаче и выписывает проблемы. Где агент ошибся, где правило не сработало, где инструмент подвел, где процесс дал сбой. Не "подумать об улучшениях", а записать случившееся, пока помнится. Дальше каждая записанная проблема превращается в правку правил: формулируется, показывается человеку, вносится после одобрения. Если улучшать нечего, так и записываем - "корректировок не требуется", - и не сочиняем правку ради галочки: придуманные на пустом месте правила раздувают регламент и топят настоящие.

Каждая такая правка кладется туда, где она сработает. Правило языка идет в регламент, формальная проверка - в скрипт сверки по diff, признак "на что смотреть глазами" - в чек-лист роли, недостаток инструмента записывается в список замечаний по инструментам. Тот дефект с необъявленной переменной, когда до него наконец дошли руки, пришлось закрывать в четырех местах сразу: одного не хватило.

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

Дает сбои и он сам: вторая потеря - та, где вывод ретроспективы не доехал до регламента, - случилась именно здесь. Так что самопочинку тоже приходится чинить руками.

Что в итоге

Что изменилось по факту, если убрать цифры.

Каждая задача доезжает с полным набором документов - от ТЗ до чек-листа для QA и документации. Раньше половина этого списка писалась только там, где хватало времени, а модульные тесты на доработки не писались вовсе.

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

Ловится, конечно, не все: шесть промахов прошли конвейер насквозь, один из них доехал до боевой базы. Три дыры из четырех удалось закрыть - синтаксическим контролем в цепочке, обязательным чек-листом для QA и правилом вскрывать любое вложение к задаче. Четвертую, когда требование приходит уже после приемки, закрытой я не считаю: гейты не ловят ее по устройству, потому что проверяют соответствие спецификации, а не ее истинность. Одна задача так и была откачена целиком - при всех зеленых проверках, потому что вся постановка стояла на неверной посылке.

Главное же, чего я хотел и что получил: у кода, написанного агентами, появились измеримые проверки. Одни и те же на каждой задаче, с фиксируемым результатом - диагностики, синтаксический контроль, метрики, замечания ревью, тесты. Раньше качество зависело от того, насколько внимательно посмотрели в этот раз; теперь на приемку приходит не "вроде работает", а набор документов и проверок, к которому можно предъявить претензии по пунктам.

Чего я не измерял и кому это не подойдет

Дальше - то, что я не измерял, и то, где схема не сработает. Без этого списка статья читалась бы убедительнее, но пользы от нее было бы меньше.

Сперва про цифры.

Я не считал, сколько это стоит в токенах. Счет за месяц я вижу, отдельно по задачам не разносил, поэтому назвать цену одной доработки не могу.

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

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

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

А теперь про границы.

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

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

Если вы работаете расширениями, часть регламента вам не нужна. Маркеры вставок в вендорский код - это специфика правок самой конфигурации; в расширениях набор требований меняется, а не исчезает. Все остальное - роли, изоляция сценариста, трехсторонняя сверка, проверки - переносится без изменений.

Ни одно из этих ограничений не мешает работать: задачи идут в базу, конвейер держит поток. Часть цифр я просто еще не собрал - соберу и напишу.

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

Буду рад отзывам и критике по существу: часть правил, описанных выше, появилась именно так - кто-то со стороны задал вопрос, на который у меня не было ответа.

Отдельная благодарность Дмитрию Заикину (TeamLead) за редактуру статьи.