KI schlägt Code schreiben: Wie sich Entwickler unverzichtbar machen

Quellcode auf einem grossen Monitor in einem abgedunkelten Raum, warmes Licht einer Schreibtischlampe
Deine Reaktion:

Wie übertrifft man KI-Modelle als Softwareentwickler? Genau darum geht es in einem vielbeachteten Essay von Sean Goedecke, den er Ende August 2026 veröffentlicht hat. Der Autor argumentiert, dass die alte Formel für den Wert eines Ingenieurs – nämlich der Vergleich mit einem durchschnittlichen Ersatzspieler – unter den Bedingungen moderner KI eine neue, viel radikalere Bedeutung bekommt.

Früher war ein durchschnittlicher Entwickler seinen Lohn wert, weil das Schreiben von Code schlicht teuer war. Die Einstiegshürde für Software lag in der Komplexität der Werkzeuge, der Einarbeitungszeit und den Fehlern, die ein Neuling erst mühsam lernen musste. Heute kostet ein KI-Agent, der Code produziert, etwa hundert Dollar im Monat. Damit stellt sich die unbequeme Frage: Was kannst du, was ein Modell wie GPT-5.6-Sol oder Claude Opus 5 an deiner Stelle nicht auch könnte? Und warum sollte dich ein Unternehmen dafür zwei oder drei Größenordnungen teurer bezahlen?

Diese Frage ist unangenehm. Aber sie ignoriert – so Goedecke – nur, wer sich in Illusionen flüchtet. Die Vorstellung, dass LLMs eigentlich gar keinen Code schreiben können und der ganze Hype bald zusammenbricht, hält einer Prüfung nicht stand. Wir werden im Jahr 2027 nicht aufwachen und wieder alles von Hand programmieren. Stattdessen lohnt es sich, genauer hinzusehen: Welche Fähigkeiten von Entwicklern sind auch für die besten Modelle schwer zu erreichen? Der Autor nennt zwei zentrale Bereiche: tiefe Vertrautheit mit der Codebase und technische Kommunikation.

Wert über Ersatz: Die neue Messlatte für Softwareentwickler

Goedecke hat den Begriff „Value over Replacement“ bereits 2025 in einem Aufsatz geprägt. Damals war die Idee noch einfach: Ein Entwickler sollte nicht danach bewertet werden, wie viel Geld sein Produkt eingebracht hat, sondern wie viel besser er im Vergleich zu einem durchschnittlichen Ingenieur auf derselben Position war. Ein JIRA-Ticket abzuarbeiten, das einem zugewiesen wurde, ist eben keine eigene Leistung, sondern bloß Erfüllung einer Rolle.

Im KI-Zeitalter wird diese Messlatte jedoch drastisch höher gelegt. Ein durchschnittlicher Ersatz ist heute kein Mensch mehr, sondern ein Modell. Und das Modell kostet nicht sechsstellig, sondern dreistellig im Jahr. Wer sich also auf seiner Position halten will, muss nachweisen, dass er mehr liefert als das, was ein LLM in derselben Umgebung liefern würde. Das ist eine ernüchternde Rechnung, aber sie hat einen Vorteil: Sie zwingt dazu, ehrlich zu inventarisieren, wo der eigene Mehrwert liegt.

Die meisten Entwickler fallen dabei auf zwei Säulen zurück, die sie vermutlich für selbstverständlich halten: Sie kennen den Code, und sie können über den Code reden. Genau diese scheinbar banalen Fähigkeiten sind es, die Modelle strukturell nicht beherrschen – und vielleicht auch nie ganz beherrschen werden.

Codebase-Vertrautheit: Der entscheidende Kontext, den Modelle nicht haben

Frontier-LLMs machen längst keine simplen Halluzinationen oder Off-by-one-Fehler mehr. Was sie stolpern lässt, sind Fehler aus Unwissenheit und aus Paranoia. Ein Modell kennt nicht das interne Modul, das genau die Logik bereits enthält, die es gerade neu implementiert. Es weiß nicht, dass System X in der Firma der Standardort für genau diese Funktionalität ist. Und es passt seinen Codestil nicht an die Konventionen des Teams an.

Die andere Fehlerklasse ist die Paranoia. Das Modell baut dreifach redundante Checks für einen Wert ein, der in der Praxis einmal aus einer Config geladen und nie wieder geändert wird. Es entwirft ein komplexes Caching-System, weil es zehn Millisekunden Stale Data für inakzeptabel hält, obwohl niemand im Unternehmen das Problem hat. Es fügt fallback-Logik und Graceful Degradation in ein CLI-Tool ein, das im Fehlerfall einfach crashen sollte. Das sind typische Fehler eines kompetenten Neulings, der die Risiken und Gewohnheiten des Systems noch nicht verinnerlicht hat.

Goedecke betont: Diese Fehler sind kein Zufall, sondern eine direkte Folge der Architektur von KI-Agenten. Ohne kontinuierliches Lernen oder wirklich massive Kontextfenster bleiben Agenten strukturell ignorant. Und genau hier liegt deine Chance. Wer die Codebase kennt, kann diese Fehler erkennen und korrigieren. Noch wichtiger: Er kann dem Modell selbstbewusst widersprechen. KI-Agenten sind überzeugend, wenn sie einen riskanten Sonderfall argumentieren. Sie neigen dazu, sich in einer Schleife zu verfangen und immer mehr defensive Systeme einzubauen, statt die einfache Lösung zu wählen. Ein Mensch, der den Code seit Jahren pflegt, muss den Mut haben zu sagen: „Das ist Quatsch, wir brauchen X und Y gar nicht, lass uns Z machen.“

Dabei hilft es nicht, andere KI-Agenten als Reviewer einzusetzen. Derselbe Model-Typ reproduziert dieselben Annahmen. Aber selbst verschiedene Modelle neigen zu denselben strukturellen Fehlerarten – Unwissenheit und Paranoia –, weil sie mit den gleichen Trainingsmethoden optimiert wurden. Ein KI-Review-Loop läuft sogar Gefahr, noch paranoidere Systeme zu produzieren, weil moderne Modelle darauf trainiert sind, unbedingt irgendeinen Nitpick zu finden. Das Ergebnis ist dann eine Codebase mit zehntausend Zeilen defensivem Müll.

Technische Kommunikation: Das menschliche Gegengift zur KI-Sprache

Der zweite Bereich, in dem Menschen Modelle schlagen, ist die Kommunikation. Ironischerweise werden die Modelle immer besser im Programmieren, aber paradoxerweise immer schlechter im Schreiben. Die frühen GPT-Modelle hatten gelegentlich einen fast menschlichen Tonfall. Mit GPT-4o kam der moderne Slop-Dialekt, und die neueren Anthropic-Modelle sprechen ein seltsames „Claudish“ – eine Mischung aus barock und abgehackt, die niemand freiwillig liest. Goedecke vermutet einen mechanistischen Grund: Die internen Reasoning-Tokens der Modelle sind zu einer Art Telegrammstil mutiert, der fast unverständlich ist. Wenn dieser Stil dann in die normale Ausgabe übersetzt wird, klingt er immer noch fremdartig.

Dahinter stecken zwei strukturelle Probleme. Gutes Schreiben ist kein verifizierbarer Bereich. Bei Mathematik oder Code kann man Aufgaben automatisch erzeugen und auswerten. Bei Schreibstil nicht. Wenn man Menschen beauftragt, Texte zu bewerten – etwa durch RLHF –, entsteht genau dieser Aufsatz-Stil, der in Einzelabsätzen beeindruckend wirkt, aber auf Dauer ermüdet. Und zweitens: Die Labore konzentrieren sich fast ausschließlich auf Fähigkeiten statt auf Kommunikation. Diese Priorität ist verständlich, aber sie hat zur Folge, dass Sprachmodelle für technische Inhalte zunehmend unleserlich werden.

Goedecke zieht dafür einen interessanten Vergleich: In Peter Watts’ Roman „Blindsight“ gibt es „Synthesisten“, die als Übersetzer zwischen kognitiv augmentierten Genies und normalen Menschen arbeiten. Die Genies kommunizieren in Abkürzungen und Gesten; die Synthesisten machen ihr Wissen für andere zugänglich. Diese Idee – dass Kommunikationsfähigkeit unabhängig oder sogar negativ mit Intelligenz korreliert sein kann – wirkt im KI-Kontext geradezu prophetisch. Ein „Land der Genies“ braucht trotzdem Menschen, die erklären können, was die Genies meinen.

Dazu kommt ein psychologischer Effekt, den viele im Berufsalltag bereits spüren: KI-Blindheit. Immer mehr Menschen haben einen Reflex entwickelt, bei KI-generierten Inhalten sofort abzuschalten. Das ist vergleichbar mit dem Ausblenden von Werbebannern. Wenn du also eine technische Strategie als KI-Text verteilst, müssen sich deine Kollegen zwingen, das Dokument wirklich zu lesen. Wenn du sie selbst schreibst, hast du eine viel größere Chance, dass deine Argumente ankommen.

Nicht zum Fleisch-Proxy werden: Die Gefahr der puren Durchreichung

Die bisherigen Fähigkeiten nützen nur, wenn du sie tatsächlich einsetzt. Goedecke warnt eindringlich vor dem „Meat Proxy“ – also dem Menschen, der nur noch Anfragen in den KI-Agenten tippt und dessen Output als eigene Arbeit weitergibt. Das ist die sicherste Methode, entlassen zu werden, denn definitionsgemäß fügst du keinen Wert hinzu. Auch ausgefeilte Multi-Agenten-Systeme – sogenannte „Software-Factorys“ – sind keine Rettung. Sobald diese Muster in die Enterprise-AI-Werkzeuge einziehen, bist du ersetzbar.

Konsequenterweise bedeutet das nicht, dass man KI meiden sollte. Im Gegenteil: Wer KI gar nicht nutzt, ist zwar besser als ein Fleisch-Proxy, weil er zumindest ein paar Dinge besser macht als das Modell. Aber er verschenkt das Potenzial, sich gerade auf die Bereiche zu konzentrieren, die Modelle nicht abdecken. Die Strategie sollte sein: Verstehe, was KI gut kann, und positioniere dich genau in die Lücken, die sie offen lässt. Aktuell sind das vor allem die tiefe Kenntnis des Systems und die Fähigkeit, klar und überzeugend darüber zu schreiben.

Diese Lücken könnten sich verschieben. Goedecke räumt ein, dass Bereiche wie „grobe Änderungen an großen Codebases“ noch vor kurzem menschliches Können erforderten – heute übernehmen das Modelle bereits. Der Versuch, sich in ein „hartes Ingenieurgebiet“ zurückzuziehen, in dem es tiefe Expertise braucht, funktioniert vielleicht kurzfristig, aber nicht dauerhaft. Wenn ein Modell erst einmal die Riemannsche Vermutung knackt, wird es bald auch solide Treiber oder GPU-Shader schreiben. Die einzige stabile Strategie ist, genau die Aufgaben zu suchen, bei denen Modelle strukturell nicht besser werden können.

Was das für deine Karriere im Jahr 2026 bedeutet

Die gute Nachricht ist: Diese beiden Fähigkeiten – Codebase-Vertrautheit und technische Kommunikation – sind übungsfähig. Du kannst sie in deinem aktuellen Job gezielt aufbauen. Nimm dir Zeit, das System wirklich zu verstehen, nicht nur die Tickets abzuarbeiten. Lies alte Requests, frage nach den Hintergründen von Designentscheidungen. Und schreibe nicht nur Doku, sondern auch Mails, Design-Dokumente und Kommentare, die ein Mensch gerne liest. Das sind Investitionen, die sich auszahlen.

Die schlechte Nachricht ist: Der Druck wird nicht nachlassen. Die Modelle verbessern sich kontinuierlich. Was heute dein Vorsprung ist, könnte morgen schon Standard sein. Deshalb solltest du dich nicht auf einer bestimmten Technologie ausruhen, sondern die Fähigkeit selbst pflegen: die Vertrautheit mit einem komplexen System und die Fertigkeit, darüber zu kommunizieren. Das sind keine statischen Skills, sondern dynamische. Jedes neue Projekt, jede neue Codebase verlangt, dass du beide erneut unter Beweis stellst.

Am Ende geht es um eine geerdete Einordnung. KI wird nicht verschwinden, und der Beruf des Softwareentwicklers wird sich grundlegend verändern. Wer die Modelle nutzt, aber gleichzeitig die Lücken füllt, die sie offen lassen, wird nicht nur überleben, sondern auch in zehn Jahren noch gefragt sein. Die eigentliche Kunst ist nicht, schneller als die KI zu programmieren, sondern zu wissen, was sie nicht weiß – und das in Worte zu fassen, die Menschen überzeugen.

Quelle: seangoedecke.com

Deine Reaktion:
Artikel teilen:
Krötzsch-Check0 — 100
Fakten 35
Relevanz 62
Hype 58
Einschätzung 45
Redaktion 50 Stand 50 · noch keine Stimmen
Ist das Hype?
Sebastian Krötzsch
Autor

Sebastian Krötzsch

Sebastian Krötzsch schreibt auf sebask.de über Künstliche Intelligenz, Automatisierung, digitale Systeme und die Frage, was davon im Alltag wirklich nützlich ist. Ohne Buzzword-Nebel, dafür mit klarem Blick auf Praxis, Tools und echte Wirkung.