"Vibe Coding macht Spaß, aber ist es sicher?" — Oracles Gegenentwurf zum LLM-Wildwest

"Vibe Coding macht Spaß, aber ist es sicher?" Die Zeile stammt aus Oracles Positionierung rund um APEX 26.1 und ist der meistzitierte Teil des Launches — teils, weil sie provokant ist, teils, weil sie sitzt. Der Begriff Vibe Coding hat sich eingebürgert für das Ausliefern von Code, den ein LLM mit minimalem Review produziert hat, unter der unausgesprochenen Annahme, dass das Modell schon meistens recht hat. Oracle sagt sanft, aber deutlich: Für Enterprise-Anwendungen ist diese Annahme nicht gut genug. Für regulierte DACH-Branchen ist das genau das Argument, auf das sie von einem großen Hersteller gewartet haben.

Was "kontrollierte KI-Generierung" in 26.1 wirklich bedeutet

Oracles Botschaft ist nicht "KI ist schlecht". Oracle liefert in 26.1 mehr KI-Fläche aus als in jedem früheren Release. Die Botschaft ist, dass KI-getriebene Generierung in APEX um einen bewussten Review-Checkpoint herum gebaut ist:

• Der APEX AI Application Generator erzeugt zunächst menschenlesbaren Pseudo-Code, nicht endgültige Anwendungsmetadaten.
• Entwickler reviewen und editieren diesen Pseudo-Code vor der Freigabe.
• Erst nach der Freigabe erzeugt APEX die tatsächlichen Anwendungsartefakte, ausgedrückt in APEXlang für die Versionskontrolle.

Der Kontrast besteht zu Workflows, in denen die KI ohne menschlichen Verständnisschritt direkt in eine Laufzeitumgebung ausliefert. Beide Workflows haben ihre Berechtigung. Oracle argumentiert: Für Enterprise-Anwendungen — die mit personenbezogenen Daten, regulierten Prozessen und namentlichen Verantwortlichen — ist der Verständnisschritt nicht optional.

Warum dieses Argument in DACH besonders zieht

Drei Kräfte treffen in deutschsprachigen Unternehmen zusammen, die das kontrollierte Modell ungewöhnlich attraktiv machen:

• Kodifizierte Compliance. DSGVO, NIS2, der EU AI Act, branchenspezifische Regulierung (BaFin für Finanzen, BSI für kritische Infrastruktur) setzen alle einen namentlich verantwortlichen Menschen für Systeme und Entscheidungen voraus. "Das Modell hat es geschrieben" ist keine tragfähige Audit-Antwort.
• Engineering-Kultur. DACH-Engineering-Teams tendieren zu review-lastigen, evidenz-lastigen Praktiken. Code Review ist Norm, nicht Anspruch. Ein Workflow, der Review umgeht, wirkt auf Senior Engineers unreif.
• Langsamere, aber tragfähigere Rollout-Normen. Mid-Market- und Enterprise-IT in DACH wählen typischerweise kleinere, sich endgültig anfühlende Entscheidungen. Ein Workflow, dessen einziges Sicherheitsnetz "das Modell hat meistens recht" lautet, passt nicht in dieses Risikoprofil.

Das sind keine KI-feindlichen Kulturmerkmale. Es sind Merkmale dazu, wie KI adoptiert wird. Das kontrollierte Modell passt zum bestehenden Entscheidungsrhythmus; das Vibe-Coding-Modell kämpft dagegen.

Das faire Gegenargument

Es lohnt sich, die andere Seite stark zu machen. Vibe Coding liefert echten Geschwindigkeitsgewinn. Für kleine Teams, die Greenfield-Consumer-Produkte ausliefern, ist "Modell fragen, Output ausliefern, schnell iterieren" ein legitimer Workflow. Die Kosten eines Bugs sind ein Hotfix; der Nutzen ist ein 5-facher Cycle-Time-Vorteil. Viele erfolgreiche Produkte 2026 sind so gebaut worden und hätten anders nicht gebaut werden können.

Der Streit geht nicht darum, ob KI-Generierung nützlich ist. Er geht darum, welche Review-Intensität welcher Kontext verlangt. Ein Consumer-Prototyp ist kein Zahlungssystem. Ein Consumer-Prototyp ist kein Krankenhaus-Aufnahmeformular. Ein Consumer-Prototyp ist kein regulierter Reporting-Workflow in einer Sparkasse. Derselbe Workflow bedient nicht alle drei.

Das richtige Review-Niveau ist eine Funktion der Kosten eines Fehlers. Enterprise-Anwendungen liegen oft am oberen Ende dieser Kostenkurve. Das kontrollierte Muster ist der natürliche Fit für dieses Ende.

Wie das kontrollierte Muster in Ihrer Woche aussieht

Konkret sieht die Adoption des Oracle-Modells in einem APEX-Team so aus:

1. Nutzen Sie KI für den ersten Entwurf. Lassen Sie das Modell Pseudo-Code für neue Screens, Regionen oder Prozesse vorschlagen. Hier ist die Geschwindigkeit echt.
2. Reviewen Sie den Pseudo-Code als normales Artefakt. Behandeln Sie ihn wie den ersten Entwurf eines Menschen — lesen, hinterfragen, editieren.
3. Promoten Sie zu APEXlang. Erzeugen Sie die endgültigen Artefakte, committen Sie auf Ihren Branch, pushen Sie.
4. Reviewen Sie den Diff. Die Diffbarkeit von APEXlang ist das, was den zweiten Review-Durchgang bedeutungsvoll macht.
5. Mergen Sie mit den üblichen Freigaben. Dieselben CI-Checks, dieselben Approval-Regeln, derselbe Audit Trail wie bei jeder anderen Änderung.

Die gesparte Gesamtzeit gegenüber dem Schreiben des Pseudo-Codes von Hand ist signifikant. Der zusätzliche Review-Aufwand gegenüber einem "vibe-coded" Merge ist ebenfalls signifikant. Das ist der Tausch.

Was das für Ihre KI-Policy bedeutet

Wenn Ihre Organisation noch keine interne Policy zu KI-generiertem Code hat, ist 26.1 ein guter Anlass, eine zu schreiben. Ein Startrahmen:

• Klassifizieren Sie Systeme nach Review-Intensität. Interne Tools, regulierte Systeme, kundenseitige Systeme und umsatzkritische Systeme sind nicht gleich.
• Koppeln Sie KI-Generierung an explizite Review-Schritte für alles oberhalb der untersten Stufe.
• Erfassen Sie den KI-Beitrag im Audit Trail. Die PR-Beschreibung soll sagen, was KI-entworfen und was menschlich editiert wurde.
• Reservieren Sie ungeprüfte KI-Generierung für Non-Production-Sandboxes. Prototypisieren Sie frei; promoten Sie bewusst.

Das längere Argument

Oracles Spitze gegen Vibe Coding ist keine Marketingzeile. Es ist eine Position zu einer realen Branchendebatte: Ist KI ein Werkzeug, das die Arbeit von Menschen beschleunigt, oder ein Werkzeug, das den menschlichen Verständnisschritt ganz ersetzt? APEX 26.1 entscheidet sich für die erste Antwort für Enterprise-Anwendungen und gibt Entwicklern das Werkzeug — APEXlang für Diffs, Pseudo-Code für Review, klar zugeschnittene KI-Tools für Agenten — um diese Entscheidung praxistauglich zu machen.

Für DACH-Unternehmen passt diese Entscheidung zur Art, wie Arbeit ohnehin freigegeben wird. Die Frage ist nicht, ob man KI in der APEX-Entwicklung einsetzt. Die Frage ist, ob man sie in der Form einsetzt, die zum bestehenden Accountability-Modell passt. 26.1 sagt: Baue mit KI, liefere wie ein Erwachsener aus.