Letzte Woche sagte mir ein Entwickler: „KI produziert nur Scheiße. Ich habe das letztes Jahr ausprobiert.“

Ich habe nicht widersprochen. Ich habe gefragt, womit er es ausprobiert hatte.

Er wusste es nicht mehr genau. Irgendein Chatbot. Irgendein Codegenerator. „Letztes Jahr halt.“

Das ist das erste Problem.

Letztes Jahr ist eine andere Welt

Wer ernsthaft über KI in der Softwareentwicklung urteilen will, sollte wissen, was das erste Modell war, mit dem professionelle Codeentwicklung realistisch möglich wurde. Claude 3.5 Sonnet, erschienen im Sommer 2024, war ein Wendepunkt. Nicht weil es perfekt war, sondern weil es zum ersten Mal möglich wurde, nicht-triviale Aufgaben vollständig durch ein Modell bearbeiten zu lassen, ohne dass jede zweite Zeile korrigiert werden musste. Wenige Monate später kamen Claude 3.7, GPT-4o mit verbessertem Code-Reasoning, Gemini 2.5 Pro. Jetzt, Mitte 2026, arbeiten produktive Teams mit Claude Code, Cursor, GitHub Copilot Workspace und agentenbasierten Setups, die vor zwei Jahren Science Fiction waren.

Wer mit einem Werkzeug aus 2024 eine Meinung über KI in 2026 hat, urteilt über ein Fahrrad und meint, Fahren sei grundsätzlich schwierig.

Das ist aber nur das zweite Problem. Das erste ist grundlegender.

Was passiert, wenn man einen Entwickler ohne Regeln loslässt

Stellen wir uns vor, ich sage einem Junior-Entwickler: „Kein Architekturkonzept, keine Konventionen, keine Tests. Schreib einfach los.“ Was kommt raus? Wahrscheinlich Code, der irgendwie funktioniert. Vielleicht kompiliert er sogar. Aber er ist nicht wartbar, nicht testbar, nicht erweiterbar. Nicht weil der Entwickler schlecht ist, sondern weil 45 Jahre Software Engineering aus gutem Grund Leitplanken entwickelt hat.

TDD. SOLID. Clean Code. Hexagonale Architektur. Domain-Driven Design. Continuous Integration. Diese Konzepte sind nicht Bürokratie. Sie sind geronnene Erfahrung aus Projekten, die ohne sie gescheitert sind.

Niemand würde auf die Idee kommen, einen Entwickler ohne diese Leitplanken loszuschicken und dann zu urteilen, Softwareentwicklung produziere grundsätzlich Scheiße.

Bei KI tun das fast alle.

Die KI braucht dieselben Leitplanken

Ein Sprachmodell optimiert lokal. Es löst das Problem, das vor ihm liegt. Es schreibt Code, der kompiliert. Es schreibt Tests, die grün werden. Was es nicht von sich aus mitbringt, ist Architekturkonsistenz, Trennungslinien zwischen Schichten, die Disziplin, keine Abkürzungen zu nehmen.

Das ist kein Fehler des Modells. Das ist die Natur des Werkzeugs.

Wer ArchUnit einsetzt und Architekturregeln als automatische Tests formuliert, bekommt von der KI keinen Code mehr, der die Schichtengrenzen verletzt. Der Build schlägt fehl. Die KI muss es richtig machen. Ich habe das zuletzt am Beispiel der Hexagonalen Architektur beschrieben.

Wer TDD konsequent einsetzt, zwingt die KI, zuerst das Verhalten zu spezifizieren und dann Code zu schreiben, der dieses Verhalten erfüllt. Das Ergebnis ist ein anderes als „schreib mir Funktion X“.

Wer persistente Kontext-Dateien pflegt, CLAUDE.md, CLAUDE-workflow.md, tech-spezifische Konventionsdateien, gibt der KI das Gedächtnis, das sie von Haus aus nicht hat. Nicht weil das Modell vergesslich ist, sondern weil das die richtige Arbeitsteilung ist: Regeln gehören in Dateien, nicht in Köpfe.

Meine Erfahrung

Wenn die Leitplanken stimmen, kommt guter Code raus. Nicht perfekter Code. Aber Code, der wartbar ist, der getestet ist, der Architekturregeln einhält und der von einem zweiten Modell reviewed wurde.

Wenn die Leitplanken fehlen, kommt Scheiße raus. Genauso wie bei einem Entwickler, dem man sagt, er solle alles in einer Klasse schreiben.

Das ist kein KI-Problem. Das ist ein Prozess-Problem.

Wie ein solcher Prozess konkret aussieht, mit Rollen, Artefakten, Takt-Modellen und Anti-Patterns, habe ich in einem Whitepaper ausgearbeitet: Ein Prozess zur KI-gestützten Softwareentwicklung.

Der Entwickler vom Anfang hat mir am Ende des Gesprächs gesagt, er werde es nochmal versuchen. Mit Regeln diesmal.

Ich bin gespannt.