Das fehlende Puzzlestück
In den ersten beiden Teilen dieser Serie ging es um die neue Rolle als Dirigent und um Projektstrukturen, die KI-Wartbarkeit ermöglichen. Dokumentation, Tests, Prozessverbesserung – die Grundlagen standen. Aber ein Problem blieb offen.
Eine KI kann Quellcode lesen. Sie kann ihn verändern, Tests schreiben, Strukturen refactoren. Was sie nicht kann: in eine laufende Software hineinschauen. Sie sieht den Code, aber nicht, was zur Laufzeit passiert. Welche Zustände gerade aktiv sind. Ob ein Filter korrekt rechnet. Ob die GUI-Komponente tatsächlich die erwarteten Daten anzeigt.
Für einen menschlichen Entwickler ist das der Moment, in dem man den Debugger anwirft. Für eine KI ist das eine Sackgasse.
Tjaaaa. Nix da 😁.
Ich baute der KI eine Tür. Und noch ein Fenster. Und noch ein Scheunentor 😊. Und musste hinterher sehen, dass ich die Scheunentore wieder schloss. Aber das kommt zum Schluss.
REST-Schnittstellen: Die Tür zur laufenden Software
Ich erwischte mich dabei, wie ich für immer mehr Kundenprojekte REST-Schnittstellen einbaute – nicht nur für externe Nutzer, sondern für Diagnose und Analyse. Schnittstellen, mit denen man an interne Daten herankommt und mal eben gucken kann, wie bestimmte Zustände sind. Das, was ein Frontend-Programmierer zur Zustandsanzeige braucht, erwies sich als sehr nah an dem, was eine KI braucht, die „mal reingucken“ muss.
Der Gedanke dahinter ist simpel: Was ein Mensch im Browser aufrufen kann, kann auch eine KI abfragen 👌.
Ein paar Praxisentscheidungen haben sich dabei als wertvoll erwiesen. Erstens: Alle Diagnose-Schnittstellen als GET anlegen, nicht als POST. Das klingt nach einem Detail, macht aber einen enormen Unterschied. GET-Endpunkte sind direkt im Browser aufrufbar. Man kann sie als Links in eine Übersichtsseite einfügen (lassen!). Man kann sie danach direkt anklicken. Und braucht keine externen Tools, wie Postman 😁.
Zweitens: Eine selbst-erklärende Übersichtsseite auf /api/. Wer die Adresse aufruft, bekommt eine Auflistung aller verfügbaren Endpunkte – mit Beispiel-Links und sinnvollen Default-Parametern. Wenn man nach zwei Wochen nicht mehr weiß, wie ein bestimmtes Kommando hieß, reicht ein Blick auf diese Seite.
Das Schöne daran: Claude schreibt diese Schnittstellen selbst. Ich beschreibe, welche internen Zustände ich zugänglich machen will, und Claude baut die Endpunkte. Inklusive der Übersichtsseite. Zumindest, nachdem ich ihn eingewiesen habe 🥳.
OpenAPI und Skills: Schnittstellen, die sich selbst dokumentieren
Wenn Claude die REST-Schnittstellen schreibt, kann Claude gleich eine OpenAPI-Beschreibung dazu anlegen 👌. Damit sind die Schnittstellen nicht nur funktional, sondern professionell dokumentiert – in einem Format, das sowohl Menschen als auch Maschinen verstehen.
Einen Schritt weiter gedacht: Zu jeder REST-Schnittstelle lasse ich Claude einen Skill schreiben. Ein Skill ist im Grunde eine Anleitung, die Claude sagt, wie es mit einem bestimmten Endpunkt umgehen soll – welche Parameter sinnvoll sind, was die Antwort bedeutet, wann man diesen Endpunkt nutzt.
Das ergibt ein einfaches Prinzip: Wenn Claude eine API ändert, muss es auch den zugehörigen Skill und die OpenAPI-Dokumentation aktualisieren. Das steht in der CLAUDE.md, und Claude hält sich daran.
MCP: Der Moment, in dem es klickte – buchstäblich
REST-Schnittstellen waren schon ein großer Schritt. Aber der eigentliche Durchbruch kam mit MCP – dem Model Context Protocol.
Das Konzept: Parallel zur REST-Schnittstelle eine MCP-Schnittstelle halten. Beide bieten dieselbe Funktionalität, aber MCP erlaubt Claude, die Software direkt aus der Entwicklungsumgebung heraus zu bedienen. Ohne Umweg über Browser oder Skripte.
Ich habe das bei einem Kundenprojekt so weit getrieben, dass Claude eine Steuerungssoftware per MCP bedienen konnte. Und dann konnte ich irgendwann fasziniert zusehen, wie Claude mehr und mehr seine eigenen Ergebnisse verifizierte, indem es selbst in der Software herumklickte 😮.
Das ist ein sehr mächtiges Werkzeug. Claude schreibt Code, lässt ihn laufen, prüft über die REST- oder MCP-Schnittstelle, ob das Ergebnis stimmt – und korrigiert, wenn nicht. Ein geschlossener Regelkreis 😁. Wer aus der Qualitätssicherung kommt, erkennt das Muster sofort: Plan, Do, Check, Act – nur dass die KI drei dieser vier Schritte selbst ausführen kann 👌.
Entscheidend war, dass Claude sowohl die REST- als auch die MCP-Schnittstelle selbst geschrieben hat. Ich musste nur sicherstellen, dass beide synchron blieben. Auch das stand in der CLAUDE.md: Wenn du einen REST-Endpunkt änderst, musst du den MCP-Endpunkt ebenfalls anpassen. Und umgekehrt. Das Ergebnis war eine Software, die sich nicht nur von außen testen, sondern von der KI im wahrsten Sinne des Wortes bedienen ließ 🥳.
Selbstdiagnose: Tausend Prüfpunkte, eine Abfrage
In allen meinen Projekten seit ToolScope (2008!) gibt es mittlerweile eine Selbstdiagnose. Das Prinzip stammt aus der Steuerungstechnik: Ein interner Selbsttest prüft fortlaufend, ob bestimmte Bedingungen eingehalten werden. Wenn etwas schiefgeht, gibt es eine Fehlernummer und einen Klartext 😁.
In der Praxis heißt das: Tausende Stellen im Code haben kleine interne Tests. Liegt ein Wert außerhalb der Erwartung? Fehlt eine Ressource? Stimmt eine Beziehung zwischen Daten nicht? Jede dieser Stellen meldet sich über die Selbstdiagnose 🥳.
Wenn man diese Selbstdiagnose über eine REST-API zugänglich macht, ergibt sich ein elegantes Muster. Ein externer Python-Test muss nicht jede einzelne Bedingung selbst prüfen. Er fragt einfach: Steht eine kritische Meldung an? Wenn die Antwort leer ist, hat man implizit tausend Dinge geprüft.
Anhand der Fehlernummer lässt sich dann entweder die Meldung ablöschen, wenn sie erwartet war, oder die exakte Stelle im Quellcode finden, die das Problem ausgelöst hat 👌.
Für Entscheider ist das relevant, weil es den Debugging-Aufwand fundamental verändert. Statt stundenlang Logs zu durchsuchen, gibt es eine klare Diagnose. Und die KI kann diese Diagnose ebenfalls lesen und darauf reagieren.
REST-APIs in Tests: Doppelter Nutzen
Die REST-Schnittstellen haben sich noch auf einem anderen Weg bewährt: in den Python-Testskripten.
Dadurch, dass ich REST und MCP parallel gehalten habe, konnte ich in den externen Tests direkt auf die REST-Endpunkte zugreifen. Das hat zwei Vorteile gleichzeitig. Die Tests nutzen die APIs, um interne Zustände abzufragen und zu validieren. Und gleichzeitig wird die API selbst implizit mitgetestet. Wenn ein Endpunkt sich unerwartet verhält, fällt das im Testlauf auf 😊.
Sicherheit: Die ehrliche Einschätzung
REST-Schnittstellen, die Zugriff auf interne Zustände geben, sind gleichzeitig ein potentielles Einfallstor für Angreifer. Damit muss man direkt umgehen!
Es gibt verschiedene Ansätze, die ich in meinen Projekten verfolge. Einer ist Token-basierte Authentifizierung: Man holt sich mit einem Passwort ein Token und gibt es in allen Folgezugriffen mit. Ein anderer ist ein Developer-Modus: Die Diagnose-Schnittstellen sind nur aktiv, wenn die Software erkennt, dass sie in einer Entwicklungsumgebung läuft.
Ich will ehrlich sein: In einigen Projekten ist die Absicherung noch nicht vollständig zu Ende geführt. Aber auch hier gilt, was sich durch diese ganze Serie zieht – die KI kann auch die Sicherheitsschnittstellen programmieren. Man muss nur dafür sorgen, dass es auf der Aufgabenliste steht.
Rückblick: Was sich verändert hat
Über drei Artikel hinweg habe ich beschrieben, wie sich mein Arbeitsalltag in der Softwareentwicklung verändert hat. Ich war bei KI ein „early adoper“ 😁. Es fing an mit einer neuen Rolle – vom Programmierer zum Dirigenten, der orchestriert statt selbst zu coden. Dann ging es um die Struktur: Projekte so aufbauen, dass sie mit KI wartbar sind, mit zwei Dokumentationsebenen, lesbaren Tests und kontinuierlicher Prozessverbesserung 😊. Und in diesem Artikel um die Verbindung zwischen KI und laufender Software – REST-APIs, Selbstdiagnose und MCP als die Werkzeuge, mit denen die KI vom passiven Code-Schreiber zum aktiven Teilnehmer wird.
Was sich fundamental verändert hat, lässt sich in drei Sätzen zusammenfassen:
- Die Qualität meiner Softwareprojekte hat sich massiv verbessert – nicht weil die Tools besser geworden sind, sondern weil ich anders arbeite.
- Ich traue mich an Dinge heran, die ich vorher nie angefasst hätte.
- Meine KI prüft ihre eigene Arbeit.
Wenn ich heute ein neues Kundenprojekt aufsetze, fange ich mit der CLAUDE.md an. Ich baue von Anfang an Teststrukturen ein, die lesbaren Output erzeugen. Und ich plane REST-Endpunkte mit, bevor die erste Zeile Geschäftslogik steht. Das ist keine Mehrarbeit – es ist die Grundlage dafür, dass die KI effektiv mitarbeiten kann.
Für Entscheider ist die Botschaft aller drei Artikel dieselbe: Der Wert von KI in der Softwareentwicklung liegt nicht in der Geschwindigkeit. Er liegt in der Qualität. Und diese Qualität entsteht nicht von allein – sie entsteht durch Struktur, durch Prozesse und durch die Bereitschaft, die KI wie einen Mitarbeiter zu führen, nicht wie ein Werkzeug zu bedienen.
Dies war der Abschluss der dreiteiligen Serie „Vom Programmierer zum Dirigenten“.
Die vorherigen Teile:
- Ich bediene keine fünf KI-Fenster parallel. Mein Eindruck von produktivem Arbeiten mit KI
- Der Qualitätsmanager in mir
Über den Autor
Jan Brinkhaus, Jahrgang 1977 ist Geschäftsführer der Brinkhaus GmbH. Er gründete mehrere Firmen und ist ein leidenschaftlicher Programmierer.