Better Harness від Qoder: як перевіряти не код агента, а весь процес його роботи

Better Harness — це відкритий проєкт Qoder для перевірки й поліпшення робочого процесу навколо coding agent, а не для оцінювання однієї відповіді моделі чи одного кодового дифу. Він аналізує інструкції репозиторію, засоби контролю, шляхи валідації, конфігурацію агента й, де це доступно, записи фактичної роботи в сесіях. Мета — виявити прогалини процесу, запропонувати обмежене за обсягом виправлення та дати спосіб перевірити результат під час наступного запуску. 124

За повідомленнями на час запуску, Qoder відкрила код проєкту на GitHub 28 липня 2026 року. 5

Головна ідея: оцінювати «обв’язку» агента, а не лише модель

Coding agent працює не у вакуумі. Його оточують правила репозиторію, специфікації, інструменти, дозволи, скрипти, тести, вимоги до рев’ю, перевірки перед релізом і передавання роботи людині. У Qoder це середовище називають harness — інженерною «обв’язкою» агента. До неї можуть входити інструкції репозиторію, правила, навички (skills), хуки, плагіни, конектори, скрипти, команди тестування, перевірки релізу та етапи людського рев’ю. 2

Ця різниця принципова: навіть сильна модель може давати ненадійний результат, якщо процес навколо неї нечіткий або погано спостережуваний. Наприклад, у проєкті може існувати тестова команда, але агент не має зрозумілої вказівки, коли її запускати; файл із правилами може бути, але агент ним не користується. Better Harness шукає саме такі операційні слабкі місця — і не вважає сам факт наявності конфігурації доказом працездатного процесу. 145

Три шари Better Harness

Qoder подає Better Harness як тришарову систему, що поєднує інженерні практики, модель оцінювання та виконувану реалізацію. 5

1. Практики Harness Engineering

Перший шар охоплює механізми, які формують роботу агента: патерни сесій і CLI, спостережуваність, правила, skills, конфігурацію MCP, пам’ять, хуки та автоматизацію. 5

На практиці цей рівень відповідає на запитання:

• чи має агент чітко задані цілі, обмеження та контекст репозиторію;
• чи контрольовані його шляхи виконання й дозволи;
• чи пов’язані тести, перевірки та рев’ю зі змінами, які він робить;
• чи зберігаються корисні уроки як активи проєкту, а не зникають разом із сесією.

Перший крок Better Harness — скласти карту поточного середовища: цілей, контексту, точок запуску, циклів зворотного зв’язку, механізмів доставки результату та накопичення знань. 1

2. Оцінювання Agent Work Loop

Другий шар перетворює ці практики на оцінку п’яти пов’язаних вимірів доставки результату: розуміння завдання, контрольоване виконання, валідація змін, надійна доставка та накопичення знань. 14

Отже, замість вузького питання «чи згенерував агент правдоподібний код?» система ставить інше: чи здатний увесь процес регулярно створювати зміни, які зрозумілі, контрольовані, перевірені, готові до доставки та враховують попередній досвід?

Модель має виявляти розриви в цьому циклі: відсутній механізм, непід’єднану інтеграцію, крок, який так і не виконали, або нестачу доказів результату. 1

3. Виконувана реалізація

Третій шар робить практики й модель оцінювання придатними до запуску в реальних проєктах, а не залишає їх набором рекомендацій. Better Harness працює через coding agent, збирає докази з проєкту та — за наявності підтримки — із сесій, після чого формує пріоритетні наступні кроки, які можна перевірити. 4

Поточні матеріали проєкту заявляють підтримку десяти host adapters — адаптерів для різних середовищ агентів. У повідомленнях про запуск серед підтримуваних середовищ прямо називали Claude Code, Codex, Qoder і Cursor. 56

Покриття адаптерів може змінюватися, тому інтеграцію з конкретним хостом варто звіряти з актуальною документацією проєкту. Надані джерела, зокрема, не підтверджують підтримку OpenClaw.

Як інструмент збирає докази

Важлива риса підходу — відокремлення збору доказів від фінальної оцінки. За даними Qoder, основний процес аналізу збирає сирі дані, а потім передає їх трьом незалежним підлеглим агентам у режимі лише для читання, після чого результати об’єднуються. 1

Ці три перспективи такі:

• Project Harness — інженерна основа репозиторію: інструкції, скрипти, перевірки та механізми контролю доставки.
• Agent Customization — налаштування агента: правила, skills, хуки та інша конфігурація.
• Session Evidence — записи того, що агент фактично робив під час реальної роботи, якщо такі дані доступні.

Така структура допомагає відрізнити запланований процес від реально спостереженого. Дані про проєкт і конфігурацію показують, що певна можливість існує; дані сесії можуть показати, чи використовувалася вона належним чином у конкретному завданні. 14

Чому «є» не означає «працює»

Найкорисніший принцип фреймворку: існування артефакту не є доказом його ефективності.

Автоматизований тестовий набір у репозиторії свідчить лише про потенційну можливість перевірки. Сам по собі він не доводить, що агент запустив релевантні тести після зміни, правильно витлумачив результат або використав його, щоб не допустити невдалого постачання коду. Те саме стосується правил, хуків, skills і погоджувальних бар’єрів. 15

Тому Better Harness намагається зберігати ланцюжок доказів явним. Звіти перетворюють підтверджені прогалини на пріоритетні Findings — висновки з описом впливу, очікуваного результату, обмеженого виправлення та критеріїв приймання. Відсутні докази не маскуються під упевнену оцінку. 46

Для команди це означає можливість перевірити чотири речі:

1. що саме спостерігали в проєкті, конфігурації або записі сесії;
2. чому це важливо для циклу доставки;
3. яке вузьке виправлення пропонується — наприклад, правило, skill, хук, скрипт, автоматизація або крок людського погодження;
4. як перевірити виправлення після його впровадження.

Цикл поліпшення: огляд, ремонт, повторна перевірка

Better Harness позиціонується не як разовий аудит, а як ітеративний процес:

1. скласти карту наявного середовища;
2. знайти розриви в робочому процесі й прогалини в доказах;
3. створити обмежене завдання на виправлення для підтвердженого висновку;
4. перевірити виправлення за визначеними критеріями приймання;
5. повторно запустити огляд і оцінити оновлені докази. 14

Саме на цьому ґрунтується теза про безперервне поліпшення. Інструмент може показати, що процес змінився і чи підтримують нові докази сильнішу оцінку. Але він сам по собі не доводить, що конкретне виправлення спричинило кращу роботу агента в кожному проєкті або середовищі. Матеріали Qoder наголошують на спостережуваних доказах і явних обмеженнях, а не на причинному доведенні за зміною балів. 46

Що означає перевірка 30 GitHub-проєктів

У повідомленнях про запуск ішлося про початкове застосування фреймворку до 30 реальних GitHub-проєктів. 5 Це варто сприймати як дослідницьку апробацію, а не як контрольоване доведення того, що Better Harness поліпшує всі coding agents або всі репозиторії.

Доступна первинна документація підтверджує модель доказів, структуру Findings та ітеративний процес виправлення. Водночас надані джерела не містять достатньо первинних деталей, щоб незалежно оцінити добірку 30 проєктів, протокол оцінювання чи сукупні результати. Це важливе застереження під час порівняння Better Harness із формальними бенчмарками або формулювання широких заяв про продуктивність. 14

Спроба зробити агентну розробку вимірюванішою

Ширша ідея Qoder полягає в тому, щоб перетворити Harness Engineering на інфраструктуру якості для розробки ПЗ з AI-підтримкою: спільну мову для опису контролів процесу, спостережувані докази, зіставні виміри доставки результату та повторювані цикли поліпшення. 12

Better Harness пропонує прикладний варіант цієї ідеї. Він дає командам спосіб перевіряти умови, у яких працює агент, у підтримуваних середовищах, обговорювати докази замість вражень і тестувати, чи витримує запропоноване виправлення наступні запуски. Його цінність не в гарантії, що кожне виправлення поліпшить результат, а в дисциплінованішому підході: робити агентні процеси доступними для перевірки, рев’ю та потенційного спростування. 46