Eval-first: сначала проверки, потом код с ИИ

Что такое eval-first простыми словами

Закажи торт у очень шустрого, но слегка безбашенного кондитера. Скажешь «сделай торт» - он сделает. Какой-то. Может, с грибами. И будет искренне горд собой.

А теперь скажи иначе: «торт шоколадный, на 8 кусков, без орехов - у гостя аллергия, и свечка пусть стоит, а не падает». Видишь разницу? У кондитера появился чек-лист, по которому он проверит сам себя. И ты проверишь - не пробуя на зуб весь торт.

Вот это и есть eval-first Eval-first (от англ. evaluation - оценка, проверка) - подход, при котором ты сначала описываешь критерии успеха и способ их проверить, и только потом запускаешь работу. Проверка появляется раньше кода. : сперва придумай, как ты поймёшь, что вышло хорошо, а уже потом запускай ИИ-агента. Звучит занудно. На деле это и есть главный секрет, почему у одних ИИ выдаёт рабочий продукт, а у других - красивый мусор.

Зачем eval-first нужен вайбкодеру

Ты вайбкодер. Код руками ты не пишешь - ты ставишь задачи агенту и принимаешь результат. И вот тут, на «принимаю результат», eval-first спасает тебе и нервы, и деньги:

• больше не нужно пялиться в 12 файлов с мыслью «ну вроде ок?» - у тебя есть точный список, что должно работать;
• агент проверяет себя сам до того, как отдать результат - меньше кругов «нет, не так, переделай»;
• ты ловишь момент, когда новая фича сломала старую (а это случается чаще, чем хочется);
• ты можешь честно сказать «готово» - потому что у «готово» теперь есть определение, а не ощущение.

Разница между «ИИ сделал что-то» и «ИИ сделал то, что нужно» - это чаще всего один вопрос, заданный до старта: «а как мы поймём, что получилось?»

Как работает петля eval-first

В скиллах ECC это зовут eval-first loop - петля «сначала проверки». Шагов всего четыре, и они простые:

1. Опиши проверки - что должно заработать (capability) и что не должно сломаться (regression).
2. Сделай замер «до» - прогони проверки на текущей версии, зафиксируй, что сейчас падает.
3. Дай агенту делать - теперь он пишет код под понятную цель, а не наугад.
4. Прогони проверки снова - сравни «до» и «после». Стало лучше? Ничего не отвалилось?

По сути проверка - это тесты для обычного кода, только для работы с ИИ. В мире ECC так и говорят: эвалы - это «юнит-тесты для разработки с ИИ».

Capability и regression: новое против старого

Их легко перепутать - поэтому разложим по полочкам.

• Capability Capability eval - проверка того, умеет ли агент сделать что-то новое, чего раньше не было: новая кнопка, новая функция, новая фича. (умеет ли новое). Проверяешь, появилось ли то, ради чего ты всё затеял. Например: «пользователь регистрируется по email», «форма заказа отправляется».
• Regression Regression eval - проверка того, что новое изменение не сломало уже работавшие вещи. «Регрессия» = откат назад, когда что-то рабочее перестало работать. (не сломал ли старое). Проверяешь, что вчерашнее всё ещё работает сегодня. Например: «старая кнопка входа на месте», «остальные страницы открываются».

Метрика pass@k: как измерить надёжность ИИ

ИИ - штука вероятностная: один и тот же запрос то выходит идеально, то мимо. Поэтому надёжность меряют не «да/нет», а долей удач из нескольких попыток. Это и есть pass@k pass@k - метрика надёжности: «получилось хотя бы один раз за k попыток». pass@1 - с первого раза. pass@3 - хотя бы раз из трёх. pass^3 - все три попытки подряд успешны. .

• pass@1 - получилось с первого раза.
• pass@3 - получилось хотя бы раз из трёх попыток.
• pass^3 - все три попытки подряд успешны (планка повыше, для критичных вещей).

В скиллах ECC дают такие ориентиры: для новых фич (capability) - pass@3 от 90% и выше, а для критичных регрессий - pass^3 = 100%. Всё, что работало, обязано работать всегда. Без исключений.

Дроби задачу на куски по 15 минут

Эвалы работают, только если задачу можно проверить. Гигантское «сделай мне маркетплейс» разом не проверишь - там сто рисков в одном флаконе. Поэтому в скилле agentic-engineering есть правило 15-минутного кусочка: дроби работу на единицы, где каждая:

• проверяется сама по себе, отдельно от остального;
• несёт один главный риск (а не «тут тебе и дизайн, и оплата, и база разом»);
• имеет понятное «готово» - видно, когда закончено.

Eval-first на живом примере: форма бронирования

Ты просишь агента: «добавь на сайт кофейни форму бронирования столика». Без eval-first агент бодро лепит форму, ты смотришь - поля есть, кнопка есть, «ну ок». А через день выясняется: форма шлёт пустые заявки, не проверяет телефон и заодно сломала меню по соседству.

А как бы это сделал понимающий вайбкодер? Сначала описал бы проверки - и только потом дал делать:

Добавь на сайт кофейни форму бронирования столика. Но сначала, ДО кода, выпиши проверки, по которым мы поймём, что готово.
Проверки на новое (что должно заработать):

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

Меню на странице по-прежнему открывается.
Кнопка «позвонить» в шапке работает.
Остальные страницы открываются как раньше.
Дальше работай так: реализуй форму, потом сам пройди по всем проверкам и напиши напротив каждой PASS или FAIL. Если есть хоть один FAIL - чини и проверяй заново. Результат с FAIL мне не отдавай.

Кто проверяет результат: код, ИИ или человек

Проверку можно поручить разным «судьям» - в скилле eval-harness их три:

• Код-судья (самый надёжный). Точная проверка без споров: тесты прошли / сборка собралась / нужная строка на месте. Можешь проверить кодом - проверяй кодом.
• ИИ-судья (LLM как оценщик). Когда «хорошо» нельзя померить линейкой: «удобен ли текст», «понятна ли ошибка». Просишь другую модель оценить по шкале от 1 до 5.
• Человек-судья (ты). Для спорного и для всего, что про безопасность. Правило ECC жёсткое: проверки безопасности никогда не отдаём на полный автомат - последнее слово за человеком.

Как выглядит эвал-отчёт PASS/FAIL

Чтобы стало совсем наглядно - вот короткий отчёт по проверкам в стиле eval-harness:

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

Частые ошибки в проверках с ИИ

• Проверять только «счастливый путь». Ты убедился, что форма работает, когда всё ввели правильно. А пустые поля? А кривой телефон? Реальные люди введут всё, включая эмодзи в графе «возраст».
• Забывать про регрессии. Радуешься новой фиче и не замечаешь, как развалилось старое. Всегда держи под рукой список «что не должно сломаться».
• Описывать проверки ПОСЛЕ кода. Так ты невольно подгоняешь критерии под то, что уже вышло. Проверки придумываются строго до.
• Гнать одну гигантскую задачу. Её нечем проверить целиком. Режь на куски по ~15 минут с понятным «готово».
• «Готово» без определения. «Сделай красиво» - агент гадает, а ты потом недоволен. «Готово» = конкретный список галочек.
• Отдавать безопасность на автомат. Логины, оплата, доступы - финальную проверку всегда делает человек.
• Гнаться за процентами, забыв про цену. Можно вылизывать pass@k до блеска и не заметить, что каждая попытка жрёт кучу токенов и времени. Следи и за надёжностью, и за расходом.