У Лондоні на сцену виходить Райан Лопополо — member of technical staff в OpenAI. Уже дев’ять місяців він будує продакшн‑софткер виключно через агентів, фактично заборонивши своїй команді торкатися редакторів коду. У цьому підході, який він називає «harness engineering», людина керує, а агенти виконують. Із цієї радикальної практики виростає теза, яка звучить майже єретично для індустрії: реалізація більше не є дефіцитним ресурсом, бо код став фактично безкоштовним.
Це не абстрактна теорія. Лопополо описує себе як «токенного мільярдера»: щодня він витрачає понад мільярд вихідних токенів, що, за його оцінкою, коштує понад $1000 на день. Такий масштаб використання моделей дозволяє йому побачити, як змінюється сама природа інженерної роботи, коли кожен розробник отримує доступ до потужності від п’яти до п’яти тисяч «віртуальних» інженерів.
Коли код стає безкоштовним: що насправді стало дефіцитним
Ключова теза Лопополо звучить просто: «код — безкоштовний». Не в сенсі нульової вартості інфраструктури, а в тому, що створення, рефакторинг і навіть масове видалення коду більше не обмежуються людським часом. У світі, де моделі можуть виступати повноцінними інженерами, написання рядків коду перестає бути вузьким місцем.
Традиційно код сприймався як тягар: кожен новий модуль додає борг підтримки, кожна зміна вимагає уваги людини. Лопополо пропонує дивитися на це інакше. Моделі, каже він, «надзвичайно терплячі» й «нескінченно паралельні». Вони не втомлюються від монотонних змін, не вигорають на рутинному рефакторингу й не втрачають концентрацію на сотій однотипній правці.
У такій парадигмі змінюється сама економіка інженерії. Найдорожчим стає не код, а три інші ресурси:
- Людський час.
- Увага — як людська, так і модельна.
- Контекстне вікно моделі.
Людський час і увага — це те, чого завжди бракує. У класичній моделі, де людина сама пише код, беклог неминуче перетворюється на піраміду пріоритетів: P0, P1, P2, а всі P3‑задачі «ніколи не будуть зроблені». Вони зависають у джирах і документах, бо немає рук, які б дійшли до них без шкоди для критичних фіч.
У світі, де код безкоштовний, ця логіка ламається. Якщо написання та підтримка коду більше не «з’їдає» людський час, усі ті P3‑задачі можна запускати одразу — і навіть у кількох варіантах паралельно. Лопополо описує підхід, коли одна й та сама задача стартує в чотирьох паралельних траєкторіях, а потім команда просто обирає найкраче рішення. Там, де раніше доводилося економити на спробах, тепер можна дозволити собі надмірність.
Це не означає, що код повністю втрачає ціну. Він усе ще створює складність, вимагає архітектурних рішень, впливає на надійність системи. Але «вартість реалізації» як така перестає бути стримувальним фактором. Обмеження зміщуються в іншу площину: як спроєктувати системи, процеси й «обв’язку» навколо агентів так, щоб вони робили правильну роботу, а не просто генерували гігабайти синтаксично коректного, але беззмістовного коду.
Від індивідуального виконавця до «staff engineer» з армією агентів
Щоб по‑справжньому скористатися тим, що код став дешевим, Лопополо радикально змінив роль інженера у своїй команді. Він буквально заборонив людям відкривати редактори коду й змусив усю розробку проходити через моделі. Це не просто експеримент заради хайпу, а спроба змусити команду мислити в новій парадигмі.
У цій моделі кожен інженер — це не «ще одна пара рук», а радше staff engineer, який керує великою кількістю агентів‑виконавців. Людина перестає бути основним джерелом реалізації й стає оркестратором: визначає напрямок, формулює вимоги, розставляє пріоритети, будує системи й процеси, що дозволяють агентам працювати довго й надійно.
Лопополо описує це як перехід до мислення системами й делегуванням. Якщо кожен інженер має доступ до потужності від п’яти до п’яти тисяч «віртуальних» колег, головне питання звучить не «як мені це реалізувати», а «як мені продуктивно розгорнути цю потужність у кодовій базі та в команді». Це вимагає іншого набору навичок:
Інженер має дивитися не на один‑два спринти вперед, а на горизонти в один день, тиждень і шість місяців одночасно. Потрібно розуміти, які структури, стандарти й обмеження потрібні, щоб сотні чи тисячі агентних траєкторій не перетворилися на хаос.
У цьому світі інженер уже не «виконує таску», а проєктує середовище, у якому таски виконують агенти. Це включає:
- визначення того, що означає «добре виконана робота» для конкретної кодової бази;
- формалізацію неявних командних стандартів у явні правила, документацію й промпти;
- побудову механізмів зворотного зв’язку й корекції, коли агенти систематично помиляються.
Лопополо підкреслює, що це зрушення не зменшує значення експертизи. Навпаки, експертиза стає мультиплікатором. Коли досвідчений інженер один раз чітко формулює, як виглядає «хороший QA‑план» або «безпечний інтерфейс для мережевих викликів», ця експертиза починає масштабуватися на всі агентні траєкторії, а не залишається в голові однієї людини чи в поодиноких рев’ю.
Людина як дизайнер промптів, гардрейлів і систем
Якщо реалізація більше не дефіцитна, то на чому мають фокусуватися люди? Відповідь Лопополо: на промптах, гардрейлах і системах, які спрямовують агентів.
Він пропонує дивитися на код не як на кінцеву мету, а як на побічний продукт правильно налаштованих процесів. Важливим стає не те, що саме написав агент у конкретному патчі, а те, яким шляхом він до цього дійшов: які документи прочитав, які правила застосував, які обмеження врахував.
У цій логіці ключовими артефактами стають:
- документація, яка пояснює, що означає «добра робота» в конкретній команді;
- ADR (architecture decision records), що фіксують, чому були прийняті ті чи інші рішення;
- «персоніфікована» документація, яка описує очікувану поведінку для різних типів задач;
- історичні логи задач і код‑рев’ю, які показують, які рішення в минулому вважалися прийнятними, а які — ні.
Усе це — не просто допоміжні матеріали для людей. У парадигмі harness engineering це — вхідні дані для агентів. Щоб агенти могли робити «повну роботу» інженера, їм потрібно надати не лише кодову базу, а й контекст: що таке «якісний код» саме тут, які неявні нефункціональні вимоги важливі, які компроміси прийнятні.
Лопополо звертає увагу на те, що написати «один хороший патч» — це не одна велика дія, а сотні дрібних рішень. Багато з них стосуються нефункціональних вимог: продуктивності, надійності, безпеки, читабельності, тестованості. Моделі під час тренування бачили трильйони рядків коду, які реалізують усі можливі комбінації цих рішень. Але вони не знають, які саме вибори є «правильними» для конкретної організації, поки люди це явно не сформулюють.
Тому роль інженера — не просто «перевіряти, що агент не накосячив», а систематично описувати очікування. Якщо агенти починають продукувати «сміття», Лопополо радить не миритися з цим, а прямо забороняти «slop» у промптах і процесах. Це означає свідомо прийняти тимчасове падіння швидкості, щоб розібратися, де саме агенти помиляються, і поставити додаткові обмеження чи перевірки.
Це схоже на інвестицію в інфраструктуру якості: замість того щоб нескінченно латати наслідки, команда витрачає час на побудову систем, які запобігають класам помилок. У світі, де код безкоштовний, така інвестиція окупається швидше, бо її ефект миттєво масштабується на сотні чи тисячі агентних змін.
Внутрішні інструменти, локалізація й «безкоштовні» найкращі практики
Один із найяскравіших наслідків парадигми «код безкоштовний» проявляється у внутрішніх інструментах. Лопополо розповідає, що створив велику кількість агентів усередині OpenAI, які підвищують продуктивність колег. І саме тут стає видно, як змінюється баланс «що ми можемо собі дозволити».
У класичному світі локалізація й інтернаціоналізація внутрішніх тулів часто відсуваються «на потім». Це типові P3‑задачі: усі розуміють, що було б добре підтримувати кілька мов, але завжди знаходяться важливіші фічі. У результаті інженери в Лондоні, Дубліні, Парижі, Брюсселі, Цюриху чи Мюнхені роками користуються інструментами, які говорять з ними лише англійською.
Коли код безкоштовний, ця дилема зникає. Лопополо описує, як може локалізувати внутрішні інструменти на англійську, французьку, німецьку та інші європейські мови «з першого дня» — без відчутного трейд‑офу з іншими задачами команди. Якщо реалізація локалізації не «з’їдає» людський час, немає причини відкладати її.
Те саме стосується й «найкращих практик» інженерії. У багатьох командах вони існують як набір неформальних правил: «ми завжди додаємо таймаути й ретраї до мережевих викликів», «ми не приймаємо PR без плану тестування», «ми не допускаємо небезпечних інтерфейсів». На практиці ці правила часто порушуються — не зі злого умислу, а через брак часу, уваги чи досвіду.
Лопополо пропонує іншу норму: у світі агентів найкращі практики мають бути доступні «за замовчуванням» у кожному продукті. Якщо код безкоштовний, немає виправдання для того, щоб не вбудувати ці практики в самі системи. Замість того щоб сподіватися, що кожен розробник згадає про ретраї, можна один раз написати документацію, лінт або рев’ю‑агента, який перевіряє всі виклики fetch на наявність таймаутів і повторних спроб.
Лопополо наводить типовий сценарій: продакшн‑інцидент через мережевий код без ретраїв і таймаутів. Людина виправляє баг, додає потрібні обгортки — і йде далі, не змінюючи системно підхід. Він визнає, що й сам так робив. Але в парадигмі harness engineering правильна реакція інша: витратити час на написання специфічної для кодової бази перевірки, яка більше не дозволить такій помилці пройти. А потім, спираючись на те, що великомасштабний рефакторинг «безкоштовний», прогнати цей стандарт через увесь код.
Це знову повертає нас до ролі інженера як дизайнера систем. Замість того щоб бути «ненадійним рев’юером» для кожного окремого PR, людина один раз формулює правило й будує механізм, який застосовує його послідовно й без втоми.
Масштабування експертизи: як один інженер підсилює всіх агентів
Ще один важливий аспект нового підходу — те, як він дозволяє масштабувати експертизу всередині команди. Лопополо працює з повноцінною фулстек‑командою, де є спеціалісти з фронтенд‑архітектури, бекенд‑масштабованості, продакт‑мислення та інших напрямів. У традиційній моделі ця різноманітність означає, що якість рішень сильно залежить від того, хто саме працює над конкретною задачею й хто робить рев’ю.
У світі агентів це можна організувати інакше. Кожен експерт описує свою ділянку — наприклад, що означає «хороший план QA» або «масштабований бекенд для такого типу навантаження» — у формі документації, гайдів, чек‑лістів, промптів. Ці артефакти стають частиною «ментальної моделі», яку агенти використовують під час роботи.
Результат: будь‑який інженер, який керує агентами, отримує «найкраще від кожного» члена команди. Щоб навчитися писати якісний QA‑план, йому більше не потрібно чекати на рев’ю від конкретної людини з високим сигналом. Достатньо того, що ця людина один раз описала свої стандарти в доступній для агентів формі. Далі агенти автоматично застосовують ці стандарти в усіх релевантних траєкторіях.
Це створює новий тип командної динаміки. Замість того щоб витрачати час на повторення одних і тих самих порад у рев’ю, експерти інвестують у «одноразові, але високорівневі» артефакти, які множать їхній вплив. І знову ж таки, оскільки код безкоштовний, вартість інтеграції цих артефактів у реальну роботу (через лінти, рев’ю‑агентів, шаблони промптів) стає відносно низькою.
Лопополо підкреслює, що це вимагає дисципліни: потрібно регулярно аналізувати, які класи помилок повторюються, чому команда витрачає на них час, і як можна системно усунути ці класи. Це безперервний цикл спостереження, рефлексії, проєктування рішень і подальшого спостереження. Але саме в такому циклі роль людини максимально відходить від «ручної реалізації» й зміщується до «побудови систем, які роблять реалізацію правильною за замовчуванням».
Новий базовий рівень: кожен інженер як керівник «нескінченної» команди
У підсумку з підходу Лопополо вимальовується новий базовий рівень для професії розробника. Якщо раніше кар’єрний шлях часто виглядав як рух від індивідуального контриб’ютора до техліда й далі до staff/ principal‑рівня, то в світі harness engineering кожен інженер стартує з позиції, близької до staff‑мислення.
Кожен має у своєму розпорядженні «стільки членів команди, скільки може одночасно вести й скільки дозволяє токенний бюджет». Обмеженням стає не кількість людей у штаті, а здатність однієї людини проєктувати, делегувати й контролювати роботу великої кількості агентів. Це вимагає:
- мислення на довших горизонтах;
- готовності інвестувати в документацію, стандарти й гардрейли;
- вміння приймати тимчасові втрати швидкості заради довгострокової якості;
- фокусу на нефункціональних вимогах і системних класах помилок.
У цьому світі «бути хорошим інженером» означає не стільки вміти швидко писати код, скільки вміти формулювати, що таке «хороший код» для конкретної системи, і будувати середовище, у якому агенти послідовно досягають цього стандарту.
Лопополо не применшує складність такого переходу. Він говорить про «AGI‑пігулку», яку потрібно проковтнути: повірити, що моделі справді здатні написати кожен рядок коду, який вам коли‑небудь знадобиться, і що ваша робота — не конкурувати з ними в реалізації, а навчитися ними керувати. Для багатьох інженерів це означає відмову від частини професійної ідентичності, побудованої навколо майстерності написання коду.
Але якщо прийняти цю нову реальність, відкривається інший тип впливу. Інженер перестає бути «одним із багатьох виконавців» і стає архітектором системи, у якій працюють сотні чи тисячі агентів. І в цій ролі людський час і увага стають ще ціннішими — саме тому, що код більше не є дефіцитним ресурсом.
Джерело
Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI