Коли OpenAI лише починала працювати над Codex, амбіція була доволі вузькою й водночас амбітною: створити інструмент, який допомагає програмістам писати код на рівні «дуже продуктивного» інженера. Сьогодні ж Codex дедалі менше схожий на спеціалізований сервіс для розробників і дедалі більше — на універсального робочого агента для будь-якої офісної роботи за комп’ютером.
Про цю трансформацію на OpenAI Forum розповідає Тібо Соттьо (Thibault Sottiaux), керівник напряму Codex в OpenAI. Його історія — це не просто технічна еволюція продукту, а показовий кейс того, як змінюється саме поняття «робочого інструменту» в епоху агентних AI?систем.
Витоки Codex: «великий виклик» рівня топ?інженера
У перших експериментах OpenAI з Codex стояло чітке завдання: навчити модель програмувати так, як це робить досвідчений, надзвичайно продуктивний інженер. Усередині компанії це сприймали як один із «великих викликів» — тест на те, чи можуть моделі стати по-справжньому корисними в реальній розробці, а не лише в лабораторних демо.
Перший публічний продукт, який вийшов із цієї роботи, отримав назву Codex Web. Це був хмарний сервіс із веб?інтерфейсом, який поводився радше як автономний агент, ніж як «розумний автодоповнювач коду».
Користувач формулював завдання у веб?інтерфейсі — наприклад, змінити певну функціональність у репозиторії. Codex Web під’єднувався до коду, аналізував репозиторій, визначав, які зміни потрібні, і самостійно відкривав pull request на GitHub. Уся взаємодія зводилася до формулювання наміру та отримання готового PR.
За задумом, це мав бути максимально «упакований» досвід: користувач описує, що хоче, а на виході отримує конкретну зміну в коді. Але саме така ізольованість і стала головною проблемою.
Чому Codex Web не злетів: тертя хмари проти реального робочого середовища
Codex Web працював виключно в хмарі OpenAI. Для розробників це означало необхідність налаштувати окреме середовище: перенести туди залежності, інструменти, конфігурації, які вже давно й ретельно відшліфовані на локальній машині.
Фактично, щоб скористатися Codex Web, потрібно було відтворити свій робочий простір у чужій інфраструктурі. Для багатьох інженерів це виявилося надто затратним за часом і зусиллями.
До цього додавалася ще одна проблема: на той момент моделі були недостатньо надійними для довгих, складних завдань із великою кількістю кроків. Codex Web мав працювати як автономний агент, який самостійно проходить увесь шлях від аналізу репозиторію до готового PR. Але якщо модель помилялася або не враховувала важливий контекст, виправляти це в хмарному середовищі було незручно.
Поєднання високого порогу входу й обмеженої надійності для «довгих» задач створило надто багато тертя. Для інструмента, який має економити час, це критичний недолік.
У результаті команда OpenAI визнала: модельна частина перспективна, але продуктова форма — ні. Потрібен був розворот.
Поворот на локальні машини: менше налаштувань, більше реальної роботи
Ключовий висновок, до якого прийшли в OpenAI: Codex має жити там, де живе реальна робота користувача, — на його власному комп’ютері, у вже налаштованому середовищі.
Замість того, щоб змушувати розробників переносити свій стек у хмару, OpenAI розвернула підхід: Codex має підлаштовуватися під користувача, а не навпаки. Це означало відмову від моделі Codex Web як основного продукту й перехід до архітектури, де агент працює безпосередньо в середовищі користувача, з доступом до його файлів, інструментів, систем управління кодом.
Такий поворот зняв одразу кілька бар’єрів. Зникла потреба дублювати конфігурації й середовища. Стало простіше швидко перевіряти й виправляти дії агента. А головне — Codex отримав змогу працювати не лише з кодом, а й із ширшим контекстом: документами, нотатками, внутрішніми базами знань.
Цей зсув збігся з іншим, більш фундаментальним усвідомленням: навіть у житті програміста код — лише невелика частина роботи.
20–30% коду, 70–80% усього іншого: реальність інженерної праці
Усередині OpenAI уважно подивилися на те, як насправді минає день інженера. Виявилося, що безпосереднє написання коду займає лише близько 20–30% часу. Решта — це те, що зазвичай не потрапляє в уявлення про «чисту розробку», але визначає її реальну складність.
Значну частину дня займає робота з задачами: перегляд і пріоритизація тікетів, обговорення варіантів рішень, узгодження архітектури. Іншу — розслідування багів: перевірка, чи справді проблема існує, чи це помилка користувача, де саме вона проявляється в системі.
До цього додаються чергування по інцидентах, робота з відмовами, постійне «тримання в голові» складних систем, пошук інформації в документації, внутрішніх базах знань, чатах, листуванні.
У такій картині світу Codex як «чистий генератор коду» покриває лише вузький сегмент реальної роботи. Якщо інструмент має бути справді корисним, він повинен допомагати не тільки писати функції, а й розбиратися з тікетами, збирати контекст, координувати людей, стежити за станом задач.
Саме це й почало відбуватися, коли Codex отримав доступ до ширшого контексту користувача.
Вихід за межі коду: як Codex став загальним робочим агентом
Коли Codex навчили працювати не лише з репозиторіями, а й з іншими джерелами інформації — документами, нотатками, внутрішніми системами на кшталт Notion, Slack чи корпоративних сховищ, — його роль почала змінюватися.
Спершу це виглядало як логічне розширення: щоб краще допомагати з кодом, агенту потрібен доступ до документації, специфікацій, історії обговорень. Але дуже швидко виявилося, що той самий механізм чудово працює й для завдань, які взагалі не пов’язані з програмуванням.
Codex став корисним там, де потрібно зібрати розпорошену інформацію, узагальнити її й перетворити на зрозумілий план дій чи звіт. Це може бути підготовка до запуску продукту, аналіз відгуків користувачів, складання дорожньої карти, планування презентації для стейкхолдерів.
Показовий епізод, який став для команди переломним моментом: під час підготовки до одного з запусків продукту продакт?менеджер OpenAI використовував Codex як свого «мультиагента». Поки він обговорював із колегами стан релізу, Codex у фоновому режимі:
- стежив за змінами в коді й задачах,
- збирав відгуки користувачів,
- агрегував інформацію від розробників,
- оновлював документ із планом запуску й статусом кожної частини роботи.
Фактично, замість того щоб годинами переглядати Slack, документи й GitHub, продакт?менеджер делегував цю рутинну, але критично важливу координаційну роботу агенту. Codex не лише збирав контекст, а й «ганявся» за людьми: через інтеграцію зі Slack він міг надсилати повідомлення колегам, уточнюючи статус задач і нагадуючи про відкриті питання.
Цей сценарій добре ілюструє, як Codex вийшов за межі «інструмента для коду» й став загальним агентом для координації знань і людей.
GPT?5, GPT?5.2 і «довгі» задачі: технологічний перелом
Перехід Codex від суто інженерного інструмента до універсального агента збігся з важливим технологічним стрибком у моделях OpenAI.
За останні пів року, після виходу GPT?5, а потім GPT?5.2, Codex отримав значно вищу «загальність» і надійність у виконанні завдань, які вимагають багатьох кроків і тривалого планування.
Йдеться не лише про кращу якість окремих відповідей, а про здатність моделі:
- тримати в голові складний контекст,
- планувати послідовність дій,
- коригувати курс у процесі виконання,
- доводити задачу до завершення без постійного ручного втручання.
Саме ці властивості критичні для «довгих» задач — від підготовки великої презентації до комплексного аналізу ринку чи організації кампанії.
У поєднанні з доступом до реальних робочих інструментів користувача це перетворює Codex на агента, який може не просто відповідати на запитання, а й виконувати роботу від початку до кінця: зібрати дані, узагальнити, сформувати план, підготувати документ, надіслати повідомлення потрібним людям.
Результат цього технологічного перелому добре видно в статистиці використання: за оцінкою OpenAI, сьогодні більшість завдань, які виконуються в Codex, уже не пов’язані з написанням коду. Це радикальна зміна порівняно з початковим задумом продукту.
Від коду до знань: як змінюється профіль завдань у Codex
Те, що більшість задач у Codex сьогодні — некодові, виглядає логічним продовженням двох паралельних процесів.
По?перше, сама робота розробників значною мірою складається з «некодових» активностей: аналізу, планування, комунікації, пошуку інформації. Коли Codex навчився добре працювати з цими аспектами, інженери природно почали використовувати його не лише як генератор коду, а як універсального помічника в щоденній роботі.
По?друге, як тільки інструмент показав себе корисним у таких задачах, стало очевидно, що він не обмежений технічними ролями. Дослідники, викладачі, операційні менеджери, власники малого бізнесу, керівники команд — усі вони виконують схожі типи роботи: збирають інформацію, структурують її, готують документи, координують людей.
Codex, який уміє:
- шукати потрібні фрагменти в документах,
- узагальнювати великі масиви тексту,
- підтримувати актуальний план із багатьма залежностями,
- комунікувати через робочі інструменти на кшталт Slack,
природно стає корисним для будь-якої «знаннєвої» професії.
Це не означає, що код перестав бути важливим напрямом. Але в загальній картині Codex уже не сприймається як «інструмент для програмістів», а радше як агент для будь-якої роботи за комп’ютером, де потрібно мислити, структурувати, координувати.
Зміна ролей і темпу: що означає Codex для роботи команд
Коли інженерні команди отримують інструмент, який суттєво прискорює їхню роботу, це неминуче змінює баланс усередині організації.
OpenAI відзначає, що завдяки Codex інженери почали «будувати швидше, ніж будь-коли». Але разом із цим з’явився новий ефект: вузькі місця змістилися в інші функції.
Якщо раніше основним обмеженням могла бути швидкість розробки, то тепер дедалі частіше гальмують інші ланки — комунікації, маркетинг, здатність компанії вчасно й послідовно розповідати світу про те, що вона будує.
Це типовий сценарій для будь-якої технології, яка різко прискорює одну частину процесу: система в цілому починає впиратися в інші, менш автоматизовані ділянки. У випадку Codex це означає, що агентні інструменти поступово проникають і в ці сфери — від підготовки презентацій до аналізу публічного сприйняття нових функцій.
У ширшому сенсі це змінює вимоги до ролей. Працівники в різних функціях мають адаптуватися до того, що «важкі» задачі, які раніше займали дні, тепер можуть виконуватися за години або значною мірою автоматизуватися.
Це не обов’язково означає зникнення ролей, але точно означає зміну їхнього змісту: менше ручної рутини, більше роботи з постановкою задач, перевіркою результатів, прийняттям рішень.
Codex як критична інфраструктура: від експерименту до залежності
Ще один важливий маркер зрілості Codex — те, як його роль описують усередині самої OpenAI. За оцінкою компанії, сьогодні Codex уже критично важливий для поточної швидкості випуску продуктів.
Інакше кажучи, без Codex OpenAI не змогла б рухатися в тому ж темпі. Це показує, що агентні інструменти перестають бути «додатковою опцією» і стають частиною базової інфраструктури роботи — так само, як колись електронна пошта чи системи контролю версій.
Водночас у компанії наголошують: нинішній стан технології вже достатньо загальний, щоб подібний підхід міг працювати й в інших організаціях. Якщо значна частина роботи відбувається за комп’ютером — від підготовки презентацій до дослідження ринку й організації фінансових процесів, — Codex?подібні агенти здатні взяти на себе значну частину цієї діяльності.
Це не універсальна «чарівна паличка», але це вже не експериментальна технологія. Це інструмент, який змінює реальний розподіл часу й зусиль у командах.
Висновок: Codex як дзеркало майбутнього офісної роботи
Історія Codex — це концентрований приклад того, як швидко може змінитися роль AI?інструмента, коли він виходить за межі вузької спеціалізації.
Починавши як амбітний проєкт для програмістів, покликаний писати код на рівні топ?інженера, Codex пройшов через невдалу, надто фрикційну хмарну модель, переосмислення архітектури й перехід на локальні машини користувачів.
Ключовим поворотом стало усвідомлення, що:
- інженери більшу частину часу витрачають не на код, а на координацію, аналіз і пошук інформації;
- ті самі типи задач характерні для більшості знаннєвих професій;
- із появою GPT?5 і GPT?5.2 моделі стали достатньо загальними й надійними, щоб брати на себе довгі, багатокрокові завдання.
Сьогодні більшість задач у Codex — уже не про програмування. Це дослідження, планування, організація файлів, автоматизація рутинних дій, аналіз даних, підготовка презентацій, координація людей через робочі інструменти.
У цьому сенсі Codex стає не стільки «інструментом для коду», скільки прототипом того, як може виглядати повсякденна офісна робота в найближчі роки: коли значну частину цифрових дій виконує агент, а людина зосереджується на постановці задач, оцінці результатів і стратегічних рішеннях.