Blog 7.5.2026

Warum das Ende der Junior Engineers ein teurer Fehler wäre

Intelligente Industrie

Warum der Verzicht auf Junior Engineers unsere Industrie teurer zu stehen kommen wird, als wir glauben. Die Debatte, ob es künftig noch Junior Software Engineers geben wird, läuft fast ausschließlich über das Kostenargument. Das ist ein Denkfehler, der unsere Industrie in zehn Jahren teuer zu stehen kommen wird. Gleich aus zwei Gründen, die in der aktuellen Diskussion kaum jemand auf dem Radar hat.

Die bequeme Rechnung

Man muss kein Prophet sein, um zu sehen, was gerade passiert. KI-Systeme übernehmen immer mehr der Aufgaben, die klassischerweise auf den Tischen von Junior Engineers landeten. Boilerplate-Code, einfache Refactorings, Standard-Tests, überschaubare Bugfixes, die ersten Gehversuche in einer neuen Codebase. Das funktioniert oft erstaunlich gut, und mit jedem neuen Modell wird es besser.

Aus Unternehmenssicht sieht die Konsequenz auf dem Papier bestechend einfach aus. Warum noch teure Menschen einstellen, wenn eine Maschine vergleichbare Ergebnisse für einen Bruchteil der Kosten liefert? Die Rechnung wird in Vorstandsetagen und Finanzabteilungen gerade landauf, landab gemacht, und sie geht – kurzfristig – wunderbar auf. Weniger Einstiegspositionen, weniger Gehaltskosten, eine schlanke Bilanz, und obendrauf ein Erzählmuster, das man gut verkaufen kann: Wir sind AI-first, wir sind effizient, wir sind zukunftsfähig.

Ich will dieses Argument gar nicht karikieren. Es hat eine innere Logik, und Menschen, die es vertreten, sind in der Regel keine Zyniker. Sie reagieren auf reale wirtschaftliche Zwänge, auf Investorenerwartungen, auf einen Markt, der Effizienzgewinne sofort belohnt und langfristige Investitionen – wenn überhaupt – nur zögerlich. Wer heute eine Quartalsbilanz verantwortet, hat gute Gründe, diese Rechnung aufzumachen. Das Problem ist nur: Sie stimmt nicht. Oder genauer: Sie stimmt nur, wenn man eine entscheidende Variable aus der Gleichung streicht. Und diese Variable heißt Zeit.

Die Pipeline-Illusion

Die Senior Engineers von heute sind die Junior Engineers von gestern. Das klingt banal, wird aber in der aktuellen Diskussion erstaunlich konsequent ignoriert. Das Wissen, das heute in den Köpfen erfahrener Engineers steckt, ist dort nicht auf einen Schlag gelandet, und schon gar nicht von alleine. Es ist durch langjährige Praxis und nicht selten schmerzhafte Erfahrungen entstanden. Hart erworben, wie man so sagt.

Und nur ein erschreckend kleiner Teil davon lässt sich direkt weitergeben. Mentoring hilft, Schulungen helfen, Pair Programming hilft. Aber was wirklich hängen bleibt, sind die eigenen Erfahrungen. Die Narben aus den verschiedensten Schlachten. Wer nie erlebt hat, wie sich ein Projekt anfühlt, das mit voller Wucht gegen die Wand fährt, erkennt die Warnzeichen beim nächsten Mal nicht. Wer nie eine schlaflose Nacht auf der Suche nach einem Bug verbracht hat, besteht im nächsten Projekt nicht von sich aus auf besserer Testabdeckung. Wer nie selbst eine Architekturentscheidung getroffen hat, die sich drei Jahre später als teurer Fehler entpuppt, trifft Architekturentscheidungen nie mit der nötigen Demut.

Dieses mühsam erworbene Wissen lässt sich nicht komprimiert weitergeben, jedenfalls nicht ohne massive Verluste. Man kann einem Junior sagen, dass zu früh eingeführte Abstraktionen fast immer falsch sind. Er wird nicken. Er wird es trotzdem tun. Und erst wenn er selbst erlebt hat, wie seine elegante Abstraktion sechs Monate später dem tatsächlichen Anwendungsfall im Weg steht, sitzt die Lektion wirklich. Das ist kein pädagogisches Defizit, das ist die Natur von Erfahrungswissen.

Wer Junior-Positionen wegoptimiert, optimiert also nicht nur eine Kostenstelle weg. Er optimiert die Entstehungsbedingungen der nächsten Senior-Generation weg. Und zwar leise, ohne dass es jemand in der nächsten Quartalsbilanz sieht.

Der Widerspruch, den niemand ausspricht

Dabei erzählt dieselbe Industrie gleichzeitig eine zweite Geschichte, die mit der ersten nicht zusammenpasst. Man hört sie auf jeder Konferenz, liest sie in jedem zweiten LinkedIn-Post: Die Rolle des Software Engineers wird sich wandeln. Weg vom reinen Implementieren, hin zum Orchestrieren, zum Überwachen, zum vorausschauenden Planen, zum echten Partner des Business. Der Engineer der Zukunft, so die These, wird weniger Code selbst schreiben und stattdessen Agenten und Systeme orchestrieren, KI-generierten Code prüfen, Architekturen verantworten.

Ich halte diese Prognose für weitgehend zutreffend. Das ist nicht der Punkt. Der Punkt ist: Wer die Rolle so beschreibt, beschreibt eine Tätigkeit, die fast vollständig auf Erfahrungswissen beruht. Orchestrieren kann nur, wer die orchestrierten Teile aus eigener Praxis kennt. Überwachen kann nur, wer weiß, wonach er Ausschau halten muss. Vorausschauend planen kann nur, wer schon einmal überrascht worden ist.

Das ist die logische Inkonsistenz, die in der Debatte kaum jemand ausspricht. Wer behauptet, dass der Beruf seniorlastiger wird, und gleichzeitig die Junior-Phase abschafft, in der genau diese Seniorität entsteht, sagt zwei Dinge, die sich gegenseitig ausschließen. Man kann das eine sagen oder das andere. Beides zusammen ergibt keinen Sinn.

Große Teile unserer Industrie laufen gerade mit Scheuklappen durch die Welt, so groß wie Scheunentore. Und das Gefährliche an Scheuklappen ist: Darunter hat man das Gefühl, klar zu sehen.

Das verschwindende Fundament

Bis hierhin habe ich eine Argumentationslinie entwickelt, die viele Leser so oder ähnlich schon einmal gehört haben, auch wenn sie selten so direkt ausgesprochen wird. Nun komme ich zu einem Aspekt, der in der aktuellen Diskussion fast völlig fehlt und der die Sache deutlich brisanter macht: die Frage nach dem Vorwissen.

Als jemand, der sich gerade noch zur Generation X zählen darf, habe ich sowohl an mir selbst als auch an vielen Kollegen ähnlichen Jahrgangs einen typischen Werdegang beobachtet. Die Auseinandersetzung mit dem Computer, das Verstehen der Frage „Was macht diese Maschine eigentlich?“, begann bereits in der Kindheit. Mein erstes Stück BASIC-Code habe ich mit ungefähr zehn Jahren geschrieben. Der erste Code, bei dem ich wirklich verstanden habe, warum ich ihn schreibe und was dabei passiert, kam ein paar Jahre später. Zum Ende meiner Schulzeit hatte ich nicht nur eine genaue Vorstellung davon, wie man einen Computer bedient, sondern auch davon, was diese Maschine im Innersten tut und wozu sie sich nutzen lässt.

Vielen meiner Kollegen ging und geht es ähnlich. Wir waren Nerds, lange bevor der Begriff positiv besetzt wurde. „Der macht irgendwas mit Computern“ war nicht unbedingt als Kompliment gemeint. Gestört hat es uns nicht. Im Gegenteil. Irgendwann wurde klar: Das können wir zu unserem Beruf machen – und das wollen wir.

Dieses „Wollen“ ist der Punkt, an dem es für Unternehmen interessant wird. Wir haben nicht einfach einen Job gesucht. Wir haben eine Möglichkeit gesucht, unsere ohnehin vorhandenen Interessen weiterzuverfolgen – und bekamen dafür auch noch Geld. Das hat uns geprägt. Wir haben uns Wissen selbstständig und eigenmotiviert angeeignet, Jahr für Jahr, ohne dass es jemand anordnen musste. Wissen, für das andere Branchen teure Schulungen, externe Trainer und mühsam aufgebaute Lernpfade brauchen. Ein erheblicher Teil des Wissens, das wir im Beruf brauchten, hatten wir längst vor dem ersten Arbeitstag erworben. Selbstständig, aus Neugier, in durchgemachten Nächten. Die Hürde beim Berufseinstieg war vergleichweise niedrig, weil viel weniger „von Grund auf“ beigebracht werden musste als in anderen Branchen. Nicht umsonst können in der IT Quereinsteiger seit jeher besonders gut Fuß fassen: Weil ein großer Teil der relevanten Qualifikation ohnehin eigenmotiviert in der Freizeit entstand.

Das ist über Jahrzehnte hinweg ein gewaltiger, meist unausgesprochener Wettbewerbsvorteil unserer Industrie gewesen. Wir mussten nicht bei Null anfangen. Und wir mussten nicht jeden einzelnen Lernschritt organisieren und bezahlen – er passierte von allein, getrieben von Menschen, die sowieso nicht aufhören konnten.

In Bewerbungsgesprächen stelle ich potenziellen Kandidaten seit Jahren gerne die Frage: „Warum gerade Softwareentwicklung? Warum dieser Job? Was macht ihn für dich interessant?“ Bei den allermeisten sehe ich dann ein Leuchten in den Augen und höre Variationen derselben Geschichte: Weil es mich schon als Kind fasziniert hat. Weil ich nächtelang wissen wollte, wie dieses oder jenes funktioniert. Ich kann mich nicht an eine einzige Antwort erinnern, die auch nur ansatzweise in Richtung „Weil man hier gutes Geld verdient“ ging.

Und das ist keine romantische Beobachtung, das ist eine ökonomische. Intrinsisch motivierte Entwickler treiben sich selbst. Sie machen nicht um 17 Uhr Feierabend, wenn sie mitten in einem interessanten Problem stecken. Sie lesen auch am Wochenende den RFC, den ihnen ein Kollege empfohlen hat. Sie probieren die neue Technologie zu Hause aus, bevor das Unternehmen überhaupt entschieden hat, ob man sie einführen will. Dieser Typ Mitarbeiter erzeugt einen Output, der mit reiner Arbeitszeit nicht zu erklären ist – und einen Erkenntnisgewinn, der sich irgendwann als Lösung für ein Problem herausstellt, das ohne diese Neugier vielleicht nie gelöst worden wäre. Wer solche Menschen im Team hat, spart sich eine Menge explizites Wissensmanagement. Wer sie nicht hat, muss es mühsam ersetzen.

Und genau diesen Typ Biographie sehe ich in den letzten Jahren seltener werden. Nicht, weil junge Menschen fauler oder weniger neugierig wären. Sondern weil die Computer von heute schlicht zu gut geworden sind. Wer heute einen Computer nutzen will, muss nicht mehr unter die Haube schauen. Für fast alles gibt es fertige Anwendungen und Apps. Die Notwendigkeit, selbst aktiv zu werden, selbst die Innereien zu betrachten, weil es sonst keine Möglichkeit gäbe, existiert nicht mehr.

Hinzu kommt: Der Computer ist nichts Besonderes mehr. Kein ausgefallenes Gerät, kein Möbelstück, das im Wohnzimmer seinen eigenen Platz beansprucht und um das herum man eine eigene Beschäftigung aufbaut. Er ist mitten im Leben angekommen. Als Laptop, als Tablet, als Smartphone. Immer und überall dabei, selbstverständlich wie ein Kugelschreiber. Und genau das, was ihn so nützlich macht – seine Allgegenwart, seine Unsichtbarkeit als technisches Gerät – nimmt ihm die Aura, die früher Kinder stundenlang vor dem Gehäuse sitzen ließ. Man bestaunt den Kugelschreiber nicht mehr, man benutzt ihn.

Die Revolution frisst ihre Kinder. Das klingt dramatischer, als es gemeint ist, denn ich beklage diese Entwicklung nicht. Ich finde es großartig, dass man heute nicht mehr Nerd sein muss, um die Möglichkeiten eines Computers auszuschöpfen. Der Anwender darf Anwender bleiben. Für die Gesellschaft ist das ein enormer Fortschritt. Für die Rekrutierungspipeline unserer Industrie ist es eine stille Katastrophe, die sich erst langsam bemerkbar macht.

Natürlich gibt es sie weiterhin: die Enthusiasten. Die Kinder, die fasziniert sind von der Maschine. Die Jugendlichen, die sich ihre eigene Linux-Distributionen bauen. Aber sie werden weniger, und sie werden nicht mehr ausreichen, um den Bedarf einer Industrie zu decken, die jahrzehntelang von einem unsichtbaren Subventionsmodell profitiert hat – nämlich davon, dass ein Gutteil der Grundqualifikation in den Kinderzimmern der Republik kostenlos entstand.

Die Zangenbewegung

Wenn man beide Entwicklungen nebeneinanderlegt, ergibt sich ein Bild, das deutlich unangenehmer ist als jede der Teilbeobachtungen für sich genommen. Auf der einen Seite schrumpft der informelle Vorlauf, mit dem Berufseinsteiger früher ins Unternehmen kamen. Auf der anderen Seite schrumpfen die formellen JuniorPositionen, in denen dieser Vorlauf in echte Berufserfahrung umgesetzt wurde. Jede dieser Entwicklungen wäre für sich schon ein Problem. Gemeinsam sind sie eine gefährliche Zangenbewegung.

Die Pipeline wird an zwei Stellen gleichzeitig dünner. Da geht es nicht mehr um die Frage, ob ein paar weniger Juniors ins System kommen. Es geht um die Frage, ob wir in fünfzehn Jahren überhaupt noch genügend Menschen haben, die die harten Entscheidungen treffen können, auf die es dann ankommt.

Nicht jeder ist Bayern München

Firmen lassen sich, was die Rekrutierung von Engineers angeht, durchaus mit Fußballvereinen vergleichen. Da gibt es die Bayern Münchens dieser Welt: Unternehmen, die mit so viel Geld und Strahlkraft ausgestattet sind, dass sie sich die besten Spieler von überall einkaufen können. Diese Unternehmen gibt es, und sie werden auch weiterhin existieren. Aber die Fußballlandschaft besteht nicht nur aus Bayern München. Die allermeisten Vereine haben diese Option nicht, oder nur sehr begrenzt. Ihre Stärke ist stattdessen die Jugendarbeit: Talente früh erkennen, früh fördern, geduldig entwickeln, in der berechtigten Hoffnung, dass sich diese Investition auszahlt – sportlich und wirtschaftlich.

Jugendarbeit war in der Softwareindustrie in den fast 25 Jahren, in denen ich in ihr unterwegs bin, nie ein leichtes Unterfangen. Aber sie war möglich, und in vielen Fällen hat sie darüber entschieden, welche Unternehmen sich langfristig behauptet haben und welche nicht. Unter den Vorzeichen, die ich in den vorigen Abschnitten beschrieben habe, wird sie zur Überlebensfrage.

Wenn wir in unseren Unternehmen ehrlich in den Spiegel schauen, werden wir meistens feststellen müssen: Als Fußballverein wären wir kein Bayern München. Die logische Konsequenz lautet dann aber auch: Wir dürfen uns nicht länger so verhalten, als wären wir es. Die Vorstellung, man könne die Jugendarbeit anderen überlassen und bei Bedarf fertige Senior Engineers günstig vom Markt einkaufen, war schon in den letzten Jahren fragwürdig. Sie wird in den kommenden Jahren zunehmend absurd.

Hier wird sich die Spreu vom Weizen trennen. Es wird Unternehmen geben, die sehr kurzfristig auf ihre Bilanzen schauen und durch das Wegoptimieren von JuniorStellen den schnellen Gewinn mitnehmen. Und es wird die langfristig denkenden Unternehmen geben, die Ausbildung und Nachwuchsförderung nicht als Last sehen, sondern als Investition in die eigene Handlungsfähigkeit. Die erste Kategorie mag lange auf Kosten der zweiten gelebt haben. Mit dem aktuellen Wandel wird das zunehmend schwerer.

Ausbildung ist keine Wohltätigkeitsveranstaltung. Juniors nicht nur anständig zu bezahlen, sondern ihnen auch die Gelegenheit zu geben, echte Erfahrungen zu sammeln – das tun wir nicht aus pädagogischem Idealismus. Wir tun es, weil es in unserem ureigenen unternehmerischen Interesse liegt. Wer das heute nicht sehen will, lernt es in zehn Jahren auf die harte Tour.

Was jetzt zu tun ist

Die gute Nachricht ist: Die Lösung ist nicht kompliziert. Sie ist nur unbequem, weil sie Aufwand bedeutet und weil sie gegen den kurzfristigen Reflex läuft, den der aktuelle Markt belohnt.

Unternehmen können und dürfen sich bei dieser Frage nicht (nur) auf andere verlassen. Schulen und Universitäten werden einen Teil beitragen, aber die Zyklen, in denen sich Lehrpläne und Studiengänge anpassen, sind zu lang, um darauf zu warten. Nur wer bereit ist, selbst aktiv zu werden, wird am Markt bestehen. Entwicklungen zu bejammern und die guten alten Zeiten zu betrauern, löst kein Problem.

Konkret heißt das: Wir brauchen interne Ausbildungspläne, die diesen Namen verdienen. Eine enge Zusammenarbeit zwischen den Fachleuten, die das Wissen haben, und dem HR-Bereich, der die Strukturen dafür bauen kann. Echte Aufgabenfelder für Junior Engineers – nicht die Reste, die KI noch übrig gelassen hat, sondern Gelegenheiten, an denen sie selbst Entscheidungen treffen, Fehler machen und daraus lernen können. Eine Kultur, in der diese Fehler auch tatsächlich gemacht werden dürfen. Und die Bereitschaft, diesen Aufwand als das zu sehen, was er ist: keine Kosten, sondern eine strategische Investition.

Das heißt auch – und das ist der Punkt, der vielen am schwersten fallen wird: Wir müssen bewusst entscheiden, wo wir KI eben nicht einsetzen, obwohl wir könnten. Nicht aus Prinzip, nicht aus Technologieskepsis, sondern weil Juniors Aufgaben brauchen, an denen sie sich reiben können. Wenn jede Implementierungsaufgabe automatisch an den Coding-Agent geht, bleibt für den Junior nur noch das Reviewen von Code, den er selbst nie hätte schreiben müssen. Das ist ungefähr so effektiv, wie jemandem das Autofahren beizubringen, indem man ihn ausschließlich auf dem Beifahrersitz mitfahren lässt. Lernräume entstehen nicht von allein, sie müssen geschaffen und geschützt werden – auch gegen die Versuchung, alles, was automatisierbar ist, auch zu automatisieren.

Ist das anstrengend? Natürlich – finanziell und personell. Aber die Alternative möchte erst recht niemand. Wissen, das einmal aus einer Organisation verschwunden ist, lässt sich nicht per Knopfdruck zurückholen. Das ist wie mit einer eingestellten Produktionslinie, deren erfahrene Facharbeiter in Rente gegangen sind: Man kann die Maschinen reaktivieren, aber das Wissen, wie man die Maschinen in Grenzsituationen wirklich bedient, muss man sich mühsam neu erarbeiten. Und der Weg dorthin dauert, genau wie beim ersten Mal, gerne mal Jahre. Die einzige kurzfristige Alternative heißt dann: externe Dienstleister, die genau diese Abhängigkeit erkennen und sich fürstlich bezahlen lassen werden. Am Ende bringen die eingesparten Junior-Gehälter von heute die doppelten und dreifachen Beraterkosten von morgen – das exakte Gegenteil der ursprünglich erhofften Einsparung.

Der eigentliche Punkt

Die Diskussion, ob es künftig noch Junior Engineers geben wird, wird falsch geführt, wenn sie nur als Kostenfrage geführt wird. Sie ist in Wahrheit eine Frage der Handlungsfähigkeit. Kaum ein Unternehmen kommt heute noch ohne Software aus. Das bedeutet auch: Kaum ein Unternehmen kommt ohne Software Engineers aus. Egal, wie das Berufsbild in zehn oder zwanzig Jahren genau aussehen wird, egal wie viel KI-Unterstützung wir bis dahin haben werden – die Kernqualifikation, aus Erfahrung gute Entscheidungen zu treffen, bleibt.

Diese Qualifikation entsteht nicht im luftleeren Raum. Sie entsteht in Menschen, die einmal Juniors waren und denen man die Zeit und den Raum gegeben hat, Seniors zu werden. Wer diesen Raum heute wegrationalisiert, weiß morgen nicht mehr, wer die Software baut, von der sein Unternehmen abhängt.

Ausbilden oder abhängen lassen. Etwas Drittes gibt es nicht. Stellen wir die Weichen heute – morgen ist es dafür zu spät.

Christian Seifert

Christian Seifert ist Brückenbauer zwischen Code, Köpfen und Komplexität. Als Principal Software Architect bei Gofore unterstützt er Unternehmen dabei, ihre Softwarelandschaften zukunftssicher zu gestalten - technisch fundiert, nachhaltig und mit Fokus auf starke Teams. Seit fast 25 Jahren gestaltet und verantwortet er Softwareprojekte in unterschiedlichen Branchen und hat dabei gelernt, dass erfolgreiche Architektur nicht nur aus technischen Details besteht, sondern vor allem aus Menschen, die gemeinsam an guten Lösungen arbeiten.

Zum Seitenanfang