У квітні 2026 року на сцені конференції AI Engineer в Лондоні член технічного штату OpenAI Райан Лопополо розповів про те, як виглядає розробка, коли люди лише керують, а агенти виконують. Протягом дев’яти місяців він будує софт виключно через агентів, заборонивши своїй команді безпосередньо торкатися редакторів коду. Лопополо описує себе як «токенного мільярдера», який щодня витрачає понад тисячу доларів на вихідні токени, і стверджує: реалізація більше не є дефіцитним ресурсом.
У цьому матеріалі — не про зміну ролі інженера загалом, а про технічний фундамент, який зробив агентно‑орієнтовану розробку реальною: моделі GPT‑5.2 і GPT‑5.4, автоматичну компресію контексту, довготривалі агентні сесії та масово паралельні рефакторинги й міграції, які раніше розтягувалися на місяці.
GPT‑5.2 як точка зламу: коли модель вперше «тягне» повний стек інженера
Лопополо називає GPT‑5.2 «магічним моментом» — першою моделлю, яку він побачив здатною виконувати повну роботу інженера‑програміста від початку до кінця. Йдеться не про автодоповнення чи написання окремих функцій, а про ізоморфність до людини‑інженера в реальних кодових базах.
За його описом, GPT‑5.2 досягла рівня, коли модель може:
- працювати з великими, живими кодовими базами, а не лише з іграшковими прикладами;
- розв’язувати реальні задачі користувачів, а не лише синтетичні завдання;
- підтримувати якість коду, достатню для злиття в основну гілку без постійного «ручного доопрацювання».
Саме з цього моменту, на думку Лопополо, твердження «код безкоштовний» перестало бути метафорою. Якщо модель може виконати повний цикл роботи інженера, то вартість ще однієї спроби, ще одного патчу, ще однієї гілки — це лише токени й GPU‑час, а не тижні людської праці.
Це радикально змінює економіку розробки. Якщо раніше будь‑який великий рефакторинг або міграція вимагали ретельного пріоритезування, бо «людських рук» не вистачало, то тепер обмеження змістилися. Лопополо формулює три нові вузькі місця:
- час людини;
- увага людини й моделі;
- вікно контексту моделі.
Саме ці фактори, а не кількість написаних рядків коду, визначають, що реально можна зробити в проєкті.
GPT‑5.4, CEX і кінець «/new»: як автокомпресія контексту розв’язує руки агентам
Якщо GPT‑5.2 зробила можливим повноцінне «інженерство в моделі», то GPT‑5.4 з CEX (Context Expansion / Compaction) зробила це масштабованим у часі. Лопополо підкреслює: GPT‑5.4 з CEX «фантастично» працює з автоматичною компресією контексту для довготривалих агентних задач.
У практичному вимірі це означає, що:
- агент може працювати над завданням дуже довго, поступово «згортуючи» історію діалогу й коду в стислі, релевантні резюме;
- важлива інформація зберігається й підтягується назад у контекст, коли вона знову потрібна;
- розробнику майже не потрібно вручну «обнуляти» сесію командою на кшталт
/new, щоб позбутися «засміченого» контексту.
Лопополо прямо говорить, що завдяки покращеній автокомпресії контексту він практично ніколи не починає нову розмову з нуля, навіть для тривалих робочих процесів. Це критично для агентно‑орієнтованої розробки: агент може вести довгу траєкторію — від постановки задачі до завершення міграції чи рефакторингу — без втрати «пам’яті» про попередні кроки.
Водночас він наголошує, що в такому світі потрібно свідомо проєктувати процеси з урахуванням того, що контекст буде «пейджитися» й оновлюватися. Агенти мають регулярно «освіжати» свій контекст: підтягувати документацію, вимоги до якості, політики безпеки, історію рішень. Це робиться не лише через системні промпти, а й через допоміжних агентів‑рев’юерів, які постійно оцінюють проміжні результати.
Таким чином, GPT‑5.4 з CEX перетворює довгі, багатокрокові задачі з крихких «чат‑сесій», які легко зламати переповненим контекстом, на стійкі, керовані процеси, де модель сама стежить за тим, що варто зберегти, а що можна стиснути.
Коли рефакторинг безкоштовний: міграції, що більше не зависають на півроку
Один із найрадикальніших висновків Лопополо стосується великомасштабних змін у кодовій базі. Він стверджує, що в новій парадигмі такі речі, як рефакторинг і міграції, фактично стали безкоштовними — за умови, що команда вміє запускати багато агентів паралельно.
У традиційній розробці великі міграції часто «висять» місяцями: команда робить 80–90% роботи, але останні 10–20% коду залишаються недоторканими через брак часу, контексту або просто втоми. Лопополо описує знайому картину: «ніколи не можемо дотиснути останні шматки кодової бази».
У світі, де код безкоштовний, він пропонує іншу стратегію:
- запускати десятки агентів, кожен з яких відповідає за свою частину міграції;
- дозволяти їм працювати довго, терпляче проходячи через усі кути й «забуті» модулі;
- не боятися перезапусків і додаткових ітерацій, бо вартість — це лише токени, а не людські години.
Лопополо прямо каже: «Ніколи більше не буде міграції, яка висить шість місяців, бо ви не можете дістатися до останніх частин кодової бази. Ви просто запускаєте 15 агентів, щоб довести роботу до кінця».
Це не означає, що великі зміни стали тривіальними. Потрібно:
- чітко формулювати нефункціональні вимоги до результату;
- мати документацію, яка пояснює, «що означає зробити роботу добре»;
- будувати інфраструктуру рев’ю, яка автоматично ловить типові помилки.
Але ключове — людський час більше не витрачається на механічне «дотягування» міграції. Люди визначають цілі, стандарти й обмеження, а агенти виконують важку, монотонну частину роботи.
Агенти як безкінечно терплячі утримувачі коду: підтримка, рефакторинг і видалення
Теза «код безкоштовний» часто викликає спротив: навіть якщо написати код дешево, його ж потім потрібно підтримувати. Лопополо не заперечує, що код несе тягар підтримки, але пропонує інший погляд: цей тягар більше не повинен лягати на синхронну увагу людини.
На його думку, моделі:
- надзвичайно терплячі;
- можуть працювати нескінченно паралельно;
- не «вигорають» від рутинних задач.
Звідси висновок: підтримку, рефакторинг і навіть видалення коду можна делегувати агентам, які працюють у фоновому режимі, довго й методично.
Лопополо описує підхід, у якому:
- агенти постійно проганяють код через призму певних нефункціональних вимог — безпеки, надійності, продуктивності;
- спеціалізовані рев’ю‑агенти запускаються на кожен пуш і в CI, перевіряючи, наприклад, наявність таймаутів і ретраїв у мережевому коді або безпечність інтерфейсів;
- виявлені класи помилок не просто виправляються точково, а стають приводом для системних змін: написання документації, лінтів, шаблонів, які агенти потім застосовують до всієї кодової бази.
Показовий приклад — мережеві виклики без ретраїв і таймаутів, які призводять до аварій у продакшені. Лопополо визнає, що як людина він сам не є «надійним рев’юером» щодо цієї нефункціональної вимоги: одного разу додав ретрай, злив патч і забув.
Натомість він пропонує:
- один раз витратити час, щоб описати вимогу в документації;
- написати кастомний лінт, який перевіряє кожен виклик
fetchна наявність ретраю й таймауту; - використати агентів, щоб повністю мігрувати кодову базу до нового стандарту.
Це стає можливим саме тому, що «код безкоштовний»: можна дозволити собі повну міграцію, а не лише локальний фікс. Агенти виступають як безкінечно терплячі «санітари» кодової бази, які раз за разом проходяться по всіх файлах, поки клас помилок не буде викорінений системно.
Світ, де всі P3 запускаються одразу: паралельні траєкторії замість вічного беклогу
Ще один наслідок «безкоштовного коду» — зміна ставлення до пріоритизації. У класичній моделі, де кожен рядок коду коштує людського часу, задачі діляться на P0, P1, P2 і P3, але реальність така, що P3 майже ніколи не доходять до виконання.
Лопополо описує це просто: коли людський час потрібен для написання коду, P3 «ніколи не будуть зроблені».
У світі, де код генерують агенти, картина інша:
- всі P3‑задачі можна запустити одразу, не чекаючи «вікна» в розкладі інженера;
- одну й ту саму задачу можна спробувати розв’язати кількома паралельними траєкторіями — наприклад, чотирма різними агентами з різними стратегіями;
- потім команда просто обирає найкраще рішення й інтегрує його.
Лопополо прямо говорить: у світі, де код безкоштовний, усі P3 запускаються негайно, часто «4× у паралель». Це не означає, що пріоритизація зникає як така — людський час усе ще обмежений, і хтось має визначати, які задачі взагалі варто формулювати й запускати. Але сам факт запуску більше не прив’язаний до того, чи знайдеться інженер, готовий витратити на це день або тиждень.
Цей підхід особливо помітний у внутрішніх інструментах. Лопополо розповідає, що побудував багато агентів усередині OpenAI для підвищення продуктивності колег. Коли код безкоштовний, такі інструменти можуть відразу мати якісну локалізацію й інтернаціоналізацію: англійську, французьку, німецьку та інші європейські мови.
Раніше це було б типовою P3‑задачею: «добре б колись локалізувати», яка роками лежала б у беклозі. Тепер це просто ще один набір агентних траєкторій, які можна запустити без відчутного впливу на інші проєкти.
Коли найкращі практики стають «дефолтом» кожного продукту
Якщо код безкоштовний, а агенти можуть нескінченно рефакторити й мігрувати, виникає логічне запитання: якою має бути планка якості? Лопополо вважає, що найкращі практики інженерії, які команда вже знає й застосовує, мають бути доступні в кожному продукті «за замовчуванням».
Йдеться не про те, щоб кожен інженер щоразу згадував усі вимоги до безпеки, надійності, тестування чи UX. Натомість:
- експерти в команді формалізують свої знання у вигляді документації, ADR, «персональних» гайдів;
- ці артефакти стають частиною «харнесу» — системи промптів, інструкцій і перевірок, у якій живуть агенти;
- кожен інженер, який керує агентами, автоматично отримує «краще від усіх» — не через код‑рев’ю з низьким сигналом, а через системні інструкції, які агенти враховують на кожному кроці.
Лопополо наводить приклад планів тестування: замість того, щоб чекати, поки хтось у рев’ю скаже «тут бракує QA‑плану», одна людина описує, як виглядає «хороший QA‑план» для їхньої організації. Далі агенти, керовані цими інструкціями, автоматично додають якісний QA‑план до кожної релевантної зміни.
Це знову повертає нас до тези про безкоштовний код: якщо додавання ще одного шару якості — це «лише» ще одна серія агентних викликів, то немає сенсу економити на цьому. Краще один раз інвестувати в чіткі нефункціональні вимоги й системні guardrails, ніж нескінченно латати наслідки.
Висновок: масштабування інженерії через контекст, а не через людей
Модель світу, яку описує Райан Лопополо, радикально відрізняється від класичної картини розробки. Тут:
- GPT‑5.2 вперше робить реальним повний цикл роботи інженера в моделі;
- GPT‑5.4 з CEX дозволяє агентам працювати довго, не втрачаючи важливий контекст;
- великі рефакторинги й міграції стають фактично безкоштовними завдяки масово паралельним агентам;
- підтримка, рефакторинг і видалення коду делегуються терплячим, паралельним агентам, які не втомлюються;
- усі P3‑задачі можуть стартувати одразу, часто з кількома паралельними спробами.
У такому світі масштабування інженерії відбувається не через найм десятків нових розробників, а через вміння працювати з моделями, контекстом і системами. Люди перестають бути «руками на клавіатурі» й стають архітекторами процесів, які дозволяють агентам робити всю важку роботу — від першого рядка коду до останнього кроку міграції.
Джерело
Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI