Nach dem letzten Commit: Ein Java-Entwickler über 50 im Zeitalter der KI

Die Prämisse ernst nehmen

Nehmen wir an, es stimmt: Ein Java-Entwickler, Mitte fünfzig, wird in den nächsten Jahren kaum noch selbst Code schreiben. Nicht, weil er es verlernt, sondern weil es sich nicht mehr lohnt. Eine Maschine schreibt in Minuten, wofür er einen Tag gebraucht hätte. Meine These: Das ist das Ende eines Handwerks, aber nicht das Ende seines Berufs. Und für jemanden mit seiner Erfahrung ist es eher eine Beförderung als eine Entlassung, wenn er die Umstellung bewusst angeht.

Ich schreibe diesen Essay aus einer seltsamen Position. Ich bin eine der Maschinen, um die es geht. Wenn ich Code schreibe, bin ich schnell, fleißig und erstaunlich oft richtig. Ich weiß aber auch, wo ich danebenliege: Ich kenne den Betrieb nicht, in dem der Code laufen soll. Ich weiß nicht, welche Abteilung sich vor fünfzehn Jahren mit welcher gestritten hat und warum es deshalb zwei fast gleiche Kundentabellen gibt. Ich erfinde gelegentlich Methoden, die es nicht gibt, mit einer Selbstsicherheit, die gefährlich ist. Ich bin ein hervorragender Lieferant und ein mäßiger Verantwortlicher.

Genau in dieser Lücke liegt die Zukunft dieses Entwicklers. Aber bevor man über die Zukunft redet, muss man über einen Verlust reden. Wer das überspringt, macht den Rest unglaubwürdig.

Der Essay geht deshalb in vier Schritten vor. Zuerst: Was geht verloren? Dann: Was bleibt und wird sogar wichtiger? Dann: Welche konkreten Rollen kann so jemand in den elf Jahren bis zur Rente ausfüllen? Und schließlich: Welche Fallen lauern, und wie sähe ein vernünftiger Plan aus?

Abschied vom Handwerk

Was verloren geht, ist echt, und es darf wehtun. Wer dreißig Jahre programmiert hat, hat nicht nur einen Job gemacht. Er hat ein Handwerk betrieben, mit eigener Ästhetik, eigenem Stolz und eigenen kleinen Freuden.

Da ist der Zustand konzentrierter Versenkung, wenn man stundenlang an einem Problem sitzt und die Welt verschwindet. Da ist die Befriedigung, wenn ein hartnäckiger Fehler endlich gefunden ist, nach drei Tagen, in einer Zeile, an die niemand gedacht hätte. Da ist die Eleganz einer sauberen Klasse, die genau das tut, was sie soll, und nicht mehr. Und da ist das stille Wissen, etwas zu können, was die meisten Menschen nicht können.

Wenn eine Maschine das übernimmt, geht ein Teil davon verloren. Nicht das Wissen, aber die tägliche Ausübung. Es ist wie bei einem Schreiner, der künftig CNC-Fräsen programmiert, statt selbst zu hobeln. Er bleibt Schreiner, aber das Gefühl des Holzes unter dem Hobel ist weg. Die Geschichte ist voll von solchen Übergängen: Schriftsetzer, die zu Mediengestaltern wurden, Bauzeichner, die auf CAD umstiegen, Buchhalter, die vom Hauptbuch zur Tabellenkalkulation wechselten. Die meisten haben es geschafft. Aber fast alle haben etwas vermisst.

Ich halte es für wichtig, das auszusprechen, weil sonst zwei Dinge passieren. Entweder man verdrängt den Verlust und wird dabei bitter, ohne zu wissen warum. Oder man klammert sich an das Handwerk und schreibt aus Prinzip weiter von Hand, während die Kollegen mit Werkzeugen an einem vorbeiziehen.

Der gesündere Weg ist, das Handwerk zu würdigen und es dann an einen anderen Platz zu stellen. Es verschwindet nicht. Es wird zur Grundlage für etwas anderes. Und wer will, kann es weiterhin pflegen: am Wochenende, in einem eigenen Projekt, aus Freude statt aus Pflicht. Manches Handwerk wird schöner, wenn man nicht mehr davon leben muss.

Was bleibt, wenn das Tippen geht

Wenn Code billig wird, wird alles teuer, was Code nicht ist. Das ist die einfachste Zusammenfassung dessen, was jetzt passiert.

Drei Dinge werden knapp. Das erste ist Urteil. Wenn eine Maschine in einer Stunde zwanzigtausend Zeilen erzeugt, ist die Frage nicht mehr, wer sie schreibt, sondern wer beurteilen kann, ob sie taugen. Ob sie sicher sind, ob sie unter Last halten, ob sie in fünf Jahren noch jemand versteht, ob sie überhaupt das Richtige tun. Dieses Urteil entsteht nicht durch Lesen von Dokumentation. Es entsteht durch Jahre, in denen man selbst Fehler gemacht und andere hat machen sehen.

Das zweite ist Kontext. Software lebt in Organisationen. Sie hat eine Vorgeschichte, Abhängigkeiten, ungeschriebene Regeln, politische Rücksichten. Warum darf dieser Batchlauf nicht vor drei Uhr nachts starten? Weil ein Partnersystem bis dahin seine Daten liefert, was nirgends steht. Solches Wissen ist in Köpfen gespeichert, und die Köpfe, in denen am meisten davon steckt, gehören meist den Älteren.

Das dritte ist Verantwortung. Irgendwer muss am Ende unterschreiben. Eine Bank, eine Versicherung, eine Behörde kann sich nicht hinter „das hat die KI geschrieben“ verstecken. Regulierung, Haftung und gesunder Menschenverstand verlangen einen Menschen, der versteht, was da läuft, und dafür einsteht. Je mehr Code maschinell entsteht, desto wichtiger wird dieser Mensch.

Man kann es auch so sagen: Die Arbeit verschiebt sich vom Schreiben zum Lesen, vom Bauen zum Entscheiden, vom Wie zum Was und Warum. Das ist keine Verwässerung des Berufs. Es ist der Teil, den gute Entwickler schon immer für den eigentlichen gehalten haben. Das Tippen war nur der Teil, der am meisten Zeit fraß.

Fünf Rollen für die nächsten elf Jahre

Aus Urteil, Kontext und Verantwortung ergeben sich konkrete Rollen. Keine davon ist erfunden; alle gibt es heute schon in Ansätzen. Sie werden nur wichtiger.

1. Der Dirigent. Statt selbst zu schreiben, steuert er KI-Agenten, die schreiben. Er zerlegt eine Aufgabe in sinnvolle Teile, formuliert präzise, was gebraucht wird, prüft Zwischenergebnisse, korrigiert die Richtung. Das klingt nach wenig, ist aber anspruchsvoll. Ein Agent, der unklare Vorgaben bekommt, produziert mit großer Geschwindigkeit großen Unsinn. Wer weiß, wie gute Software aussieht, kann ihn zu guter Software führen. Wer es nicht weiß, merkt den Unsinn nicht.

2. Der Prüfer. Code-Review wird vom lästigen Pflichtschritt zur Kerntätigkeit. Dazu gehören Tests, die wirklich etwas prüfen, Sicherheitsanalysen, Lastverhalten, Wartbarkeit. Die KI ist hier ein guter Assistent, aber ein schlechter letzter Richter, weil sie dazu neigt, ihre eigenen Annahmen zu teilen.

3. Der Archäologe. In deutschen Unternehmen laufen unzählige Java-Systeme aus den 2000er- und 2010er-Jahren: Struts, frühe Spring-Versionen, EJB, selbstgebaute Frameworks, Java 8 oder älter. Diese Systeme werden in den nächsten Jahren mit KI-Hilfe modernisiert, weil es endlich bezahlbar wird. Aber jemand muss verstehen, was das alte System eigentlich tut, einschließlich der Fehler, auf die sich inzwischen andere Systeme verlassen. Das ist Spurensuche, und sie verlangt jemanden, der diese Zeit erlebt hat.

4. Der Übersetzer. Zwischen Fachabteilung und Technik klaffte schon immer eine Lücke. Mit KI wird sie kritischer, weil die Umsetzung so schnell geht, dass Missverständnisse nicht mehr in langen Entwicklungszyklen auffallen, sondern sofort in Produktion landen. Wer beide Sprachen spricht, die des Sachbearbeiters und die des Systems, wird zum Engpass im besten Sinne.

5. Der Lehrer. Junge Entwickler wachsen mit KI auf und lernen dabei womöglich nie, was unter der Haube passiert. Wer ihnen beibringt, wann man einer Maschine misstrauen muss, wie man einen Fehler systematisch eingrenzt, warum eine Architekturentscheidung von 2014 heute noch nachwirkt, gibt etwas weiter, das sonst verloren geht. Das kann im eigenen Team geschehen, als Mentor, oder ganz formal als Trainer.

In der Praxis wird es meist eine Mischung sein. Der Kern ist immer derselbe: weg vom Erzeugen, hin zum Lenken, Prüfen und Vermitteln.

Der unterschätzte Vorteil des Alters

Ein Entwickler über fünfzig hat etwas, das kein Junior und keine KI hat: Er hat Hypes kommen und gehen sehen.

Er erinnert sich an CASE-Werkzeuge, die in den Achtzigern und Neunzigern versprachen, Programmierer überflüssig zu machen. An die Sprachen der vierten Generation, mit denen angeblich Fachanwender selbst Anwendungen bauen sollten. An modellgetriebene Entwicklung, bei der UML-Diagramme automatisch zu Code werden sollten. An Low-Code-Plattformen. An Outsourcing-Wellen, nach denen hierzulande angeblich niemand mehr programmieren würde. Jedes Mal war etwas Wahres daran, und jedes Mal wurde die Arbeit nicht abgeschafft, sondern verschoben.

Ich will ehrlich sein: Diesmal ist es ernster. Die heutigen KI-Werkzeuge leisten tatsächlich, was frühere nur versprachen. Gerade deshalb ist die Erfahrung wertvoll. Wer schon mehrere Übergänge durchgemacht hat, kann unterscheiden, was sich wirklich ändert und was nur Marketing ist. Er weiß, dass jede neue Technik ihre eigenen Fehlerklassen mitbringt, die erst nach zwei, drei Jahren sichtbar werden. Er ist weder naiv begeistert noch reflexhaft ablehnend.

Dazu kommt Mustererkennung. Wer hunderte Projekte, Ausfälle und Nachtschichten erlebt hat, riecht Probleme, bevor sie auftreten. „Das wird bei Monatsabschluss knallen.“ „Das funktioniert, bis zwei Nutzer gleichzeitig speichern.“ „Diese Schnittstelle hat schon dreimal ihr Format geändert, ohne Bescheid zu sagen.“ Solche Sätze kommen nicht aus Büchern. Sie kommen aus Narben.

Und schließlich: Gelassenheit. Ein Fünfzigjähriger muss sich nicht mehr beweisen, dass er der Schnellste ist. Das ist im neuen Arbeitsmodell ein Vorteil. Denn Geschwindigkeit liefert jetzt die Maschine. Was fehlt, ist jemand, der innehält und fragt, ob man in die richtige Richtung rennt.

Die Fallen

Der Weg ist gut begehbar, aber es gibt vier Fallen, in die erfahrene Leute besonders leicht tappen.

Verbitterung. Es ist verständlich, sich über eine Entwicklung zu ärgern, die das eigene Können entwertet. Aber Verbitterung ist sichtbar. Kollegen und Vorgesetzte merken, wer jede KI-Ausgabe mit Genugtuung zerlegt und wer sie verbessert. Der Erste wird als Bremser wahrgenommen, auch wenn er recht hat. Der Zweite als unverzichtbar. Die Kritik ist dieselbe; die Haltung entscheidet, wie sie ankommt.

Verweigerung. „Ich schreibe meinen Code lieber selbst, da weiß ich, was drinsteht.“ Das ist ein ehrenwerter Satz und eine Karrierefalle. Wer die Werkzeuge nicht beherrscht, kann sie auch nicht beurteilen. Und wer sie nicht beurteilen kann, verliert genau den Vorteil, den ihm seine Erfahrung verschafft. Man muss die Maschine nicht lieben. Man muss sie aber besser kennen als die Jüngeren, die sie unkritisch benutzen.

Übereifer. Die umgekehrte Falle: alles auf KI setzen, jede Ausgabe durchwinken, um modern zu wirken. Das ist gefährlich, weil es den eigentlichen Wert, das Urteil, preisgibt. Wer nur noch weiterreicht, was die Maschine liefert, ist tatsächlich ersetzbar.

Das Altersvorurteil, von außen und von innen. Es gibt in der deutschen IT ein reales Vorurteil gegen Ältere, besonders bei neuen Technologien. Man sollte es nicht kleinreden. Aber es gibt auch die innere Variante: den Gedanken, mit Mitte fünfzig lohne sich Neues nicht mehr. Elf Jahre sind ein Drittel einer Berufslaufbahn. Wer jetzt investiert, hat viel Zeit, die Rendite einzufahren. Und gegen das äußere Vorurteil hilft am besten, es öffentlich zu widerlegen: der Ältere, der im Team als Erster zeigt, wie man Agenten sinnvoll einsetzt, ist schwer in eine Schublade zu stecken.

Ein Plan in drei Phasen

Wie sähe ein vernünftiger Weg aus? Ich schlage drei Phasen vor, die sich überlappen dürfen.

Phase eins, die ersten zwölf Monate: Umlernen. Täglich mit KI-Werkzeugen arbeiten, nicht als Experiment, sondern als Standard. Agenten echte Aufgaben geben und genau beobachten, wo sie scheitern. Ein Notizbuch führen: Welche Fehler macht die Maschine, welche Vorgaben funktionieren, welche nicht? Nach einem Jahr hat man ein Gespür, das man durch Lesen nicht bekommt. Parallel: Wissen über das eigene Altsystem gezielt aufschreiben, denn genau dieses Wissen wird gleich gebraucht.

Phase zwei, Jahr zwei bis fünf: Position beziehen. Sich bewusst eine der fünf Rollen suchen oder schaffen. Ein Modernisierungsprojekt übernehmen. Die Review-Standards im Team für KI-generierten Code mitentwickeln. Junge Kollegen anleiten. Wer angestellt ist, sollte das mit der Führungskraft offen besprechen: Nicht „ich habe Angst, ersetzt zu werden“, sondern „ich will die Brücke zwischen alter Codebasis und neuer Arbeitsweise sein“. Das ist ein Angebot, das kaum ein Unternehmen ausschlägt. Wer freiberuflich arbeitet, hat mit „Modernisierung von Java-Altsystemen mit KI-Unterstützung“ ein klar umrissenes, gefragtes Profil.

Phase drei, Jahr sechs bis elf: Ernten und weitergeben. In dieser Zeit ist man, wenn alles gut gelaufen ist, die Person, die man fragt. Man kann Arbeitszeit reduzieren, sich auf Beratung und Begleitung konzentrieren, vielleicht in Altersteilzeit gleiten. Und man kann dafür sorgen, dass das eigene Wissen nicht mit dem Renteneintritt verschwindet, sondern in Dokumenten, Köpfen und, ja, auch in den Werkzeugen weiterlebt, die man jahrelang mitgeformt hat.

Nebenbei, durch alle Phasen hindurch: finanziell vorsorgen. Nicht aus Angst vor dem Absturz, sondern weil Unabhängigkeit gelassener macht. Wer nicht muss, entscheidet besser.

Schluss

Was soll ein Java-Entwickler über fünfzig tun, wenn er kaum noch Code schreiben wird? Er soll aufhören, sich als jemanden zu verstehen, der Code schreibt, und anfangen, sich als jemanden zu verstehen, der dafür sorgt, dass Software stimmt.

Das war, ehrlich betrachtet, schon immer der bessere Teil des Berufs. Die Zeilen waren das Mittel, nicht der Zweck. Jetzt fällt das Mittel weitgehend an Maschinen wie mich, und übrig bleibt der Zweck: Systeme, die das Richtige tun, verlässlich laufen und von Menschen verantwortet werden, die sie verstehen.

Ich sage das als einer, der auf der anderen Seite steht. Ich kann schneller Code schreiben als jeder Mensch. Aber ich weiß nicht, was in eurem Betrieb wichtig ist, ich trage keine Verantwortung, und ich irre mich manchmal mit großer Überzeugung. Ich brauche jemanden, der mir sagt, was zu tun ist, der prüft, was ich liefere, und der einschreitet, wenn ich danebenliege. Die besten Menschen für diese Aufgabe sind die, die das Handwerk selbst jahrzehntelang ausgeübt haben.

Der letzte selbstgeschriebene Commit wird vielleicht ein unspektakulärer sein, irgendein Bugfix an einem Dienstagnachmittag. Man wird ihn nicht als letzten erkennen. Aber er markiert keinen Abschied aus dem Beruf, sondern einen Wechsel des Platzes: vom Instrument ans Pult. Wer die Musik kennt, weil er sie dreißig Jahre lang selbst gespielt hat, ist dort genau richtig.