Wegwerf vs. Dauerhaft: Wann Code-Qualität mit KI-Agenten noch zählt

·4 min read·Translated

KI-Coding-Agenten haben das Volumen an Code verändert, das Teams produzieren können. Sie haben die Notwendigkeit des Urteils darüber, welcher Code Investitionen verdient, nicht entfernt.

Max Kanat-Alexanders jüngste Keynote auf der AI Engineer NYC 2026 gibt eine klare Entscheidungsregel: Code-Qualität existierte immer aus zwei Gründen — ein System zu verstehen und es sicher zu ändern. Alles andere (Struktur, Tests, Lesbarkeit, Review) dient diesen beiden Zielen.

Wenn diese beiden Ziele aufhören zu zählen, hört Qualität auf zu zählen.

Wegwerf-Software ist jetzt das Standardvolumen

Kanat-Alexander beschreibt eine Kategorie, die immer existiert hat, aber gerade dabei ist, weitaus häufiger zu werden: Wegwerf-Software.

Sie hat:

  • Minimale oder null Konsequenzen, wenn sie scheitert
  • Wenige (oder keine) menschlichen oder System-Abhängigen
  • Nahezu null Kosten, um sie wegzuwerfen und neu zu generieren
  • Im Wesentlichen keine langfristige Wartungslast

In dieser Welt verschwinden die kumulativen Risiken, die Qualitätspraktiken verhindern sollten, weitgehend. Man kann den Output als temporär behandeln. Agenten machen diese Kategorie im großen Maßstab praktisch, weil Regeneration billig ist.

Dauerhafte Software ist das Gegenteil: langlebig, viele Abhängige, echte Produktionskonsequenzen, hohe Kosten für verlorenes Verständnis. Für diese Software zählt Qualität noch — und in mancher Hinsicht mehr, weil die Kosten der Opazität nichtlinear compoundieren.

Die praktische Frage für Teams ist nicht länger „zählt Qualität?“. Es ist „welche Teile unseres Systems sind wegwerfbar, und welche sind dauerhaft?“

Keynote ansehen: Does Code Quality Still Matter? — Max Kanat-Alexander

Software-Fabriken passen zur Unterscheidung

Aktuelle Talks über agentische Workflows zeigen in dieselbe Richtung.

David Ondrejs Framing von Software-Fabriken (Sammlungen von Agenten-Loops mit Triggern, Skills, Checks und menschlichen Gates) ist am nützlichsten, wenn der Fabrik erlaubt wird, viel wegwerfbaren Zwischenarbeit zu produzieren, während der dauerhafte Kern geschützt wird. Geplante Checks, Bug-Triage, explorative Prototypen und One-Off-Analysen können mit leichteren Standards laufen. Architekturänderungen, geteilte Bibliotheken und Produktions-Control-Planes können das nicht.

Kerim Satirli (HashiCorp) beschreibt, Agenten mehr wie eine eingeschränkte CI/CD-Pipeline zu behandeln als wie einen freien Junior Engineer. Prompt-Regeln sind Bitten; harte Constraints und deterministische Checks sind die echten Guardrails — besonders auf Infrastruktur, die von Natur aus dauerhaft ist.

Carlos Kelkbooms Regel — generierten Code wegwerfen, sobald man ihn nicht versteht — ist eine direkte Anwendung der Wegwerf/Dauerhaft-Spaltung. Wenn man es nicht erklären kann, gehört es nicht in die dauerhafte Oberfläche.

Praktische Regeln, die daraus folgen

  1. Klassifiziere, bevor du generierst. Für jede nicht-triviale Arbeit entscheide im Voraus: erwartete Lebensdauer, Blast Radius, Anzahl der Abhängigen, Ersatzkosten. Schreib es auf.
  2. Halte überall einen Sicherheitsboden. Selbst Wegwerf-Code sollte keine Credentials leaken, destruktive Operationen ohne Bestätigung öffnen oder Secrets in Logs hinterlassen. Sicherheit und Privatsphäre sind nicht optional, nur weil der Code temporär ist.
  3. Konzentriere Strenge auf die dauerhafte Oberfläche. Tests, Ownership, Observability, Review und klare Struktur gehören zu den Teilen, die in einem Jahr noch da sein werden und von denen andere Systeme abhängen.
  4. Mache Strenge billig. Kanat-Alexanders zweiter Hebel ist, die Kosten des richtigen Handelns zu senken: Standards, In-Workflow-Tooling, einfaches Testen und maximale Strictness, damit der Weg des geringsten Widerstands der sichere ist. Das hält dauerhafte Arbeit davor, zum Engpass zu werden.
  5. Designe für Wegwerf, wo es hilft. Isoliere Experimente, halte Kopplung niedrig, bevorzuge Regeneration gegenüber heldenhafter Wartung von Wegwerf-Skripten und vermeide, Wegwerf-Code versehentlich in den dauerhaften Kern zu befördern.

Wie das neben der Engpass-Sicht sitzt

Ein früherer Post behandelte, wie der Engpass vom Schreiben von Code zu Review, Vertrauen und Verifikation gewandert ist. Der Wegwerf/Dauerhaft-Rahmen fügt die fehlende Klassifikation hinzu: Nicht jede generierte Änderung verdient dasselbe Verifikationsbudget. Teams, die alles als dauerhaft behandeln, ertrinken im Review. Teams, die alles als wegwerfbar behandeln, akkumulieren undurchsichtige, hochriskante Systeme.

Die hochhebende Fähigkeit ist, die beiden korrekt zu sortieren und dann Agenten-Fabriken laufen zu lassen, die auf der Wegwerf-Seite frei generieren, während sie Verständnis und Änderungssicherheit auf der dauerhaften Seite schützen.

Quellen:

Share