Unsere Entwickler sparen mit KI mehrere Stunden pro Woche. Und keiner von ihnen würde eine Zeile dieses Codes ungeprüft ausliefern. Beides stimmt gleichzeitig.
Die meisten Diskussionen über KI in der Entwicklung bleiben in der ersten Hälfte dieses Satzes hängen – bei der Zeitersparnis. Die interessante Geschichte steckt in der zweiten. Denn der eigentliche Engpass KI-gestützter Entwicklung ist nicht, wie gut ein Modell schreibt. Es ist, wie schnell und mit wie wenig Aufwand man prüfen kann, ob das Geschriebene stimmt.
Der häufigste KI-Fehler in der Entwicklung
Wer KI-generiertem Code misstraut, denkt zuerst an Halluzination: erfundene Funktionen, veraltete Bibliotheken, Code, der einfach falsch ist. Das kommt vor. Aber in der Praxis eines erfahrenen Teams ist es selten der Hauptträger.
Der häufigste Fehler ist das Gegenteil von zu wenig. Es ist zu viel. Die KI baut einen Generator, den niemand bestellt hat. Sie löst ein kleines Problem mit einer großen, eleganten Maschinerie. Sie verliert auf halbem Weg den roten Faden und verkompliziert, was simpel hätte bleiben sollen. Über-Engineering und Kontextverlust gehören zum Fehlerprofil, das uns regelmäßig begegnet, nicht die spektakuläre Erfindung.
Mit dieser Beobachtung stehen wir nicht allein. Carson Gross, der Erfinder von htmx, hat es kürzlich treffend formuliert: Sprachmodelle kennen keine Angst vor Komplexität und produzieren trotzdem unermüdlich Code. Genau diese Mischung macht sie gefährlich. Komplexität bleibt der härteste Gegner langlebiger Software, und ein Werkzeug, das sie ohne Hemmung vermehrt, braucht eine feste Hand.
Deshalb folgt unser Arbeitsmodell einer einfachen Linie: Die KI bekommt die wiederkehrende, gut umrissene Arbeit. Architektur, Kernlogik und Business-Rules bleiben beim Menschen. Nicht aus Prinzipientreue, sondern weil genau dort der Schaden entsteht, wenn etwas danebengeht.
Warum ein besseres KI-Modell das Vertrauensproblem nicht löst
Man könnte annehmen, all das erledige sich mit der nächsten Modellgeneration. Tut es nicht – und der Grund ist aufschlussreich.
Unsere Entwickler halten die Qualität des Outputs für durchaus ordentlich. Und vertrauen ihm trotzdem nicht ungeprüft. Diese beiden Dinge hängen weniger zusammen, als man denkt. Vertrauen ist keine Funktion von Qualität, sondern von Prüfbarkeit. Ein besseres Modell macht den Code vielleicht besser. Prüfbar – im Sinne von „ich kann mit vertretbarem Aufwand sicher sein, dass das stimmt" – macht es ihn nicht.
Wer auf das nächste Modell wartet, um das Vertrauensproblem zu lösen, optimiert deshalb die falsche Variable.
KI spart keine Arbeit. Sie verschiebt sie.
„Mehrere Stunden pro Woche" ist eine Brutto-Zahl. Was die KI an Schreibarbeit abnimmt, gibt sie zu einem Teil als Prüfarbeit zurück. Die Arbeit verschwindet nicht. Sie wandert vom Schreiben zum Prüfen. Und das Prüfen kostet Konzentration, Kontextwechsel und Sorgfalt, die in keiner Zeitersparnis-Statistik auftaucht.
Erschwerend kommt eine alte Wahrheit hinzu, die unter KI neue Schärfe gewinnt: Fremden Code zu lesen und zu verstehen ist anstrengender, als eigenen zu schreiben. Und was eine KI erzeugt, ist immer fremder Code, auch wenn er auf dem eigenen Bildschirm steht.
Wer nur die Schreibseite misst, feiert einen Gewinn, dessen Kehrseite er nicht sieht. Die ehrliche Konsequenz: Die Prüfseite muss man genauso ernst nehmen wie die Schreibseite. Sonst frisst der Korrekturaufwand den Geschwindigkeitsgewinn still wieder auf.
Vertrauen in KI-Code aufbauen: Prüfbarkeit und geteilter Kontext
Wenn Vertrauen von Prüfbarkeit kommt und sich die Arbeit zum Prüfen verschiebt, dann ist klar, wo der Hebel liegt. Und es ist nicht das nächste Tool-Abo. Es sind zwei Dinge.
Erstens: Verifikation günstig und automatisch machen.
Maschinen-prüfbare Qualitäts-Gates, die im CI blockieren – über alle Sprachen im Stack hinweg. Was eine Maschine zuverlässig prüfen kann, sollte sie prüfen, statt es einem Menschen im Review aufzuhalsen. Das senkt die Kosten des Prüfens. Und mit sinkenden Prüfkosten steigt, was man der KI überhaupt anvertrauen kann. Verifikation ist kein Bremsklotz für Geschwindigkeit – sie ist ihre Voraussetzung.
Zweitens: Kontext teilen.
Der größte ungehobene Hebel sitzt nicht im Modell, sondern im Team. KI wird meist als private Beziehung zwischen einem Entwickler und einem Tool genutzt: Prompts, Kontext, gelernte Eigenheiten.Alles bleibt im Kopf des Einzelnen. Der gefühlte Engpass ist fast nie ein fehlendes Feature, sondern fehlender geteilter Kontext. Aus vielen Einzel-Piloten eine geteilte Team-Fähigkeit zu machen, ist der Schritt, der den nächsten echten Sprung bringt – nicht das stärkere Modell.
Dazwischen, als Rahmen für beides: klar abgesteckte No-Go-Bereiche und obligatorisches Review. Nicht als Misstrauensbekundung gegen die Technologie, sondern als das, was sie nutzbar macht.
Das eigentliche Paradox: Wo KI-generierter Code sicher ist und wo nicht
Ein Gedanke aus unserem Team bringt die Grenze auf den Punkt, sinngemäß:
Ich muss bewerten können, was die KI getan hat. Und das kann ich nicht, wenn ich erst durch die KI verstehe, was sie getan hat.
Darin steckt das eigentliche Paradox. KI ist genau dort sicher, wo man die Aufgabe auch selbst gekonnt hätte, weil man das Ergebnis dann beurteilen kann. Und genau dort unsicher, wo sie am verlockendsten wäre: bei dem, was man selbst nicht beherrscht. Sie hebt die Decke dessen, was ein kompetenter Mensch schafft. Sie senkt nicht den Boden an Kompetenz, den es braucht, um zu urteilen.
Deshalb gehören Lern- und Verständnissituationen für uns bewusst nicht in die Hand der KI. Wer aufhört, selbst zu verstehen, verliert irgendwann die Fähigkeit, das KI-Ergebnis zu prüfen – und damit die Grundlage von allem, was darüber steht.
Fazit
Vertrauen in KI-generierten Code ist keine Eigenschaft des Modells. Es ist eine Bauleistung aus Prüfbarkeit, geteiltem Kontext und klaren Grenzen.
Für alle, die selbst Software bauen: Das ist die Arbeit, die zählt. Nicht das Tool, sondern das System drumherum.
Und für alle, die Software bauen lassen: Fragt einen Dienstleister nicht, welche KI er einsetzt. Fragt ihn, was zwischen dem KI-Output und eurer Produktion steht. Die Antwort darauf sagt euch mehr über die Verlässlichkeit des Codes als jeder Modellname.
