Selbstheilende Code-Generierung: was sie ist, wie sie arbeitet, wo sie aufhört

Was ist selbstheilende Code-Generierung?

Selbstheilende Code-Generierung heißt, dass dasselbe System, das den Code schreibt, auch seine eigenen Fehler erkennt und behebt, bevor ein Mensch sie zu sehen bekommt. Entscheidend ist der Zeitpunkt. Die meisten KI-Werkzeuge generieren, hören auf und übergeben dir, was herausgekommen ist; fehlt ein Import oder passt ein Typ nicht, ist das Herausfinden dein Job, und dein nächster Schritt ist, die Fehlermeldung zurück in den Chat zu kopieren. Ein selbstheilendes System schließt diese Schleife selbst: Es baut, was es gerade geschrieben hat, liest die Ausgabe des Compilers so, wie eine Entwicklerin es täte, setzt einen gezielten Fix und baut erneut.

Das verändert nicht den Komfort, sondern das Ergebnis. Ein Werkzeug, das Code mit den Fehlern darin übergibt, übergibt einen Entwurf. Ein System, das ausschließlich bauende Zustände übergibt, übergibt etwas Lauffähiges. Der Unterschied zeigt sich daran, was du als Nächstes tust: das Ergebnis prüfen — oder es erst einmal debuggen.

Wie läuft die Heilungsschleife konkret ab?

Bei Airbuild läuft die Schleife innerhalb einer Generierung, nicht als Aufräumdurchgang danach. Jeder Generierungsschritt baut das Projekt, ein Fehler taucht also in dem Moment auf, in dem er entsteht, und nicht am Ende, wo er schwerer zuzuordnen ist. Der Agent liest die echte Build-Ausgabe — denselben Text, den du im Terminal sehen würdest — und setzt einen Fix auf genau diesen Fehler an, statt die Datei neu zu erzeugen und zu hoffen. Dann baut er erneut. Das wiederholt sich, bis der Build sauber ist.

Laufzeitfehler haben einen zweiten, schmaleren Weg. Ein Build kann durchlaufen und die Anwendung trotzdem beim Ausführen brechen — das fängt kein Compiler ab. In der Live-Vorschau übergibst du einen solchen Fehler per Klick an die KI, mitsamt Stacktrace und umgebendem Code als Kontext, und bekommst die Korrektur in derselben Sitzung zurück.

Beim Veröffentlichen läuft derselbe Mechanismus noch einmal, aber mit harter Grenze: Scheitert der Produktions-Build, versucht Airbuild eine KI-Reparatur und baut neu — bis zu zwei Wiederholungen. Klappt es danach nicht, bekommst du den Fehlertext, und die Schleife endet, statt sich festzubeißen. Diese Grenze ist Absicht: Eine unbegrenzte Reparaturschleife verbrennt dein Kontingent an einem Problem, das sie nicht sieht.

Was prüft Airbuild, bevor eine Veröffentlichung live geht?

Airbuild prüft bei jedem Projekt standardmäßig drei Bereiche — Tests, Sicherheit und Codequalität —, und alle drei sind vom ersten Build an aktiv, ohne dass jemand etwas einstellt. Die Sicherheitsprüfung nutzt Semgrep für Code-Muster und Trivy für Schwachstellen in Abhängigkeiten sowie mitcommittete Secrets. Die Qualitätsprüfung nutzt Ruff für Python und Biome für JavaScript und TypeScript. Tests entstehen zusammen mit dem Code und laufen im Test-Cockpit.

Geprüft wird nicht dein Arbeitsstand. Beim Veröffentlichen friert Airbuild genau den Code ein, der rausgeht, und prüft diesen Stand. Das schließt die Lücke zwischen „die Version, die ich gescannt habe" und „die Version, die ausgeliefert wurde" — in einem normalen CI-Aufbau wohnen genau dort die Überraschungen.

Alle drei Bereiche lassen sich pro Projekt abschalten. Das ist eine Entscheidung, kein Versehen: Ein Wegwerf-Prototyp braucht kein Release-Gate, und ein Gate, das niemand abschalten kann, wird umgangen statt benutzt. Entscheidend ist, dass der Standard „an" lautet — damit das Projekt, das die Prüfungen braucht, sie hat, ohne dass jemand daran denken muss.

Was blockiert eine Veröffentlichung tatsächlich?

Bei Airbuild blockieren Funde mit hohem Schweregrad aus der Sicherheits- und der Qualitätsprüfung die Veröffentlichung — und sonst nichts, solange du es nicht verlangst. Ein Fund dieses Schweregrads stoppt die Veröffentlichung, bis er behoben ist; Funde darunter landen im Problems-Panel und halten nichts auf. Jeder Fund trägt einen Ein-Klick-Fix, der das Problem an dieselbe KI übergibt, die den Code erzeugt hat — meist schneller, als die Regel nachzulesen.

Bei den Tests liegt der verbreitetste Irrtum. Ein fehlgeschlagener Test blockiert für sich genommen nichts. Er blockiert erst, wenn dein Team das Test-Gate vor der Veröffentlichung für dieses Projekt einschaltet — dann stoppt eine rote Suite das Release. Dass das standardmäßig aus ist, lässt sich gut begründen: Ein frühes Projekt voller halbfertiger Tests käme sonst überhaupt nicht live.

Eine Regel ist erwähnenswert, weil sie der Intuition widerspricht: Stürzt eine eingeschaltete Prüfung ab oder fällt serverseitig aus, wird die Veröffentlichung blockiert statt durchgewunken. Ein Gate, das verschwindet, sobald sein Scanner kaputtgeht, ist kein Gate.

Was kannst du zusätzlich einschalten?

Drei weitere Prüfungen gibt es in Airbuild, und sie bleiben aus, bis du sie aktivierst: die SonarQube-Tiefenanalyse, das OpenAPI-Linting und ein dynamischer Sicherheitsscan. Sie sind opt-in, weil jede von ihnen bei jeder Veröffentlichung Zeit kostet und diese Zeit nur für manche Projekte wert ist — eine Marketing-Seite hat keine API zu linten.

Der dynamische Scan ist der interessanteste, weil er anders arbeitet als alle anderen. Alles bisher Beschriebene liest deinen Quellcode. Der dynamische Scan klopft die **laufende** Anwendung über HTTP ab, so wie es ein Angreifer täte. Das findet eine Klasse von Problemen, die kein Quellcode-Lesen findet: eine Route, die ohne Anmeldung erreichbar ist, ein falsch gesetzter Header, ein Endpunkt, der mehr preisgibt als gedacht.

Die SonarQube-Tiefenanalyse hat, einmal eingeschaltet, dieselbe Autorität wie die Standardprüfungen — auch ihre Funde mit hohem Schweregrad blockieren ein Release. Das solltest du wissen, bevor du sie mitten im Projekt aktivierst: Du fügst keinen Bericht hinzu, du fügst ein Gate hinzu.

Worin unterscheidet sich das von selbstheilender CI?

Selbstheilende CI und selbstheilende Code-Generierung reparieren Unterschiedliches zu unterschiedlichen Zeitpunkten. Eine selbstheilende CI-Pipeline reagiert, nachdem der Code geschrieben wurde und der Build bereits gescheitert ist: Sie wiederholt einen instabilen Job, pinnt eine Abhängigkeit, startet einen Schritt neu. Der Code, der sie zum Scheitern gebracht hat, ist zu diesem Zeitpunkt längst committet und im Repository.

Selbstheilende Code-Generierung greift früher, in dem Moment, in dem der Code entsteht. Der kaputte Zwischenstand wird nie ein Commit, erreicht nie die Pipeline und braucht auch keine Pipeline, die klug damit umgeht. Wenn ein CI-System das Projekt zum ersten Mal sieht, sind die Fehler, die der Generator beheben konnte, schon weg.

Die beiden sind keine Alternativen, ein ernsthaftes Setup hat beides. Der Punkt der Unterscheidung ist, wo du die Zeitersparnis erwarten darfst: Eine selbstheilende Pipeline spart die Minuten nach einem gescheiterten Build — selbstheilende Generierung nimmt den gescheiterten Build aus der Reihenfolge heraus.

Wo hört Selbstheilung auf?

Selbstheilung hört an der Grenze zwischen Fehler und Absicht auf. Sie repariert, was nachweisbar falsch ist — Code, der nicht kompiliert, eine Abhängigkeit mit bekannter Schwachstelle, ein Muster, das eine Regel markiert —, denn dafür gibt es eine maschinell prüfbare Definition von „behoben". Sie kann dir nicht sagen, dass deine Rechnungslogik die falsche Summe bildet, weil in keiner Build-Ausgabe steht, was du gemeint hast. Korrekte Software, die das Falsche tut, besteht jede Prüfung auf dieser Seite.

Drei weitere Grenzen gehören klar gesagt. Die Reparaturschleife beim Veröffentlichen ist auf zwei Wiederholungen begrenzt und übergibt danach an dich, statt weiterzulaufen. Die Prüfung läuft auf dem Code, den Airbuild selbst erzeugt — es ist also kein Review-Werkzeug, das du auf ein beliebiges bestehendes Repository richtest. Und jedes Gate lässt sich pro Projekt abschalten, die Zusage lautet also „standardmäßig an", nicht „immer an".

Nichts davon spricht gegen den Mechanismus. Es spricht dafür, zu wissen, welche deiner Probleme er wegnimmt: die mechanischen, verlässlich und ohne dass du fragst. Die, für die es Urteilsvermögen braucht, bleiben deine.

Heißt Selbstheilung, dass niemand mehr den Code prüft?

Nein — Selbstheilung ändert, was zur Prüfung kommt, nicht ob geprüft wird. Was die Schleife dir abnimmt, ist die Klasse von Problemen mit objektiv richtiger Antwort: Compile-Fehler, bekannte Schwachstellen, Abhängigkeits-Advisories, Lint-Verstöße. Genau die findet ein menschlicher Reviewer am unzuverlässigsten und liest sie am ungernsten. Zur Prüfung kommt stattdessen Code, der baut, seine Tests besteht und keinen offenen Fund mit hohem Schweregrad trägt.

Und der Code bleibt deiner zum Lesen. Airbuild erzeugt gewöhnliches React, TypeScript und Python — keine proprietäre Laufzeitumgebung, kein Format, das du nur mit Airbuild öffnen kannst. Ab dem Plan Website Builder Pro verbindest du dein eigenes GitHub-Repository, und jede Änderung der KI wird dorthin committet und gepusht. Die Prüfung findet damit dort statt, wo dein Team ohnehin prüft, mit der vollständigen Historie in Git.