Краткият отговор: OpenAI вече говори за Codex не само като за приложение за програмиране, CLI или IDE разширение, а като за платформа, върху която други екипи могат да строят собствени AI агентни продукти. Новата публикация на OpenAI Developers поставя акцента върху отворения Codex harness – слоя, който управлява контекста, инструментите, ограниченията, одобренията и самото изпълнение на задачите.
Какво обяви OpenAI
В публикацията „Codex as a platform: build on the open agent harness“ OpenAI описва Codex като по-широка основа за разработчици, а не като единичен продукт. Компанията посочва, че open-source Codex harness стои зад познатите Codex преживявания – приложението, командния ред и IDE разширението – но може да се използва и в специализирани бизнес приложения.
Идеята е важна, защото много екипи не искат просто чатбот до работата си. Те искат агентът да бъде вграден в реалния софтуер: табло за сигурност, вътрешна система за поддръжка, инженерна опашка, продуктова платформа или админ панел със специфични данни и правила. Това е различна посока от познатото „отворете прозорец и говорете с AI“.
На NewTechGen вече следим как OpenAI пренарежда developer стека си – от миграцията от Assistants API към по-новите Responses модели до новите работни потоци около агентите. Сега фокусът е още по-инфраструктурен: не само какъв модел стои отдолу, а кой слой управлява работата му в истинско приложение.
Защо harness слоят е важен
Моделът сам по себе си не е пълноценен агент. За да свърши реална работа, той трябва да вижда правилния контекст, да извиква инструменти, да помни състоянието на задачата, да показва напредък, да спира при рискови действия и да може да продължи след прекъсване. Именно това OpenAI нарича harness – изпълнителната рамка около модела.
В публикацията компанията дава и конкретен пример защо този слой не е дребен технически детайл. При ARC-AGI-3 комбинацията от запазено reasoning състояние и compaction на контекста е вдигнала резултата на GPT-5.6 Sol от 13,3% до 38,3%, като едновременно е намалила изходните токени шест пъти. Казано по-просто: начинът, по който агентът пази и подрежда работата си, може да промени резултата почти толкова силно, колкото и самият модел.
Тук има връзка и с темата за AI инфраструктурата и центровете за данни. Колкото по-скъпи стават изчисленията, толкова по-важно е агентите да не губят контекст, да не повтарят излишни стъпки и да не харчат токени за хаотични цикли.
Какво могат да строят екипите
OpenAI посочва три слоя за интеграция. За ограничени автоматизирани задачи може да се използва codex exec. За приложения, които трябва да стартират, възобновяват или следят Codex задачи програмно, има Codex SDK. А когато агентът е част от самия продукт, Codex app-server дава по-директен контрол върху жизнения цикъл, събитията, прекъсванията, инструментите и одобренията.
Това отваря практични сценарии. Security екип може да има табло със сигнали, засегнати услуги и задължителна човешка проверка преди remediation ticket. Support екип може да даде на агента история на акаунта, продуктови логове и вътрешна документация, за да подготви отговор. Product екип може да върже issue tracker към scoped implementation поток, без да мести целия процес в отделен чат.
За българските софтуерни екипи най-интересната част е контролът върху интерфейса и границите. Ако AI агентът работи в продуктова система, той може да вижда точно нужните данни и да изпълнява само позволените действия. Това е по-подходящо за фирмена среда от свободен чат с копирани файлове, особено когато има клиентски данни, production достъп или регулаторни изисквания.
Подобна посока се вижда и при конкурентите. Microsoft вече позиционира AI агентите като част от security и productivity stack, а Google натиска интеграцията на Gemini в Android и работните приложения. Затова Codex като платформа не е просто нов developer блог, а част от по-голямата надпревара кой ще притежава работния слой на AI агентите.
Вижте още: как Microsoft говори за нов кибер стек в ерата на AI агентите и как Google превръща Android в AI помощник.
Рискове и граници
Отвореният harness не означава, че всеки продукт автоматично получава безопасен и полезен AI агент. Трудната част остава в дизайна на инструментите, ограниченията и одобренията. Ако приложението даде твърде широк достъп, агентът може да прави прекалено много. Ако достъпът е твърде тесен, той се превръща в скъп асистент, който само обяснява, но не помага реално.
Има и продуктова дилема. Много компании ще се изкушат да добавят „AI агент“ като етикет, без да променят работния процес. По-смисленият подход е обратният: първо да се види къде хората губят време между системи, документи, логове и решения, а след това агентът да бъде вкаран точно там, с ясни правила кога действа сам и кога иска одобрение.
Най-важното през 2026 г.
AI агентите навлизат в етап, в който интерфейсът, контекстът и оперативните правила стават почти толкова важни, колкото и моделът. Codex като платформа показва, че OpenAI иска да бъде не само доставчик на модел или coding assistant, а инфраструктурен слой за софтуер, който върши работа в реални системи. За разработчиците това е възможност, но и тест: добрият агентен продукт вече ще се мери не по демото, а по това дали прави сложния работен процес по-кратък, по-наблюдаем и по-контролируем.
Полезни въпроси
Ще замени ли Codex app-server нуждата от собствен backend?
Не. Той е слой за управление на Codex задачи, събития, инструменти и одобрения. Приложението пак трябва да притежава своите данни, потребители, права, бизнес логика и интерфейс.
Подходящо ли е това за малки екипи?
Да, ако имат конкретен повтаряем процес: QA проверки, вътрешни DevOps задачи, support triage, security анализ или документация. Ако няма ясен процес, по-добре е първо да се започне с CLI или SDK експеримент.
Къде е най-големият риск?
В прекалено широките права и неясните човешки одобрения. Агентът трябва да има ясна зона на действие, лог на стъпките и видима граница преди промени с реални последици.
Източници: OpenAI Developers, open-source Codex в GitHub, OpenAI Codex open-source components.
