Vom Schreiben zum Verifizieren: Warum KI das Codehandwerk nicht abschafft, sondern verschiebt

Die These und ihr blinder Fleck

Hansson vergleicht den Moment mit der Erfindung der Kamera: So wie die Fotografie die Malerei abgelöst habe, löse die KI das Programmieren ab. Die Analogie trägt seine Schlussfolgerung allerdings nicht. Die Kamera hat die Malerei nicht getötet - sie hat sie von der Pflicht zur Abbildung befreit und in Impressionismus und Abstraktion verschoben. Das Handwerk ist nicht verschwunden, es hat sich verlagert. Genau das ist auch hier der Punkt.

Der Pragmatic-Engineer-Autor Gergely Orosz ordnet die Euphorie nüchtern ein: Die Qualität von Software sinkt gerade spürbar dort, wo Disziplin fehlt - er belegt es mit einem vielzitierten Entwickler-Bericht ("niemand denkt mehr", Zwölf-Stunden-Tage, nur um Enter zu drücken) und sichtbaren Fehlern in großen Apps. Seine eigentliche Schlussfolgerung ist aber die entscheidende: Software-Engineering wird nicht unwichtiger, sondern wichtiger. Es verlagert sich nur - vom Schreiben des Codes hin zum Bauen der Systeme, die generierten Code einhegen, prüfen und verantworten.

Das deckt sich mit dem, was wir in Jahren an serverloser Entwicklung und Systemmodernisierung gelernt haben. Wenn das Erzeugen von Code zur Commodity wird, wird das Verifizieren zum Beruf. Der Wert wandert von der Tastatur in die Fabrik, die den Code umgibt.

Die optimistische Gegenprobe - und warum sie dasselbe sagt

Man könnte einwenden, das sei die Sicht der Vorsichtigen. Deshalb lohnt der Blick auf die andere Seite. Der Softwareautor Dan Luu argumentiert in seinem Essay "We should be more ambitious with the software we build", die meisten Menschen trügen noch ein "prä-agentisches Kostenmodell" im Kopf: Projekte, die man früher gar nicht erst anfing - eine eigene Regex-Engine, ein spezialisiertes Werkzeug, eine Spiel-KI -, kosten heute Stunden statt eines Jahres. Sein Appell: mehr wagen, nicht weniger. Das ist das genaue Gegenteil von Kulturpessimismus - und ein nötiges Korrektiv gegen die müde Haltung, KI-Code sei grundsätzlich wertloser "Slop".

Interessant ist, wo Luu landet. Seine ambitionierten Projekte wurden nicht durch cleveres Prompten möglich, sondern durch selbstprüfende Systeme: Fuzzing, eigenschaftsbasierte Tests, Konsistenzprüfungen. Die Regeln eines chaotischen Brettspiels rekonstruierte er über Konsistenz-Checks, nicht über Eingebungen des Modells. Und er benennt ehrlich die Grenze: Die Lücke zwischen dem, was Modelle verifizieren, und dem, was sie zuverlässig implementieren können, wird größer - "es funktioniert einfach" gilt nur für die leichteren Aufgaben. Selbst der Optimist macht also die Verifikation zum eigentlichen Werkzeug. Von beiden Seiten - der warnenden und der bauenden - führt der Weg an denselben Punkt: Der Hebel sitzt im Prüfsystem.

Eine Einschränkung gehört dazu, und sie ist für den Unternehmenskontext entscheidend. Luus Welt sind persönliche "läuft bei mir"-Werkzeuge, die er selbst prüfen kann und bei denen Überanpassung und schwere Wartbarkeit kaum schaden. Er sagt selbst, solche Tools würden von der nächsten Modellgeneration schnell überholt, lange Investitionen seien riskant. Sobald jemand anderes den Code übernehmen, warten und dafür geradestehen muss - also im Geschäftsbetrieb -, kehrt genau die Disziplin zurück, die er für den Bastelfall ausklammern darf. "Mehr bauen" und "sauber verantworten" sind kein Widerspruch: Das eine gilt für das verifizierbare Einzelstück, das andere für die Codebasis, die bleiben soll.

Unser Arbeitsansatz: die Fabrik zählt, nicht die Tastatur

"Software-Fabrik" ist ein gutes Bild, aber es braucht Substanz. Aus unserer Praxis ergeben sich vier Prinzipien, die festlegen, wie wir KI, Low-Code und No-Code einsetzen - und wie nicht.

Erstens: Verbinden statt Zentralisieren. Wir setzen nicht auf eine zentrale KI oder Plattform, die alles schreibt, sondern auf saubere Bausteine über definierte Schnittstellen. KI und Low-Code kommen dort zum Einsatz, wo sie Tempo bringen - aber immer eingebettet in Freigaben, Tests und Kontrollen. Geschwindigkeit ohne Aufsicht ist keine Effizienz, sondern aufgeschobene Wartung.

Zweitens: die Verifikationsschicht ist das eigentliche Produkt. Jede Änderung läuft durch automatisierte Gates - Tests, statische Analyse, Abhängigkeits- und Secret-Scans -, und sicherheitskritische Logik geht zusätzlich durch ein menschliches Review. Besonders elegant ist dabei ein Gedanke, den Orosz pointiert formuliert: nichtdeterministische KI nutzen, um deterministische Prüfungen zu erzeugen. Statt teure, langsame KI-Reviews über jede Änderung zu schicken, setzt man die KI einmal ein, um einen Linter oder eine Testregel zu bauen - die danach billig, schnell und reproduzierbar bei jedem Commit läuft. So verlagert sich der Aufwand genau dorthin, wo er bleibt: ins Entwerfen des Prüfsystems, nicht ins Tippen.

Drittens: die richtige Werkzeugklasse für den richtigen Fall. No-Code für einfache, klar abgegrenzte Fachanwendungen. Low-Code, wo visuelle Modellierung und eigener Code sinnvoll zusammenspielen. KI-gestützte Entwicklung mit menschlicher Aufsicht für alles, was Substanz und Langlebigkeit braucht. Der Fehler ist, eine Klasse für alles zu verwenden - und sich dann zu wundern, dass die Produktivität zunächst um das Zwei- bis Dreifache springt und drei Monate später beim Hinzufügen einer Funktion etwas an anderer Stelle bricht.

Viertens: Legacy inkrementell und mit kleinem Schadensradius. Bestehende Systeme binden wir über APIs an und modernisieren sie Stück für Stück, serverlos, statt einen riskanten Komplettersatz zu wagen. So bleibt der Betrieb stabil, während sich die Architektur erneuert - und ein Fehler bleibt lokal, statt das Ganze mitzureißen.

Der Streit um die Abstraktion - und warum wir sie behalten

Ein Argument von Hansson verdient eine ernsthafte Antwort. Er sagt, Abstraktionen verlören an Sinn, weil der Preis der Wiederholung gegen null gehe - wenn die Maschine Code beliebig oft neu erzeugt, müsse man Wiederholung nicht mehr vermeiden. Auf der Erzeugungsseite stimmt das sogar. Auf der Wartungs- und Haftungsseite ist es ein Trugschluss.

Abstraktion diente nie nur der Vermeidung von Wiederholung. Sie dient der Verständlichkeit, der Änderungssicherheit und der Begrenzung des Schadensradius einer Änderung. Billig zu erzeugen heißt nicht billig zu prüfen und zu warten. Verstreute, duplizierte Logik ist genau das, was eine Codebasis unprüfbar macht - und Prüfen ist nach allem oben Gesagten der neue Engpass. Für ein Team, das am Ende für Code geradestehen muss, den eine Maschine geschrieben hat, ist billige Wiederholung eine Milchmädchenrechnung. Wir halten die Architekturdisziplin deshalb nicht trotz, sondern wegen der KI aufrecht.

Fazit

Die "Tod des Handcodings"-Rahmung ist überzogen - aber die Richtung ist real und sie beschleunigt sich. Dass selbst ein handwerksverliebter Laden wie 37signals all-in geht, erhöht den Einsatz, statt die Governance-Frage zu erledigen. Bemerkenswert ist, dass die Mahner und die Enthusiasten am selben Punkt ankommen: Ob man vor sinkender Qualität warnt oder zum ambitionierten Bauen aufruft - der Hebel sitzt im Prüfsystem. Der tragfähige Kern lautet: Das Schreiben wird billig, das Verifizieren wird zum Handwerk. Genau an dieser Stelle - zwischen Tempo und Kontrolle, zwischen Erzeugen und Verantworten - haben wir immer gearbeitet. Wer Software modernisieren will, braucht heute weniger die schnellste Codemaschine als die beste Fabrik um sie herum.