У Лондоні команда OpenAI з розробницького напряму, зокрема Вайбгав Срівастав (Vaibhav Srivastav) та Катія Гіл Гусман (Katia Gil Guzman), представила оновлене бачення Codex. Те, що починалося як «розумніший автокомпліт» для програмістів, сьогодні описується як відкритий програмний інженер‑агент, здатний не лише писати код, а й виконувати команди, запускати тести, досліджувати великі кодові бази та працювати через цілу низку інструментів — від IDE до Slack і GitHub.
Це не просто ще один «AI‑асистент». Codex опирається на нове покоління моделей GPT‑5.x, працює через уніфікований агентний «harness» з вбудованою безпекою та отримав суттєві інфраструктурні покращення — від WebSocket‑стримінгу до Fast Mode, які помітно знижують затримки для розробників.
Від «агента, що пише код» до «агента, що працює як інженер»
Ключова зміна в позиціонуванні Codex — це відхід від образу «інструмента для генерації коду» до ролі повноцінного софтверного інженера, який може виконувати весь цикл роботи, а не лише окремі фрагменти.
Codex описують як відкритого (open) програмного інженера‑агента OpenAI. Його можливості виходять далеко за межі автодоповнення чи написання функцій. Агент може запускати команди в середовищі розробки, виконувати тести, досліджувати структуру й залежності в кодовій базі, переходити між файлами, аналізувати контекст і фактично діяти так, як це робить живий інженер, що працює з репозиторієм.
Важливий акцент — Codex не обмежений одним інтерфейсом. Він задуманий як «двигун», який можна вбудувати в різні точки розробницького робочого процесу. Це означає, що агент не просто генерує код у чаті, а може:
- виконувати shell‑команди для запуску збірки чи тестів;
- читати й змінювати файли в проєкті;
- аналізувати результати тестів і логів;
- повертатися до коду з урахуванням отриманого фідбеку.
Така модель роботи наближає Codex до сценарію, де інженер делегує йому не окреме завдання «напиши функцію», а цілий шматок роботи: «розберися з цим багом», «додай цю фічу», «проведи рефакторинг модуля» — з очікуванням, що агент сам пройде всі проміжні кроки.
Єдиний агентний «harness»: як Codex керує інструментами, середовищем і безпекою
Технічно Codex тримається не лише на моделях. Над ними побудовано уніфікований агентний «harness» — шар, який керує тим, як модель взаємодіє зі світом інструментів і кодом.
Цей harness виконує кілька критичних функцій.
По‑перше, він відповідає за виконання інструментів. Модель сама по собі генерує текст, але для того, щоб запустити тести, виконати команду в терміналі чи прочитати файл, потрібні окремі «tools». Harness виступає обгорткою для цих інструментів, приймає рішення, коли й як їх викликати, передає результати назад агенту та дозволяє йому будувати багатокрокові ланцюжки дій.
По‑друге, він займається налаштуванням середовища. Щоб агент міг працювати з реальними проєктами, потрібно підняти відповідний runtime, надати доступ до файлової системи, репозиторію, залежностей. Harness інкапсулює цю логіку, щоб розробнику не доводилося вручну будувати складні пайплайни для кожного завдання.
По‑третє, у цьому шарі вбудовано механізми оцінки поведінки агента. Codex не просто «виконує все, що придумав». Harness відстежує, що саме робить агент, як він використовує інструменти, чи не заходить у небажані сценарії, і може коригувати або обмежувати його дії.
Нарешті, у harness інтегровано безпеку. Це означає, що контроль за тим, які команди дозволено виконувати, які ресурси доступні, як обробляються потенційно чутливі дані, знаходиться не в руках кінцевого користувача, а в централізованому шарі, який розробляє OpenAI. Для підприємств і команд, які розглядають Codex як інженерного «колегу», це критично: агент отримує потужні можливості, але в межах керованого, безпечного середовища.
У результаті Codex виглядає не як набір розрізнених інструментів, а як цілісний агентний стек: модель, що мислить, harness, що керує діями, і набір інтерфейсів, через які розробник взаємодіє з цим «віртуальним інженером».
Один агент — багато поверхонь: як Codex вбудовується в робочий день розробника
Ще одна важлива зміна — Codex перестав бути прив’язаним до одного «місця проживання». Замість того, щоб змушувати розробників переходити в окремий інструмент, OpenAI розносить агента по всьому робочому середовищу.
Центральною точкою став окремий Codex‑додаток для десктопа. Через нього можна спілкуватися з агентом, керувати проєктами, запускати складні сценарії, але це лише один із «фронтів».
Codex інтегрується з IDE через розширення. Це дозволяє викликати агента безпосередньо з редактора коду, де він бачить файли, структуру проєкту, може пропонувати зміни, писати тести, проводити рефакторинг. Для багатьох розробників саме IDE залишається основним робочим простором, і Codex намагається не руйнувати цю звичку.
Для тих, хто віддає перевагу терміналу, є CLI‑інтерфейс. Він дозволяє взаємодіяти з агентом у звичному командному середовищі, де можна комбінувати можливості Codex з shell‑скриптами, git‑командами та іншими інструментами.
Окремий вектор — інтеграція з командними сервісами. Усередині OpenAI, як розповідають спікери, Codex активно використовують у Slack: інженери просто «пінгують» агента в каналі, просять «пофіксити» щось, пояснити помилку, допомогти з кодом. Подібний сценарій працює й у GitHub, де Codex може брати участь у рев’ю, аналізувати pull‑requests, пропонувати зміни.
Нарешті, Codex можна вбудувати в інші інструменти, які вже є частиною робочого процесу команди. Серед згаданих інтеграцій — Figma, Linear, Notion. Це означає, що агент може, наприклад, читати специфікації з Notion, звірятися з задачами в Linear, орієнтуватися на дизайн у Figma й на цій основі будувати або змінювати код.
З погляду розробника це зрушення від «ще одного окремого сервісу» до «фону», який присутній у всіх ключових точках роботи: у редакторі, терміналі, таск‑трекері, месенджері та репозиторії.
Модельний стек Codex: від GPT‑5.2 до GPT‑5.4 і легких Mini/Nano
Під капотом Codex працює на сімействі моделей GPT‑5.x, які OpenAI розвиває з орієнтацією саме на інженерні сценарії.
Коли Вайбгав Срівастав приєднався до OpenAI у грудні, флагманською моделлю була GPT‑5.2. На її основі з’явилася спеціалізована версія GPT‑5.2 Codex — варіант, налаштований під задачі програмування. Ця модель стала першим кроком до того, щоб зробити агента здатним витримувати довгі, безперервні сесії роботи над кодом і довготривалі завдання.
Далі вийшла GPT‑5.3 Codex, яка продовжила цю лінію, а потім — GPT‑5.3 Codex Spark, створена у партнерстві з Cerebras. Spark позиціонують як «надшвидкий» варіант, орієнтований на сценарії, де швидкість відповіді критична.
Найсвіжіший крок — реліз GPT‑5.4, яку зараз називають state‑of‑the‑art‑моделлю. Вона стала новим флагманом, на який поступово переходить Codex. Кожне покращення в базових моделях автоматично піднімає й можливості агента: краще розуміння контексту, точніший аналіз коду, надійніша робота з довгими ланцюжками дій.
Паралельно з нарощуванням потужності великих моделей OpenAI розвиває й легші варіанти. З’явилися GPT‑5.4 Mini та GPT‑5.4 Nano — моделі, оптимізовані для коротких завдань і ролі субагентів у системі Codex.
Їхня логіка проста: не всі задачі потребують повної потужності флагманської моделі. Для коротких, чітко окреслених кроків — наприклад, локального аналізу фрагмента коду, дрібної трансформації, допоміжних перевірок — можна використовувати легкі моделі, які працюють швидше й дешевше. У багатокомпонентній агентній системі це дозволяє розподіляти навантаження: складні, довгі задачі віддаються GPT‑5.4, а дрібні операції — Mini та Nano.
Такий підхід формує своєрідну «ієрархію інтелекту» всередині Codex, де різні моделі виконують різні ролі, але працюють у межах одного агентного середовища.
Швидкість як функція продукту: WebSocket‑стримінг і Fast Mode
Для інженерного агента швидкість відповіді — не косметичний параметр, а частина користувацького досвіду. Якщо агент повільно «друкує» токени, розробник втрачає концентрацію, а інтеграція в робочий процес стає болючою.
OpenAI робить помітний акцент на інфраструктурних покращеннях, які зменшують затримки при роботі з Codex.
Перший крок — підтримка WebSocket у API. Замість класичної моделі запит‑відповідь поверх HTTP, WebSocket дозволяє встановити постійне з’єднання між клієнтом і сервером. Це зменшує накладні витрати на встановлення з’єднання й дає змогу стримити токени швидше. У результаті, за оцінками команди, WebSocket забезпечує приблизно у 1,75 раза швидшу доставку токенів без додаткової вартості для користувачів.
Другий шар — Fast Mode. Це режим, який поверх уже досягнутого прискорення через WebSocket дає ще приблизно дворазове пришвидшення стримінгу токенів. У поєднанні ці два фактори суттєво скорочують час очікування відповіді.
Для Codex, який часто працює в інтерактивному режимі — аналізує код, пропонує зміни, запускає тести й реагує на їх результати — така економія часу відчувається безпосередньо. Розробник отримує не лише «розумнішого» агента, а й такого, що встигає за темпом його роботи.
Команда OpenAI підкреслює, що робота над швидкістю триває: WebSocket і Fast Mode — це лише частина ширшого зусилля з оптимізації сервінгу моделей. Але вже зараз Codex отримує вигоду від цих покращень, що робить його більш придатним для повсякденного використання, а не лише для демонстраційних сценаріїв.
Codex як платформа, що масштабується разом із спільнотою
Хоча фокус цієї розмови — на архітектурі агента, моделях і швидкості, важливою частиною історії Codex є його прийняття спільнотою. OpenAI повідомляє, що сервіс перетнув позначку у 3 мільйони щотижневих активних користувачів, причому ця цифра більш ніж утричі зросла з січня.
Такий темп зростання свідчить про те, що Codex виходить за межі нішевого інструмента для ентузіастів і стає масовим компонентом розробницької інфраструктури. Для OpenAI це створює додатковий тиск: будь‑які зміни в моделях, harness чи інтерфейсах відчуваються мільйонами людей, а отже, вимоги до стабільності, безпеки й прозорості рішень зростають.
Водночас це дає й перевагу: зворотний зв’язок від широкої бази користувачів дозволяє швидко ітеративно покращувати як моделі, так і агентний шар. Саме так, за словами команди, формується «flywheel» між моделями й harness: кращі моделі відкривають нові сценарії, які вимагають кращого керування інструментами, а покращений harness, у свою чергу, дозволяє повніше розкрити потенціал моделей.
Codex у цій картині виглядає не як статичний продукт, а як платформа, що еволюціонує разом із тим, як змінюється уявлення про роль AI в інженерній роботі.
Висновок: агент, що вбудовується в інженерну культуру
Сьогоднішній Codex — це вже не «розумний автокомпліт», а спроба створити повноцінного програмного інженера‑агента, який може працювати з кодом від початку до кінця: писати, запускати, тестувати, досліджувати, інтегруватися з інструментами команди й робити це в межах керованого, безпечного середовища.
Його основу складає сімейство моделей GPT‑5.x — від GPT‑5.2 Codex до GPT‑5.4 — доповнене легкими GPT‑5.4 Mini та Nano для коротких задач і субагентів. Над моделями працює уніфікований агентний harness, який керує інструментами, середовищем, оцінкою поведінки та безпекою. А для розробників Codex доступний через низку поверхонь — десктопний додаток, IDE, CLI, Slack, GitHub і кастомні інтеграції з Figma, Linear, Notion.
Інфраструктурні кроки — WebSocket‑стримінг і Fast Mode — зменшують затримки й роблять взаємодію з агентом достатньо швидкою, щоб він органічно вписувався в повсякденний робочий процес. На цьому тлі зростання до мільйонів щотижневих користувачів виглядає не випадковістю, а наслідком того, що Codex починає виконувати роль не просто інструмента, а повноцінного учасника інженерної культури.
Як далеко ця трансформація зайде — залежить від того, наскільки спільнота буде готова делегувати агентам дедалі більше частин розробницької роботи. Але вже зараз зрозуміло: Codex рухається в бік системи, де AI не просто допомагає писати код, а бере на себе значну частину інженерного циклу.
Джерело
Codex and Subagents — Vaibhav Srivastav & Katia Gil Guzman, OpenAI (YouTube)