In den meisten Entwicklungsteams, die ich sehe, ist die Frage nach KI längst entschieden. Nicht in einem Strategie-Meeting, sondern nebenbei. Jemand hat einen Assistenten installiert, es hat funktioniert, der Kollege hat es gesehen. Sechs Monate später ist ein erheblicher Teil dessen, was in den Release geht, nicht mehr Zeile für Zeile getippt worden.
Die Diskussion darüber dreht sich fast immer um Qualität. Ist der generierte Code sicher? Hat er Schwachstellen? Erfindet das Modell Bibliotheken, die es nicht gibt? Das sind berechtigte Fragen, aber sie sind nicht die interessanten. Für all das haben Sie bereits Mechanismen. Ihr Review greift, Ihre Tests greifen, Ihr Scanner greift. Ein generiertes SQL-Statement mit Injection-Lücke fällt genauso auf wie ein handgeschriebenes, oder eben genauso wenig. Daran hat sich nichts geändert.
Etwas anderes hat sich geändert, und darüber wird kaum gesprochen.
Die Begründung wandert aus dem Repository
Nehmen Sie eine Änderung, die vor drei Jahren entstanden ist. Ein Entwickler hat ein Problem verstanden, Optionen abgewogen, sich entschieden und die Lösung geschrieben. Der Kontext dieser Entscheidung saß in seinem Kopf. Im Review konnte er ihn abrufen. Warum dieser Ansatz und nicht der andere, was passiert unter Last, was ist der Sonderfall, an den keiner denkt. Ein Teil davon landete im Commit, ein Teil im PR-Kommentar, ein großer Teil blieb ungeschrieben, war aber jederzeit abrufbar, solange die Person im Haus war.
Heute läuft es anders. Der Entwickler beschreibt die Absicht in einem Prompt. Er bekommt eine Implementierung. Er liest sie, findet sie plausibel, passt zwei Stellen an, committet. Die Absicht war präzise formuliert. Die Abwägung hat stattgefunden, teilweise im Modell, teilweise im Kopf des Entwicklers beim Lesen. Und dann verschwindet sie.
Der Prompt ist die eigentliche Begründung für diesen Code. Der Prompt landet in keinem Repository. Er steht in einem Chatverlauf in einer IDE, die in vier Wochen neu aufgesetzt wird.
Das ist der Punkt. Nicht: KI produziert schlechteren Code. Sondern: Der Weg, auf dem Code entsteht, hat sich verschoben, und die Artefakte, in denen wir Nachvollziehbarkeit ablegen, sind mitgewandert, ohne dass jemand ihnen gefolgt wäre.
Warum das praktisch weh tut
Das klingt nach einem Problem für Dokumentationsfreunde. Ist es nicht. Es schlägt an drei Stellen konkret durch.
Die Review-Asymmetrie. Bei handgeschriebenem Code korreliert der Aufwand des Autors grob mit dem Aufwand des Reviewers. Wer zwei Tage an einer Änderung gesessen hat, produziert selten dreitausend Zeilen. Diese Kopplung ist weg. Ein Pull Request, der in zwanzig Minuten entstanden ist, kann eine Stunde Review kosten. Der Autor hat weniger Kontext, als er bei gleicher Zeilenzahl früher gehabt hätte, und der Reviewer merkt das nicht, weil der Code gut aussieht. Generierter Code sieht fast immer gut aus. Er ist sauber formatiert, benennt Variablen sinnvoll und hat Kommentare. Das ist genau das Signal, an dem Reviewer traditionell Sorgfalt erkannt haben.
Das Volumen. Teams produzieren mehr Änderungen. Die Review-Kapazität wächst nicht mit, sie ist an Menschen gebunden. Was passiert, ist absehbar: Reviews werden oberflächlicher, oder sie werden zum Engpass und dann teilweise umgangen. Beides sehe ich.
Die Wartung. In zwei Jahren fragt jemand, warum an dieser Stelle ein Retry mit exponentiellem Backoff und genau fünf Versuchen steht. Früher lautete die Antwort im schlechtesten Fall “das hat damals der Kollege gemacht, der ist weg”. Heute lautet sie “das war ein Vorschlag, der plausibel aussah”. Der Unterschied ist, dass es im zweiten Fall nie eine Person gab, die eine Begründung hatte. Sie können niemanden fragen.
Und dann kommt irgendwann jemand von außen. Ein Kunde im Lieferantenaudit, ein Interessent in der technischen Due Diligence, ein neuer Teamlead in Woche zwei. Die Frage ist immer dieselbe: Warum ist das so? Was Sie in dem Moment zeigen können, entscheidet, wie das Gespräch weitergeht.
Zwei Reaktionen, die nicht tragen
Die erste ist das Verbot. Manche Häuser haben KI-Assistenten untersagt, meist mit Verweis auf Datenabfluss oder ungeklärte Lizenzfragen. Beides sind reale Themen. Das Verbot löst sie trotzdem nicht, es verlagert sie. Der Assistent läuft dann auf dem privaten Rechner, der Code wird per Copy-and-paste eingefügt, und der einzige Unterschied ist, dass Sie es jetzt nicht mehr wissen. Ein Verbot, dessen Einhaltung Sie nicht prüfen können, ist eine Behauptung, kein Kontrollmechanismus.
Die zweite ist die Richtlinie. Ein Dokument entsteht, es steht darin, dass generierter Code besonders sorgfältig zu prüfen und zu kennzeichnen ist, es wird verteilt und abgehakt. Sechs Monate später gilt es als geregelt. Fragen Sie in dem Moment, wie viele Änderungen des letzten Quartals gekennzeichnet wurden. Die ehrliche Antwort ist selten die erwartete.
Was diese beiden Reaktionen verbindet: Sie erzeugen kein Signal. Am Ende steht in beiden Fällen eine Aussage über den Zustand des Systems, die niemand überprüfen kann. Damit ist sie nichts wert, auch intern nicht.
Was tatsächlich hilft
Der naheliegende Reflex ist, KI-generierte Änderungen zu markieren. Ein Flag im Commit, ein Label am PR, eine Quote im Dashboard. Davon rate ich ab, aus einem einfachen Grund: Der Wert dieser Information verfällt. Heute können Sie vielleicht noch sinnvoll zwischen generiert und geschrieben unterscheiden. In achtzehn Monaten ist praktisch jede Änderung teilweise assistiert entstanden, und die Kennzeichnung markiert dann nichts mehr. Sie bauen eine Metrik, die genau so lange existiert, wie sie ihre Aussagekraft verliert.
Die Alternative ist unspektakulär, und das ist ihr Vorteil: Legen Sie die Begründung dorthin, wo die Änderung liegt.
Das heißt konkret, dass ein Pull Request beantwortet, was die Änderung erreichen soll, welcher Weg verworfen wurde und was im Fehlerfall passiert. Nicht als Formular, sondern als das, was der Entwickler ohnehin gedacht hat, bevor er den Prompt formuliert hat. Wer eine Absicht präzise genug beschreiben kann, dass ein Modell brauchbaren Code liefert, kann sie auch in drei Sätzen in den PR schreiben. Der Aufwand ist marginal, weil die Denkarbeit bereits geleistet wurde. Sie geht heute nur verloren.
Bei Entscheidungen mit Reichweite über die einzelne Änderung hinaus gehört das in einen Architecture Decision Record im selben Repository. Kein Wiki, kein Confluence-Space, der beim nächsten Umzug verwaist. Im Repo, versioniert, im gleichen Diff.
Zweitens: Verschieben Sie den Fokus des Reviews. Wenn generierter Code sauber aussieht und Stilfragen erledigt sind, ist die Zeile die falsche Betrachtungsebene. Interessant ist die Entscheidung. Ist das der richtige Ansatz für dieses Problem? Passt das zu dem, was wir an anderer Stelle machen? Was ist der Radius, wenn es schiefgeht? Ein Reviewer, der diese drei Fragen stellt, ist wertvoller als einer, der Formatierung anmerkt, und er wird von generiertem Code weniger geblendet.
Drittens: Machen Sie die Gates objektiv. Ein Gate, das eine Person nach Gefühl passieren lässt, skaliert nicht gegen ein Volumen, das sich verdoppelt. Entweder es ist maschinell entscheidbar, oder es hat eine dokumentierte, prüfbare Begründung. Alles dazwischen ist Hoffnung mit Prozessanstrich.
Nichts davon ist neu. Es sind dieselben Prinzipien, die vorher schon galten. Der Unterschied ist, dass Sie früher damit durchgekommen sind, sie nicht ernst zu nehmen, weil das Tempo niedrig genug war, dass Menschen die Lücke gefüllt haben. Dieser Puffer ist weg.
Die Frage, die zählt
Der EU AI Act und die Debatte um KI-Governance drehen sich fast vollständig um KI als Produkt. Welche Risikoklasse hat Ihr Modell, welche Pflichten folgen daraus. Das ist relevant, wenn Sie KI-Systeme in Verkehr bringen. Für die meisten mittelständischen Softwarehäuser ist KI aber zuerst etwas anderes: ein Werkzeug in der eigenen Fertigung. Dafür gibt es keine Risikoklasse und keine Checkliste, und trotzdem ist es der Punkt, an dem KI Ihre Auslieferung real verändert.
Wenn Sie einen Indikator wollen, dann nicht die Quote generierten Codes. Nehmen Sie stattdessen eine beliebige Änderung, die im letzten Quartal in Produktion gegangen ist. Nicht die, auf die Sie stolz sind, eine zufällige. Und beantworten Sie in fünf Minuten drei Fragen: Wer hat sie freigegeben. Warum sieht sie so aus. Was wurde vor dem Deployment geprüft.
Wenn Sie das können, ändert KI für Sie erstaunlich wenig. Ihre Disziplin trägt auch bei höherem Tempo.
Wenn Sie es nicht können, dann haben Sie dieses Problem nicht wegen KI. Sie hatten es vorher. KI hat es nur schneller sichtbar gemacht, und das ist, ehrlich gesagt, der nützlichste Beitrag, den sie in diesem Punkt leisten konnte.
Unternehmensprofil
MHM Digitale Lösungen UG entwickelt GitSecOps, ein Framework für nachweisfähige Software-Auslieferung. Wir machen Compliance technisch auditierbar: Repository-Analyse, Security-Checks und Deployment-Transparenz aus einer Quelle. Sitz in Essen. Wir ersetzen keine Rechtsberatung und keine formale Zertifizierungsprüfung.
Kontakt
Manuel Engelhardt
MHM Digitale Lösungen UG
Geschäftsführer
mm@mhm-dl.de