OpenAI ehitas sisemiste rakenduste hostingu otse Codexisse
OpenAI lisas Codexisse funktsiooni Sites: nüüd saab koodiagent mitte ainult rakenduse kirjutada, vaid ka selle avaldamiseks ette valmistada, versiooni salvestada, deploy’da ja tagastada lingi majutatud saidile. OpenAI kirjeldab dokumentatsioonis Sitesi kui pluginat saitidele, veebirakendustele ja mängudele, mida hostitakse OpenAI-s ilma eraldi deploy-protsessi seadistamiseta.
See on Codexi rollis oluline nihe. Ta meenutab üha vähem IDE kõrval olevat abilist ja üha rohkem töökeskkonda, kus tiim palub: “ehita sisemine tööriist”, ning agent läbib tee koodist töötava lingini. Kuid praegu ei ole see “uus Lovable kõigile”: Sites on preview’s ja saadaval ChatGPT Businessi ning Enterprise’i jaoks.
Mida Sites täpselt oskab
Põhistsenaarium on lihtne. Kasutaja kirjeldab thread’is saiti või rakendust, kutsub vajaduse korral selgelt @Sitesi, palub Codexil buildi kontrollida ja valib seejärel: salvestada versioon ülevaatuseks või deploy’da juba kinnitatud versioon. Pärast edukat deploy’d tagastab Codex töötava URL-i.
OpenAI rõhutab eraldi: iga Sitesi deploy-link on töötav avaldamine. Kui tiim tahab tulemust esmalt vaadata, tuleb paluda Codexil versioon salvestada ilma avaldamiseta. See on väike detail, kuid sisemiste rakenduste jaoks kriitiline: agent võib ülesande kiiresti lingini viia, seega peab revjuuprotsess olema sama selge kui buildi kiirus.
Dokumentatsiooni näited keerlevad praktiliste sisemiste ülesannete ümber: operatsioonitiimi dashboard, omanike ja staatustega taotluste loend, andmete säilitamine külastuste vahel, mängude edetabelid, avataride ja failide üleslaadimine. Fookus ei ole seega landing page’il landing page’i pärast, vaid tiimirutiini muutmisel väikeseks elavaks rakenduseks.
Andmed, failid ja ligipääs
Sites toetab püsivaid andmeid ja üleslaadimisi. Struktureeritud kirjete jaoks viitab OpenAI D1-le ehk relatsioonilisele andmebaasile, failide jaoks R2 object storage’ile. Projekti konfiguratsioonis hoitakse hostingu seost failis .openai/hosting.json, kus võivad olla project_id ja storage binding’ute nimed.
Cloudflare’iga tuleb siin olla täpne. Allikas ütleb otse, et Sites majutab projekte, mis ehitatakse Cloudflare Workersiga ühilduvateks ES-mooduliteks, ning nimetab D1 ja R2. Kuid selle lehe põhjal ei saa kindlalt väita rohkemat: näiteks et kogu toode töötab täielikult nagu tavaline Cloudflare’i projekt või et kasutaja juhib taristut samamoodi nagu Cloudflare’i kontol. Lugeja praktiline järeldus on lihtsam: rakendus peab ehituma ühilduvasse formaati ja agent viib selle ise läbi OpenAI hallatud hostingu kihi.
Ligipääs tuleks vaikimisi hoida kitsas: omanik ja administraatorid. Hiljem saab Sites avada rakenduse kogu workspace’ile või valitud kasutajate ja gruppide komplektile. Sisemiste tööriistade jaoks on see õige loogika: kõigepealt kontrollida sisu, andmeid ja publikut, seejärel ligipääsu laiendada.
Miks see tiimidele tähtis on
Sites sulgeb ebamugava vahe “agent kirjutas kasuliku prototüübi” ja “nüüd peab keegi hostingu, andmebaasi, saladused ja õigused üles tõstma” vahel. Paljude sisemiste rakenduste jaoks tapab projekti just see vahe: kood on juba olemas, kuid tee kasutatava lingini on liiga igav ja killustunud.
Nüüd proovib OpenAI selle tee Codexi thread’i sisse ehitada. Tiim saab paluda mitte ainult koodi, vaid tulemust, mida saab kasutada: onboarding’u dashboard’i, teadmistebaasi, lihtsat vormi, aruandeekraani või kerget töövoo rakendust. See teeb Codexist konkurendi mitte ainult programmeerimistööriistadele, vaid ka no-code/low-code keskkondadele sisemiste ülesannete jaoks.
Piirangud on samuti selged. Enne deploy’d soovitab OpenAI kontrollida koodimuudatusi, andmebaasimigratsioone, buildi, valitud salvestatud versiooni, publikut ja keskkonnasaladusi. Teisisõnu kiirendab Sites tarnimist, kuid ei võta vastutust andmete ja ligipääsu eest ära. Selle funktsiooni kõige tervem roll on praegu kiired sisemised rakendused workspace’i kontrolli all, mitte avalikud tooted ilma korraliku revjuuta.
