AI schreibt Code. Entwickler entwickeln Software.

AI hat das Programmieren nicht beendet. Sie hat die Vorstellung beendet, dass es beim Programmieren hauptsächlich darum geht, Code einzutippen. Dieser Unterschied ist wichtig. In vielen aktuellen Diskussionen über AI wird Softwareentwicklung noch immer so behandelt, als bestünde der größte Mehrwert darin, schneller mehr Codezeilen zu produzieren. Die vorherrschende Logik: jedem Entwickler einen Coding-Assistenten geben, mehr Features generieren, mehr Pull Requests ausliefern und steigende Produktivitätskurven feiern. 

Doch Softwareorganisationen leiden selten darunter, dass sie zu wenig Code haben. Meist haben sie zu viel Code, den sie nicht vollständig verstehen, nicht sicher ändern, nicht richtig testen und keinem klaren geschäftlichen Ergebnis zuordnen können. Wenn ich AI falsch einsetze, verschärft sie dieses Problem nur. Code wird im Überfluss verfügbar, während echtes Engineering knapp wird. 

Das Zeitalter des Code-Überflusses

Während des größten Teils der Geschichte der Softwareentwicklung war es aufwendig, Code zu schreiben. Dafür brauchte man Menschen, die Sprache, Frameworks, Bibliotheken, Muster und Eigenheiten des Systems genau kannten. Selbst für ein kleines Feature musste jemand das Problem durchdenken, die Implementierung schreiben, Syntaxfehler beheben, Tests ausführen und die Änderung durch den Review-Prozess bringen.

AI-Coding-Tools haben diese Wirtschaftlichkeit grundlegend verändert. Heute kann ein Entwickler einen Assistenten bitten, eine React-Komponente zu generieren, das Grundgerüst für eine API zu erstellen, Tests zu migrieren oder eine Legacy-Funktion zu erklären. Die Ergebnisse sind nicht immer korrekt, aber sie entstehen unglaublich schnell. So zeigen beispielsweise aktuelle GitHub-Daten, dass Entwickler mit AI-Assistenten bis zu 55 % schneller programmieren und aus einer API-Grundstruktur, die früher drei Tage dauerte, Arbeit für einen Vormittag wird.

Ich will nicht behaupten, dass Geschwindigkeit nicht nützlich ist. AI nimmt langweilige Aufgaben ab, beschleunigt die Einarbeitung in unbekannte Codebases und hilft Nicht-Muttersprachlern, verständlichere Dokumentation zu schreiben. Sie kann eine grobe Absicht einfach in einen brauchbaren Ausgangspunkt verwandeln.

Doch Code im Überfluss schafft einen neuen Engpass. Die zentrale Frage lautet nicht mehr: Können wir das schreiben? Stattdessen müssen Teams fragen:

• Sollte es das überhaupt geben?

• Passt es zur Architektur?

• Löst es das tatsächliche Problem?

• Können wir es sicher testen und betreiben?

• Kann die nächste Person es verstehen und später ändern?

Das sind Engineering-Fragen, keine Fragen des Codens.

AI Slop ist Code ohne Engineering

„AI Slop“ ist nicht einfach nur hässlicher Code. Es ist Code, der ohne ausreichenden Kontext, klare Vorgaben, Verantwortlichkeit oder Feedback entsteht. Er kompiliert vielleicht oder besteht einen einfachen Test, gehört letztlich aber nicht in das System.

Das passiert, wenn ein AI-Assistent eine neue Abstraktion erfindet, weil er die bestehende nicht verstanden hat, oder wenn ein Pull Request unnötige Abhängigkeiten hinzufügt, um ein Problem zu lösen, das die Plattform bereits abdeckt. Es passiert, wenn Tests direkt aus der Implementierung statt aus der Anforderung generiert werden und damit im Grunde nur bestätigen, dass sich der generierte Code wie er selbst verhält. Besonders gefährlich ist es, wenn Entwickler riesige Patches akzeptieren, nur weil es länger dauern würde, sie sorgfältig zu lesen, als ein Modell zu bitten, sie zu schreiben. Dann bleibt Code zurück, der in einer Demo funktioniert, in der Produktion aber auf rätselhafte Weise versagt.

Das ist Output-Management, nicht Software Engineering, und Output-Management lässt sich nicht skalieren. Je mehr Code AI produzieren kann, desto wichtiger wird es, konsequent zu kontrollieren, welcher Code in das System gelangen darf.

Die Aufgabe von Programmierern verlagert sich in höhere Ebenen

Diese Veränderung macht Entwickler nicht weniger wichtig. Sie verlagert ihre wertvolle Arbeit lediglich in höhere Ebenen. Je weniger zentral das manuelle Tippen von Codezeilen wird, desto wichtiger wird ein tiefes Verständnis des Systems. Der Mehrwert von Engineers verlagert sich von der Codeproduktion hin zur Gestaltung von Veränderungen.

Dazu gehört:

• Die Domäne gut genug zu verstehen, um zu wissen, welche Probleme tatsächlich lösenswert sind.

• Klare Grenzen zwischen Systemen, Services und Verantwortlichkeiten zu definieren.

• Vage Anfragen in präzise, testbare Absichten zu übersetzen.

• AI-Tools mit genauem Kontext zu versorgen, statt darauf zu hoffen, dass sie ihn selbst ableiten.

• Robuste Feedbackschleifen durch Tests, CI/CD, Observability und Produktionsmetriken zu gestalten.

Hier wird die Bedeutung des Wortes Engineer wirklich deutlich. Ein Programmierer bittet AI, ein Feature zu entwickeln. Ein Engineer fragt, ob das Feature überhaupt ins Produkt gehört, wo es angesiedelt werden sollte, wie es bei Fehlern reagieren soll, was sein Betrieb kostet und welche künftigen Änderungen es erleichtert oder erschwert. AI senkt die Einstiegshürde für die Codeerstellung, erhöht aber nicht automatisch die Obergrenze für Softwarequalität. Diese Obergrenze hängt weiterhin vollständig vom technischen Urteilsvermögen von Menschen ab.

Orchestrierung ist die neue Kernkompetenz

Die besten Entwickler, die ich beim Einsatz von AI beobachte, verlangen nicht nach riesigen magischen Codeblöcken. Stattdessen orchestrieren sie kleine, kontrollierte Schritte.

Sie liefern Kontext, verlangen, dass das Tool bestehenden Code prüft, bevor es Änderungen vornimmt, und grenzen die Lösung ein. Sie trennen die Erstellung von Tests von der Implementierung, lesen die Diffs sorgfältig und lehnen Code, der plausibel aussieht, aber nicht zum System passt, konsequent ab. Dieser Workflow ähnelt weniger einer Autovervollständigung als der Betreuung eines blitzschnellen Junior-Entwicklers, der das gesamte Internet gelesen hat, aber nichts über eure Produktionsumgebung weiß.

Wenn ich Engineering-Teams zur Einführung von AI schule, zeige ich ihnen, dass effektives AI-gestütztes Engineering in der Regel diesem Muster folgt:

1. Beschreibt das gewünschte Verhalten in einfacher Sprache.

2. Lasst das Tool relevanten Code prüfen und das aktuelle Design zusammenfassen.

3. Erstellt oder aktualisiert zuerst die Tests, idealerweise in einem separaten Schritt.

4. Generiert die kleinstmögliche Implementierung, die diese Tests erfüllt.

5. Führt die üblichen manuellen Prüfungen durch: Linting, Typprüfungen, Sicherheitsscans und Pipeline-Validierung.

6. Prüft den Diff auf Architektur, Lesbarkeit und langfristige Wartbarkeit.

7. Dokumentiert alles, was der nächste Entwickler wissen muss.

Nichts davon ersetzt den Engineer. Im Gegenteil: Seine Verantwortung steigt, denn wenn AI den Code generiert, trägt weiterhin der Mensch die Verantwortung für das Ergebnis.

Unternehmen müssen aufhören, die falschen Dinge zu messen

Das größte Risiko von AI-Coding-Tools ist nicht die Bequemlichkeit der Entwickler. Das größte Risiko besteht darin, dass Unternehmen die falschen Verbesserungen messen.

Wenn das Ziel mehr Code, mehr Pull Requests oder mehr Features sind, wird AI genau das liefern – einschließlich Features, die niemals hätten entwickelt werden sollen. Software Delivery ist jedoch eine Disziplin des Änderungsmanagements und kein Tippen um die Wette. Die Frage ist nicht, wie viel schneller wir Code erstellen können, sondern wie viel schneller wir sichere, wertvolle und wartbare Änderungen bereitstellen können.

Dafür ist ein grundlegend anderes Betriebsmodell erforderlich. Teams brauchen Coding-Standards, denen AI-Tools folgen können, ausreichend aktuelle Architekturdokumentation und CI/CD-Pipelines, die schnell Feedback liefern. Sie brauchen verhaltensgesteuerte Tests, Review-Praktiken, die Risiken stärker gewichten als Stil, sowie Observability, um zu bestätigen, dass eine Änderung in der Produktion tatsächlich funktioniert hat.

Mit anderen Worten: Sie brauchen mehr denn je eine starke DevOps-Disziplin. AI ersetzt keine guten Praktiken für Software Delivery, sondern bestraft ihr Fehlen gnadenlos. Bei der Prüfung der CI/CD-Pipelines von Kunden stellte ich fest, dass schnellere, von AI generierte Pull Requests ihre Deployment-Fehlerrate um 20 % erhöhten, weil ihre automatisierten Tests nicht mithalten konnten.

Erfolgreiche Teams entwickeln ihr System rund um AI

Bei der Einführung von AI gibt es einen verlockenden, gefährlichen Ansatz: Ein Unternehmen kauft Lizenzen, aktiviert die Tools und wartet einfach darauf, dass die Produktivität in die Höhe schnellt.

Ein Teil davon wird eintreten. Einzelne Entwickler werden schneller arbeiten, kleine Aufgaben werden einfacher und Demos werden beeindruckend aussehen. Der langfristige Vorteil wird jedoch nicht daraus entstehen, dieselben AI-Tools wie eure Wettbewerber zu haben, sondern aus dem Engineering-System, das ihr um diese Tools herum aufbaut.

Dieses System umfasst:

• Klare Regeln dafür, wo AI eingesetzt werden darf und wo nicht.

• Sicheren Zugriff auf Repositories, Dokumentation und Umgebungen.

• Leitplanken für generierten Code, Abhängigkeiten und Secrets.

• Teststrategien, die AI-Halluzinationen frühzeitig erkennen, und CI/CD-Pipelines, die Änderungen mit AI-Unterstützung nicht umgehen können.

• Architekturentscheidungsprotokolle und Standards, die für die Verarbeitung durch Tools ausgelegt sind.

• Eine Kultur, in der Entwickler weiterhin uneingeschränkt für das Ergebnis verantwortlich sind.

Hier verläuft die Grenze zwischen AI-unterstütztem Coding und AI-unterstütztem Engineering. Das eine erzeugt Output, das andere Software.

Coding wird günstiger. Engineering macht den Unterschied.

Ich bleibe optimistisch, was AI in der Softwareentwicklung angeht. Sie reduziert Reibungsverluste, beschleunigt das Lernen, verringert den Aufwand mit Legacy-Systemen und liefert einen entscheidenden ersten Entwurf, wenn die leere Seite die größte Hürde ist.

Doch schnellere Codegenerierung darf ich nicht mit besserem Software Engineering verwechseln. Die Entwickler, die im AI-Zeitalter erfolgreich sind, werden nicht diejenigen sein, die den meisten Code generieren. Es werden diejenigen sein, die aus unklaren Anforderungen sichere, funktionierende und wartbare Systeme machen können. Sie werden wissen, wie man Probleme definiert, Lösungen eingrenzt, Ergebnisse überprüft und Verantwortung für die Folgen übernimmt.

Sie werden AI als Beschleuniger nutzen, nicht als Ausrede, nicht mehr nachzudenken.

AI schreibt Code. Entwickler bauen Software. Dieser Unterschied wird bald wichtiger sein als je zuvor.