Как проверять AI-агента на задачах JavaScript и TypeScript

Evals для coding agent — это повторяемая задача, сохранённый ход работы и заранее определённые критерии результата. Для JS/TS полезно собрать разные типы работ: исправить ошибку типов, добавить обработку пустого ответа API, устранить регрессию в интерфейсе, обновить тест и объяснить неочевидное поведение сборки. Если все задания похожи, оценка будет измерять лишь одну сильную сторону инструмента.

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

Часть оценки должна быть детерминированной. Прошёл ли tsc --noEmit, остались ли успешными существующие тесты, появилась ли проверка на новую ветку поведения, менял ли агент файлы за пределами задачи? Скрипт способен быстро ответить на эти вопросы, но не определит, насколько понятным получился API и не спрятал ли патч сложность в другом месте.

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

Добавьте задачи, в которых простое изменение выглядит привлекательным, но неверно. Например, тест падает из-за бага в функции, а агенту легче изменить ожидание. Или внешний JSON кажется типизированным, хотя TypeScript не проверяет данные после выполнения. Ещё один сценарий — неподдерживаемое браузером API: хорошее решение содержит fallback, а не только красивую демонстрацию в одном окружении.

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

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

После оценки пересмотрите сами задания. Если критерий допускает случайную победу, уточните его. Если задача требует сведений, которых не было в репозитории, предоставьте их всем кандидатам одинаково. Цель evals — обнаружить, где агент помогает инженерной работе, а где людям всё ещё приходится угадывать и исправлять. Это основа для осмысленного выбора инструмента и безопасного расширения его прав.

В центре решения — оценки AI-агентов на задачах JavaScript и TypeScript: его стоит оценивать в границах «пять повторяемых задач в одном репозитории с одинаковыми правами», а не на абстрактном демо.

Тема оценки AI-агентов на задачах JavaScript и TypeScript легко превращается в спор о вкусах. Чтобы принять инженерное решение, нужно сначала зафиксировать исходное состояние, ожидаемый результат и стоимость ошибки. Полезно сузить пилот до области «пять повторяемых задач в одном репозитории с одинаковыми правами»: так легче сравнить поведение до и после, а также откатить изменение без потери данных.

• Ограничить пилот контуром: пять повторяемых задач в одном репозитории с одинаковыми правами.
• Заранее описать доказательство готовности: сохранённые задания, diff, логи тестов и независимая оценка.
• Выбрать один репрезентативный сценарий: исправление ошибки API-контракта без изменения публичного поведения.
• Зафиксировать версии, настройки, права и бюджет, чтобы опыт можно было повторить.
• Назначить человека, который может остановить пилот и оценить качество без авторитета инструмента.

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

Репрезентативный сценарий для пилота — исправление ошибки API-контракта без изменения публичного поведения; он достаточно реален, но остаётся управляемым.

Хороший пилот начинается не с миграции всего проекта, а с одного повторяемого сценария. Для этой темы подойдёт «исправление ошибки API-контракта без изменения публичного поведения». Важно записать не только итог, но и путь: какой контекст потребовался, где возникли неясности, сколько было повторов и какие ручные решения остались за разработчиком.

1. Снять базовые замеры и сохранить чистую точку отката до начала работы.
2. Разбить сценарий на исследование, минимальную реализацию, проверку и независимое ревью.
3. Запустить проверки, соответствующие риску: typecheck, unit, интеграционные проверки и ручное ревью.
4. Собрать артефакты: сохранённые задания, diff, логи тестов и независимая оценка, не ограничиваясь текстом финального отчёта.
5. Попросить ревьюера оценить результат по критериям, не зная, какой инструмент или подход использовался.

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

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

Главный риск здесь — переобучение на красивый единичный пример и подмена цели метрикой. Его нельзя снять одним промптом, настройкой или проходящим unit-тестом. Нужна сетка защиты: минимальные права, маленький diff, изолированная среда, автоматические проверки и ручная оценка там, где ошибка влияет на пользователя, данные или производство.

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

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

Для итогового решения нужны артефакты «сохранённые задания, diff, логи тестов и независимая оценка» и динамика метрик, а не субъективное впечатление от первого запуска.

Пилот стоит признавать успешным только тогда, когда он улучшает измеримую часть работы. Для оценки AI-агентов на задачах JavaScript и TypeScript полезно наблюдать долю завершённых задач, время ревью и число регрессий. Сначала нужна базовая линия без нового подхода, затем две-три недели наблюдения и только после этого — решение о расширении. Единичный удачный пример не заменяет серию повторяемых задач.

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

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

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

• Какой минимальный контур «пять повторяемых задач в одном репозитории с одинаковыми правами» даст полезный ответ без большой миграции?
• Как будет собрано доказательство: сохранённые задания, diff, логи тестов и независимая оценка?
• Нужно ли включить в обязательный набор typecheck, unit, интеграционные проверки и ручное ревью?
• По какому сигналу пилот будет остановлен, даже если первые результаты выглядят многообещающе?

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