OpenAPI als Vertrag zwischen KI und Code
Eine OpenAPI-Definition wirkt auf den ersten Blick wie eine technische Pflichtübung. Schnittstellen-Doku, generierte Clients, vielleicht ein Swagger-UI. Was viele Teams nicht erkennen: In KI-gestützten Integrationen wird OpenAPI plötzlich der zentrale Vertrag, der das Modell daran hindert, Methoden zu erfinden.
Was passiert ohne klare Schnittstellen-Definition
Wenn ein Entwickler die KI bittet, eine Funktion gegen eine externe API aufzurufen, hat das Modell zwei Optionen. Erste Option: es liest die offizielle Doku, falls sie im Trainings-Set war. Zweite Option: es rät plausibel auf Basis ähnlicher APIs.
Die zweite Option führt zu den klassischen Halluzinationen. Endpunkte, die nicht existieren. Parameter, die anders heißen. Authentifizierungs-Header, die so nicht funktionieren. Der Code sieht überzeugend aus, scheitert aber zur Laufzeit.
Was sich mit OpenAPI verändert
Mit einer OpenAPI-Definition als Kontext kann das Modell nicht mehr raten. Es muss exakt das nutzen, was im Schema steht. Endpunkte, Parameter, Response-Formate, Authentifizierung, alles ist verbindlich beschrieben. Der KI fehlt der Spielraum für plausible Erfindungen.
Praktisch heißt das: ihr packt die OpenAPI-Datei ins Prompt-Kontext oder lasst die KI sie über ein Tooling auslesen. Die KI generiert dann Code, der gegen das Schema validierbar ist. Bricht der generierte Code, weil er das Schema verletzt, wird das vor dem ersten Lauf erkannt.
Was das praktisch bewirkt
In Teams, die ohnehin OpenAPI pflegen, ist der Effekt sofort sichtbar. KI-generierter Integrations-Code ist zuverlässiger als ohne Schema-Kontext. Halluzinierte Endpunkte verschwinden weitgehend.
In Teams, die kein OpenAPI haben, lohnt sich die Investition jetzt mehr als früher. Was vorher als “Doku-Pflicht” galt, ist heute auch ein KI-Beschleuniger. Die gleiche Datei, doppelter Nutzen.
Was es nicht löst
OpenAPI definiert die Schnittstelle, nicht die Geschäftslogik. Was hinter dem Endpunkt passiert, welche Validierungen greifen, welche Berechtigungen geprüft werden, all das steht nicht im Schema. Die KI generiert korrekten Aufruf-Code, aber sie versteht nicht, ob die Logik dahinter sinnvoll ist.
Auch komplexe Workflows, die mehrere Aufrufe in der richtigen Reihenfolge brauchen, sind kein OpenAPI-Thema. Da bleibt der Mensch zuständig.
Fazit
Eine OpenAPI-Definition ist heute mehr als Schnittstellen-Doku. Sie ist die wichtigste Maßnahme, um KI-generierten Integrations-Code zuverlässig zu machen. Wer überlegt, wie das im eigenen Stack aussehen kann, kann mich gerne ansprechen.