WTF (agent-wtf) - открытый инструмент, который детерминированно проверяет результаты работы кодинг-агентов и не использует LLM вообще. Запускается локально командой npx agent-wtf, не требует аккаунта, облака и API-ключа. Вместо опроса агента инструмент смотрит на итоговое состояние репозитория: файлы, зависимости, манифесты, результаты тестов.
Проблема, которую он закрывает, знакома каждому, кто отдавал задачи кодинг-агенту. Агент пишет «done», а дальше начинается расследование: какие файлы он тронул, изменились ли зависимости, не остался ли тест пропущенным, не задело ли правки в auth, конфигурации или миграциях, действительно ли запускались тесты, которые названы успешными, и какую часть огромного диффа вообще нужно читать глазами.
Первым порывом обычно бывает бросить на проверку ещё одну модель и попросить её оценить первую. Автор WTF задаётся встречным вопросом: зачем, если Git уже знает, что изменилось, файловая система знает, какие файлы существуют, манифесты пакетов знают, какие зависимости поменялись, а тест-раннеры знают, прошли ли тесты. Эти данные не нужно угадывать, их достаточно прочитать и сопоставить с заявлениями агента. Инструмент и его логика описаны автором в анонсе на r/LocalLLaMA.
Инструмент оценивает итоговое состояние проекта, а не агента. Он не знает и не учитывает, кто именно внёс изменения, поэтому работает с любым агентом: Claude, Codex, Cursor, локальной моделью под своим раннером. Обратная сторона того же решения: привязать конкретную правку к конкретному агенту через WTF не получится.
Как работает WTF: детерминированная проверка вместо LLM
WTF не спрашивает агента, что тот сделал. Он читает репозиторий после завершения работы и сопоставляет заявленное с наблюдаемым. Источники данных предсказуемы:
- Git: что изменилось в рабочем дереве и истории;
- файловая система: какие файлы существуют и какие появились;
- манифесты зависимостей (например, package.json): что добавилось, удалилось или сменило версию;
- тест-раннеры: запускались ли тесты и с каким результатом.
Автор описывает внутренности инструмента коротко: «It is deliberately boring underneath: local, deterministic, no account, no cloud, no API key, no LLM». Скучно здесь означает предсказуемо. Один и тот же репозиторий даёт один и тот же отчёт, результат не зависит от доступности внешнего сервиса и не тратит токены. Исходный код открыт, поэтому логику проверок можно прочитать и при необходимости расширить.
Отличие от проверки через языковую модель принципиальное. Модель интерпретирует, достраивает пропущенное и иногда ошибается в подсчёте файлов, а детерминированная проверка отвечает на узкий вопрос «да или нет» либо «что именно изменилось» со ссылкой на факт. WTF при этом не пытается оценить качество кода или бизнес-логику: он фиксирует наблюдаемые изменения и степень их доказанности.
Такой слой хорошо стыкуется с архитектурным паттерном, где проверка заложена в процесс с самого начала, а не приделана после релиза. Примеры такого подхода разобраны в материале об архитектуре LLM-агентов с верификацией: агент-скептик, воспроизводимые тесты и трассировка рассуждений там решают ту же задачу, что и WTF, только внутри самого агента.
Почему не LLM: аргументы автора
Позиция автора сформулирована прямо: «I'm increasingly interested in whether we're using LLMs for things that really should just be deterministic infrastructure around the LLM». Речь не о том, что модели не нужны, а о границах их применения.
Генерация кода, объяснения, планирование шагов - там LLM сильны. Вопрос «поменялся ли lock-файл», «сколько тестов реально запускалось», «появился ли новый файл миграции» решается чтением файлов и запуском тест-раннера, без модели. Проверка через LLM добавляет неопределённость: модель может ошибиться в подсчёте, придумать несуществующий файл или пропустить изменение. Добавляются стоимость токенов и зависимость от API, а для локальных моделей ещё и время на инференс. Детерминированный инструмент даёт ответ за секунды и без счёта за токены.
Четыре категории достоверности: REPORTED, OBSERVED, VERIFIED, UNKNOWN
Ядро модели доверия в WTF - четыре категории, описанные автором при анонсе: «REPORTED - something says it happened; OBSERVED - WTF can see evidence it happened; VERIFIED - WTF independently checked it; UNKNOWN - the evidence doesn't establish it». На практике это выглядит так:
- REPORTED: нечто заявило о событии. Агент сказал, что тесты прошли. Это утверждение, а не доказательство.
- OBSERVED: инструмент видит свидетельство. Файл появился в репозитории, запись в манифесте изменилась.
- VERIFIED: инструмент независимо проверил событие, например сам запустил тест-раннер.
- UNKNOWN: доказательств недостаточно, чтобы установить факт.
Смысл категорий в честной градации: от слов агента до факта, который можно перепроверить. REPORTED - самый слабый уровень. OBSERVED уже опирается на репозиторий, но не гарантирует корректность. VERIFIED - максимум, который доступен без человека, и даже он не означает, что код правильный. UNKNOWN - прямое признание, что данных нет, и это полезнее уверенного, но бездоказательного вывода.
Как читать отчёт WTF на практике
Допустим, агент отчитался: добавил зависимость и написал тесты. Изменение в package.json попадёт в OBSERVED, появление файла теста тоже в OBSERVED, а факт прохождения тестов останется REPORTED, пока не появится независимая проверка. Если тест-раннер не запускался, категория будет UNKNOWN. Разработчику стоит смотреть в первую очередь на REPORTED и UNKNOWN: это зоны риска, где решение остаётся за человеком, либо довериться агенту, либо проверить руками.
OBSERVED тоже не приговор к доверию. Файл может существовать, но содержать не то, что требовалось, а изменение в манифесте - относиться к другой задаче. Категория показывает, что событие видно в репозитории, и не более того.
Почему успешные тесты не гарантируют корректность кода
Главный тезис автора инструмента звучит предельно просто: «Passing tests means the tests passed. It doesn't mean the software is correct». Зелёный прогон подтверждает ровно один факт: тесты выполнились и вернули успех.
Причин, по которым этого мало, хватает. Тесты могут быть неполными, часть из них может стоять со статусом skip, покрытие может не затрагивать граничные случаи, а сами проверки бывают написаны под уже готовую реализацию. Агент, который одновременно пишет код и тесты к нему, легко получает зелёный прогон, ничего не доказывающий о поведении системы в реальных условиях.
WTF фиксирует факт прохождения тестов как VERIFIED, но вывода о корректности не делает и не может сделать. Это разделение труда: инструмент отвечает за факты, человек - за суждение о покрытии, граничных случаях и бизнес-логике. Как выстраивать такой контроль в команде, подробно разобрано в материале про верификацию, evals и жёсткие CI-проверки у Cursor: там речь идёт о том же принципе, где проверка живёт отдельно от генерации.
Как использовать WTF: запуск и типовой сценарий
Запуск сводится к одной команде npx agent-wtf в корне репозитория. Установка не нужна, аккаунт, облако и API-ключ тоже. Типовой цикл выглядит так: вы даёте агенту задачу, дожидаетесь сообщения о завершении, запускаете WTF и получаете отчёт с категориями достоверности по ключевым изменениям. Дальше смотрите, где стоят REPORTED и UNKNOWN, и решаете, что проверять вручную, а что можно принять как есть.
Code review инструмент не заменяет. Он убирает подготовительную рутину: ревью начинается не с выяснения того, что вообще произошло, а с содержательного разбора изменений. Отдельный плюс для тех, кто работает с локальными моделями: внешний детерминированный слой не зависит от того, какой именно агент и какой раннер использовались.
Пример: проверка изменений после работы агента
Агент отчитался: добавил новую функцию, обновил зависимости, написал тесты. Без WTF вы открываете diff и вручную выясняете, что к чему. С инструментом картина раскладывается по полочкам: файл функции - OBSERVED, изменение в package.json - OBSERVED, новый файл теста - OBSERVED, прохождение тестов - REPORTED, если независимой проверки не было, или VERIFIED, если она была. Если по миграциям или конфигурации стоит UNKNOWN, это прямой сигнал посмотреть их руками.
Такой отчёт не отвечает на вопрос «всё ли сделано правильно». Он даёт карту изменений и уровень доказанности по каждому пункту, а это и есть основная экономия времени. Дополнить детерминированный слой можно генерацией тестов: как это устроено в инструменте, который сканирует репозиторий и трейсы агента, разобрано в статье про Eval Engineering Skill.
Ограничения и подводные камни WTF
WTF не различает агентов. Он смотрит на итоговое состояние проекта, поэтому в командной работе не покажет, кто именно внёс правку. Это осознанный компромисс, цена универсальности: инструменту не нужно знать, кто писал код.
Бизнес-логику инструмент не проверяет и качество кода не оценивает. Code review он не заменяет и не претендует на это.
Категория UNKNOWN может появляться часто. Если тест-раннеры в проекте не запускаются штатно, а манифесты нестандартные, доказательств для многих утверждений просто не найдётся. Инструмент честно это покажет, но пользы в таком отчёте меньше.
OBSERVED не гарантирует связи изменения с задачей агента. Файл мог измениться по другой причине: фоновая правка, сгенерированный артефакт, посторонний коммит.
Отдельная оговорка про источник. Всё описание инструмента и его категорий известно из поста автора, это не независимая проверка. Сведений о версиях, лицензии, поддерживаемых платформах и результатах стороннего тестирования в доступных материалах нет. Перед тем как встраивать WTF в рабочий процесс, эти детали стоит проверить в самом репозитории проекта.
Кому стоит попробовать WTF
Инструмент полезен там, где кодинг-агент регулярно вносит изменения, а время на выяснение фактов тратится вручную. Три сценария, где он окупается:
- разработчики, которые работают с Claude, Codex, Cursor и аналогами и хотят независимо проверять результат;
- те, кто запускает локальные модели: встроенных механизмов верификации там обычно нет, и внешний детерминированный слой закрывает пробел;
- команды, которым нужен предсказуемый шаг проверки в CI/CD или перед ревью.
Ждать от WTF оценки качества кода или бизнес-логики не стоит, для этого нужны другие инструменты и человеческое суждение. Если вы обращаетесь к агентам эпизодически и всё равно читаете каждый diff целиком, отдельный слой может оказаться лишним звеном. Порог входа минимальный: одна команда npx, без настройки и регистрации.
Вопрос о границах LLM: детерминированная инфраструктура вокруг агентов
Вместе с анонсом инструмента автор ставит вопрос шире: не используем ли мы LLM там, где достаточно детерминированной инфраструктуры вокруг LLM. Призыва убирать модели из процесса здесь нет.
Разделение проходит по типу задачи. Генерация кода, объяснение чужого кода, планирование шагов, разбор неоднозначных требований - территория моделей. Сбор доказательств, классификация изменений, ответы «да или нет» по фактам - территория Git, тест-раннеров и инструментов вроде WTF. Первое дороже, медленнее и плохо воспроизводится. Второе не тратит токены и даёт одинаковый результат при повторном запуске.
Есть и обратная сторона. Там, где критерий результата не сводится к факту, детерминированной проверки мало: оценка качества длинных аналитических отчётов, соответствие ответа рубрике или качество объяснения требуют LLM-as-judge и калибровки критериев. Практический разбор такой ситуации есть в кейсе Similarweb про оценку агентов для длинных отчётов. Границу разумно проводить не по привычке, а по типу вопроса: факт или суждение.
Автор WTF отдельно спрашивает у тех, кто запускает локальные модели: «what do you currently do to independently check an agent after it says it's finished?». Вопрос остаётся открытым, а WTF предлагает один из вариантов ответа: смотреть на репозиторий вместо слов агента.