← Referenční architektury / reference-architecture / diagrams / ai
Enterprise AI Vibe Coding Platform
Úvod
Vibe coding ↗ je postup vývoje softwaru, který k vytváření aplikací z popisu v přirozeném jazyce používá velké jazykové modely (LLM). Enterprise AI vibe coding platforma je interní nástroj, ve kterém zaměstnanci v přirozeném jazyce popíšou, co chtějí vytvořit, a platforma vygeneruje funkční kód, zobrazí živý náhled a publikuje jej, vše v prostředí, které má organizace pod kontrolou.
Díky tomu mohou interní nástroje, dashboardy i firemní aplikace vytvářet všichni zaměstnanci bez ohledu na to, zda mají zkušenosti s vývojem softwaru. Bez řízení ale u každé aplikace vytvořené pomocí AI hrozí nekontrolovaný únik dat, používání neschválených poskytovatelů LLM a kód s neznámou úrovní zabezpečení.
Tato referenční architektura navazuje na Platforma pro AI vibe coding s podnikovými kontrolními mechanismy pro identitu, ochranu dat, přiřazování nákladů, dohledatelnost a auditní protokolování. Základní architektura je postavena na platformě Cloudflare Developer Platform: AI Gateway pro správu LLM a ochranná opatření (guardrails), Sandbox pro spouštění kódu a Workers for Platforms pro nasazení a hosting. Tento dokument se zaměřuje na podnikovou vrstvu postavenou nad těmito primitivy.
Bezpečnostní model
Enterprise vibe coding platformy musí vycházet z toho, že kód generovaný AI je nedůvěryhodný. Bezpečnostní model proto vynucuje ochranu na úrovni platformy, ne na úrovni kódu.
- Spouštění nedůvěryhodného kódu: Kód generovaný AI může obsahovat chyby, zranitelnosti nebo neočekávané chování. Sandboxy a kontejnery jej izolují od produkčních systémů.
- Exfiltrace dat prostřednictvím promptů: Zaměstnanci mohou do promptů neúmyslně zahrnout citlivá data. AI Gateway a DLP je zkontrolují a případně zablokují dřív, než se dostanou k poskytovatelům LLM.
- Prompt injection: Škodlivé prompty se mohou pokusit přimět AI ke generování škodlivého kódu. Všechny interakce se zaznamenávají a lze je auditovat.
- Únik přihlašovacích údajů: Kód generovaný AI nikdy nepracuje se skutečnými tajnými klíči. Přihlašovací údaje vkládají do vrstvy platformy outbound handlery nebo outbound workery.
- Eskalace oprávnění: Chybně nakonfigurované připojovací řetězce nebo síťový přístup by mohly umožnit neoprávněný přístup k prostředkům vyšší úrovně. Model vazeb (binding) vynucuje připojení založené na seznamu povolených položek.
- Neoprávněný přístup: Bez kontroly identity by k nasazeným aplikacím mohl přistupovat kdokoli v organizaci. Cloudflare Access proto vynucuje zásady založené na rolích jak na úrovni platformy, tak u nasazených aplikací.
Základní architektura
Podniková platforma pro vibe coding se skládá ze tří systémů, v nichž lze podle potřeby vrstvit nebo rozšiřovat stávající firemní kontrolní mechanismy:
- Vývojová rovina: Zde zaměstnanci pomocí AI vytvářejí aplikace a postupně je vylepšují, s řízeným přístupem k LLM a podnikovým datům.
- Nasazovací pipeline: Proces schvalování a validace, který posouvá aplikaci z vývoje do produkce, včetně bezpečnostních kontrol, kontroly závislostí a v případě potřeby i kontroly s lidským zásahem.
- Produkční rovina: Zde běží schválené aplikace v izolovaných, multitenantních prostředích s plnou observabilitou, kontrolou odchozího provozu a zásadami přístupu.
Observabilita, dohledatelnost a kontrola nákladů by měly být součástí všech tří komponent. Značkování prostředků uplatňovaná v celém životním cyklu poskytuje přehled a umožňuje administrátorům platformy sledovat a spravovat všechny aplikace, uživatele a prostředky na jednom místě.
Vývojová rovina
Cloudflare Access chrání vstupní bod do platformy, ať už jde o webové uživatelské rozhraní, nebo ověřený přístup ke kódovacímu prostředí přes CLI. Access se integruje se stávajícími poskytovateli identity (Okta, Azure AD, Google Workspace) prostřednictvím SAML a OIDC, takže organizace mohou využívat své stávající SSO.
Platforma ukládá metadata, jako jsou profily uživatelů, relace, nákladové štítky a oprávnění oddělení a týmů, do datového úložiště, jako je D1 pro strukturované dotazy, KV pro rychlé vyhledávání typu klíč-hodnota, nebo R2 pro objektové úložiště. Frontend nebo tok agenta tato metadata dotazuje, aby určil oprávnění a sledoval využití.
Vývojový proces podporuje dva postupy. V prostředí založeném na prohlížeči zaměstnanci pracují přes webové UI, které orchestruje agenty na straně serveru. Kód generovaný AI se spouští v jednom ze dvou izolačních modelů podle typu zátěže. Sandboxované kontejnery poskytují kompletní vývojové prostředí s náhledovými URL adresami, vhodné pro aplikace, které potřebují plnohodnotné běhové prostředí se závislostmi. Dynamic Workers poskytují odlehčené, okamžité vyhodnocení kódu bez režie kontejnerů, vhodné pro rychlou iteraci u menších skriptů a funkcí. Vývojová služba může použít kteroukoli z těchto možností samostatně nebo je zkombinovat, přičemž Dynamic Workers využije pro rychlé ověření kódu a kontejnery pro úplné náhledy aplikací.
S lokálním agentním rámcem vývojáři používají nástroje založené na CLI, jako Cursor, Windsurf nebo OpenCode, integrované do svého stávajícího IDE a workflow v terminálu. Kód se iteruje lokálně na počítači vývojáře. Jakmile je připravený, vývojář ho nahraje do Cloudflare, kde se spustí v izolovaném kontejneru nebo Dynamic Workeru pro účely náhledu a staging prostředí. portály serveru MCP a AI Gateway lze integrovat do místních vývojářských postupů, což poskytuje přehled o využití nástrojů, protokolování promptů a sledování nákladů ještě předtím, než se kód dostane na platformu.
Všechny interakce s LLM jsou sledovány a řízeny prostřednictvím AI Gateway, což zajišťuje směrování mezi poskytovateli, kontrolu nákladů, protokolování promptů a Kontrola DLP. Sledování nákladů přiřazuje využití k projektům, týmům, oddělením a jednotlivým uživatelům.
Veškerý odchozí provoz z vývojového prostředí je řízen na úrovni platformy. U kontejnerů outbound handler zachytává provoz HTTP. U Dynamic Workers řízení odchozího provozu poskytuje ekvivalentní možnosti. Tajné klíče potřebné pro navazující připojení se ukládají do Secrets Store a vkládá je obslužná rutina pro odchozí provoz na úrovni platformy. Sandboxované prostředí nemá k přihlašovacím údajům nikdy přímý přístup. Díky této obslužné rutině mohou správci platformy povolovat nebo zakazovat konkrétní cílové origin servery, přesměrovávat provoz, uplatňovat vlastní zásady na odchozí provoz nebo se připojovat k dalším prostředkům Cloudflare prostřednictvím vazby. Pro přístup k on-premises nebo interním systémům Workers VPC vytváří soukromé připojení, aniž by tyto systémy vystavovala internetu.
Do vývojového kontejneru lze díky uzamčení verzí balíčků a organizačním kontrolám zabudovaným do image kontejneru vrstevně doplnit další bezpečnostní prvky. Pokud harness využívá servery MCP, portály MCP poskytují protokolování auditu volání nástrojů, správu oprávnění pro přístup k nástrojům a přehled o tom, které nástroje agenti používají a k jakým datům přistupují.
Nasazovací pipeline
Assety vytvořené ve vývojové rovině lze ukládat do stávajících podnikových repozitářů kódu nebo do Artefakty, úložiště kompatibilní s gitem od Cloudflare vytvořené pro agenty. Týmy mohou začlenit výstup vytvořený pomocí vibe codingu do stávajících procesů revize kódu, aby se před nasazením aplikace do produkčního prostředí zajistilo dodržení osvědčených postupů a vývojových kontrol.
Platforma se integruje se stávajícími podnikovými procesy vývoje softwaru. Spolu s nativními službami Cloudflare lze používat repozitáře Git, úložiště tajných klíčů i pipeline CI/CD.
Produkční rovina
Nasazené aplikace jsou hostované na Workers for Platforms. Cloudflare Access ověřuje a zabezpečuje přístup zaměstnanců nebo třetích stran k celé vlastní doméně a řídí přístup k nasazeným aplikacím prostřednictvím dispatch worker. Na úrovni dispatch workeru lze uplatnit podrobné řízení přístupu, které zajistí, že přístup uživatele odpovídá řízení přístupu na základě rolí a přiděleným oprávněním.
Workers for Platforms hostují aplikaci vytvořenou pomocí vibe codingu, přičemž outbound worker a řídí veškerý odchozí provoz. Tajné klíče jsou uloženy v Secrets Store a vkládá je outbound worker, díky čemuž uživatelské workery nikdy nepracují s přihlašovacími údaji přímo. Outbound worker zároveň řídí navazující přístup: vazby, externí rozhraní API, Hyperdrive pro stávající databáze, nebo Workers VPC hodnotou Cloudflare Tunnel k navázání konektivity k lokálním (on-premises) nebo existujícím interním systémům.
Každý uživatelský worker má přístup k sadě vazby k poskytování úložiště a služeb každé aplikaci vytvořené pomocí vibe codingu. Pro úplnou izolaci jednotlivých tenantů platforma pro každou aplikaci vytváří a připojuje unikátní databázi D1, KV namespace nebo R2 bucket. Každý User Worker má přístup pouze k bindingům, které jsou k němu výslovně připojeny.
Dispatch worker může nastavit vlastní limity na jedno volání, čímž omezuje maximální dobu zpracování i počet dílčích požadavků, aby zneužití nebo neúmyslné smyčky nespotřebovávaly nadměrné množství prostředků. Platforma může přiřazovat různé limity podle úrovně uživatele, týmu nebo klasifikace aplikace. Pokud je limit překročen, uživatelský worker vyvolá výjimku, kterou může dispatch worker zpracovat a zaznamenat.
Observabilita funguje na dvou úrovních. Na úrovni platformy, Workers Trace Events Logpush povolená na dispatch workeru se vztahuje na všechny uživatelské workery v daném namespace. GraphQL Analytics API dotazy prostřednictvím dispatchNamespaceName pro souhrnné metriky napříč celou platformou. Na úrovni aplikace Tail Workers lze připojit k jednotlivým uživatelským workerům pro podrobné protokolování. Workers Analytics Engine umožňuje platformě zapisovat a dotazovat se na události podle script tagu, a zobrazovat tak jednotlivým uživatelům metriky využití pro každou aplikaci.
S rostoucím počtem aplikací vytvořených pomocí vibe codingu slouží úložiště metadat platformy jako registr aplikací, který pro každé nasazení zobrazuje vlastníka, tým, popis, připojené datové zdroje a metriky využití. Stejně jako u vývojové vrstvy lze tato metadata ukládat do libovolného preferovaného úložiště dat, například D1, KV, nebo R2. Díky tomu zaměstnanci najdou existující nástroje dřív, než začnou duplicitně vyvíjet vlastní. Značkování prostředků použité na podkladové prostředky Cloudflare propojuje každý uživatelský worker zpět s jeho vlastníkem a s přiřazením nákladů.