Schlagzeilen behaupten immer wieder, dass KI Softwareentwickler überflüssig machen wird. Ich glaube das nicht. Das wahre Risiko ist nicht, dass Mas

Schlagzeilen behaupten immer wieder, dass KI Softwareentwickler überflüssig machen wird. Ich glaube das nicht. Das wahre Risiko besteht nicht darin, dass Maschinen das Engineering übernehmen. Das Risiko besteht darin, dass Ingenieure aufhören, die harte Arbeit des Denkens zu leisten.

Bei Software ging es nie nur darum, Syntax zu tippen. Es ging immer darum, Komplexität im Kopf zu behalten, Fehlermodi zu verstehen und Kompromisse einzugehen, wenn keine Option perfekt ist. KI hat die Geschwindigkeit verändert, mit der wir Code produzieren, aber sie hat nicht geändert, warum wir Menschen im Prozess („humans in the loop“) brauchen. Wenn überhaupt, hat sie klares Denken wertvoller und knapper gemacht.

Der erste Entwurf ist noch kein Engineering

Ich beobachte, wie eine wachsende Zahl von Junior-Entwicklern ChatGPT oder Claude so behandeln, als säße der Senior-Engineer im nächsten Stuhl. Sie fügen eine Ticketbeschreibung ein, kopieren die Antwort heraus, lassen die Tests laufen und machen einen Commit. Wenn es kompiliert, ist die Aufgabe erledigt. Dieser Kreislauf ist schnell, reibungslos und gefährlich.

Die Nutzung von KI ist nicht das Problem. Ich nutze sie. Die meisten produktiven Ingenieure, die ich kenne, nutzen sie. Das Problem beginnt, wenn die KI der einzige Ingenieur im Raum ist. Die erste Lösung zu akzeptieren, nur weil sie funktioniert, ist kein Engineering. Es ist die Auslagerung des Urteilsvermögens an ein Modell, das weder Ihre Nutzer noch Ihre geschäftlichen Rahmenbedingungen oder den letzten Zeitpunkt versteht, an dem Ihr Stack um 2 Uhr morgens zusammengebrochen ist.

Large Language Models liefern Antworten mit einer beunruhigenden Selbstsicherheit, selbst wenn sie völlig falsch sind. Ein Ingenieur bat eine KI, eine skalierbare Architektur zu entwerfen. Das Modell lieferte einen detaillierten, autoritären Vorschlag, der vollständig auf einer Funktion basierte, die im eigentlichen Produkt gar nicht existierte. Es sah korrekt aus. Es war in sich schlüssig. Es war aber auch nutzlos. Die Gefahr besteht nicht nur darin, dass KI halluziniert. Die Gefahr besteht darin, dass zu viele Menschen diesen Halluzinationen nun vertrauen, weil ihnen der Kontext fehlt, um die Lüge zu erkennen.

Man lernt aus Reibung

Wenn ich darüber nachdenke, was mich von einem Junior-Entwickler zu jemandem gemacht hat, der ein System verantworten konnte, erinnere ich mich nicht an die Syntax, die ich auswendig gelernt habe. Ich erinnere mich an die Ausfälle. Ich erinnere mich an die langsamen Abfragen, die ich manuell nachverfolgen musste, an die Race Conditions, die nur unter Produktionslast auftraten, und an die Deployments, die scheiterten, weil meine lokale Umgebung nichts mit der realen Welt zu tun hatte.

Beim Debugging findet das Lernen statt. Wenn man Code manuell Schritt für Schritt durchgeht, sieht man, warum Systeme tatsächlich scheitern. Man entdeckt, wo Engpässe entstehen. Man lernt, wie sich eine Architektur verhält, wenn man von einer Demo mit zehn Nutzern zu einem Produktionssystem übergeht, das zehntausend gleichzeitige Anfragen verarbeitet. Man verinnerlicht bis in die Knochen, wie sich die Produktion von einer schön geskripteten Demo unterscheidet.

Keines dieser Kenntnisse stammt aus der Annahme einer generierten Antwort. Sie entstehen durch das Ringen mit dem Problem. Wenn die KI jede Anstrengung eliminiert, wenn sie den Code schreibt, die Bugs behebt und die Fehler einfach weg erklärt – wie genau verdient die nächste Generation von Entwicklern dann ihre Seniorität? Erfahrung ist kein Zertifikat, das man herunterlädt. Sie ist das Narbengewebe, das man durch Produktionsvorfälle und gescheiterte Deployments aufbaut. Wenn man die Reibung entfernt, entfernt man auch das Wachstum.

Urteilsvermögen schlägt Generierung

Eine Zeit lang behandelte die Branche Prompt Engineering als die neue Trend-Fähigkeit für den Lebenslauf. Das ging völlig am Punkt vorbei. Die wertvollste Fähigkeit in einer KI-gesättigten Umgebung ist nicht das Generieren von Optionen. Es ist das Wissen, welche Vorschläge man ablehnen muss.

Die besten Ingenieure, mit denen ich zusammenarbeite, schreiben nicht die meisten Prompts. Sie stellen die schwierigsten Fragen. Sie wissen, wann ein Refactoring eine versteckte Abhängigkeit einführt. Sie erkennen, wenn ein generierter Test nur den Happy Path abdeckt, aber den Edge Case ignoriert, der Kundendaten korrumpieren wird. Sie können auf perfekt gültigen Code schauen und sagen: „Dieser Code ist korrekt, aber die Architektur ist falsch.“

Dieser letzte Satz ist die Trennlinie zwischen zwei sehr unterschiedlichen Kulturen. KI-gestütztes Engineering bedeutet, dass man die Maschine nutzt, um Gerüste zu entwerfen, Muster zu erkunden oder Boilerplate zu automatisieren, während das eigene Gehirn die Entscheidungen trifft. KI-abhängiges Engineering bedeutet, dass man der Maschine das Steuer überlässt. Viele Organisationen driften stillschweigend in die Abhängigkeit ab, weil es sich kurzfristig schneller anfühlt. Schnell ist nicht dasselbe wie richtig.

Die Arbeit, die immer noch den Menschen gehört

KI kann fast jeden Teil des Entwicklungslebenszyklus beschleunigen, doch es gibt Kernpraktiken, die fest in menschlicher Hand bleiben sollten. Systemdesign erfordert das Abwägen konkurrierender Randbedingungen: Kosten, Latenz, Zuverlässigkeit und zukünftige Wartbarkeit. Architektur-Reviews hängen vom institutionellen Gedächtnis und der Fähigkeit ab, Folgeeffekte zweiter Ordnung abzuschätzen. Mentoring erfordert jemanden, der die Fehlermodi, vor denen er warnt, tatsächlich selbst durchlebt hat. Ein tiefes Produktverständnis entsteht durch Gespräche mit Nutzern und die Beobachtung ihres Verhaltens in der Praxis, nicht durch das Lesen von Trainingsdaten.

Engineering-Urteilskraft ist die Summe dieser Erfahrungen. Es ist die leise Stimme, die einem sagt, dass eine Migration an einem Freitagnachmittag zu riskant ist, um sie auszurollen, selbst wenn das Code-Review bestanden wurde. Es ist die Intuition, dass eine Performance-Optimierung jetzt später eine Sicherheitslücke reißen könnte. Ein LLM besitzt keine Intuition. Es besitzt Muster. Muster sind nützlich, aber sie sind kein Urteil.

Unternehmen, die derzeit einstellen, müssen aufhören, gezielt nach Menschen zu suchen, die lediglich gut im Umgang mit KI-Tools sind. Stellen Sie Menschen ein, die die KI infrage stellen können. Suchen Sie nach Kandidaten, die innehalten, den generierten Output sorgfältig lesen und erklären können, warum sie ihm widersprechen. Das sind die Ingenieure, die Ihre Systeme gesund halten werden, wenn der generierte Code auf die unordentliche Realität der Produktion trifft.

Beschleunigung ohne Kompass

Betrachten Sie KI als ein Gaspedal. In einem Auto mit einem