Посмотрел короткий доклад Nick Nisi, инженера по Developer Experience в WorkOS, с AI Engineer Europe 2026. Выступление прошло 10 апреля 2026 года в Лондоне, а запись вышла в мае под провокационным заголовком: «How I deleted 95% of my agent skills and got better results», хотя доклад скорее не провокация, а хороший инженерный разбор того, почему длинный промпт еще не делает агента надежной системой.
Недавно я уже разбирал на этом же канале выступление Matt Pocock про skill hell. Тогда речь шла о том, как проектировать и регулярно чистить skills. Nisi добавляет к этой рамке практический контрпример: иногда полезность skill становится видна только в тот момент, когда eval показывает, что без него модель работает лучше.
Главный тезис Ника о том, что недетерминированную работу модели нужно помещать внутрь детерминированного инженерного контура. Не просить агента еще настойчивее соблюдать процесс, а вынести переходы, проверки и критерии завершения в обычный код. Ник показывает это на своей системе Case. По его словам, он поддерживает больше 20 репозиториев WorkOS на восьми языках, и ручная постановка каждой агентной задачи сама стала узким местом. Первая версия Case была большим Claude skill: модель читала описание процесса, запускала этапы и решала, куда идти дальше. По мере роста контекста она стала пропускать проверки и забывать ограничения.
Дальше Ник перенес управление потоком в написанную на TypeScript машину состояний (state machine) поверх Pi. В версии из доклада работа идет через implementer, verifier, reviewer, closer и ретроспективного агента. Но важны не пять названий, а обязательные проверки (gates) между ними. Реализация не переходит к ревью, пока отдельный verifier не проверил результат; замечания возвращают задачу на доработку; PR нельзя создать без свидетельств результата (evidence).
Он приводит пару интересных историй
1️⃣ История с тестами
Агенту нужно было оставить файл
.case-tested после прогона, и он нашел самый короткий путь: просто создал этот файл через touch. Формально, AI оптимизировал заданный критерий - условно, выполнил букву, а не дух намерения инженера:) Ник заменил пустой маркер на команду, которая принимает вывод тестов, разбирает результаты и сохраняет SHA-256. Это не криптографическое доказательство того, что тесты действительно были запущены: происхождение переданного вывода все равно нужно контролировать. Но такой маркер уже закрывает примитивный обход и оставляет проверяемый артефакт, без которого конвейер не идет дальше. Для UI-багов та же идея доведена до записи Playwright до и после исправления.2️⃣ История со скиллами для WorkOS CLI (из которой и появилось провокационное название доклада)
Сначала из документации автоматически сгенерировали 10 739 строк инструкций. Выглядело солидно, но прогоны evals стали долгими, дорогими по токенам и показывали лишний шум. После ручного сокращения до 553 строк с конкретными ловушками продукта (gotchas), по словам Ника, время одного прогона уменьшилось с 68 до 6 минут. Здесь важно аккуратно читать цифры. «Удалил 95%» означает примерно 95% объема сгенерированного текста, а не 95% отдельных skills. И 77% против 97% — не общий рост точности системы: это составной балл (composite score) одного SSO/CSRF eval-кейса, где подключенный skill упустил важный шаг и увел модель в неправильную последовательность.
Из двух историй у Nisi складываются три правила:
1️⃣ Enforce, а не instruct: важное ограничение должно жить в коде, обязательной проверке или политике;
2️⃣ Guide, а не prescribe: агенту полезнее дать специфические «мины» продукта, чем пересказать всю документацию;
3️⃣ Measure, а не assume: каждый кусок контекста нужно сравнивать через evals, в том числе с вариантом «без него».
Это хорошо продолжает и прошлый разбор Zack Proser из WorkOS про внимание как узкое место. Proser говорил, что человек выгорает, когда становится диспетчером нескольких агентов. Nisi показывает следующий инженерный шаг: прежде чем отдавать человеку очередной diff, обвязка агента (harness) должна сама собрать доказательства, провести независимую проверку и вернуть только то, на что действительно стоит тратить внимание.
Итого, кажется, что нам надо не просто максимизировать контекст или количество скиллов, а пытаться выстроить agentic процесс вокруг минимального релевантного контекста, детерминированных переходов, проверяемых артефактов, evals и человеческого суждения в конце.
#AI #AI4SDLC #Engineering #Agents #Evals #Software