Синтетические данные для проверки кода агента должны воспроизводить ограничения реальных записей

Синтетические данные здесь означают вымышленные записи для проверки программы. CTO нужно убедиться, что после правки агент правильно считает возврат, выдаёт доступ или меняет статус заказа. Имена покупателей могут быть любыми; связь заказа с оплатой и предел возврата должны соответствовать правилам продукта.

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

Документация PostgreSQL описывает ограничения полей и связей, а DataCebo отдельно различает закономерности данных и обязательные правила. Похожесть на рабочие записи ещё не обеспечивает соблюдения правила. Если возврат нельзя сделать без оплаты, это условие надо записать и проверять явно.

Возьмём вымышленный заказ: оплачено 10 000 ₽, ранее возвращено 7 000 ₽, доступный остаток 3 000 ₽. Запрос на 4 000 ₽ должен получить отказ. Если генератор создал только новые заказы без истории возвратов, ошибка в расчёте остатка останется незаметной.

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

Теперь добавьте развязку: запрос на ровно 3 000 ₽ должен пройти, а его повтор не должен увеличить общую сумму возврата. Такой пример проверяет границу и повтор события. Тысячи свежих заказов с разными именами могут ни разу не проверить ни то ни другое.

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

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

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

В открытой машине агентов на vibecoding.ru инженер ведёт машину агентов и записывает сбои вместе с изменениями правил. Эти истории не доказывают качество генератора синтетических данных. Они показывают, почему набор должен сохранять состояние покупки, форму ответа и повторы событий.

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

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

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

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

Проверьте также силу проверки: временно уберите из копии функции вычитание предыдущих возвратов. Сценарий с запросом на 4 000 ₽ должен обнаружить ошибку. Если он по-прежнему проходит, ожидаемый ответ или способ сравнения не ловит нарушение; такой набор ещё рано использовать для приёмки.

Начать можно с возврата, выдачи доступа или расчёта скидки: инженер собирает правила с владельцем процесса, агент готовит записи и прогон, инженер проверяет ожидаемые ответы. Учебный возврат считается описанным, когда в наборе есть предыдущие 7 000 ₽, граница остатка и повтор события; одни новые заказы для этой задачи недостаточны.

Если обсуждаются данные клиентов у агента, сначала выберите, как появятся вымышленные записи. Их можно придумать по правилам функции; модель, обученная на рабочих записях, уже использует эти записи при обучении. ICO отдельно отмечает: синтетические данные могут оставаться неанонимными. Само название набора не доказывает, что исходные сведения исчезли.

Подготовку набора для конкретной функции можно включить в очередь подписки на агентную разработку: «Один проект» стоит 250 000 ₽/мес по странице услуг на 08.10.2026. Это цена подписки, а не отдельного набора; состав работы согласуют для вашего продукта. Чтобы определить первый участок проверки, обсудите задачу разработки.

1. Начните с правил одной функции: поля, связи, суммы, состояния и повторы событий.

2. Генерируйте связанную историю, а правильный ответ задайте до прогона кода.

3. Добавьте обычные, граничные и намеренно ошибочные записи; не потеряйте разрешённые старые состояния.

4. Сохраните записи, время и порядок событий; убедитесь, что проверка обнаруживает намеренное нарушение.

5. Каждую найденную ошибку закрепите отдельным сценарием и запускайте его после следующих правок.