Codex Sites im Praxistest: Was KI-generierte interne Tools wirklich taugen

Das Backlog-Problem: Interne Tools, die nie gebaut werden

Jedes Unternehmen hat sie: die Liste der internen Tools, die dringend gebraucht werden, aber nie Priorität bekommen. Eine Urlaubsplanung für die Abteilung, ein Dashboard für offene Bestellungen, ein Genehmigungstool für Budgetanträge. Das Entwicklungsteam ist mit Kundenprojekten ausgelastet, und ein Spreadsheet muss genügen.

OpenAI hat dieses Problem am 2. Juni 2026 mit einem neuen Codex-Plugin namens Sites adressiert. Die Idee: Beschreiben Sie eine interne Anwendung in natürlicher Sprache, und die KI baut sie, hostet sie und stellt einen Link bereit. Kein Deployment, kein DevOps, kein Ticket im Backlog. 5 Millionen wöchentliche Codex-Nutzer, von denen die nichttechnischen Anwender schneller wachsen als die Entwickler, zeigen das Interesse an solchen Werkzeugen.

Was Codex Sites technisch leistet

Codex Sites ist ein Plugin für den Codex-Editor, das aus einer Textbeschreibung eine Webanwendung erzeugt. Die Architektur: Cloudflare-Worker-kompatible ES-Module auf OpenAI-Infrastruktur, mit D1-Datenbank für persistente Daten und R2-Objektspeicher für Dateien. Der Ablauf trennt Speichern von Deployen: Eine gespeicherte Version ist nicht live, erst der explizite Deploy macht sie für Workspace-Mitglieder erreichbar.

Ein Beispiel-Prompt aus der OpenAI-Dokumentation:

@Sites Baue ein Projekt-Request-Dashboard. Mitarbeiter sollen Anfragen einreichen, den Status einsehen und filtern können. Erfordere Workspace-Login und speichere die Daten zwischen Sessions.

Die Demo sieht überzeugend aus. Aber was passiert, wenn dieses Dashboard echte Geschäftszahlen verarbeitet?

Das Problem: KI-generierte Software ohne Qualitätskontrolle

Hier liegt der entscheidende Haken. Codex Sites generiert Code, den niemand reviewt. Es gibt keine automatisierten Tests, keine statische Code-Analyse, keine manuelle Prüfung der Geschäftslogik. Die Anwendung funktioniert auf den ersten Blick, aber niemand weiß, ob sie richtig rechnet.

Ein Beispiel aus der Praxis: Ein KPI-Dashboard, das Umsatzzahlen aggregiert. Der Prompt beschreibt die Logik in natürlicher Sprache, die KI interpretiert sie und generiert JavaScript. Aber interpretiert sie "Monatsumsatz" als Summe aller Transaktionen oder als Summe abzüglich Stornierungen? Zählt sie Teillieferungen separat oder als eine Position? Jede dieser impliziten Annahmen kann richtig oder falsch sein, und der nichttechnische Anwender, der den Prompt geschrieben hat, kann den generierten Code nicht validieren.

Die Konsequenz: Eine Führungskraft trifft eine Personalentscheidung auf Basis eines fehlerhaft berechneten Dashboards, und der Fehler fällt erst Wochen später auf, wenn die Quartalszahlen nicht zusammenpassen.

Acht Anwendungsfälle, acht Risikoprofile

Die Stärke von Codex Sites liegt in internen Anwendungen. Diese Anwendungsfälle nennt OpenAI selbst:

Das Muster ist klar: Sobald Zahlen aggregiert, berechnet oder als Entscheidungsgrundlage verwendet werden, wird das Risiko kritisch. Genau die Anwendungen, die den größten Geschäftswert versprechen, sind die riskantesten.

Sensible Daten: Die zweite unbeantwortete Frage

Codex Sites läuft auf OpenAI-Infrastruktur. Die Zugriffskontrolle beschränkt sich auf drei Modi: admins_only, workspace_all und custom. Was fehlt, ist eine rollenbasierte Berechtigungsstruktur, wie sie jedes mittlere ERP-System bietet.

Für Unternehmen in der EU stellt sich die DSGVO-Frage unmittelbar. Ein Schadensmeldungs-Tool für die Hausverwaltung verarbeitet personenbezogene Daten von Mietern: Namen, Adressen, Schadensbeschreibungen. Eine Datenschutz-Folgenabschätzung ist vorgeschrieben, sobald solche Daten verarbeitet werden. Auf welcher Infrastruktur laufen die D1-Datenbanken? In welchem Rechenzentrum? Mit welchem Auftragsverarbeitungsvertrag? OpenAI dokumentiert diese Fragen für Codex Sites nicht mit der Tiefe, die ein Datenschutzbeauftragter benötigt.

Die KI macht Fehler, und niemand merkt es

Der grundlegendste Einwand ist zugleich der einfachste: Große Sprachmodelle halluzinieren. Sie erfinden API-Endpunkte, die nicht existieren. Sie berechnen Summen falsch. Sie interpretieren Geschäftslogik kreativ statt korrekt.

Im Codex-Kontext bedeutet das: Die KI generiert eine Anwendung, die auf den ersten Blick funktioniert. Der Button ist da, die Tabelle lädt, die Filter reagieren. Aber stimmt die Filterlogik? Sortiert der Szenario-Planer nach dem richtigen Kriterium? Berechnet das KPI-Dashboard den gleitenden Durchschnitt über den korrekten Zeitraum? Diese Fragen beantwortet kein Prompt, sondern nur ein Code-Review, und genau das fehlt im Sites-Workflow.

OpenAI selbst signalisiert Vorsicht: Save vor Deploy, Review-Pane, Zugriff erst nach Prüfung. Aber was genau soll ein nichttechnischer Anwender reviewen? Den generierten Code? Das kann er nicht. Die Ausgabe? Die sieht korrekt aus, bis sie es nicht mehr ist.

Fazit: Eine beeindruckende Spielerei, noch nicht produktionsreif

Codex Sites ist technisch beeindruckend. Die Idee, interne Tools per Sprachbefehl zu erstellen, ist richtig und wird kommen. Aber in der aktuellen Preview-Phase ist das Werkzeug für den professionellen Einsatz nicht geeignet, sobald finanzielle Konsequenzen, personenbezogene Daten oder strategische Entscheidungen im Spiel sind.

Die Entwicklung erinnert an die frühen Tage von No-Code-Plattformen: Die Demos sehen fantastisch aus, die ersten Prototypen begeistern, aber der Sprung in die Produktion offenbart Lücken in Sicherheit, Korrektheit und Governance, die im Demo-Video nicht sichtbar sind.

Für centerbit ist die Lehre klar: Werkzeuge wie Codex Sites sind wertvoll als Prototyping-Umgebung und für unkritische interne Tools. Sobald eine Anwendung geschäftskritische Prozesse berührt, braucht sie das, was KI-generierter Code per Definition nicht mitbringt: einen nachvollziehbaren Qualitätsprozess, eine getestete Codebasis und eine Governance, die Fehler entdeckt, bevor sie zu Fehlentscheidungen führen.