Das Geständnis eines Programmierers: Die drei beruflichen Säulen, die ich mir in 10 Jahren aufgebaut habe, stehen kurz vor dem Einsturz – wäre es nicht besser, Zimmermann zu werden?

Künstliche Intelligenz (KI) bringt Angestellte in der Arbeitswelt vor schmerzliche Umbrüche. Wenn wir uns auf die Geschichte eines einzelnen Menschen konzentrieren, wird dieser Schmerz sehr konkret.

Kürzlich hat ein Beitrag mit dem Titel „LLMs schädigen meine Karriere als Softwareingenieur, und ich weiß nicht, was ich tun soll“ auf Hacker News Aufmerksamkeit erregt.

Der Autor ist ein Softwareingenieur mit zehnjähriger Berufserfahrung. Sein Karrierepfad schien recht klar zu sein: Er begann als Front-End-Entwickler, wechselte dann in die Back-End-Entwicklung und vertiefte sich in den Bereichen Finanzen und Zahlungen. Er hat ein umfangreiches Fachwissen in Bereichen wie PCI-Kompatibilität, doppelter Buchführung, Idempotenz zur Verhinderung von doppelten Zahlungen und Verwaltung des Zahlungslebenszyklus aufgebaut. Er war fest davon überzeugt, dass diese auf „echten“ Projekterfahrungen gegründeten Fachkenntnisse der Grundstein für sein Berufserfolg in der Branche seien.

Allerdings beschreibt er seine beruflichen Erfahrungen der letzten zwei Jahre mit dem Satz: „Drei Pfeiler sind nacheinander zusammengebrochen.“

Der erste Pfeiler: Fachwissen

Im vergangenen Jahr wurde er von einem Unternehmen aus dem Finanzsektor eingestellt. Die Unternehmen, bei denen er zuvor arbeitete, hatten zwar auch Zahlungs- und Finanzmodule in ihrem Betrieb oder Produkten, aber es waren keine reinen Finanzunternehmen.

Dieses Unternehmen hat sich vollständig der Künstlichen Intelligenz verschrieben. Daher erhielt er ab seinem ersten Arbeitstag Zugang zu den Unternehmensversionen von ChatGPT und Claude und wurde ermutigt, diese Tools bei Recherchen, Explorationen und sogar beim Codieren zu nutzen. Allerdings wurde er darauf hingewiesen, dass er für jede Zeile Code, die in die Produktionsumgebung geht, selbst prüfen und verantwortlich sein muss.

Eines der ersten Projekte, die er übernahm, war die Umgestaltung eines chaotischen alten Online-Zahlungssystems. Das Unternehmen setzte auf seine Erfahrungen bei der Erstellung solcher Systeme und vertraute ihm diese Aufgabe an.

Im Gegensatz zu anderen Unternehmen, bei denen er gearbeitet hat, erwartete dieses Unternehmen, dass die „Entwurfsdokumente“, die er schreibt, sowohl für Ingenieure als auch für Produktmanager verständlich sein sollten. Daher sollten die Dokumente nicht zu technisch und tiefgründig sein, sondern eher wie Architekturansichten aussehen. Er absolvierte das erste Dokument mit minimaler Unterstützung der KI – damals nannte er die großen Sprachmodelle sogar „zufällige Papageien“ (heute hat er diese Meinung nicht mehr) – und lieferte es ab.

Er schätzte sein Wissen sehr und glaubte, dass kein großes Sprachmodell es ersetzen könnte.

Dann sprach ihn sein Manager an: „Obwohl du die Codeabgabe recht schnell machst, hast du zu viel Zeit für die Entwurfsdokumente aufgewendet. Hast du die KI genutzt? Du solltest die KI öfter nutzen.“

Er dachte: „Das wird definitiv nicht funktionieren.“ Aber er stimmte zu. Die Modelle waren damals noch nicht so leistungsstark wie heute, aber sie verbesserten tatsächlich seine Schreibeffizienz erheblich und unterstützten sogar die Entscheidungsfindung.

Dann begann er zu erkennen, dass all sein über Jahre hinweg gesammeltes Wissen – die Abwägungen zwischen verschiedenen Implementierungslösungen, wie die Zahlungsabwicklung funktioniert, wie man Idempotenz zur Verhinderung von doppelten Zahlungen aufbaut – all das an Wert verlor. Obwohl die Modelle noch einige Anweisungen benötigten, konnten sie bereits die wesentlichen Punkte bei der Gestaltung solcher Systeme zusammenfügen, was normalerweise das schwierigste Teil ist und oft Jahre praktische Erfahrung erfordert, um in einem Kopf zu entstehen. Dies war sein erster Schock.

Aber dann dachte er: Die Modelle können das, weil es im Internet zahlreiche Artikel gibt, die die Prinzipien solcher Systeme erklären, sowie alle technischen Dokumente und eine Vielzahl von Blogbeiträgen, die beschreiben, wie man technische Tools in den Geschäftsbetrieb integriert. Für Menschen dauert es lange, all dies zu lernen, aber diese Dinge sind ja die Trainingsdaten, die die Modelle natürlich lernen können.

Der Bereich, in dem die Modelle niemals gut werden können und in dem Menschen glänzen werden, ist das Debugging! Er hat reiche Erfahrungen in der Fehlersuche in Produktionsumgebungen und in verteilten Systemen gesammelt. Dies war lange Zeit die Garantie für seinen Arbeitsplatz.

Der zweite Pfeiler: Debugging und verteilte Systeme

Nachdem die großen Sprachmodelle gut darin geworden waren, Dokumente zu schreiben und die konkrete Umsetzung zu planen, wurden sie auch gut im Codieren. Dies begann mit der Claude Code-Welle im zweiten Halbjahr 2025, gefolgt von Tools wie Codex. Obwohl er zuvor jeden Tag die großen Sprachmodelle zum Schreiben von Unittests genutzt hatte, vertraute er ihnen noch nicht, eine vollständige Implementierung direkt zu erledigen.

Der nächste Schritt war natürlich, mehr KI in den Codierungsprozess einzubringen. Ehrlich gesagt, gefiel ihm das. Er mag sowohl das Codieren als auch das Inbetriebnehmen von Produkten und das Erleben der Zufriedenheit der Benutzer. Also ersetzte er einfach eine Tätigkeit, die er mochte, durch eine andere, was ganz fair erschien.

Die großen Sprachmodelle werden immer besser im Codieren, aber sie können immer noch nicht das Durcheinander beheben, das sie (sowohl die Modelle als auch Menschen) hinterlassen. Daher hat er immer noch eine größere Rolle als nur „Roboter zu bedienen“ – dies ist sein Ticket, um seinen Job zu behalten.

Alles schien noch in Ordnung zu sein.

Dann kamen MCP, Agenten-Workflows und Claude 4.5, und der Himmel fing an, einzubrechen.

Ehrlich gesagt, war Claude 4.5 nicht so gut. Bei einer gegebenen Stapelverfolgung und etwas Kontext (in den meisten Fällen reicht es, Sentry MCP zu aktivieren und einen Sentry-Link bereitzustellen) kann es etwa 60 % der Fehler beheben. Manchmal gibt es Lösungen, die vernünftig klingen, aber völlig falsch sind.

Diesmal zweifelte er nicht mehr an der Fähigkeit der Maschine. Er sah, dass Fehler, die früher oft einen ganzen Tag lang von einem Fachmann für das Debugging behoben werden mussten, von Claude Code auf einmal gelöst wurden. Natürlich nicht alle, aber der Trend war deutlich.

Dann kamen nacheinander 4.6, 4.7, GPT 5.5, Opus 4.8 und DataDog MCP... Jetzt hat er Befehlszeilentools, die Fehler in verteilten Systemen auf einmal beheben können, Fehler, die er früher nicht lösen konnte, Fehler, die zwei ganze Tage lang intensives Debugging erforderten. Fehler in verteilten Systemen ohne ausreichende Beobachtbarkeit. Jetzt können 90 % der Fehler auf einmal behoben werden, einschließlich seltsamer Wettlaufbedingungen, unerwarteter Randfälle, Probleme bei der Integration von Drittanbietern, nicht dokumentierten API-Grenzsituationen – alles. Er muss fast nicht mehr eingreifen.

Natürlich hat er immer noch Arbeit zu tun, denn es muss jemand den Code prüfen und die Roboter bedienen. Aber jetzt ist er nur noch ein durchschnittlicher, jederzeit austauschbarer Ingenieur. Jede seiner Fachkenntnisse kann von einem anderen Senior-Ingenieur, der mit großen Sprachmodellen umgeht, leicht erreicht werden. Er hat das Gefühl, dass all sein Fachwissen in den Bereichen Finanzen und Zahlungen, all seine Debugging-Intuition und sein Wissen über verteilte Systeme, das er mit Schweiß und Tränen erworben hat, jetzt über Prompting abgerufen werden kann.

Wir wurden immer gesagt, dass Generalisten und Spezialisten immer ihre Nische haben würden. Aber jetzt formt der Markt jeden Menschen zu einem Generalisten. Das an sich ist kein Schlechtes – bis man die Ökonomie von Angebot und Nachfrage betrachtet: Wenn jeder ein Generalist wird und es keine entsprechende Nachfrage gibt, sinkt der Preis für Generalisten. Und wir wissen alle, dass die Nachfrage schwindet.

Der dritte Pfeiler, der noch steht: Codequalität und Architektur

Allerdings hat er noch einen Pfeiler, der steht: Codequalität und Softwarearchitektur – das, was jetzt einfach als „Geschmack“ bezeichnet wird.

Im Laufe seiner Karriere hat er immer gerne Refactoring vorgenommen, hochwertigen Code geschätzt und sich in den Iterationen Zeit für diese Aufgabe genommen. Begriffe wie DDD, Hexagonale Architektur, Saubere Architektur – diese waren ihm alle vertraut. Er mag dieses Thema und mag es, über die verschiedenen Abwägungen und Ideen zur Gestaltung von Codebasen zu diskutieren. Er mag es wirklich.

Dies ist der letzte stehende Pfeiler. Nur, dass es jetzt niemandem mehr interessiert.

Agenten sind sehr schlecht darin, die Codebasis sauber zu halten. Wenn man sie nicht leitet, stoßen sie schnell auf Probleme mit zirkulären Abhängigkeiten. Sie wiederholen Code, fügen irrelevante Kommentare hinzu, mischen reine Funktionen und Nebeneffekte und ignorieren die SOLID-Prinzipien.

Dies hätte eigentlich den Menschen ihren Arbeitsplatz sichern können, aber diese Fähigkeit ist jetzt auf das Wort „Geschmack“ reduziert worden. Aber es ist nicht nur eine Umbenennung – die gesamte Branche geht in eine Welt, in der die Codeorganisation nicht mehr so wichtig ist.

Ja, die Menschen sollten die Agenten leiten, um eine spaghettiartige Codebasis mit zirkulären Abhängigkeiten zu vermeiden. Niemand will eine Codebasis, die bei einem Anrühren kaputt geht und die eine Note F bekommt. Aber was ist mit einer Note C oder D? Das ist jetzt völlig in Ordnung. Es wird keine Codebasis mit Note A oder B mehr benötigt, denn der Code wird für große Sprachmodelle geschrieben, nicht für Menschen.

Er will nicht darüber streiten, ob das an sich gut oder schlecht ist. Wenn der Quellcode jetzt für Maschinen und nicht für Menschen geschrieben wird, dann ist es vielleicht auch in Ordnung, auf die Maschine abzustellen.

Aber dies ist wieder ein Pfeiler in seinen Fachkenntnissen, der sich auflöst. Das umfangreiche Wissen, das er in diesem Bereich gesammelt hat, ist nicht mehr so wertvoll. All die Zeit, die er aufgewendet hat – Lesen von Büchern, praktische Übungen, Diskussionen mit anderen Ingenieuren, Schreiben von Architekturentscheidungsdokumenten – all das wird nutzlos.

Was nun?

Der Autor sagt, dass er immer noch einen Job hat und glaubt, dass er in absehbarer Zukunft (zumindest in diesem Unternehmen) weiterhin angestellt bleiben wird, aber er weiß nicht, wie er das langfristig einschätzen soll.

Er hat zehn Jahre (wenn man auch die nicht beruflichen Erfahrungen mitzählt, noch länger) damit verbracht, Dinge zu beherrschen, die immer weniger wert sind. Sein letzter Fachpfeiler ist jetzt auf „Geschmack“ reduziert, und es ist wahrscheinlich, dass er auch nicht lange halten wird.

Und er weiß, dass er nicht der Einzige in dieser Situation ist. Vor etwa acht Monaten hat sein aktuelles Unternehmen eine Entlassungsrunde durchgeführt (angeblich unabhängig von der KI). Einige hervorragende ehemalige Kollegen wurden entlassen und suchen noch immer nach einem Job. Die meisten von ihnen haben dasselbe Problem: Ihre Fachkenntnisse reichen nicht mehr aus, um sich von anderen abzuheben.

Das Unternehmen beginnt jetzt wieder, einige Stellen zu besetzen. Die Vertrautheit mit dem Bereich ist jetzt kein starker Unterscheidungsfaktor mehr. Früher haben sie „Softwareingenieur – bestimmter Bereich“ eingestellt. Jetzt steht nur „Softwareingenieur“ geschrieben, und die Teamzuweisung erfolgt erst nach der Einstellung.

Natürlich ist das für diejenigen ausgezeichneten Ingenieure, die nie die Möglichkeit hatten, sich in einen bestimmten Bereich zu vertiefen und jetzt bessere Beschäftigungsmöglichkeiten haben, gut. Aber wenn man daran denkt, dass andere ausgezeichnete Ingenieure, die ihr ganzes Leben lang Fachwissen aufgebaut haben, jetzt auf demselben Wettlaufbahn konkurrieren müssen, ist das auch ein wenig traurig.

Der Autor meint, dass der einzige Ausweg, um langfristig seinen Arbeitsplatz zu sichern, darin besteht, sein Fachwissen in eine Richtung zu wenden, in der es für große Sprachmodelle schwerer ist, es zu erlernen. Aber was bleibt noch übrig?

Er hat überlegt, wieder in die Schule zu gehen, Mathematik, Statistik, fortgeschrittenes maschinelles Lernen zu studieren und dann um eine Forschungsstelle in einem führenden Labor zu bewerben. Aber in seinem Land gibt es keine führenden Labore, und die wenigen, die es gibt, erhalten eine enorme Anzahl von Bewerbungen. Außerdem ist es für ihn aus familiären Gründen schwierig, ins Ausland zu ziehen. Wenn er endlich in der Lage ist, diesen Sprung zu machen, könnte die RSI die Forscher überflüssig machen.

Am Ende schreibt er einen witzigen Satz: „Vielleicht sollte ich überlegen, meine Holzbau-Hobby zur Berufung zu machen...“

Antwort auf Kontroversen

Nach der Veröffentlichung dieses Blogs wurde es in den sozialen Medien massiv verbreitet. Der Autor hat einige repräsentative Kommentare ausgewählt und darauf geantwortet.

Zur Frage: „Ist das Fachwissen wirklich nutzlos? Zum Beispiel die lokalen Steuergesetze“

Einige Kommentare haben darauf hingewiesen, dass die großen Sprachmodelle bei der Behandlung von lokalen Steuergesetzen, Details der Buchhaltungsprozesse, der Umsetzung von Kontenrahmen usw. oft Fehler machen. Wie können sie also das menschliche Fachwissen ersetzen?

Der Autor gibt zu, dass er in seinem Originaltext nicht klar genug war. Die LLMs können tatsächlich nicht alle lokalen Steuergesetze oder extrem feinen Regeln automatisch erledigen – aber diese werden normalerweise von der juristischen Abteilung behandelt (und auch die juristische Abteilung nutzt in großem Umfang LLMs, um routinemäßige Arbeiten zu automatisieren). Das Problem ist, dass sein über Jahre hinweg gesammeltes Fachwissen (obwohl es viel weniger tief ist als das der juristischen Abteilung) jetzt direkt über ChatGPT Pro/Extended Thinking abgerufen werden kann. Das ist es, was ihn frustriert – er hatte immer gedacht, dass in einer Welt von „nur Code schreibenden“ Programmierern diese Kenntnisse ihn von anderen abheben würden, aber das ist nicht mehr der Fall.

Was die Agenten betrifft, die früher nicht gut in diesen Details waren, gibt er zu. Aber mit neuen Modellen, Agent-spezifischen Dokumenten und der Pflicht, die Agenten im Root-Verzeichnis der Codebasis eine AGENT.md-Datei zu lesen, bevor sie Code schreiben, hat sich die Situation geändert. Er muss immer weniger auf Kollegen zurückgreifen, die länger in der Firma sind und die Details kennen. Jetzt benötigt er für seine Arbeit viel weniger menschliche Eingaben – wenn man darüber nachdenkt, ist das beängstigend.

Zur Frage: „Es ist total unvernünftig,