Warum 2026 das Programmieren beendet, aber nicht das Engineering

Claude Opus 4.5 ist gerade erschienen. Und das Forschungsteam von Anthropic behauptet, Software-Engineering könnte bis Mitte 2026 automatisiert sein. Unser Team hat sich zuletzt intensiv mit Claude beschäftigt, und wir sind ehrlich beeindruckt. Aber wir glauben, dass die Branche zwei sehr verschiedene Dinge vermischt.

Programmieren ist nicht Engineering

Programmieren heißt, Logik in Syntax zu übersetzen. Anweisungen zu schreiben, die eine Maschine ausführen kann. Darin sind LLMs heute erstaunlich gut geworden. Sie erzeugen Funktionen, beheben Bugs, refaktorieren Code und bestehen sogar technische Vorstellungsgespräche besser als die meisten Menschen.

Aber Software-Engineering? Das ist alles rund um den Code. Architekturentscheidungen, die einen drei Jahre später nicht einholen. Verstehen, was Nutzer tatsächlich brauchen, im Unterschied zu dem, was sie sagen, dass sie wollen. Abstimmung zwischen Teams mit unterschiedlichen Prioritäten. Abwägungen treffen, wenn es keine eindeutig richtige Antwort gibt.

Soft Skills werden zu den neuen Hard Skills. Programmieren ist Syntax. Engineering ist algorithmisches und kritisches Denken.

Was Modelle noch nicht können

Software-Engineering findet in unordentlichen Umgebungen statt. Altsysteme mit undokumentierten Abhängigkeiten. Geschäftsanforderungen, die sich mitten im Sprint ändern. Stakeholder, die nicht wissen, was sie wollen, bis sie sehen, was sie nicht wollen. Ein LLM kann perfekten Code für ein klar definiertes Problem schreiben. Aber wie geht es mit einer Situation um, in der die richtige Lösung von den Fähigkeiten Ihres Teams, dem Zeitplan für die Auslieferung, den technischen Schulden und der Risikobereitschaft des Unternehmens abhängt?

Das verlangt Urteilsvermögen und Geschmack. In unseren Projekten sind die meisten gescheiterten KI-Vorhaben nicht an der Technik gescheitert. Sie scheitern an der Organisation: falsch gesetzte Anreize, schlechte Kommunikation, niemand hat das Problem klar vor Augen, wenn der erste Sprint zu Ende geht. Der Code besteht jeden Test. Nichts im Repository erklärt, was schiefgelaufen ist, weil nichts im Repository das Problem war.

Das Kontextproblem

Denken Sie einen Moment wie ein Software-Engineer. Sie lesen sich durch eine Codebasis, die jemand anderes vor fünf Jahren geschrieben hat, und versuchen zu verstehen, warum bestimmte Entscheidungen getroffen wurden. Sie suchen den Grund, warum sich Staging anders verhält als Produktion. Sie entscheiden, ob Sie das Feature jetzt einbauen oder auf das Refactoring im nächsten Quartal warten.

Sie könnten uns unterbrechen und sagen: Warum nicht einfach alles in ein LLM kippen? Können Sie. Aber eine Million Tokens zu halten ist nicht dasselbe wie Kontext zu verstehen. Es weiß immer noch nicht, warum diese Architekturentscheidung getroffen wurde, was die Codebasis geprägt hat oder welche Abkürzungen Panik vor der Deadline waren und welche bewusste Abwägungen.

Die Urteilslücke

Das sehen wir in der Praxis immer wieder. Die Unternehmen, die KI zur Code-Erzeugung nutzen, kämpfen nicht mit der Codequalität. Der Code, den Modelle heute liefern, ist oft sauber, gut dokumentiert und folgt bewährten Praktiken. Der eigentliche Kampf ist alles andere.

• Sollten wir dieses Feature überhaupt bauen?
• Ist das die richtige Architektur für unsere Größenordnung?
• Was passiert, wenn das mit den drei Altsystemen zusammenspielt, die niemand anfassen will?
• Wie gehen wir mit den Sicherheitsfolgen um, an die niemand gedacht hat?

Diese Fragen verlangen Empathie. Das Verständnis für das Geschäft, die Nutzer, den Zeitplan, das Risikoprofil und ein Dutzend weiterer Faktoren, die in keinem Prompt auftauchen. Sie sind auch der Grund, warum wir Engineers in die Teams unserer Kunden setzen, statt eine Spezifikation zu übergeben. Der Kontext, der zählt, steht selten irgendwo geschrieben.

Der realistische Blick

Die Unternehmen, die wir mit der Einführung von KI vorankommen sehen, versuchen nicht, ihre Engineers zu ersetzen. Sie nutzen KI als Multiplikator für die mechanischen Teile, damit sich ihre Engineers auf die Urteilsentscheidungen konzentrieren können, die wirklich zählen: Architekturentscheidungen, Abwägungen und die Gespräche der Sorte "Sollten wir das überhaupt bauen?".

Unterm Strich

Ist Software-Engineering in sechs Monaten erledigt? Nicht annähernd. Die Arbeit findet in unordentlichen, menschlichen Umgebungen statt, in denen Anforderungen unklar sind, Stakeholder sich uneinig sind und die richtige Antwort von Kontext abhängt, den niemand aufgeschrieben hat.

Ein Modell kann den Code schon heute schreiben. Es kann nicht in einem Raum sitzen, in dem zwei Direktoren Verschiedenes wollen, herausfinden, wer von beiden das hier eigentlich bezahlt, und laut aussprechen, dass das Feature, auf das sich beide geeinigt haben, nicht gebaut werden sollte. Das ist der Job. Das war immer der Job.