У світі, де великі мовні моделі вже здатні виконувати повний цикл роботи програміста, головним викликом стає не написання коду, а організація середовища, в якому цей код створюють агенти. Про це говорить Райан Лопополо, Member of Technical Staff в OpenAI, який останні дев’ять місяців будує софт виключно через агентів і навіть заборонив своїй команді безпосередньо торкатися редакторів коду. Його досвід — це не футуристичний експеримент, а практичний посібник: як змінити кодову базу, документацію та процеси так, щоб агенти стабільно видавали якісний результат.
Цей матеріал зосереджується на тому, як зробити код і процеси «дружніми до агентів»: від локалізації внутрішніх інструментів і стандартизації патернів до ролі документації, ADR і неявних нефункціональних вимог, які визначають, що таке «добре виконана робота» для моделі.
Коли код безкоштовний: внутрішні агенти, локалізація і «розкіш» найкращих практик
Лопополо виходить із радикальної, але вже практично підтвердженої передумови: реалізація більше не є дефіцитним ресурсом. Код, у його формулюванні, «безкоштовний» — не в сенсі відсутності вартості підтримки, а в сенсі вартості створення, рефакторингу й видалення, коли цим займаються моделі.
У такій парадигмі він побудував в OpenAI велику кількість внутрішніх агентів, які підвищують продуктивність колег по всій організації. Важливий наслідок цієї «безкоштовності коду» — можливість робити те, що раніше завжди програвало в пріоритезації, наприклад, якісну локалізацію.
Внутрішні інструменти, які він розгортає для команд у Лондоні, Дубліні, Парижі, Брюсселі, Цюриху чи Мюнхені, одразу отримують підтримку кількох європейських мов — англійської, французької, німецької та інших. І це не вимагає відмови від інших задач чи «з’їдання» спринтів. Якщо код генерує агент, додати ще одну мову інтерфейсу — це не місяць ручної роботи, а ще одна інструкція й кілька додаткових запусків моделі.
Звідси випливає більш амбітна теза: найкращі практики інженерії програмного забезпечення мають бути доступні «за замовчуванням» у кожному продукті. Якщо агенти можуть дешево тиражувати патерни, немає підстав обмежуватися мінімальною реалізацією. Те, що раніше вважалося «розкішшю» — продумана обробка помилок, надійні інтерфейси, ретельні QA-плани, локалізація, — тепер може стати базовим рівнем.
Ключове питання зміщується: не «чи вистачить нам часу це зробити», а «чи правильно ми описали, що саме означає зробити це добре, і чи навчили ми агентів наслідувати ці стандарти».
Документація як промпт: як навчити агентів «розуміти», що таке хороша робота
Якщо код пише модель, то головним артефактом стає не сам код, а все, що формує поведінку агента: промпти, обмеження, приклади, історія рішень. Лопополо підкреслює, що документація, ADR (Architecture Decision Records), описи персон, тікети та код-рев’ю — це не просто супровідні матеріали, а фактично навчальні дані, які визначають, як агент розуміє «якісну роботу».
У традиційній команді ці артефакти допомагають новачкам увійти в контекст і зрозуміти, чому система влаштована саме так. У команді, де основну реалізацію виконують агенти, їхня роль стає ще важливішою: вони перетворюються на промпти, які постійно «підказують» моделі, які рішення прийнятні, а які — ні.
Лопополо пропонує мислити цими матеріалами як «хлібними крихтами», що ведуть агента до правильних рішень. Якщо є історія тікетів і код-рев’ю, де чітко видно, які зміни приймалися, а які відхилялися і чому, агент може вивести патерн: що вважається безпечним, підтримуваним, відповідним до стандартів команди.
Особливу роль відіграє документація, орієнтована на персони. У команді Лопополо працюють фахівці з фронтенд-архітектури, бекенд-скейлінгу, продакт-орієнтованого дизайну. Кожен приносить власне бачення нефункціональних вимог: як виглядає «добре спроєктований API», «якісний QA-план», «стабільна система під навантаженням». Коли ці знання фіксуються в документах, кожен інженер, який керує агентами, отримує доступ до найкращих практик усієї команди, а не лише до власного досвіду.
Це знімає залежність від «низькосигнальних» код-рев’ю, де знання передаються повільно й фрагментарно. Один ретельно написаний гайд із QA-планування чи безпечного використання мережевих викликів може вплинути на всі майбутні траєкторії агентів, які працюють із кодовою базою.
Одноманітність як стратегія: чому варто зробити кодову базу передбачуваною для моделей
Щоб агенти працювали надійно, їм потрібно не лише знати стандарти, а й легко передбачати правильні токени — тобто наступні фрагменти коду, які відповідають цим стандартам. Для цього кодова база має бути максимально одноманітною.
Лопополо радить робити код «однаковим настільки, наскільки це можливо». Ідеться не про бездумну уніфікацію, а про свідоме зменшення варіативності там, де вона не додає цінності. Якщо одна й та сама задача розв’язується в різних частинах системи однаково, моделі легше вгадати правильний патерн і менше «витрачати увагу» на вибір між десятком стилістично різних, але функціонально схожих підходів.
У світі, де великомасштабний рефакторинг «безкоштовний», це стає практично здійсненним. Лопополо наголошує: міграції, які раніше зависали на пів року, бо «руки не доходять до останніх 10% коду», тепер можна довести до кінця, просто запустивши кілька десятків агентів паралельно. Якщо команда вирішила, що всі мережеві виклики мають обгортатися в єдиний утилітарний шар із таймаутами й ретраями, агенти можуть систематично пройтися по всій кодовій базі й привести її до цього стандарту.
Більше того, самі агенти можуть стати інструментом забезпечення одноманітності. Вони здатні не лише писати новий код, а й рефакторити існуючий, вирівнюючи стилі, патерни, підходи до обробки помилок. Людям залишається визначити, який саме патерн вважається «правильним», і зафіксувати це в документації та промптах.
Результат — кодова база, в якій:
- однакові проблеми розв’язуються однаково;
- моделі легше передбачати правильні рішення;
- зменшується кількість «дивних» кутових кейсів, де агент поводиться непередбачувано, бо не може зіставити поточну задачу з відомими йому патернами.
Це не лише підвищує надійність агентів, а й робить саму систему більш підтримуваною для людей, які залишаються тими, хто проєктує архітектуру й приймає ключові рішення.
Нефункціональні вимоги: 500 дрібних рішень, які потрібно зробити явними
Одна з найскладніших частин роботи інженера — це не реалізація бізнес-логіки, а сотні дрібних рішень навколо нефункціональних вимог: надійності, безпеки, продуктивності, зручності підтримки. Лопополо оцінює, що навіть для одного патчу може знадобитися близько 500 таких мікрорішень.
Моделі під час тренування бачили трильйони рядків коду, в яких ці рішення приймалися по-різному. Вони знають безліч варіантів: із ретраями й без, із суворими інтерфейсами й «дірявими», із продуманими таймаутами й повною їх відсутністю. Якщо не задати рамки, агент може обрати будь-який із цих варіантів, і далеко не завжди це буде той, який команда вважає прийнятним.
Тому завдання команди — зробити нефункціональні вимоги явними. Їх потрібно не просто «мати в голові», а чітко описати в документах, промптах, правилах рев’ю. Агент має бачити, що означає «достатньо добре, щоб змерджити», які компроміси допустимі, а які — ні.
Лопополо пропонує підходити до цього системно. Якщо агенти (або люди) регулярно припускаються однакових помилок, варто:
- виявити клас помилок, який повторюється;
- зрозуміти, чому на нього постійно витрачається час;
- розробити рішення, яке систематично усуває цей клас помилок;
- зафіксувати його в документації, промптах, лінтах, CI-перевірках;
- продовжувати спостерігати й уточнювати вимоги.
Показовий приклад — мережевий код без таймаутів і ретраїв. Багато інженерів, включно з самим Лопополо, визнають, що не завжди послідовно дотримуються цього стандарту. Один раз виправити баг, додавши ретрай і таймаут, — не те саме, що системно вирішити проблему.
Якщо ж витратити час на написання документа, який описує, як саме мають виглядати мережеві виклики, і створити кастомний лінт, що перевіряє кожен виклик fetch на наявність ретраїв і таймаутів, проблема вирішується «раз і назавжди». Далі агенти можуть автоматично мігрувати кодову базу до цього стандарту, а CI — не пропускати нові відхилення.
Це і є практична реалізація тези «код безкоштовний»: можна дозволити собі дорогі на вигляд зміни, якщо вони знімають цілий клас помилок і більше не вимагають ручного контролю.
Коли агенти помиляються: чому варто свідомо гальмуватися заради кращих гардрейлів
Агенти не ідеальні. Вони можуть продукувати «сміття», пропускати критичні нефункціональні вимоги, обирати небажані патерни. Лопополо не пропонує закривати на це очі — навпаки, він радить свідомо приймати короткострокове падіння швидкості заради покращення системи.
Якщо агент регулярно видає неприйнятний код, це сигнал не стільки про «погану модель», скільки про недостатньо чіткі промпти, відсутні гардрейли або нечітко сформульовані вимоги. У такій ситуації, за його словами, варто:
- «відмотати назад» і детально розібратися, де саме агент збивається;
- уточнити промпти, додати заборони на «сміттєвий» код, конкретизувати очікування;
- посилити системні обмеження: від лінтів до спеціалізованих рев’ю-агентів;
- лише після цього знову переключатися на більш високорівневі задачі.
Формулювання на кшталт «не приймайте шлак» у цьому контексті — не метафора, а прямий інструктаж для процесу: якщо код не відповідає стандартам, його не можна змерджити лише тому, що «так швидше». Інакше агенти продовжать відтворювати небажані патерни.
Щоб підтримувати якість на тривалій дистанції, Лопополо використовує рев’ю-агентів, які постійно проглядають зміни крізь призму успіху. У кодовій базі OpenAI працюють спеціалізовані агенти безпеки й надійності, які запускаються на кожен пуш у CI. Вони звіряють пропоновані патчі з документацією й перевіряють конкретні речі: чи є таймаути й ретраї в мережевому коді, чи інтерфейси спроєктовані так, щоб їх було важко неправильно використати.
Це не замінює людський код-рев’ю, але знімає з людей значну частину рутинної перевірки нефункціональних вимог. Люди можуть зосередитися на архітектурі й продукті, тоді як агенти-рев’юери стежать за тим, щоб жоден патч не порушував базові стандарти надійності й безпеки.
Ключова умова успіху — готовність інвестувати час у налаштування цих гардрейлів, навіть якщо це тимчасово зменшує видиму швидкість розробки. У довгостроковій перспективі це окупається з лишком: агенти починають стабільно видавати прийнятний код, а команда звільняється від нескінченного виправлення одних і тих самих помилок.
Висновок: код як витратний матеріал, стандарти як капітал
Досвід Райана Лопополо в OpenAI показує, що перехід до агентно-орієнтованої розробки — це не лише питання вибору моделі чи інструментів. Це глибока перебудова того, що вважається головним активом інженерної організації.
Якщо код дійсно стає «безкоштовним» у створенні й зміні, то справжнім капіталом стають:
- чітко сформульовані нефункціональні вимоги;
- стандартизовані патерни, які агенти можуть легко тиражувати;
- документація, ADR, історія рішень і код-рев’ю як навчальні дані для моделей;
- одноманітна, передбачувана кодова база, дружня до токен-передбачення;
- системні гардрейли й рев’ю-агенти, які забезпечують якість на кожному кроці.
У такому світі роль інженера зміщується від «людини, яка пише код», до «людини, яка проєктує середовище, в якому агенти можуть писати правильний код». Це вимагає більше системного мислення, більше уваги до процесів і стандартів, але відкриває можливість робити те, що раніше було економічно невигідно: завершувати великі міграції, локалізувати інструменти для всіх офісів, вбудовувати найкращі практики в кожен продукт за замовчуванням.
У підсумку, питання вже не в тому, чи можуть агенти писати код, а в тому, чи готові команди інвестувати в структури, які зроблять цей код надійним, підтримуваним і послідовним. Саме від якості цих структур залежить, чи стане «безкоштовний код» активом, а не боргом.
Джерело
Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI