NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Gießform mit Schriftzug SCHEMA formt KI Code zu sauberem Bauteil

Schema Based AI Coding: Definition

Schema Based AI Coding bedeutet, dass ein maschinenlesbares Schema den Vertrag definiert, gegen den ein KI Agent Code schreibt. Das Schema wird nicht gelesen, sondern ausgeführt: Weicht der generierte Code davon ab, bricht der Build, statt dass ein Mensch den Fehler im Review finden muss.
Ein Schema ist dabei jede formale Struktur, die eine Maschine prüfen kann. Ein Zod Objekt im TypeScript Projekt. Ein JSON Schema für einen Tool Call. Eine OpenAPI Datei für eine Schnittstelle. Ein Doctrine Entity mit Constraints. Eine Datenbank Migration mit NOT NULL. Alle haben dieselbe Eigenschaft: Sie sind eindeutig, sie sind versioniert, und sie sagen sofort Nein.
Der Unterschied zur klassischen Entwicklung liegt im Empfänger. Früher war ein Schema Dokumentation für Menschen und Schutz vor kaputten Daten. Heute ist es zusätzlich die Leitplanke für einen Agenten, der in Sekunden hunderte Zeilen produziert und dabei keine Ahnung hat, was das Team letzte Woche entschieden hat.

Inhalt

Schema Based AI Coding mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet seit über 20 Jahren mit typisierten Verträgen, lange bevor KI Agenten Code geschrieben haben. PHPStan auf hohem Level, Psalm, Doctrine Constraints und Rector im Symfony Backend. Zod und Drizzle in Astro Projekten. Cypress mit Cypress Cloud für End to End Tests. Diese Werkzeuge waren immer schon Qualitätssicherung. Mit KI Agenten werden sie zur wichtigsten Steuerungsebene, weil sie das Einzige sind, was ein Modell nicht wegdiskutieren kann.
Konkret unterstützen wir Teams bei Quality Gates für KI Code, beim Aufbau einer Schema First Architektur mit Zod 4 in TypeScript Projekten, bei der Strukturierung von rules.md und AGENTS.md, bei Code Qualität mit KI Agenten und im gesamten Vibe Coding Consulting vom Prototyp bis zur Produktion.

Schema Based AI Coding im eigenen Projekt verankern

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum Prompts und Specs allein nicht reichen

Ein Prompt ist eine Bitte. Eine Spezifikation ist ein Text. Beide sind Sprache, und Sprache lässt sich unterschiedlich lesen. Genau das ist das Problem: Zwei identische Prompts erzeugen zwei verschiedene Implementierungen, und niemand merkt es, solange beide durchlaufen.
Spec Driven Development hat darauf eine gute Antwort gefunden. Anforderungen wandern aus dem Chat in versionierte Markdown Dateien, die der Agent bei jedem Lauf mitliest. Tools wie OpenSpec und das GSD Framework machen das sauber. Aber eine Spec bleibt Prosa. Sie kann veralten, ohne dass etwas rot wird.
Der Unterschied in einem Satz: Eine Spec driftet still, ein Schema bricht den Build. Wenn ein Agent ein Feld umbenennt, merkt die Markdown Datei nichts davon. Der TypeScript Compiler, PHPStan und der Datenbank Constraint merken es sofort.
Deshalb ersetzt Schema Based AI Coding Spec Driven Development nicht. Es setzt eine Ebene darunter an. Die Spec beschreibt, was gebaut werden soll. Das Schema erzwingt, dass das Gebaute noch dazu passt, auch nach der zwölften Iteration und nach dem Modellwechsel.

Ebene 1: Das Schema als Vertrag für die Modellausgabe

Die erste Ebene betrifft das, was direkt aus dem Modell kommt. Freier Text ist für eine Pipeline wertlos. Sobald ein Agent Ergebnisse an ein anderes System weitergibt, an eine CI, ein Ticket System oder eine Datenbank, braucht die Ausgabe eine feste Form.
Alle großen Anbieter unterstützen dafür Structured Outputs auf Basis von JSON Schema. Das Modell darf beim Generieren nur noch Token wählen, die zum Schema passen. Aus einem hoffentlich gültigen JSON wird ein garantiert gültiges JSON. Dasselbe Prinzip trägt jeden Tool Call und jeden MCP Server: Jeder Parameter ist typisiert, bevor der erste Token fließt.
Code: 
          
{
  "name": "create_ticket",
  "input_schema": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "maxLength": 120 },
      "severity": { "enum": ["low", "medium", "high"] },
      "component": { "type": "string" }
    },
    "required": ["title", "severity"],
    "additionalProperties": false
  }
}
Entscheidend ist die letzte Zeile. additionalProperties auf false bedeutet: erfundene Felder fliegen raus, statt still mitzureisen. Wer eigene MCP Server betreibt, sollte das Schema bewusst klein halten, weil jedes Feld Kontext kostet. Wie viel das ausmacht, zeigen wir in MCP Responses optimieren.

Ebene 2: Das Schema als Leitplanke im Code

Die zweite Ebene ist die wichtigste für den Alltag. Hier steht das Schema im Repository und der Agent muss sich daran vorbeiarbeiten, um Unsinn zu bauen. Genau das gelingt ihm nicht, wenn die Werkzeuge scharf gestellt sind.
Ein Schema wirkt an drei Stellen: an der Systemgrenze, wenn fremde Daten hereinkommen. Im Typsystem, wenn Funktionen miteinander reden. Und in der statischen Analyse, wenn der Agent eine Annahme trifft, die nicht trägt.
Code: 
          
import { z } from 'zod';

export const InvoiceSchema = z.object({
  number: z.string().regex(/^RE-\d{6}$/),
  netAmount: z.number().positive(),
  taxRate: z.union([z.literal(7), z.literal(19)]),
  issuedAt: z.coerce.date(),
});

export type Invoice = z.infer<typeof InvoiceSchema>;
Ein Agent, der gegen dieses Schema arbeitet, kann keinen Steuersatz von 20 Prozent erfinden und keine Rechnungsnummer im falschen Format erzeugen. Der Typ wird aus dem Schema abgeleitet, nicht daneben gepflegt. Damit gibt es genau eine Wahrheit, und die steht im Code. Mehr zu den Feinheiten in unserem Beitrag zu Zod 4 und TypeScript Schema Validation.

Ebene 3: Das Schema als letzte Verteidigungslinie in den Daten

Die dritte Ebene ist die unbestechlichste. Eine Datenbank diskutiert nicht. NOT NULL, UNIQUE, Foreign Keys und Check Constraints wirken auch dann noch, wenn Validierung im Code vergessen wurde und der Agent einen Umweg gefunden hat.
Viele KI generierte Projekte lassen genau diese Ebene weg. Die Migration entsteht nebenbei, alle Spalten sind nullable, Beziehungen existieren nur in der Anwendungslogik. Das läuft, bis der erste inkonsistente Datensatz auftaucht und niemand mehr sagen kann, welcher Lauf ihn geschrieben hat. Wie daraus ein Kartenhaus wird, beschreiben wir in Technische Schulden durch Vibe Coding.
Ein sauberes Datenbank Schema hat noch einen zweiten Nutzen, der beim KI Einsatz oft übersehen wird: Aus ihm lassen sich realistische Testdaten erzeugen. Wer mit Faker generierten Testdaten arbeitet, kann jedes Coding Modell gegen eine lokale Entwicklungsumgebung laufen lassen, ohne echte Kundendaten anzufassen.
Das ist bei NCA kein Nebensatz, sondern das Leitmotiv: Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk. Große Coding Modelle laufen nicht auf Kundenhardware. Sie arbeiten gegen lokale Entwicklungsumgebungen mit Fake Daten. Das Schema ist der Bauplan, aus dem diese Fake Daten entstehen. Für gehostete Inferenz in Europa nutzen wir TensorX, für Infrastruktur und Hosting arbeiten wir mit Conversis aus Duisburg zusammen.

Schema Based AI Coding in PHP und Symfony

PHP hat für dieses Vorgehen einen Vorteil, den viele unterschätzen: Das Ökosystem ist voll von Werkzeugen, die Verträge maschinell prüfen. Symfony Validator Constraints an der Grenze. Doctrine Mapping für die Persistenz. PHPStan und Psalm für die statische Analyse. Rector für automatisiertes Refactoring, wenn sich ein Vertrag ändert.
Code: 
          
final class Invoice
{
    public function __construct(
        #[Assert\Regex('/^RE-\d{6}$/')]
        public readonly string $number,

        #[Assert\Positive]
        public readonly int $netAmountCents,

        #[Assert\Choice([7, 19])]
        public readonly int $taxRate,
    ) {
    }
}
Ein Agent, der dieses Objekt erweitern soll, hat sehr wenig Spielraum. readonly verhindert nachträgliche Mutation. Die Constraints stehen direkt am Feld und werden vom Modell mitgelesen. PHPStan meldet jeden Aufruf, der nicht passt. Das ist Guardrail Engineering, nicht Code Review.
Für Schnittstellen empfehlen wir den API First Weg: Erst die OpenAPI Definition, dann der Controller. Der Agent generiert gegen ein Dokument, das Client und Server gleichzeitig bindet. Ändert sich die Definition, laufen beide Seiten in denselben roten Test. Wie wir solche Regeln durchsetzen, steht in Quality Gates für KI Code.

Schema Based AI Coding in Astro und TypeScript

Im Frontend liegt der Hebel noch etwas höher, weil dort ein einziges Schema mehrere Schichten gleichzeitig absichert. In unseren Astro Projekten definieren wir das Datenmodell mit Drizzle, die Eingaben mit Zod und die Inhalte über Content Collections. Aus jeder dieser Definitionen fällt ein TypeScript Typ heraus.
Code: 
          
import { defineCollection, z } from 'astro:content';

const glossar = defineCollection({
  schema: z.object({
    title: z.string().max(70),
    updated: z.coerce.date(),
    tags: z.array(z.string()).min(1),
  }),
});

export const collections = { glossar };
Vergisst ein Agent das Feld updated in einer neuen Datei, schlägt der Build fehl. Nicht die Live Seite, nicht der Nutzer, sondern der Build. Genau das ist der Punkt: Der Fehler wird billig, weil er früh auftaucht.
Für die Datenbank Ebene arbeiten wir mit SQLite und libSQL sowie Drizzle als Query Layer. Schema und Migration liegen im selben Repository wie der Code, den der Agent verändert. Damit sieht das Modell den Vertrag und die Implementierung in einem Kontext. Wie stark der Kontext die Ergebnisqualität bestimmt, zeigt Context Window Management.

Die vier Reifegrade von Schema Based AI Coding

Kein Team springt von null auf eine durchgängige Schema Architektur. In der Praxis sehen wir vier Stufen, und die meisten Projekte stecken zwischen der ersten und der zweiten fest. Der Sprung, der wirklich etwas ändert, ist der auf Stufe drei: Ab dort ist das Schema die Quelle, aus der Typen und Validierung entstehen, statt eine dritte Stelle, die auch noch gepflegt werden muss.
Die folgende Tabelle ordnet die Stufen ein. Entscheidend ist die rechte Spalte: Was passiert konkret, wenn der Agent danebenliegt, und wie früh merkt es jemand.

Reifegrade im Überblick

Stufe Werkzeuge Was den Fehler stoppt
Prompt Chat, freie Prompts, Notizen im Ticket Nichts. Der Fehler fällt im Review oder in Production auf
Validierung Einzelne Checks im Controller, manuelle Prüfungen Der Laufzeitfehler beim Nutzer, nicht der Build
Schema First Zod, JSON Schema, OpenAPI, Symfony Constraints, PHPStan Compiler und statische Analyse in der CI, vor dem Merge
Generiert Typen, Clients, Migrationen und Fake Daten aus einem Schema Der Build der abhängigen Artefakte, sofort beim Schemawechsel
Aufsteigendes Säulendiagramm der vier Schema Reifegrade Prompt, Validierung, Schema First und Generiert. Inhalt steht textuell in der Tabelle darüber.

Spec Driven Development und Schema Based AI Coding im Vergleich

Beide Ansätze verfolgen dasselbe Ziel und arbeiten auf verschiedenen Ebenen. Wer sie gegeneinander ausspielt, verliert. Wer sie kombiniert, bekommt Absicht und Durchsetzung. Die Tabelle zeigt, wo der jeweilige Hebel liegt.

Zwei Ebenen derselben Idee

Kriterium Spec Driven Development Schema Based AI Coding
Artefakt Markdown, Prosa, Akzeptanzkriterien Zod, JSON Schema, OpenAPI, Constraints
Leser Mensch und Modell Compiler, Validator, CI
Reichweite Architektur, Ziel, Scope Datenform, Typen, Schnittstellen
Bei Abweichung Nichts passiert automatisch Build oder Test schlägt fehl
Typische Schwäche Spec veraltet unbemerkt Deckt Absicht und Architektur nicht ab

Grenzen: Wo Schemas nicht helfen

Ein Schema prüft die Form, nicht den Sinn. Ein Betrag kann typkorrekt sein und trotzdem falsch berechnet. Eine Rechnungsnummer kann dem Muster entsprechen und trotzdem doppelt vergeben sein. Wer glaubt, Schemas ersetzen Tests, baut sich eine neue Illusion von Sicherheit.
Deshalb bleibt die Reihenfolge der Quality Gates unverändert: statische Analyse, Unit Tests, funktionale Tests, End to End Tests mit Cypress. Das Schema ist das billigste und schnellste Gate, aber es ist das erste, nicht das einzige.
Zweite Grenze: Zu große Schemas werden selbst zum Problem. Verschachtelte Strukturen mit dutzenden optionalen Feldern verwirren Modelle und fressen Kontext. Kleine, klar benannte Schemas mit engen Wertebereichen schlagen große generische Strukturen deutlich.
Dritte Grenze: Ein Schema ohne Durchsetzung in der CI ist Dekoration. Wenn der Check lokal übersprungen werden kann, wird er übersprungen. Erst in der Pipeline wird aus dem Vertrag eine Regel. Wie ein Agent trotz Regeln Sicherheitslücken erzeugt, zeigt Vibe Coding Security.

The goal is to eliminate duplicative type declarations.

Colin McDonnell, Entwickler von Zod – Zod README auf GitHub

Aus der NCA Praxis: Der Vertrag steht vor dem Code

Wenn wir in ein Projekt kommen, in dem KI Agenten seit Monaten Code schreiben, sieht das Muster fast immer gleich aus. Die Typen existieren, aber sie werden übersprungen. Die Validierung existiert, aber nur an drei von zwanzig Stellen. Die Datenbank akzeptiert alles. Der Agent ist nicht das Problem, er nutzt nur jede Lücke, die offen steht.
Unser Vorgehen ist deshalb immer dieselbe Reihenfolge: erst Quality Gates aufbauen, dann aufräumen. Basis Refactoring läuft bei uns stark manuell mit KI Unterstützung, niemals als autonomer Agent auf einer Legacy Codebasis. Zuerst statische Analyse, Unit Tests, funktionale Tests und End to End Tests mit Cypress. Danach die Struktur.
Realistisch braucht die Einführung 15 bis 30 Tage bis zum ersten verlässlichen Ergebnis. Danach ein paar Tage im Monat, damit Regeln, Gates und Agenten mit dem Projekt mitwachsen. Beides sind Aufwandsschätzungen, keine Pakete. Wir rechnen minutengenau ab und starten mit einem kostenlosen Kennenlernen.
Weiterführend passen dazu Skalierbarkeit und Wartbarkeit beim Vibe Coding, Agentic Coding Patterns, Agent Skills im Vercel Ökosystem, Enterprise Readiness und die Vibe Coding Beratung von Never Code Alone.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu Schema Based AI Coding

Die wichtigsten Antworten zu Schemas als Leitplanke für KI Agenten, zur Abgrenzung von Spec Driven Development und zur praktischen Einführung in PHP, Symfony und TypeScript Projekten.

Was ist Schema Based AI Coding 2026?

Schema Based AI Coding heißt, dass ein maschinenlesbares Schema den Vertrag definiert, gegen den ein KI Agent Code schreibt. Zod, JSON Schema, OpenAPI, Symfony Constraints oder Datenbank Constraints legen die erlaubte Form fest. Weicht der generierte Code ab, schlägt der Build oder die Pipeline fehl. Der Fehler wird also von einer Maschine gefunden, nicht erst im Review.

Wie unterscheidet sich Schema Based AI Coding 2026 von Spec Driven Development?

Spec Driven Development beschreibt Anforderungen in Prosa, meist in versionierten Markdown Dateien. Das ist wertvoll für Absicht und Architektur, aber eine Spec kann veralten, ohne dass etwas rot wird. Ein Schema ist ausführbar. Es prüft bei jedem Lauf. Die beiden Ansätze konkurrieren nicht, sie ergänzen sich: Die Spec beschreibt das Ziel, das Schema erzwingt die Einhaltung.

Welche Schemas braucht ein Team 2026 mindestens?

Drei reichen für den Anfang. Erstens ein Schema an jeder Systemgrenze, an der fremde Daten hereinkommen. Zweitens typisierte Datenmodelle, aus denen Typen abgeleitet statt doppelt gepflegt werden. Drittens ein Datenbank Schema mit echten Constraints statt durchgängig nullable Spalten. Wer diese drei Ebenen hat, fängt den größten Teil der typischen KI Fehler automatisch ab.

Funktioniert Schema Based AI Coding 2026 auch in PHP und Symfony?

Ja, und PHP ist dafür sogar gut ausgestattet. Symfony Validator Constraints sichern die Grenze, Doctrine bildet die Persistenz ab, PHPStan und Psalm prüfen statisch, Rector zieht Änderungen automatisiert durch die Codebasis. Für Schnittstellen empfiehlt sich der API First Weg über OpenAPI, damit Client und Server an dieselbe Definition gebunden sind.

Ersetzen Schemas 2026 die Tests?

Nein. Ein Schema prüft die Form, nicht die Bedeutung. Ein Betrag kann typkorrekt und trotzdem falsch berechnet sein. Schemas sind das erste und billigste Quality Gate, danach folgen weiterhin statische Analyse, Unit Tests, funktionale Tests und End to End Tests mit Cypress. Wer Schemas als Testersatz verkauft, tauscht nur eine Illusion von Sicherheit gegen eine andere.

Wie führe ich Schema Based AI Coding in ein bestehendes Projekt ein?

Nicht flächendeckend, sondern an der schmerzhaftesten Grenze zuerst. Meist ist das die Stelle, an der externe Daten hereinkommen oder an der ein Agent regelmäßig Unsinn baut. Dort ein Schema definieren, den Check in die CI hängen, dann die nächste Grenze. Parallel dazu wachsen die Regeln in rules.md oder AGENTS.md mit, damit der Agent den Vertrag kennt.

Was kostet die Einführung bei Never Code Alone?

Wir arbeiten mit einer transparenten Minuten Abrechnung, ohne Pakete und ohne Festpreis. Am Anfang steht ein kostenloses Kennenlernen, in dem wir den Zustand der Codebasis anschauen und den Aufwand gemeinsam schätzen. Erfahrungsgemäß liegt die Einführung bei 15 bis 30 Tagen bis zum ersten verlässlichen Ergebnis, danach ein paar Tage im Monat für die laufende Pflege.

Welche Rolle spielen Structured Outputs und JSON Schema?

Sie sichern die Ausgabe des Modells selbst. Mit einem JSON Schema darf das Modell beim Generieren nur noch Token wählen, die zur Struktur passen. Aus einem hoffentlich gültigen JSON wird ein garantiert gültiges JSON. Dasselbe Prinzip trägt jeden Tool Call und jeden MCP Server, weil dort jeder Parameter typisiert ist, bevor der erste Token fließt.

Machen möglichst große Schemas die Ergebnisse besser?

Nein, meist das Gegenteil. Tief verschachtelte Strukturen mit vielen optionalen Feldern verwirren Modelle und kosten unnötig Kontext. Kleine Schemas mit sprechenden Feldnamen und engen Wertebereichen liefern deutlich stabilere Ergebnisse. Enums schlagen freie Strings, Pflichtfelder schlagen optionale Felder, und additionalProperties auf false verhindert, dass erfundene Felder still mitreisen.

Was hat Schema Based AI Coding mit der DSGVO zu tun?

Mehr als es zunächst wirkt. Aus einem sauberen Datenbank Schema lassen sich realistische Fake Daten erzeugen. Damit arbeiten große Coding Modelle gegen eine lokale Entwicklungsumgebung statt gegen echte Kundendaten. Genau das ist unser Leitmotiv: Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk. Für gehostete Inferenz in Europa nutzen wir TensorX, für Infrastruktur arbeiten wir mit Conversis zusammen.

Brauche ich dafür zwingend TypeScript?

Nein. TypeScript macht den Weg bequem, weil sich Typen direkt aus dem Schema ableiten lassen. Das Prinzip funktioniert aber in jeder Sprache mit ordentlicher statischer Analyse. In PHP übernehmen PHPStan und Psalm diese Rolle, in Python Ruff und mypy. Entscheidend ist nicht die Sprache, sondern ob die Prüfung in der Pipeline verpflichtend läuft.

Wie verhindere ich, dass der Agent einfach das Schema ändert?

Über zwei Mechanismen. Erstens Regeln: In rules.md oder AGENTS.md steht explizit, dass Schemas nur mit Migration und Begründung geändert werden. Zweitens Prozess: Schemadateien gehören in ein Review, das ein Mensch abnimmt. Ein Agent, der eine Regel umschreiben darf, um sie zu erfüllen, hat keine Leitplanke mehr, sondern eine Ausrede.