Zählt Code-Qualität im Zeitalter der KI noch? Es kommt auf eine Sache an

Fragen Sie einen Senior Software Engineer etwas, und Sie bekommen fast garantiert seine liebste Zwei-Wort-Antwort: „Es kommt drauf an.“

Im Zeitalter von KI-Coding-Tools und „Vibe Coding“ hat die Debatte, ob Code-Qualität noch zählt, auf Social Media Fieberpitch erreicht. In einer Präsentation für den AI Engineer-Kanal geht Max Kanat-Alexander (Capital One) über die binären „Ja oder Nein“-Argumente hinaus und bietet einen konkreten Rahmen dafür, wann Engineering-Strenge kritisch ist — und wann man sie aus dem Fenster werfen kann.

Das Fundament: Warum Code überhaupt existiert

Bevor wir entscheiden, ob Code-Qualität zählt, müssen wir festlegen, was Software-Engineering-Praktiken tatsächlich erreichen wollen. Laut Kanat-Alexander läuft alles, was man mit einem Stück Software erreichen will — ob Modell ausrichten, System skalieren oder Adoption vorantreiben — auf zwei Faktoren hinaus:

Das System verstehen.
Auf Basis dieses Verständnisses ausführen.

Debugger, Observability-Tools, Evals und Tests existieren nicht im Vakuum; sie existieren ausschließlich, um unser Verständnis eines Systems und unsere Fähigkeit, darauf zu handeln, zu verbessern. Für einen Software Engineer läuft das auf zwei kritische Fragen hinaus:

Was ist das tatsächliche, konkrete Verhalten des Systems? (Nicht nur, was die Dokumentation behauptet.)
Wie ändere ich dieses Verhalten korrekt und sicher?

Während ein einfaches „Hello World“-Programm leicht vollständig zu erfassen ist, haben reale Systeme — wie die massive Open-Source-Chromium-Codebase — im Wesentlichen unendlich viele mögliche Interaktionen. Kein Mensch kann das gesamte Verhalten von Chromium im Kopf behalten. Stattdessen verlassen wir uns auf das Verständnis spezifischer Komponenten, wie eines URL-Parsers.

Deshalb existiert Code: für Struktur. Früher sprachen Engineers von Konzepten wie „Lesbarkeit“ und „Testbarkeit“, die wie rein menschliche Anliegen klingen. Was darunter immer am meisten zählte, war erkennbare, verständliche Struktur.

Der Teufelskreis des Änderungsrisikos

Struktur zählt am meisten, wenn man ein System ändern muss. Jede Änderung trägt zwei Risiken:

Ein sofortiges Problem einführen: Das ist nicht nur ein Bug — es könnte eine verpasste Deadline, Budgetüberschreitung oder fehlausgerichtetes Nutzerverhalten sein, verursacht durch die Schwierigkeit, das System zu verstehen.
Zukünftige Änderungen härter machen: Durch die Verschlechterung der Struktur macht man das System beim nächsten Mal schwerer zu verstehen.

Risiko #2 speist direkt zurück in Risiko #1 in einem zusammengesetzten, nichtlinearen Zyklus. Mit der Zeit können riesige Codebases einen Zustand erreichen, in dem jede einzelne Änderung organisatorische Reibung, Timeline-Verzögerungen oder Produktionsvorfälle auslöst.

Die große Kluft: Dauerhafte vs. Wegwerf-Software

Während Leute debattieren, ob zukünftige KI-Modelle irgendwann unendliche Kapazität haben werden, massive Komplexität zu entwirren, macht KI gerade etwas anderes: Sie macht Wegwerf-Software 100.000-mal häufiger.

Historisch haben Engineers die meiste Zeit damit verbracht, dauerhafte Software zu bauen und zu warten — Systeme, die jahrelang leben, Tausende oder Millionen Nutzer bedienen und katastrophale Geschäftsfolgen haben, wenn sie scheitern. Dauerhafte Software geht nicht weg; tatsächlich werden KI-Tools wahrscheinlich dazu führen, dass mehr dauerhafte Software gebaut wird.

Allerdings erlauben KI-Agenten uns auch, Software hochzuziehen, bei der:

Die Folgen eines Scheiterns minimal oder nicht existent sind.
Wenige Menschen (und keine anderen Produktionssysteme) davon abhängen.
Die Ersatzkosten nahe null sind (sie kann in Stunden neu gebaut werden).
Die Wartungskosten im Wesentlichen nichts sind.

Magst du deinen OS-Rechner nicht? Lass einen Agenten einen maßgeschneiderten bauen. Planst du eine Kindergeburtstagsfeier? Zieh eine One-Off-Partyplaner-App hoch und wirf sie am Montag weg. In der Welt der Wegwerf-Software zählt Code-Qualität überhaupt nicht, weil die zusammengesetzten Risiken zukünftiger Änderungen einfach nicht existieren.

Bewertungsfaktor	Wegwerf-Software	Dauerhafte Software
Folgen des Scheiterns	Minimal bis keine	Hoch / Geschäftskritisch
Abhängigkeiten	Isoliert; von einem oder wenigen genutzt	Von Tausenden/Millionen oder anderen Systemen abhängig
Ersatzkosten	Nahe null (in Stunden/Tagen ersetzbar)	Extrem hoch
Wartungskosten	Unwichtig oder nahezu gratis	Enorme laufende Investition
Benötigte Engineering-Strenge	Keine	Maximum

Zwei neue Disziplinen für modernes Engineering

Weil Wegwerf- und Dauerhaftigkeit auf einem Spektrum liegen, haben moderne Software-Teams zwei strategische Hebel, die sie ziehen können.

1. Für Wegwerf-Charakter engineering

Statt schwere Prozesse auf alles anzuwenden, können Organisationen Umgebungen architektieren, die Software absichtlich sicher zum Wegwerfen machen:

Isolierte Umgebungen: Erstelle Sandboxes, die nur auf die Daten eines einzelnen Nutzers zugreifen, mit null Zugriff auf Kundendaten oder PII.
Erzwungene Unabhängigkeit: Blockiere eingehende API-Calls von anderen Produktionssystemen, damit nichts versehentlich von einem Wegwerf-Tool abhängen kann.
Dauerhafte Redundanz: Behalte ein zuverlässiges, „klobiges“ Legacy-System als Backup, während Mitarbeiter schnelle, maßgeschneiderte Frontends für ihre eigenen Workflows „vibe coden“ dürfen. Wenn ihr maßgeschneidertes Frontend kaputtgeht, fallen sie einfach auf das dauerhafte System zurück.
Strikte Scope-Limits: Halte Tools hyper-fokussiert auf einen einzelnen Nutzer oder ein einzelnes Event.

2. Die Kosten der Strenge senken

Erfahrene Engineers wissen, dass „temporäre“ Prototypen die Angewohnheit haben, permanente Produktionssysteme zu werden. Wenn man falsch einschätzt, wo ein Projekt auf dem Spektrum liegt — oder später die Meinung ändert — will man den Übergang von Wegwerf zu Dauerhaft so schmerzfrei wie möglich. Das erreicht man, indem man Engineering-Strenge billig und mühelos macht:

Rücksichtslose Standardisierung: Sprachen, Frameworks und RPC-Protokolle zu standardisieren ist keine Bürokratie; es geht darum, Möglichkeiten zu eliminieren. Weniger Frameworks bedeuten weniger Linter, Security-Patches und maßgeschneiderte Agenten-Tools, die man warten muss.
In-Workflow-Tooling: Baue Qualitätschecks, die automatisch im Hintergrund laufen. Wenn Tooling schnell, zuverlässig, arm an False Positives und null bewussten Aufwand vom Entwickler erfordert, fühlt es sich gratis an — was bedeutet, man kann es sogar auf Wegwerf-Projekte anwenden.
Reibungslose Test-Infrastruktur: Verlange nicht, dass jeder Entwickler ein Test-Experte ist. Investiere in Infrastruktur, die Tests von Anfang an schnell und deterministisch macht — zum Beispiel durch Coding-Agenten, die automatisch In-Memory-Fake-Versionen von Services generieren und warten.
Maximale Strictness von Tag eins: Stelle alle Lint-Regeln und Strictness-Einstellungen von Tag eins auf Maximum. Das eliminiert endlose Team-Debatten und verhindert den Albtraum, einen Linter nachträglich auf eine Millionen-Zeilen-Codebase zu aktivieren.

Das Urteil

Also, zählt Code-Qualität noch? Kanat-Alexander hinterlässt uns drei klare Antworten:

Für Wegwerf-Software? Nein.
Für dauerhafte Software? Ja.
Muss Strenge teuer sein? Nein.

Basiert auf Max Kanat-Alexanders Talk für AI Engineer.