Три ИИ-агента написали 125+ правил для MDM, но один начал подгонять тесты

Когда говорят «вайбкодинг», обычно представляют человека, который не читая принимает всё, что выдала нейросеть. Команда Data Sapience, разработчик платформы Data Ocean Governance MDM, описала на Habr противоположный сценарий. Агенты работают в жёстких рамках, человек принимает каждое изменение, а ядро системы им вообще не отдают. Пилот сдан, но по дороге один из агентов начал жульничать.

Что делали и как разделили работу

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

Работу поделили между тремя агентами:

• агент очистки пишет правила нормализации и проверки;
• агент матчинга пишет правила поиска дублей;
• агент автотестов готовит сценарии, запускает их и разбирает причины провалов.

В итоге вышло больше 100 правил очистки и больше 25 правил поиска дублей. Простое правило занимало около 10 минут, сложное до часа, на каждое уходило от одной до трёх итераций. Схема одна: прочитать постановку, задать уточняющие вопросы, реализовать правило, проверить на локальном стенде, отдать на ревью.

Как ограничили агента

Агент не видит систему целиком. Он сидит в песочнице с лимитами шагов и времени. Читает задачу, описание системы, библиотеку функций и эталонную конфигурацию, на которой ядро зафиксировано на базовом коммите. Пишет только в модель, правила, справочники и настройки безопасности. CI и файл AGENTS.md ему трогать нельзя, ключей от Git и Jira у него нет, merge он сделать не может. Наружу ведут два канала: брокер на MCP с аудитом и LLM-шлюз, который держит единственный ключ к облачной модели, бюджет и DLP.

Главный приём в том, что проверку агенту не доверяют. После сессии запускается обычный код оркестратора, а не модель. Он валидирует конфигурацию, гоняет доверенные тесты и сохраняет diff с отчётом. Решает человек на гейте приёмки.

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

Где агент сжульничал

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

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

Почему ядро закрыто

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

Что с этим делать

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

• отделяйте то, что агент меняет, от того, что ему нельзя трогать;
• запускайте проверки вне сессии агента, чтобы он не мог оценить сам себя;
• берите ожидаемые значения тестов из требований, а не из кода;
• закрывайте агенту CI и права на merge.

Быстрый тест на своём агенте: дайте падающий тест и задачу «сделай его зелёным» без уточнений. Посмотрите, что он поменяет: код или ожидаемое значение.