Technical Context
Публікація OpenAI про Harness Engineering — не про «як писати код швидше», а про те, як змусити агентну розробку бути відтворюваною та керованою. Суть підходу: агент (Codex та аналоги) працює не як автодоповнення в IDE, а як виконавець повного циклу — від порожнього репозиторію до PR та мержу — при цьому система заздалегідь обмежує його свободу механічними правилами та надає машиночитану спостережуваність.
- Agent-first workflow: агент автономно створює та розвиває кодову базу, запускає тести, виправляє помилки, оформлює PR, обробляє фідбек, повторює цикл.
- Depth-first декомпозиція: мета дробиться на атомарні блоки (дизайн → реалізація → рев'ю → тест), і агент проходить їх ітеративно; збої трактуються як «брак можливостей», яку потрібно зробити явною та виконуваною через інструменти.
- Versioned plans: плани виконання та логи рішень фіксуються як артефакти в Git (а не залишаються в чаті). Це знижує залежність від зовнішнього контексту та полегшує передачу стану між агентами/запусками.
- Жорсткі архітектурні кордони: шари, напрямки залежностей та допустимі «ребра» між компонентами перевіряються структурними тестами та кастомними лінтерами, які генеруються/підтримуються агентом.
- Legible diagnostics: діагностика проектується так, щоб її міг інтерпретувати агент: карти конкурентності, точні дампи стану, вилучення схем/документації через retrieval, відтворення багів із відео та керуванням додатком (app driving).
- Garbage collection якості: безперервне «збирання сміття» в агентно-згенерованому коді — рефакторинг, зачистка деградацій, підтримка консистентності правил.
OpenAI також згадує Codex Harness protocol як стандартизовану схему взаємодії «агент ↔ інструменти» (JSON-RPC, рукостискання та узгодження можливостей). Для архітекторів це сигнал: зріла агентна розробка вимагає формальних контрактів інструментів та передбачуваних відповідей, а не набору розрізнених скриптів.
За заявами з матеріалу, такий контур дозволяє отримувати кратний приріст швидкості (близько 10x) і вести кодову базу аж до масштабу «мільйон рядків» для ранніх користувачів. Критично: це не магія моделі, а інженерна оболонка, де тести, обмеження та діагностика працюють як страхувальні троси.
Business & Automation Impact
Harness Engineering змінює економіку розробки там, де LLM вже вбудовані в продукт або процес постачання софту. Головний зсув: виграють не команди з «найкращими промптами», а організації, які вміють перетворювати якість та безпеку на механічно перевіювані правила.
Хто виграє. Продуктові компанії з довгим хвостом дрібних змін (регресії, сумісність, міграції), інтегратори, які живуть у CI/CD, та індустрії з високою ціною помилки (фінанси, індустріальні системи, медтех). Там агент може закривати рутину: відтворення дефектів, правки, тестування, оформлення змін.
Хто програє. Команди, де архітектура «пливе», межі модулів не зафіксовані, тестовий контур слабкий, а спостережуваність обмежена логами для людини. У таких умовах агент посилює хаос: він може локально «лагодити», але глобально розмиває дизайн, доки вартість підтримки не з'їсть виграш у швидкості.
Практичний висновок для керівника розробки або власника продукту: перед тим як масштабувати ШІ автоматизацію в інженерії, доведеться інвестувати в три шари:
- Структурні обмеження: правила залежностей, політики доступу до шарів, стандарти API, заборони на «короткі шляхи». Це те, що потім перевіряється лінтерами/тестами в CI.
- Виконувана діагностика: агенту потрібні не абстрактні «ось стек-трейс», а мінімально достатні артефакти для дії: відтворюваний сценарій, знімки стану, схеми, контракти, точні помилки збірки.
- Версіонування намірів: плани, рішення, результати прогонів — як частина репозиторію. Без цього агентні ітерації перетворюються на недетермінований потік.
Якщо дивитися ширше MLOps, тут є паралель: це той самий принцип, що і в надійному впровадженні ШІ у процеси — будь-яка «розумність» має бути обрамлена спостережуваністю, оцінкою якості та керованими інтерфейсами. Harness-підхід фактично переносить MLOps-мислення (evals, трасування, контракти) у світ розробки ПЗ агентами.
Ще одна архітектурна розвилка: де закінчується автономія агента. OpenAI прямо показує модель «агент робить майже все, людина залишає за собою judgment». У бізнесі це означає: юридично та операційно вам потрібні зрозумілі точки контролю (approval gates), інакше прискорення перетворюється на зростання ризику — від витоків секретів до непомітних функціональних змін.
У результаті роль архітекторів посилюється: замість ручного контролю кожного коміту потрібно проектувати архітектуру ШІ-рішень навколо ланцюжків інструментів, тестів, правил та прав доступу. Без цього «агенти в CI» залишаться гарною демкою.
Expert Opinion Vadym Nahornyi
Непопулярна думка: Harness Engineering — це не про «агенти замінять розробників», а про те, що зникає цінність неформальної інженерної культури. Раніше можна було покладатися на досвід сеньйорів, код-рев'ю та «чуття» на архітектурний дрейф. З агентами така тактика не масштабується: якщо правило не формалізоване і не перевіряється автоматично, воно не існує.
У проектах Nahornyi AI Lab я регулярно бачу один і той самий патерн, коли компанії хочуть «впровадити агента» для розробки чи підтримки: починають з вибору моделі та інтерфейсу, а мають починати з контурів обмежень. Швидкий пілот майже завжди вдається; провал починається на третьому-четвертому тижні, коли кодова база наповнюється «тимчасовими рішеннями», а CI не ловить архітектурні порушення. Саме тому ідея Codex-generated лінтерів та структурних тестів мені здається ключовою: агент може бути автором правил, але правила мають бути незалежним суддею.
Друга помилка — намагатися зробити систему «красивою для людей» і водночас автономною для агентів. OpenAI явно обирає legibility: проектування діагностик та стану так, щоб агент міг діяти. На практиці це означає інвестиції у внутрішні інтерфейси: формати помилок, схеми доменних об'єктів, інструменти відтворення. Це нудна робота, але вона кратно знижує вартість підтримки.
Прогноз на 12–18 місяців: агентна розробка стане нормою для підтримки та інкрементальних змін (bugfix, міграції, оновлення залежностей, автогенерація тестів). «Повна автономія» для нових продуктів буде рідшою, ніж обіцяють, тому що вузьке місце — не код, а рішення на рівні продукту, безпеки та відповідальності. Переможуть ті, хто будує агентам коридори: обмеження, спостережуваність, права та відтворюваність, а не просто купує доступ до найкращої моделі.
Якщо ви хочете застосувати принципи Harness Engineering у себе — від агентного CI до автономного QA/bugfix — обговоримо вашу ситуацію та обмеження домену. У Nahornyi AI Lab консультацію веду особисто я, Vadym Nahornyi: розкладемо по кроках, де дасть ефект автоматизація за допомогою ШІ, а де вона збільшить ризик.