TL;DR
Исследователи проанализировали как LLM-агенты используют тесты при решении задач по программированию. Неожиданная находка: GPT-5.2 почти не пишет тесты (только в 0.6% задач), но решает 71.8% задач — практически как топовые модели, которые пишут тесты в 80-98% случаев.
Главный инсайт: тесты работают как инструмент наблюдения, а не проверки. Когда модели пишут тесты, они в 3-5 раз чаще используют print() для вывода значений, чем assert для проверки условий. Модель предпочитает видеть что происходит, а не формально проверять правильность. При этом успешные и неуспешные попытки решения пишут тесты одинаково часто — внутри одной модели разницы почти нет.
Контролируемый эксперимент подтвердил: когда через промпт заставили модели писать больше или меньше тестов, результативность почти не изменилась. Написание тестов — это скорее стиль работы модели, чем фактор успеха. Зато изменился расход токенов: меньше тестов = в 1.5-2 раза дешевле.
Схема исследования
Не метод, а НАХОДКА:
СРАВНИЛИ: 6 топовых моделей на 500 реальных GitHub issues
├─ GPT-5.2: 0.6% задач с тестами → 71.8% решено
├─ Claude Opus 4.5: 83% задач с тестами → 74.4% решено
├─ Minimax-M2: 98.6% задач с тестами → 61% решено
└─ Вывод: частота тестов НЕ коррелирует с успехом
ПРОАНАЛИЗИРОВАЛИ содержимое тестов:
├─ Print-выводы: 60-80% обратной связи
├─ Assert-проверки: 20-40% обратной связи
└─ Вывод: модели предпочитают НАБЛЮДАТЬ, не проверять
ЭКСПЕРИМЕНТ: изменили промпты
├─ "Пиши больше тестов" → результат почти не изменился, токены +40%
├─ "Не пиши тесты" → результат почти не изменился, токены -35%
└─ Вывод: тесты не влияют на решение, но влияют на расход
Применимый принцип
Принцип "Observation over Verification":
Когда модель решает задачу, показать промежуточные значения эффективнее, чем проверять правильность. Формальные проверки (assert, правила, критерии) создают иллюзию контроля, но модель использует их редко. Вместо этого модель предпочитает видеть данные напрямую и корректировать логику на основе наблюдений.
Где применить:
1. Работа с кодом — попроси вывести, а не проверить:
Задача: ChatGPT написал функцию обработки данных, но она работает не так. Вместо проверки через assert, попроси показать промежуточные значения.
Промпт:
Функция parse_price() возвращает странные результаты.
Не пиши assert-ы для проверки.
Вместо этого: добавь print() после каждого шага обработки —
покажи что получилось после .strip(), после .replace(), после int().
Запусти на примерах: "1 200 руб", "1200р.", "1200.00"
Результат: Модель добавит print-ы, покажет промежуточные значения на каждом шаге. Ты увидишь ГДЕ логика сломалась — после какого .replace() строка стала нечисловой. Это быстрее, чем писать assert-ы и ловить исключения.
2. Анализ данных — распечатай шаги, не проверяй формулы:
Промпт:
Посчитай конверсию воронки продаж по этапам:
- Лиды: 1000
- Звонки: 300
- Встречи: 120
- Сделки: 45
Покажи промежуточные расчёты на каждом шаге:
1. Какие числа берёшь
2. Какую формулу применяешь
3. Какой результат получился
НЕ проверяй корректность формулы — просто покажи ЧТО считаешь.
Результат: Модель распечатает: "300/1000 = 30% на этапе Звонки". Если формула неправильная — ты увидишь сразу. Если бы попросил "проверь правильность формулы" — модель написала бы общие правила, но не показала бы конкретные числа.
3. Отладка промпта — выведи рассуждения, не оцени качество:
Промпт:
Ты написал текст для email-рассылки. Вместо проверки по критериям
(понятность, УТП, призыв к действию) — покажи свою логику:
1. Какую мысль хотел передать в каждом абзаце
2. Какое ключевое слово выбрал для SEO и почему
3. Какую эмоцию решил вызвать в призыве
Не оценивай "соответствует ли критериям" — просто распиши ЧТО и ЗАЧЕМ сделал.
Результат: Модель покажет логику изнутри. Ты увидишь что вместо "срочность" она выбрала "безопасность" в призыве — и поймёшь почему текст не работает. Формальная проверка по критериям дала бы "соответствует 4 из 5" без объяснения WHY.
Почему это работает
Слабость LLM: Модель не может "проверить" свою работу так же, как компилятор проверяет код. Assert-ы и правила — это инструкции для новой генерации текста, не для проверки предыдущей. Когда пишешь "проверь правильность формулы", модель генерирует текст о проверке, но не пересчитывает результат заново.
Сильная сторона LLM: Модель отлично следует структурированным инструкциям и выводит промежуточные данные. Когда пишешь "покажи что получилось после каждого шага", модель симулирует выполнение —генерирует текст с конкретными значениями, который ты можешь проверить глазами.
Как принцип использует это: Вместо абстрактной проверки ("всё ли правильно?") ты просишь конкретный вывод ("что в переменной X после строки 5?"). Модель генерирует наблюдаемые данные — числа, промежуточные результаты, логику рассуждений. Ты видишь проблему напрямую, без прослойки "формальной проверки".
Рычаги управления:
- Глубина наблюдения — попроси print после каждой строки vs после каждого блока → детальнее vs обзорнее
- Формат вывода — "покажи в виде таблицы" vs "построчно" → структурировать данные для анализа
- Что выводить — "только значения переменных" vs "значения + твои рассуждения почему так" → данные vs контекст
- Убрать проверки — вырежи все "assert", "if correct", "validate" → модель не тратит токены на имитацию проверки
Ключевой инсайт для работы
Value-revealing > Assert-based:
Когда просишь модель решить задачу: - ❌ "Проверь правильность решения по критериям A, B, C" → модель сгенерирует текст о проверке - ✅ "Покажи промежуточные значения на шагах 1, 2, 3" → модель выведет конкретные данные
Когда просишь модель отладить код: - ❌ "Добавь assert-ы чтобы проверить корректность" → модель напишет проверки, которые могут упустить баг - ✅ "Добавь print() чтобы видеть что в переменных" → модель покажет данные, ты увидишь баг
Практический вывод: Формальные проверки (правила, assert-ы, критерии оценки) работают хуже чем кажется. Модель использует их редко и неточно. Вместо этого проси показать данные — промежуточные результаты, рассуждения, значения переменных. Observation beats verification.
Ограничения
⚠️ Применимость: Принцип извлечён из исследования про код-агентов. Прямая применимость — для работы с кодом в ChatGPT/Claude. Для задач без кода (написание текстов, анализ) — требуется адаптация, эффект может быть слабее.
⚠️ Не про качество тестов: Исследование НЕ про то, как писать хорошие тесты. Оно про то, что модели естественным образом предпочитают print-ы assert-ам. Если тебе нужны формальные тесты для production-кода — этот принцип не отменяет их необходимость.
⚠️ Контекст исследования: Выводы основаны на задачах программирования (SWE-bench). Для других доменов (креатив, стратегия, анализ текстов) эффективность "observation over verification" не проверялась систематически.
Как исследовали
Команда взяла 500 реальных GitHub issues из SWE-bench Verified — баги и задачи из популярных Python-проектов. Запустили 6 топовых моделей (Claude Opus 4.5, GPT-5.2, Gemini 3 Pro и др.) в одинаковых условиях: минималистичный scaffold без встроенных модулей тестирования. Модель могла создавать тесты через bash-команды если захочет, но это никто не требовал.
Неожиданность: GPT-5.2 почти не писал тесты (3 из 500 задач), но решил 359 из 500 — второй результат среди всех моделей. Minimax-M2 писал тесты в 493 из 500 задач, но решил только 305. Это противоречило ожиданиям: если тесты важны, GPT-5.2 должен был провалиться.
Дальше исследователи вручную проанализировали содержимое тестов в успешных и неуспешных попытках. Обнаружили: модели пишут в 3-5 раз больше print() чем assert. Даже когда пишут assert-ы — это простые проверки вида assert x == 5, а не сложные условия. Это говорит о том, что тесты — скорее инструмент отладки (посмотреть значения), чем проверки корректности.
Контролируемый эксперимент: взяли 4 модели и изменили промпты. Одна группа: "Always write tests to validate". Вторая: "Avoid writing new test files". Запустили на тех же 500 задачах. Результаты почти не изменились (±2-3 процентных пункта), зато расход токенов изменился на 30-40%. Вывод: написание тестов влияет на стоимость, но не на результат.
Почему результаты получились такими: Модели обучены на кодовых корпусах, где распространён паттерн "написал код → написал тест". Они воспроизводят этот паттерн, даже если он не помогает решить конкретную задачу. GPT-5.2, видимо, не воспроизводит этот паттерн — и успешно решает задачи без тестов. Это показывает, что тестирование — усвоенный шаблон поведения, а не обязательный фактор успеха.
Адаптации и экстраполяции
💡 Адаптация для работы с таблицами и формулами:
Принцип "observation > verification" работает для любых вычислений. Вместо проверки формулы — попроси вывести промежуточные расчёты.
Промпт:
Рассчитай юнит-экономику для онлайн-курса:
- Цена: 15000 руб
- Трафик: 10000 визитов/мес
- Конверсия в покупку: 2%
- CAC (стоимость привлечения): 3000 руб
- Churn (отток): 30%/мес
- Маржинальность: 70%
Выведи пошагово:
Шаг 1: Покупателей в месяц = [формула] = [число]
Шаг 2: Выручка в месяц = [формула] = [число] руб
Шаг 3: Маржинальная прибыль = [формула] = [число] руб
...
НЕ проверяй корректность — просто покажи ЧТО считаешь на каждом шаге.
Ты увидишь если модель перепутала формулу (например, взяла всю выручку вместо маржинальности). Value-revealing вместо verification.
🔧 Техника: Логи рассуждений для отладки текста
Когда модель пишет текст и результат не устраивает — вместо критики по критериям попроси показать логику изнутри.
Промпт:
Ты написал описание товара для маркетплейса.
Не оценивай текст по критериям (УТП, эмоция, призыв).
Вместо этого — распечатай свои рассуждения:
1. Какую главную боль клиента решил закрыть в первом предложении?
2. Какое конкретное слово выбрал для триггера срочности? Почему именно его?
3. Какую альтернативу рассматривал для призыва к действию? Почему отклонил?
Формат: "Шаг N: [решение] → потому что [рассуждение]"
Модель покажет внутреннюю логику. Ты увидишь что вместо "боль — дорого" она выбрала "боль — долго" — и поймёшь откуда несоответствие. Это observation, не verification.
💡 Экстраполяция: Multi-shot debugging с выводом
Комбинируй принцип "observation" с итеративной отладкой. Вместо одного запроса "реши задачу" → цепочка "покажи → исправь → покажи снова".
Промпт (цикл 1):
Напиши email для возврата клиента после отмены пробного периода.
После написания — выведи:
- Ключевая эмоция, которую хотел вызвать: [X]
- Главное возражение, на которое отвечаю: [Y]
- Призыв к действию: [Z]
Промпт (цикл 2):
Ты выбрал эмоцию "любопытство", но я хочу "FOMO".
Перепиши текст под эту эмоцию.
После переписывания — снова выведи три пункта: эмоция, возражение, призыв.
Каждый цикл — observation+correction. Ты видишь ЧТО изменилось, не полагаешься на абстрактную "проверку качества".
Ресурсы
Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents Zhi Chen, Zhensu Sun, Yuling Shi, Chao Peng, Xiaodong Gu, David Lo, Lingxiao Jiang Singapore Management University, Shanghai Jiao Tong University, ByteDance