{"id":855,"date":"2026-02-13T11:12:59","date_gmt":"2026-02-13T10:12:59","guid":{"rendered":"https:\/\/brinkhaus-gmbh.de\/?p=855"},"modified":"2026-02-13T11:13:00","modified_gmt":"2026-02-13T10:13:00","slug":"technische-schulden-eliminieren-wenn-ki-die-software-selbst-bedient","status":"publish","type":"post","link":"https:\/\/www.brinkhaus-gmbh.de\/en\/technische-schulden-eliminieren-wenn-ki-die-software-selbst-bedient\/","title":{"rendered":"Technische Schulden eliminieren \u2013 Wenn KI die Software selbst bedient"},"content":{"rendered":"\n

Das fehlende Puzzlest\u00fcck<\/h2>\n\n\n\n

In den ersten beiden Teilen dieser Serie ging es um die neue Rolle als Dirigent und um Projektstrukturen, die KI-Wartbarkeit erm\u00f6glichen. Dokumentation, Tests, Prozessverbesserung \u2013 die Grundlagen standen. Aber ein Problem blieb offen.<\/p>\n\n\n\n

Eine KI kann Quellcode lesen. Sie kann ihn ver\u00e4ndern, 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\u00e4nde gerade aktiv sind. Ob ein Filter korrekt rechnet. Ob die GUI-Komponente tats\u00e4chlich die erwarteten Daten anzeigt.<\/p>\n\n\n\n

F\u00fcr einen menschlichen Entwickler ist das der Moment, in dem man den Debugger anwirft. F\u00fcr eine KI ist das eine Sackgasse.<\/p>\n\n\n\n

Tjaaaa. Nix da 😁.<\/p>\n\n\n\n

Ich baute der KI eine T\u00fcr. Und noch ein Fenster. Und noch ein Scheunentor 😊. Und musste hinterher sehen, dass ich die Scheunentore wieder schloss. Aber das kommt zum Schluss.<\/p>\n\n\n\n

\"\"<\/figure>
\n

REST-Schnittstellen: Die T\u00fcr zur laufenden Software<\/h2>\n\n\n\n

Ich erwischte mich dabei, wie ich f\u00fcr immer mehr Kundenprojekte REST-Schnittstellen einbaute \u2013 nicht nur f\u00fcr externe Nutzer, sondern f\u00fcr Diagnose und Analyse. Schnittstellen, mit denen man an interne Daten herankommt und mal eben gucken kann, wie bestimmte Zust\u00e4nde sind. Das, was ein Frontend-Programmierer zur Zustandsanzeige braucht, erwies sich als sehr nah an dem, was eine KI braucht, die “mal reingucken” muss.<\/p>\n\n\n\n

Der Gedanke dahinter ist simpel: Was ein Mensch im Browser aufrufen kann, kann auch eine KI abfragen 👌.<\/p>\n\n\n\n

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 \u00dcbersichtsseite einf\u00fcgen (lassen!). Man kann sie danach direkt anklicken. Und braucht keine externen Tools, wie Postman 😁.<\/p>\n\n\n\n

Zweitens: Eine selbst-erkl\u00e4rende \u00dcbersichtsseite auf \/api\/<\/code>. Wer die Adresse aufruft, bekommt eine Auflistung aller verf\u00fcgbaren Endpunkte \u2013 mit Beispiel-Links und sinnvollen Default-Parametern. Wenn man nach zwei Wochen nicht mehr wei\u00df, wie ein bestimmtes Kommando hie\u00df, reicht ein Blick auf diese Seite.<\/p>\n\n\n\n

Das Sch\u00f6ne daran: Claude schreibt diese Schnittstellen selbst<\/em>. Ich beschreibe, welche internen Zust\u00e4nde ich zug\u00e4nglich machen will, und Claude baut die Endpunkte. Inklusive der \u00dcbersichtsseite. Zumindest, nachdem ich <\/em>ihn eingewiesen habe 🥳.<\/p>\n<\/div><\/div>\n\n\n\n

OpenAPI und Skills: Schnittstellen, die sich selbst dokumentieren<\/h2>\n\n\n\n

Wenn Claude die REST-Schnittstellen schreibt, kann Claude gleich eine OpenAPI-Beschreibung dazu anlegen 👌. Damit sind die Schnittstellen nicht nur funktional, sondern professionell dokumentiert \u2013 in einem Format, das sowohl Menschen als auch Maschinen verstehen.<\/p>\n\n\n\n

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 \u2013 welche Parameter sinnvoll sind, was die Antwort bedeutet, wann man diesen Endpunkt nutzt.<\/p>\n\n\n\n

Das ergibt ein einfaches Prinzip: Wenn Claude eine API \u00e4ndert, muss es auch den zugeh\u00f6rigen Skill und die OpenAPI-Dokumentation aktualisieren. Das steht in der CLAUDE.md, und Claude h\u00e4lt sich daran.<\/p>\n\n\n\n

\"\"<\/figure>
\n

MCP: Der Moment, in dem es klickte \u2013 buchst\u00e4blich<\/h2>\n\n\n\n

REST-Schnittstellen waren schon ein gro\u00dfer Schritt. Aber der eigentliche Durchbruch kam mit MCP \u2013 dem Model Context Protocol.<\/p>\n\n\n\n

Das Konzept: Parallel zur REST-Schnittstelle eine MCP-Schnittstelle halten. Beide bieten dieselbe Funktionalit\u00e4t, aber MCP erlaubt Claude, die Software direkt aus der Entwicklungsumgebung heraus zu bedienen. Ohne Umweg \u00fcber Browser oder Skripte.<\/p>\n\n\n\n

Ich habe das bei einem <\/em>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 <\/em>in der Software herumklickte 😮.<\/p>\n\n\n\n

Das ist ein sehr m\u00e4chtiges Werkzeug. Claude schreibt Code, l\u00e4sst ihn laufen, pr\u00fcft \u00fcber die REST- oder MCP-Schnittstelle, ob das Ergebnis stimmt \u2013 und korrigiert, wenn nicht. Ein geschlossener Regelkreis 😁. Wer aus der Qualit\u00e4tssicherung kommt, erkennt das Muster sofort: Plan, Do, Check, Act \u2013 nur dass die KI drei dieser vier Schritte selbst ausf\u00fchren kann 👌.<\/p>\n\n\n\n

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 \u00e4nderst, musst du den MCP-Endpunkt ebenfalls anpassen. Und umgekehrt. Das Ergebnis war eine Software, die sich nicht nur von au\u00dfen testen, sondern von der KI im wahrsten Sinne des Wortes bedienen lie\u00df 🥳.<\/p>\n<\/div><\/div>\n\n\n\n

Selbstdiagnose: Tausend Pr\u00fcfpunkte, eine Abfrage<\/h2>\n\n\n\n

In allen meinen Projekten seit ToolScope (2008!) gibt es mittlerweile eine Selbstdiagnose. Das Prinzip stammt aus der Steuerungstechnik: Ein interner Selbsttest pr\u00fcft fortlaufend, ob bestimmte Bedingungen eingehalten werden. Wenn etwas schiefgeht, gibt es eine Fehlernummer und einen Klartext 😁.<\/p>\n\n\n\n

In der Praxis hei\u00dft das: Tausende Stellen im Code haben kleine interne Tests. Liegt ein Wert au\u00dferhalb der Erwartung? Fehlt eine Ressource? Stimmt eine Beziehung zwischen Daten nicht? Jede dieser Stellen meldet sich \u00fcber die Selbstdiagnose 🥳.<\/p>\n\n\n\n

Wenn man diese Selbstdiagnose \u00fcber eine REST-API zug\u00e4nglich macht, ergibt sich ein elegantes Muster. Ein externer Python-Test muss nicht jede einzelne Bedingung selbst pr\u00fcfen. Er fragt einfach: Steht eine kritische Meldung an? Wenn die Antwort leer ist, hat man implizit tausend Dinge gepr\u00fcft.<\/p>\n\n\n\n

Anhand der Fehlernummer l\u00e4sst sich dann entweder die Meldung abl\u00f6schen, wenn sie erwartet war, oder die exakte Stelle im Quellcode finden, die das Problem ausgel\u00f6st hat 👌.<\/p>\n\n\n\n

F\u00fcr Entscheider ist das relevant, weil es den Debugging-Aufwand fundamental ver\u00e4ndert. Statt stundenlang Logs zu durchsuchen, gibt es eine klare Diagnose. Und die KI kann diese Diagnose ebenfalls lesen und darauf reagieren.<\/p>\n\n\n\n

\"\"<\/figure>
\n

REST-APIs in Tests: Doppelter Nutzen<\/h2>\n\n\n\n

Die REST-Schnittstellen haben sich noch auf einem anderen Weg bew\u00e4hrt: in den Python-Testskripten.<\/p>\n\n\n\n

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\u00e4nde abzufragen und zu validieren. Und gleichzeitig wird die API selbst implizit mitgetestet. Wenn ein Endpunkt sich unerwartet verh\u00e4lt, f\u00e4llt das im Testlauf auf 😊.<\/p>\n<\/div><\/div>\n\n\n\n

Sicherheit: Die ehrliche Einsch\u00e4tzung<\/h2>\n\n\n\n

REST-Schnittstellen, die Zugriff auf interne Zust\u00e4nde geben, sind gleichzeitig ein potentielles Einfallstor f\u00fcr Angreifer. Damit muss man direkt umgehen!<\/p>\n\n\n\n

Es gibt verschiedene Ans\u00e4tze, 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\u00e4uft.<\/p>\n\n\n\n

Ich will ehrlich sein: In einigen Projekten ist die Absicherung noch nicht vollst\u00e4ndig zu Ende gef\u00fchrt. Aber auch hier gilt, was sich durch diese ganze Serie zieht \u2013 die KI kann auch die Sicherheitsschnittstellen programmieren. Man muss nur daf\u00fcr sorgen, dass es auf der Aufgabenliste steht.<\/p>\n\n\n\n

R\u00fcckblick: Was sich ver\u00e4ndert hat<\/h3>\n\n\n\n

\u00dcber drei Artikel hinweg habe ich beschrieben, wie sich mein Arbeitsalltag in der Softwareentwicklung ver\u00e4ndert hat. Ich war bei KI ein “early adoper” 😁. Es fing an mit einer neuen Rolle \u2013 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 \u2013 REST-APIs, Selbstdiagnose und MCP als die Werkzeuge, mit denen die KI vom passiven Code-Schreiber zum aktiven Teilnehmer wird.<\/p>\n\n\n\n

Was sich fundamental ver\u00e4ndert hat, l\u00e4sst sich in drei S\u00e4tzen zusammenfassen:<\/p>\n\n\n\n

\n
    \n
  1. Die Qualit\u00e4t meiner Softwareprojekte hat sich massiv verbessert \u2013 nicht weil die Tools besser geworden sind, sondern weil ich anders arbeite.<\/li>\n\n\n\n
  2. Ich traue mich an Dinge heran, die ich vorher nie angefasst h\u00e4tte.<\/li>\n\n\n\n
  3. Meine KI pr\u00fcft ihre eigene Arbeit.<\/li>\n<\/ol>\n<\/blockquote>\n\n\n\n

    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\u00e4ftslogik steht. Das ist keine Mehrarbeit \u2013 es ist die Grundlage daf\u00fcr, dass die KI effektiv mitarbeiten kann.<\/p>\n\n\n\n

    F\u00fcr Entscheider <\/em>ist die Botschaft aller drei Artikel dieselbe: Der Wert von KI in der Softwareentwicklung liegt nicht in der Geschwindigkeit. Er liegt in der Qualit\u00e4t. Und diese Qualit\u00e4t entsteht nicht von allein \u2013 sie entsteht durch Struktur, durch Prozesse und durch die Bereitschaft, die KI wie einen Mitarbeiter zu f\u00fchren, nicht wie ein Werkzeug zu bedienen.<\/p>\n\n\n\n

    \n\n\n\n

    Dies war der Abschluss der dreiteiligen Serie \u201eVom Programmierer zum Dirigenten”.<\/p>\n\n\n\n

    Die vorherigen Teile:<\/p>\n\n\n\n