KI im Engineering: Warum die besten Entwickler jetzt mehr denken als schreiben

Künstliche Intelligenz hat die Softwareentwicklung revolutioniert – und fast jeder Entwickler nutzt sie mittlerweile in irgendeiner Form. Ob für Debugging, Boilerplate-Code, Dokumentation oder schnelle Code-Reviews: Die Technologie ist allgegenwärtig. Selbst Skeptiker haben schon einmal einen mysteriösen Stack Trace in ein Chatfenster kopiert, um eine Lösung zu finden.

Doch die entscheidende Frage ist nicht mehr, ob Entwickler KI verwenden. Viel wichtiger ist:

Hat KI die Art und Weise verändert, wie sie Software entwickeln?

Denn das ist nicht dasselbe.

KI zu nutzen ist einfach. KI-gestütztes Engineering ist jedoch eine ganz andere Herausforderung.

Nicht der Code war das Problem

Meine eigenen Erfahrungen mit KI in realen Projekten haben mir gezeigt, dass die eigentliche Hürde nicht in der Codegenerierung lag. Ein vages Prompt konnte zwar schnell viel Code produzieren – manchmal sogar sauber aussehenden Code. Doch nützlich wurde dieser Output erst, wenn ich bereits die grundlegenden Engineering-Aufgaben erledigt hatte:

• Klare Anforderungen definiert
• Den Umfang der Aufgabe begrenzt
• Rahmenbedingungen und Constraints erklärt
• Einen Plan für die Überprüfung der Lösung erstellt

Der schwierige Teil war nicht, KI um Code zu bitten. Der schwierige Teil bestand darin, den richtigen Kontext zu liefern – ohne die KI mit unstrukturierten Informationen zu überfluten. Es ging darum, die Aufgabe in kleine, handhabbare Schritte zu zerlegen. Und vor allem: Es ging darum, vor der Implementierung Trade-offs zu diskutieren und zu entscheiden, ob die Lösung überhaupt in das bestehende System passte.

Das hat meine Sicht auf KI-gestützte Entwicklung grundlegend verändert.

Prompting war nicht die eigentliche Fähigkeit.

Die Fähigkeit bestand darin, die Arbeit zu strukturieren.

Schnellerer Output, aber keine stärkere Verifikation

Es gibt nichts Falsches daran, KI für kleine Aufgaben zu nutzen. Ich setze sie ein für:

• Debugging-Hinweise
• Namensfindung
• Generierung von Boilerplate-Code
• Testideen
• Dokumentationsentwürfe
• Erkundung unbekannter Codebasen

Diese Anwendungen reduzieren Reibung und beschleunigen repetitive Tätigkeiten. Doch genau hier beginnt das Risiko: Wenn schnellerer Output mit besserem Engineering verwechselt wird.

KI kann zwar schnell Code generieren – sauber formatierte Funktionen, strukturierte Dateien, überzeugende Erklärungen und plausible Testfälle. Doch sie weiß nicht automatisch, ob diese Änderungen zu Produkt, Architektur oder langfristigen Wartungskosten passen. Das bleibt Engineering-Arbeit.

Das Problem liegt nicht darin, dass KI schlechten Code produziert. Entwickler sind bereits mit schlechtem Code konfrontiert – von anderen Entwicklern, Bibliotheken, Tutorials, Stack Overflow oder ihren eigenen müden Gedanken.

Das größere Problem ist, dass KI die Geschwindigkeit der Codegenerierung erhöht, ohne die Qualität der Verifikation zu verbessern.

Wenn Code schneller entsteht, werden unklare Anforderungen teurer. Schwache Code-Reviews werden gefährlicher. Fehlende Tests schmerzhafter. Schlechte Architektur leichter kopierbar und schwerer rückgängig zu machen.

KI verbessert Engineering nicht automatisch.

Sie verstärkt den bestehenden Engineering-Prozess – sowohl die Stärken als auch die Schwächen.

Zweimal nachdenken, einmal codieren

KI macht es einfacher, Code zu produzieren, bevor das Problem vollständig verstanden wurde. Das ist nützlich, wenn die Aufgabe klar definiert ist. Es wird gefährlich, wenn die Anforderungen vage sind.

Wenn die Spezifikation unklar ist, wird KI trotzdem etwas produzieren. Wenn die Architektur chaotisch ist, wird KI diesen Chaos kopieren. Wenn der Entwickler die Ausgabe nicht richtig prüfen kann, wird Geschwindigkeit zum Risiko.

Deshalb halte ich die Aussage „KI wird Entwickler ersetzen“ für die am wenigsten hilfreiche Diskussion.

Eine bessere Frage lautet:

„Welche Teile des Engineerings werden wichtiger, wenn Code günstiger zu generieren ist?“

Meine Antwort: Klares Denken vor der Implementierung.

KI macht die alten Ratschläge wichtiger – nicht weniger:

Denke zweimal nach, bevor du codest.

Bevor KI Code generiert, muss das Problem definiert sein. Bevor die Ausgabe akzeptiert wird, müssen die Trade-offs geprüft werden. Bevor die Änderung gemerged wird, muss das Verhalten verifiziert werden.

Der Wert des Engineerings verschiebt sich weg von der reinen Codeerstellung hin zur Gestaltung der richtigen Änderung.

So sieht Engineering mit KI aus

Für mich bedeutet Engineering mit KI, KI nicht als magische Antwortmaschine, sondern als strukturierten Kollaborateur zu behandeln. Die Arbeit beginnt lange vor der Implementierung:

• Anforderungen präzise formulieren
• Den Umfang der Aufgabe eingrenzen
• Nützlichen Kontext liefern
• Nach Risiken fragen
• Einen Plan vor der Codegenerierung erstellen

Nach der Implementierung liegt die Verantwortung wieder beim Entwickler:

• Den Diff prüfen
• Die Checks ausführen
• Entscheiden, ob die Änderung ins System gehört

Ein nützlicher KI-gestützter Prozess kann einfach aussehen:

Anforderung → Lücken identifizieren → Plan erstellen → kleine Änderung → Review → Checks → Dokumentation

Das ist nicht die glamouröse Seite der KI-Entwicklung. Aber es ist näher an realem Engineering.

Denn echtes Engineering bedeutet nicht nur Code zu produzieren. Es bedeutet zuverlässige Änderungen zu schaffen.

Die echte Veränderung steht noch bevor

Der nächste große Wandel in der Softwareentwicklung wird nicht darin bestehen, wer am meisten Code generieren kann. Dieser Vorteil wird immer günstiger. Der schwierigere Vorteil liegt darin, zu wissen:

• Was gebaut werden sollte
• Wie es in das System passt
• Wie die Funktionsfähigkeit überprüft wird

Genau hier wird KI-gestütztes Engineering interessant. Nicht weil KI das Urteilsvermögen der Entwickler ersetzt, sondern weil sie dieses Urteilsvermögen unverzichtbarer macht.

Die meisten großen Engineering-Tools wurden erst dann wertvoll, als Teams ihre Arbeitsabläufe rund um diese Tools neu definiert haben: Git veränderte die Zusammenarbeit, die Cloud veränderte die Infrastruktur, CI/CD veränderte das Deployment. KI ist breiter, unstrukturierter und bewegt sich schneller als diese Veränderungen – deshalb sollte man nicht erwarten, dass sie denselben Pfad folgt.

Doch die Lektion bleibt dieselbe:

Das Tool ist wichtig. Der Arbeitsablauf um das Tool herum ist noch wichtiger.

Die Entwickler, die am meisten profitieren werden, sind nicht unbedingt diejenigen, die KI am häufigsten nutzen. Es sind diejenigen, die bessere Prozesse um KI herum gestalten:

• Klarere Spezifikationen
• Kleinere Änderungen
• Stärkere Code-Reviews
• Bessere Tests
• Bewusstere Entscheidungen

Ja, die meisten Entwickler nutzen KI heute. Doch nur wenige beginnen wirklich, mit KI zu engineerieren.

Die besten Entwickler in dieser Phase sind vielleicht nicht die schnellsten Prompt-Schreiber. Sie sind diejenigen, die das Problem verlangsamen, bevor sie die Implementierung beschleunigen.

Erinnern wir uns: Qualität entsteht nicht durch Geschwindigkeit allein, sondern durch klare Entscheidungen.