Ist Code-Qualität noch wichtig, wenn KI den Code schreibt? Oder kümmert sich die KI inzwischen selbst darum? Aktuell gibt es zwei Lager.
Die einen sagen: Die Modelle sind so gut, dass du einfach drauflos prompten kannst, ohne dir anzuschauen, was im Hintergrund passiert. Und im Zweifel setzt du am Ende einen zweiten Agent drauf, der alles prüft.
Die anderen sagen: Coding Agents haben immer noch massive Probleme. Sie neigen zu Overengineering, nehmen Abkürzungen, beschönigen ihre Ergebnisse, drehen sich in Fehlerschleifen und vergessen Dinge. Ohne strukturiertes System baust du auf Sand.
Die ehrliche Antwort ist: Es kommt darauf an. In diesem Artikel schauen wir uns an, worauf genau, damit du einschätzen kannst, wie viel Qualität dein eigenes Projekt braucht. Den Rahmen dafür liefert ein Talk von Max Kanat-Alexander, Autor und Software Engineer bei Capital One.
Warum Code-Qualität überhaupt wichtig ist
„Sauberer Code fühlt sich gut an“ reicht als Begründung nicht. Alles, was du mit Software erreichen willst, hängt an zwei Dingen: Du musst dein System verstehen, und du musst auf Basis dieses Verständnisses handeln können. Tests, Debugger und Monitoring gibt es im Kern nur dafür.
Verstehen heißt konkret, zwei Fragen beantworten zu können:
- Was macht mein System wirklich, wenn es läuft, unabhängig von irgendeiner Dokumentation?
- Wie ändere ich es, ohne dabei etwas kaputt zu machen?
Bei einem kleinen Helfer für dich selbst ist das trivial. Bei einer produktiven App, die über Jahre gewachsen ist, kann irgendwann niemand mehr das ganze System im Kopf behalten. Du brauchst also eine Struktur, die die Anwendung in verständliche Bausteine zerlegt. Genau das meinen Begriffe wie Lesbarkeit und Testbarkeit.
Jede Änderung hat zwei Risiken
Wichtig wird das vor allem, wenn du etwas änderst. Jede Änderung trägt zwei Risiken:
- Du verursachst ein Problem. Ein Bug entsteht, die Umsetzung dauert dreimal so lange wie geplant, es tritt unerwartetes Verhalten auf oder das Budget läuft aus dem Ruder.
- Du machst das System schwerer verständlich. Damit wird jede künftige Änderung riskanter. Du baust technische Schulden auf.
Das zweite Risiko füttert das erste. Je schwerer dein System zu verstehen ist, desto mehr Probleme verursachst du, und die machen es wieder schwerer verständlich. Das schaukelt sich auf, bis irgendwann jede Änderung ein Problem verursacht.
Das beste Bild dafür ist der Kabelsalat unter meinem Schreibtisch. Bei den ersten zwei Geräten weiß ich genau, welcher Stecker wohin gehört. Wenn ich aber Gerät um Gerät dazustecke, weiß ich irgendwann nicht mehr, welcher Stecker zu welchem Gerät gehört. Und wenn ich die Lampe ausstecken will, ziehe ich aus Versehen den Monitor.
Wenn bei dir am Anfang alles super lief und Claude oder Codex irgendwann beim Fixen eines Bugs ein anderes Feature kaputt gemacht hat, ist das genau dieser Effekt. Die typischen Probleme von Coding Agents wie stille Annahmen, Overengineering, Abkürzungen und vergessener Kontext machen ein System schwerer verständlich. Und weil Agents Code viel schneller produzieren, als du ihn prüfen oder verstehen kannst, beschleunigen sie diesen Kreislauf.
Wie gut ist der Code von Claude Code, Codex & Co.?
Es gibt einige aktuelle Analysen dazu. In einem Punkt sind sich alle einig: Syntaktisch korrekten Code schreiben die Modelle heute zuverlässig. Veracode bezeichnet das in seinem aktuellen Report als praktisch gelöst.
Auch bei der Qualität gibt es Fortschritte. Sonar hat Claude Opus 5.5 mit seinem Vorgänger Opus 5 verglichen. Das neue Modell schreibt für dieselben Aufgaben gut ein Viertel weniger Code und hat deutlich weniger Auffälligkeiten. Trotzdem besteht noch etwa jede achte Lösung ihre Tests nicht.
Anders sieht es bei der Sicherheit aus:
- Endor Labs hat Claude Code mit Opus 5.5 an echten Aufgaben in echten Open-Source-Projekten getestet. Der Code funktionierte in knapp 70 % der Fälle, war aber nur in rund einem Drittel der Fälle auch sicher. Codex mit GPT-6 Astra lag bei der Sicherheit fast gleichauf.
- Veracode zufolge hat sich die Sicherheitsquote über alle getesteten Modelle in vier Jahren kaum bewegt.
- Die Software Improvement Group hat über 400 Milliarden Zeilen echter Unternehmenssoftware ausgewertet. KI-generierter Code hat dort rund doppelt so viele Sicherheitsverstöße wie von Menschen geschriebener Code, ist schwerer wartbar, und der Abstand wird größer, je größer die Codebasis ist.
Fairerweise muss man sagen: Sonar, Endor Labs und Veracode verkaufen selbst Werkzeuge für Code-Analyse und Sicherheit. Die Zahlen sind also mit Vorsicht zu genießen. Der Trend ist aber bei allen derselbe.
Damit haben beide Lager vom Anfang ein Stück weit recht. Claude Code und Codex liefern inzwischen zuverlässig funktionierenden Code. Aber funktionierender Code und sicherer, wartbarer Code sind zwei verschiedene Dinge, und da ist noch Luft nach oben.
Wegwerf-Software: Wann Code-Qualität egal ist
Vielleicht lösen künftige Modelle das, vielleicht auch nicht. Spannend finde ich, dass Coding Agents eine neue Kategorie von Software geschaffen haben: Wegwerf-Software.
Das ist Software, bei der eigentlich nichts passiert, wenn sie ausfällt. Kaum jemand hängt davon ab, kein anderes System greift darauf zu, und du kannst sie in ein paar Minuten oder Stunden neu entwickeln. Wartung kostet dich praktisch nichts.
Beispiele dafür habe ich im Artikel zu macOS-Apps mit AI gezeigt: kleine persönliche Tools, die meine Systemleistung überwachen, meinen Festplattenspeicher analysieren oder mir eine KI-gestützte Spracheingabe geben. Bei solcher Software ist Code-Qualität egal, weil sich die Risiken über die Zeit gar nicht erst aufschaukeln können.
Verwechseln solltest du das aber nicht mit produktiver, langlebiger Software, die jahrelang läuft, von vielen genutzt wird und deren Ausfall richtig teuer werden kann. Das ist die wichtigste Art von Software überhaupt.
Vier Fragen für dein Projekt
Wo dein Projekt steht, kannst du mit vier Fragen einschätzen:
- Was passiert, wenn die Software ausfällt?
- Wie teuer wäre es, sie neu zu entwickeln?
- Wer oder was hängt davon ab? Also Menschen, aber auch andere Systeme.
- Wie viel Wartung braucht sie?
Lautet die Antwort überall „wenig“, hast du Wegwerf-Software. Lautet sie überall „viel“, hast du langlebige Software. Dazwischen gibt es ein ganzes Spektrum. Je näher dein Projekt an der langlebigen Seite liegt, desto mehr Sorgfalt braucht es bei Planung und Entwicklung.
Genau hier sehe ich bei vielen das Problem: Sie entwickeln ein Software-as-a-Service für echte Kund:innen, gehen aber vor wie bei Wegwerf-Software. Sobald du echte Kundendaten verarbeitest oder echte Kund:innen im Spiel sind, solltest du dein Projekt wie langlebige Software behandeln.
Wie ich Qualität mit Claude Code günstig mache
Egal, wo dein Projekt auf dem Spektrum liegt: Entscheidend ist, dass Sorgfalt dich möglichst wenig kostet. Wenn Qualität praktisch nichts kostet, ist es auch egal, wenn aus einem Wegwerf-Tool später doch ein Produkt wird. Deine Hebel dafür sind Standards, automatische Checks, Tests und Leitplanken, die von Anfang an greifen.
So sieht das bei mir aus:
Kontext und fester Ablauf
Unabhängig vom Stack nutze ich Context Management und einen standardisierten Workflow. Meine CLAUDE.md (oder bei anderen Agents die entsprechende AGENTS.md) hat eine feste Struktur: Projektbeschreibung, Tech-Stack, Verhaltensregeln und Projektstruktur.
Claude entwickelt in einem festen Zyklus: Anforderungen als Spezifikation, Aufgabenplanung, Umsetzung, Qualitätssicherung und Deployment. Für jedes Feature beginnt dieser Zyklus von vorn.
Eine Spezifikation pro Feature
Bevor Claude die erste Zeile Code schreibt, gibt es für jedes Feature eine Spezifikation. Sie beschreibt, was das Feature tun muss, welche Edge Cases es gibt und woran ich erkenne, dass es fertig ist. Dafür habe ich mir einen eigenen Skill mit einem Spec-Template gebaut, damit am Ende immer gleich aufgebaute, prüfbare Anforderungsdokumente entstehen. Ein Template zum Mitnehmen findest du im Artikel zu macOS-Apps mit AI.
Teil jeder Spezifikation sind Acceptance Criteria, die der Agent selbst testen kann und die ich später bei der Abnahme prüfe.
Tests und ein unabhängiger Prüf-Agent
Für jede Funktion werden Tests geschrieben, entweder vorher nach dem Prinzip von Test-Driven Development oder danach. Die abschließende Prüfung übernimmt ein separater Agent, der nur die Spezifikation und das fertige Ergebnis kennt, nicht aber den Weg dorthin. Er prüft jedes Acceptance Criterion, sucht aktiv nach Sicherheitslücken und schreibt mir einen Testbericht, mit dem ich die Qualität selbst einschätzen kann.
Mehr zu Regressions-, Integrations- und End-to-End-Tests findest du im Artikel zu Testing mit Claude Code.
Automatische Checks nach jeder Umsetzung
Zusätzlich läuft ein Linter, also ein Programm, das deinen Code automatisch auf Fehler und Regelverstöße prüft. Dazu kommt zum Beispiel ein TypeScript-Typcheck, der merkt, wenn du irgendwo eine Zahl erwartest, aber Text übergibst. Nach jeder Umsetzung laufen Linter, Typprüfung und Tests automatisch, ohne dass ich daran denken muss.
Wenn du so einen automatisierten Ablauf mit Claude Code, Codex & Co. aufsetzen willst, von der Spezifikation über die Planung und Umsetzung bis zur Qualitätssicherung, schau dir meinen kostenlosen AI Engineering Blueprint an. Dort steht genau, wie du vorgehst.
Fazit
Ist Code-Qualität wichtig, wenn KI den Code schreibt?
- Bei Wegwerf-Software: Nein, da ist sie wirklich egal.
- Bei Software, die lange produktiv genutzt wird: Ja, unbedingt. Dazu gehört jedes Software-as-a-Service mit echten Kundendaten.
Und Qualität muss nicht teuer sein. Standards wie Spezifikationen, Tests und automatische Checks richtest du einmal ein. Danach laufen sie bei jedem Feature im Hintergrund mit.
