Wenn du seit zehn oder fünfzehn Jahren Software entwickelst, hast du schon ein paar Zyklen überlebt. Frameworks kamen und gingen. Du hast die Microservice-Welle mitgemacht, die Container-Revolution, die Cloud-Migration. Du hast gelernt, dass nicht jeder Hype hält, was er verspricht, und dass die fundamentalen Prinzipien erstaunlich stabil sind.
Diese Erfahrung hat dir ein gesundes Maß an Skepsis beigebracht. Und genau diese Skepsis macht es schwer, AI einzuordnen. Ist das der nächste Hype? Oder ist das etwas Anderes?
Nicht weil AI pauschal besser programmiert als du. Sondern weil AI eine Grundannahme verändert, auf der dein Berufsbild aufgebaut ist: dass jede Form von Implementierung zwangsläufig knapp, teuer und zeitaufwändig ist.
Diese Annahme stimmt bald nicht mehr.
Was sich verschiebt
Ich arbeite seit Jahren in Enterprise-Projekten. Deutsche Bahn, Banken, Konzerne – Umgebungen, in denen Veränderung langsam passiert und in denen "das haben wir schon immer so gemacht" kein Witz ist, sondern ein Architekturprinzip. Und selbst dort spüre ich, wie sich etwas verschiebt.
Standardisierte Code-Erzeugung wird zur Commodity. Das ist die unbequeme Wahrheit – und ich sage das als jemand, der guten Code schreibt und dem das wichtig ist. Ein erster Entwurf ist schnell erzeugt. Produktionsfähiges Engineering bleibt schwieriger: Kontext, Systemgrenzen, Migration, Fehlerszenarien und Betrieb passen in keine generische Lösung.
Rezeptwissen verliert als Differenzierungsmerkmal an Wert. Wie man einen REST-Endpunkt aufsetzt oder ein bekanntes State-Management-Muster implementiert, lässt sich zunehmend automatisieren. Die Fähigkeit zu implementieren verschwindet deshalb nicht. Sie wird zum Mittel, Annahmen zu prüfen und kritische Systemteile belastbar zu bauen.
Die Codebasis wächst schneller als das Verständnis. Wenn AI-Agenten Code generieren, den du reviewst statt schreibst, arbeitest du mit einer Codebasis, die du nicht Zeile für Zeile kennst. Weniger "Ich kenne jede Zeile" und mehr "Ich verstehe das System auf einer höheren Ebene."
Das klingt erstmal bedrohlich. Aber ich glaube, die meisten von uns schauen aus dem falschen Winkel drauf.
Der falsche Winkel und der richtige
Die Debatte, die ich überall mitbekomme – in Projekt-Meetings, in Team-Chats, in den Kommentarspalten – dreht sich um die Frage: "Werden Entwickler ersetzt?" Das ist die falsche Frage. Sie führt entweder zu Panik oder zu Verdrängung, beides nicht hilfreich.
Und wenn ich ehrlich bin – die Antwort darauf beruhigt mich mehr, als sie mich beunruhigt. Denn alles, was mich in den letzten Jahren in Enterprise-Projekten wirklich wertvoll gemacht hat, war nie der Code allein.
Es war das Wissen, warum ein bestimmtes Modul nicht angefasst werden darf, weil vor sechs Jahren ein Entwickler unter Zeitdruck einen Workaround gebaut hat und der einzige Mensch, der das System verstand, längst in Rente ist. Es war das Gespür dafür, wann eine Architekturentscheidung technisch elegant, aber organisatorisch eine Katastrophe ist, weil das Team, das sie warten muss, nicht die Kompetenz hat. Es war die Fähigkeit, in einem Meeting mit dem Fachbereich zu sitzen und zu übersetzen – zwischen dem, was die Anforderung wirklich meint, dem, was die Compliance erlaubt, und dem, was die Technik hergibt.
Ein Blick nach vorne
Wer heute anfängt, größere Teile seiner Arbeit mit AI-Unterstützung zu erledigen – nicht Snippets, nicht Boilerplate, sondern ganze Features – der bemerkt schnell etwas Überraschendes. Es ist nicht die Geschwindigkeit, die sich am meisten verändert. Es ist die Verschiebung im eigenen Kopf.
Man denkt weniger über Code nach und mehr über Richtung. Weniger "Wie implementiere ich das?" und mehr "Ist das überhaupt der richtige Ansatz?" Nicht weil man aufhört, sich für Code zu interessieren. Sondern weil die Implementierung nicht mehr der Engpass ist – und plötzlich die Fragen sichtbar werden, die vorher unter dem Zeitdruck der Umsetzung begraben waren.
Und ich glaube, das ist ein Vorgeschmack auf das, was kommt.
In zwei, drei Jahren wird sich das Verhältnis zwischen Denken und Tippen grundlegend verschieben. Nicht weil wir weniger arbeiten, sondern weil die Arbeit eine andere Textur bekommt. Mehr Zeit damit, Entscheidungen zu bewerten, die eine Maschine vorbereitet hat, als selbst Lösungen zu bauen. Mehr Zeit mit der Frage "Ist das richtig?" als mit "Wie geht das?"
Das klingt abstrakt. Aber wenn man es einmal erlebt – wenn man in einer halben Stunde drei Architekturvarianten vergleicht, die alle funktionieren, und der einzige Job ist, die richtige auszuwählen – dann merkt man, was sich wirklich ändert. Nicht das Handwerk verschwindet. Aber was "Handwerk" bedeutet, verschiebt sich. Weg vom Code als Endprodukt, hin zum Code als Zwischenschritt auf dem Weg zur richtigen Lösung.
Was ich im Enterprise-Umfeld beobachte
Wer in einem regulierten Umfeld arbeitet – Banken, Versicherungen, Konzerne – hat gerade einen Vorteil, auch wenn es sich nicht so anfühlt. Die Transformation wird dort langsamer ankommen. Strengere Compliance, regulierte Deployments, Security-Freigaben, die dauern. AI-Tools, die man nicht einfach benutzen darf, weil sie erst durch drei Gremien müssen.
Das gibt dir Zeit. Aber es sollte keine Ausrede sein.
Denn was ich gleichzeitig beobachte: Die Entscheider in diesen Organisationen wissen, dass sich etwas verändert. Die Bank, die ihre Softwareentwicklung nicht beschleunigt, wird gegen die Bank verlieren, die es tut. Nicht morgen. Aber in fünf Jahren. Und in fünf Jahren ist in der Bankenwelt übermorgen.
Die Leute, die in diesen Organisationen die Brücke bauen werden – die AI-Tools einführen, sie in den Enterprise-Kontext übersetzen, Compliance einhalten und trotzdem Mehrwert liefern – das sind keine frischen Absolventen mit einem Kurs in Prompt Engineering. Das sind Leute, die das System kennen. Die wissen, wo die Leichen im Keller liegen und warum man bestimmte Türen nicht öffnet.
Worüber niemand spricht
Es gibt einen Aspekt in dieser Debatte, der zu kurz kommt: die menschliche Seite.
Ich kenne Entwickler, die seit fünfzehn Jahren in Scrum-Teams arbeiten. Deren gesamte Karriere auf einem bestimmten Skill-Set aufgebaut ist. Die stolz darauf sind, eine komplexe Codebasis im Kopf zu haben, einen Bug in dreißig Minuten zu finden, ein Feature elegant zu implementieren.
Wenn du diesen Leuten sagst "Dein Wert liegt in Zukunft nicht mehr im Code, sondern in der Entscheidung", dann klingt das für sie nicht nach einer Beförderung. Es klingt nach Verlust. Der Verlust einer Identität, die über Jahre gewachsen ist.
Das verdient Respekt. Und Ehrlichkeit.
Die Ehrlichkeit ist: Ja, es wird sich anfühlen wie ein Verlust. Die Fähigkeit, ein komplexes Problem in elegantem Code zu lösen – allein, in der Zone, in einer langen Session – das wird seltener werden. Nicht weil du es nicht mehr kannst, sondern weil es effizienter ist, wenn eine Maschine den ersten Entwurf macht und du ihn beurteilst.
Aber was dazukommt, ist nicht weniger. Es ist anders. Statt "Ich habe dieses Feature gebaut" wird es "Ich habe die Entscheidung getroffen, die dieses Produkt in die richtige Richtung gelenkt hat." Statt der Befriedigung von elegantem Code die Befriedigung von gutem Urteilsvermögen. Statt dem Flow-Zustand beim Programmieren der Flow-Zustand beim Orchestrieren.
Ob das besser oder schlechter ist, kann ich nicht sagen. Es ist anders. Und mit "anders" kann man arbeiten.
Der ehrlichste Satz, den ich dazu habe
Die Brücke von "klassisch" nach "AI" ist nicht eine von "alt" nach "neu". Sie führt von "Ich liefere Code" zu "Ich übernehme technische Verantwortung — und beweise Entscheidungen in funktionierender Software."
Und wenn du ehrlich bist, stehst du auf dieser Brücke nicht am Anfang. Du stehst schon in der Mitte. Du triffst diese Entscheidungen seit Jahren – du hast nur nebenbei auch noch selbst den Code geschrieben.
Der Unterschied ist: Den ersten Entwurf schreibt zunehmend ein Werkzeug. Den kritischen Pfad, die Integration in das reale System und die Verantwortung dafür nimmt es dir nicht ab.
Aber er weiß nicht, warum das Compliance-Modul so gebaut ist, wie es gebaut ist. Er weiß nicht, dass der CTO am Freitag seine Meinung zu Event Sourcing geändert hat. Und er weiß nicht, dass man Team drei gerade besser nicht mit einem weiteren Refactoring belastet.
Das weißt du.
Die beste Zeit, die Brücke zu bauen, war vor einem Jahr. Die zweitbeste ist jetzt.