На конференції AI Engineer AI‑інженер Supabase Педру Родрігеш показує, як компанія перетворює абстрактну ідею «скілів» для агентів на керований інженерний процес. Supabase — це open source backend‑as‑a‑service на Postgres, який активно експериментує з агентами й інструментами на кшталт MCP. У цьому воркшопі Родрігеш фокусується не стільки на тому, як писати скіли, скільки на тому, як їх системно тестувати: спочатку вручну, а потім за допомогою evals і платформи Braintrust. Цей підхід він називає «eval‑driven development» для агентів.
Від «Skill Issue» до «Level Up Your Skills»: чому назва має значення
У програмі конференції цей воркшоп спочатку значився під назвою «Skill Issue», але в останній момент отримав м’якший брендинг — «Level Up Your Skills». Провокативний лейбл «Skill Issue» Родрігеш переніс на окремий кейноут наступного дня, де обіцяє показати, як ці ж патерни скілів та evals поводяться вже в продакшн‑системах Supabase.
Розділення не випадкове. Воркшоп — це лабораторія: учасники вчаться писати скіли, тестувати їх вручну, а потім переводити все це в автоматизовані оцінки. Кейноут — це вже пост‑мортем: що з цього реально спрацювало в бойових умовах, а що виявилося тим самим «skill issue».
Таким чином, поточна сесія — це свідомо поставлений пролог до розмови про продакшн. І в центрі цього прологу — цикл оцінки скілів, який має замінити інтуїцію й «магію LLM» на вимірюваний процес.
Від markdown до поведінки агента: навіщо взагалі тестувати скіли
У Supabase скіл — це не абстрактна «здатність» моделі, а цілком конкретний артефакт: папка з основним файлом skill.md і додатковими референсами та скриптами. Усередині — інструкції, довідкові матеріали, сценарії дій, які мають зробити агента кориснішим у реальних робочих процесах.
На перший погляд це просто markdown. Звідси й базове питання, яке Родрігеш ставить аудиторії: як тестувати щось, що виглядає як текстовий файл?
У класичній розробці відповідь очевидна: є юніт‑тести, інтеграційні тести, end‑to‑end. Але з агентами й LLM усе складніше. Вихід моделі — недетермінований, промптинг і контекст впливають на результат, а поведінка агента може змінюватися від запуску до запуску навіть при однаковому інпуті.
Саме тут у гру вступають evals — спеціальні оцінки, які не намагаються зробити тест «жорстко детермінованим», а натомість фіксують сценарій, очікувану поведінку й аналізують не лише фінальний текст, а й увесь ланцюжок міркувань і викликів інструментів.
У воркшопі учасники проходять шлях поетапно. Спочатку вони пишуть скіл і дивляться, як він змінює поведінку агента в ручному режимі. Потім ті самі сценарії переносять в evals, щоб перетворити разові експерименти на повторюваний, вимірюваний цикл.
Як працюють evals: тестування недетермінованої поведінки
Родрігеш описує evals як спосіб тестувати не лише «що сказав агент», а й «як він до цього дійшов». Структурно eval нагадує класичний тест: є вхідні дані й очікуваний результат. Але між ними — цілий простір для аналізу.
У типовому eval‑сценарії задається інпут, який моделює реальне завдання для агента. Далі фіксується очікувана поведінка: які інструменти мають бути викликані, які кроки міркування є бажаними, які проміжні дії вважаються коректними. Через те, що LLM‑відповіді варіативні, фокус зміщується з точного збігу тексту на відповідність патерну поведінки.
Оцінюються кілька рівнів:
По‑перше, сам факт досягнення цілі: чи вирішив агент задачу, чи отримав потрібні дані, чи виконав потрібну дію.
По‑друге, траєкторія: які інструменти він викликав, у якій послідовності, чи не пропустив критичний крок, чи не зробив зайвих, потенційно небезпечних дій.
По‑третє, міркування: наскільки логічним був ланцюжок reasoning, чи не було очевидних помилок або «галюцинацій» у проміжних висновках.
Такий підхід дозволяє працювати з недетермінованістю: навіть якщо конкретні формулювання відповідей змінюються, можна порівнювати скіли між собою за тим, наскільки стабільно вони спрямовують агента до правильної поведінки.
Фреймворк OpenAI: цикл оцінки скілів як інженерна практика
Методологічною опорою для воркшопу стає блог‑пост OpenAI «Systematically evaluate agent skills». У ньому пропонується рамка, яка перетворює роботу зі скілами на повторюваний інженерний цикл. Родрігеш адаптує цю рамку до контексту Supabase і формулює її як простий, але дисциплінований loop:
Спочатку визначаються метрики. Потрібно чітко відповісти, що означає «хороший» скіл у конкретному продукті. Чи має він швидше приводити агента до документації? Чи навпаки — інкапсулювати конкретний робочий процес? Чи зменшувати кількість помилкових викликів інструментів? Без цього кроку будь‑які подальші вимірювання втрачають сенс.
Далі створюється сам скіл. Пишеться skill.md з обов’язковими полями name і description у front matter, додаються референс‑файли й, за потреби, скрипти. На цьому етапі скіл — це гіпотеза: набір інструкцій і контенту, який, як очікується, змінить поведінку агента в бажаний бік.
Після цього запускаються evals. Спочатку це може бути ручне тестування: інженер проганяє кілька сценаріїв у чаті з агентом і дивиться, як той використовує новий скіл. Потім ці ж сценарії формалізуються у вигляді eval‑кейсів: фіксуються інпути, очікувані патерни поведінки, бажані інструменти.
Наступний крок — градація поведінки. На основі зібраних запусків оцінюється, наскільки агент відповідає визначеним раніше метрикам. Тут важливо не обмежуватися бінарним «пройшов/не пройшов», а дивитися на розподіл результатів, частоту помилок, типові failure modes.
І нарешті — ітерація. Скіл доопрацьовується: змінюються формулювання, додаються або видаляються референси, коригуються скрипти. Потім цикл повторюється: нова версія скіла проганяється через ті самі evals, і можна порівняти, чи стало краще, гірше чи нічого не змінилося.
У Supabase цей loop подається як аналог test‑driven development, але для агентів. Замість того щоб «на око» вирішувати, чи допоміг новий скіл, інженери спираються на стабільний набір eval‑сценаріїв і метрик.
Braintrust як інфраструктура для evals: від разових запусків до системи
Щоб цей цикл працював не лише на слайдах, потрібна інфраструктура, яка вміє збирати, зберігати й порівнювати результати evals. У воркшопі Родрігеш використовує Braintrust — платформу, яка спеціалізується саме на систематичному запуску evals і спостереженні за поведінкою агентів.
Braintrust у цьому контексті виконує кілька ролей.
По‑перше, це запускник. Платформа дозволяє проганяти один і той самий набір eval‑сценаріїв для різних версій скілів або агентів, зберігаючи всі параметри запуску. Це критично важливо, коли потрібно порівняти, як невелика зміна в skill.md вплинула на поведінку.
По‑друге, це система збору трейсів. Braintrust фіксує не лише фінальні відповіді, а й reasoning‑ланцюжки, виклики інструментів, проміжні стани. Це дає змогу розбиратися не тільки з тим, що пішло не так, а й чому саме агент зробив помилковий крок.
По‑третє, це інструмент спостережуваності. Родрігеш порівнює Braintrust з observability‑системами для класичних сервісів: замість логів і метрик HTTP‑запитів тут — логи думок агента й викликів MCP‑інструментів. Для інженерів це спосіб бачити, як агент поводиться в контрольованих сценаріях, перш ніж випускати його в продакшн.
У поєднанні з eval‑циклом Braintrust перетворює роботу зі скілами на процес, де кожна зміна може бути виміряна. Це особливо важливо в середовищі на кшталт Supabase, де агенти мають доступ до потужних MCP‑інструментів і можуть виконувати реальні дії в локальних проєктах.
Від ручного тестування до автоматизації: як виглядає перехід
Практичний маршрут, який пропонується учасникам воркшопу, починається з максимально простого кроку: написати скіл і подивитися, що зміниться в поведінці агента в ручному режимі. Це дозволяє відчути, як навіть невеликий шматок інструкцій у skill.md може переналаштувати пріоритети агента, змінити те, як він читає документацію чи викликає інструменти.
На цьому етапі інженер фактично виступає «живим eval‑раннером»: задає питання, спостерігає за відповідями, інтуїтивно оцінює, чи став агент кориснішим. Але такий підхід не масштабується. Неможливо вручну проганяти десятки сценаріїв після кожної зміни скіла, особливо коли скілів багато й вони взаємодіють між собою.
Тому наступний крок — формалізація цих ручних сценаріїв у вигляді evals. Кожен «ручний» діалог перетворюється на записаний кейс: інпут, очікувані інструменти, бажаний патерн reasoning. Далі ці кейси запускаються автоматично через Braintrust, і кожна нова версія скіла проходить через той самий набір випробувань.
Таким чином, перехід від ручного тестування до системних evals не відбувається стрибком. Це радше поступова кристалізація: спочатку інженер експериментує в чаті, потім найцінніші сценарії переносяться в код, а далі вже інфраструктура бере на себе рутину.
Навіщо все це Supabase: підготовка до продакшн‑кейноуту
Хоча воркшоп зосереджений на методології, він чітко позиціонується як підготовка до наступного кроку — окремого кейноуту, де Родрігеш обіцяє показати, як ці патерни працюють у реальних продуктах Supabase.
У компанії агенти мають допомагати розробникам працювати з екосистемою Supabase: від бази даних на Postgres до інструментів міграцій, CLI й MCP‑серверів із десятками доступних тулів. Скіли в цьому контексті — «секретний соус», який має зробити агентів не просто «розумними», а передбачувано корисними в конкретних робочих процесах.
Щоб це стало можливим, потрібен саме той цикл, який демонструється на воркшопі: чіткі метрики, формалізовані evals, інфраструктура на кшталт Braintrust і готовність ітеруватися, визнаючи, що не кожен новий скіл автоматично покращує агента. Іноді зміни нічого не дають, іноді погіршують ситуацію, і лише системні evals дозволяють це побачити до того, як агент потрапить до користувачів.
Тому «Level Up Your Skills» — це не просто навчальна сесія з написання markdown‑файлів. Це спроба закласти в спільноту AI‑інженерів практику, де скіли для агентів розробляються й перевіряються з тією ж дисципліною, з якою тестуються звичайні сервіси.
Висновок: eval‑driven development як новий стандарт для агентів
Поява скілів, MCP‑інструментів і агентів, здатних працювати з реальними системами на кшталт Supabase, створює новий клас проблем: як гарантувати, що ці агенти поводяться очікувано, не ламають робочі процеси й дійсно допомагають розробникам.
Відповідь, яку пропонує Педру Родрігеш, спираючись на фреймворк OpenAI та інфраструктуру Braintrust, — це системний цикл оцінки скілів. Визначити метрики, створити скіл, прогнати evals, оцінити поведінку, ітерувати. Почати з ручних експериментів, але якнайшвидше перетворити їх на автоматизовані сценарії.
У такій моделі скіл перестає бути «магічним промптом» і стає інженерним артефактом, для якого існують чіткі критерії якості й зрозумілий шлях покращення. А агенти — з «чорної скриньки» перетворюються на системи, поведінку яких можна спостерігати, вимірювати й, зрештою, робити «actually good» у реальних продуктах.