OpenAI Codex steht heute für Coding-Workflows rund um CLI, Cloud-Aufgaben und IDE-Integration. Die konkreten Modelle und Produktnamen ändern sich schnell. Codex ist nicht zu verwechseln mit dem alten Codex-Modell von 2021 oder mit ChatGPT Code Interpreter (Advanced Data Analysis). Für autonome Code-Aufgaben über mehrere Dateien hinweg, Bugfixes und Pull-Request-Vorschläge kann das sehr nützlich sein.
Was Codex in einer Stunde generiert, lässt sich nicht einfach so in den produktiven Betrieb nehmen. Der Output ist häufig skriptlastig (FastAPI, Express, Bash), und Sandbox-Annahmen verstecken Annahmen über Datei- und Netzwerk-Zugriff. Sicherheitsstudien zu KI-generierten Pull Requests zeigen zudem ein erhöhtes Risiko für Logik- und Authorization-Fehler, die statische Scanner nicht zuverlässig finden.
Das bringen wir in Ordnung. In vier bis acht Wochen. Mit ehrlicher Einschätzung, klarem Plan und ohne versteckte Kosten.
Codex ist gut darin, autonom über mehrere Dateien hinweg Code zu erzeugen. Die Stärken:
AGENTS.md — saubere Stelle für Coding-Standards, Test-Befehle, Sicherheits-Hinweise.Wo Codex an Grenzen stösst:
workspace-write ohne Netzwerk. Generated Code unterstellt deshalb häufig lokale SQLite, lokale Dateien, lokale Mocks. Auf Cloud Run, Vercel oder AWS bricht das.Codex generiert Code, der in der lokalen Sandbox läuft: SQLite-Datei im Projektordner, lokal gemountete Volumes, hard-codierte Pfade wie ./data/, lokale .env-Dateien. Auf Cloud Run, Vercel oder Render bricht das beim ersten Cold-Start. Folge: Deploy läuft durch, App startet, beim ersten echten Request — 500.
Codex nimmt FastAPI-Users, NextAuth oder Passport in der einfachsten Variante. Sessions im Memory, JWT-Secrets im Code, kein RBAC, kein Refresh-Token-Handling, keine Mehrkundenfähigkeit. Folge: Erster Pen-Test deckt Privilege-Escalation auf, Multi-Tenancy ist ohne Datenbank-Re-Architektur nicht möglich.
Codex schreibt gerne synchrone Endpoints. Stripe-Webhooks, asynchrone Aufgaben, Retry-Logik bei Fehlschlägen, idempotente Verarbeitung — all das wird nur generiert, wenn explizit angefordert, und dann meist ohne Dead-Letter-Queue. Folge: Doppelte Charges, verlorene Events, fehlerhafte Rechnungen.
In agentischen Phasen können falsche Dependency-Annahmen entstehen. package.json nennt dann Pakete, die es so nicht gibt, oder Versionen mit bekannten CVEs. Lockfile widerspricht der Manifest-Datei. Folge: Build im CI-Server schlägt fehl, oder schlimmer — er läuft mit einer angreifbaren Version durch.
Codex liefert häufig console.log oder print(), aber selten von selbst strukturierte Logs, Tracing oder Error-Monitoring. Im Produktiv-Betrieb merkst du Probleme sonst erst, wenn Kunden anrufen. Bei verteilten Tasks fehlt oft jedes Tracing über Service-Grenzen.
Was Codex hinterlässt, ist AGENTS.md plus inline-Kommentare. Eine Architektur-Dokumentation, ein API-Contract, ein Onboarding-Playbook für neue Entwickler — fehlt. Folge: Wartungskosten steigen, sobald die zweite Person ins Team kommt, und du verlierst die Geschwindigkeit, wegen der du Codex überhaupt eingesetzt hast.
Dauer: 4 bis 6 Wochen.
Dauer: 8 bis 16 Wochen.
Schriftlicher Bericht, Risiko-Übersicht, Härtungs-Plan inklusive Sandbox-Annahmen-Sweep und Dependency-Audit. 1 bis 2 Wochen.
Für Codex-Prototypen mit klarer Grundstruktur. 4 bis 6 Wochen. Sicherheit, Skalierung, Bezahlung, Mehrkundenfähigkeit.
Für grössere Codex-Projekte mit vielen Anbindungen, MCP-Tools und Subagent-Architektur. 6 bis 8 Wochen.
Wenn zu viel von Grund auf neu gebaut werden muss. 8 bis 16 Wochen.
Wir managen Infrastruktur, Wartung, Sicherheit, Updates und Skalierung. Der Kunde kann weiter vibecoden und neue Features erfinden; wir prüfen, härten und mergen sie kontrolliert über klare Regeln und eine saubere Pipeline in den produktiven Betrieb. Die monatlichen Kosten wachsen mit Nutzung und Anspruch, damit der Start auch mit wenigen Usern tragbar bleibt.
Wir reden vom heutigen Codex-Ökosystem: Codex CLI im Terminal, Codex Cloud bzw. browserbasierte Aufgaben, IDE-Integrationen und ähnliche OpenAI-Coding-Workflows. Die konkreten Modelle und Produktnamen ändern sich schnell; im Audit prüfen wir deshalb dein tatsächliches Setup statt nur den Namen. Das alte OpenAI-Codex-Modell aus 2021 ist damit nicht gemeint.
Selten direkt. Codex generiert Code, der in seiner Sandbox läuft. Cloud-Run, Vercel oder AWS haben andere Spielregeln: kein Schreibrecht im Container-Filesystem nach dem Build, keine lokalen SQLite-Dateien als persistenter Store, andere Netzwerk-Topologie. Wir lokalisieren die Sandbox-Annahmen, ersetzen sie durch produktionsfähige Pendants (Postgres, Object-Storage, Secret-Manager) und bringen den Code damit echt deployfähig.
Wenn du es nicht aktiv vorgegeben hast, sehen wir häufig Python (FastAPI, Flask) oder TypeScript/Node (Express, Next.js). Bash-Scripts kommen für Glue-Code dazu. Codex ist nicht festgelegt; Rust, Go und Java sind ebenfalls möglich. Die Qualität hängt stark von Prompt, Kontext und Review-Prozess ab.
Häufiger Fall, gerade wenn der Prompt iterativ war (’Mach mir ein Script, das X tut. Jetzt eines für Y. Jetzt eines für Z.’). Wir prüfen, ob die Skripte gemeinsame Geschäftslogik haben, und konsolidieren sie zu einem sauberen Service. Manchmal lohnt sich das, manchmal ist Neuaufbau schneller. Das sagen wir dir nach der kostenlosen Code-Analyse ehrlich.
Codex ist ein Werkzeug, kein Provider — du hast keinen Service-Vertrag mit OpenAI für deinen App-Code. Was Codex generiert hat, gehört dir. Im Betrieb läuft dein Code auf unserer cloud-nativen Infrastruktur, je nach Compliance in Zürich oder in Europa. Du kannst auch nach dem Live-Gang weiter mit Codex an Features arbeiten, und wir prüfen und mergen sie kontrolliert in den produktiven Stand.
Wir machen einen systematischen Sweep: lokale Dateipfade, lokale SQLite-DBs, lokale Mocks, hard-codierte Endpoints. Jede Stelle wird identifiziert und durch ein produktionsfähiges Äquivalent ersetzt — Cloud-Storage statt Filesystem, Postgres statt SQLite, Secret-Manager statt .env-Dateien, gerichtete Service-Calls statt Localhost. Anschliessend testen wir den Cloud-Lauf gegen den Sandbox-Lauf, damit nichts unbemerkt davonläuft.
Wir prüfen package.json und requirements.txt (oder Cargo.toml, go.mod) gegen reale Registry-Stände. Halluzinierte oder CVE-belastete Versionen werden ersetzt, das Lockfile wird konsistent neu erzeugt. Im CI bauen wir einen Dependency-Scan ein, damit der Fehler nicht wiederkommt. Renovate oder Dependabot übernimmt danach das laufende Patching.
Wir sind von Anfang an für dich da. Uns ist wichtig, dass ihr mit eurer Software- oder SaaS-Lösung langfristig erfolgreich seid, weil beide Seiten davon profitieren: du bekommst ein stabiles Produkt, wir gewinnen eine starke langfristige Partnerschaft. Deshalb ist uns der laufende Betrieb besonders wichtig. Unsere Begleitung ist optional, sorgt aber dafür, dass Infrastruktur, Wartung, Sicherheit, Updates und Skalierung zu deinen aktuellen Nutzerzahlen und Kosten passen.
Schick uns deinen Code (Git-Repo, .zip, Live-Link oder direkt deine Codex-Cloud-Branch). Wir analysieren ihn kostenlos, schicken dir einen schriftlichen Bericht und einen klaren Plan für die Härtung.