Code bewegte sich schon immer auf Englisch zu. Jetzt ist er angekommen.

9 min read

Jeder Senior-Entwickler, dem ich in letzter Zeit begegne (10, 15 Jahre voller Firmen, Migrationen, Stacks die im schlimmsten Moment aufgegeben wurden, Leute die die Ära überlebt haben, in der alles Microservices sein musste, selbst für eine CRUD-App mit 12 Nutzern täglich) trägt dasselbe mit sich herum. "Ich weiß nicht, ob ich noch programmieren lernen oder einfach besser im Prompten werden sollte." "Ich unterrichte an der Uni, aber sollten wir Studenten, die in 4 Jahren ihren Abschluss machen, noch PHP beibringen..." "Mein Job sieht nicht mehr aus wie vor einem Jahr, ich verstehe nicht warum."

Tokenmaxxer oder Pro-Vibe-Coder. Was denn nun?

TLDR: Die erfahrensten Entwickler, die ich kenne, können nicht benennen, was sie an der Richtung der Softwareentwicklung so unruhig macht. Dieses Unbehagen hat einen Namen und taucht alle 20 bis 30 Jahre seit 1957 auf. Die Frage, die du dir stellst, ist vielleicht nicht die richtige.

Zwei Entwickler an Schreibtischen mit gegensätzlichen Ansätzen: einer programmiert hektisch mit Programmierbüchern, der andere spricht entspannt in ein Headset mit sauberem Code auf dem Bildschirm.
Alte Garde vs. neue Garde: einer schwitzt über Syntax, der andere fragt einfach höflich nach.

Was mich jedes Mal umhaut, ist nicht die Sorge. Es ist die Präzision der Unschärfe. Diese Leute debuggen Race Conditions in der Produktion, sie sehen Hype-Zyklen schon von weitem kommen. Und trotzdem: dieselbe Leere am Ende des Satzes. Ich kannte diese Leere. Wir waren schon mal hier. Nur nicht mit LLMs.

Jedes Gespräch. Dieselbe Stille.

Der Lehraspekt kommt in all diesen Gesprächen immer wieder vor, und er beschäftigt mich am meisten. "Soll ich Studenten, die in 4 Jahren ihren Abschluss machen, noch Python beibringen?" Das hat eine harte Deadline. Die Person, die fragt, muss bis September eine Curriculum-Entscheidung treffen. Kein Raum für "mal schauen, wie es sich entwickelt."

Quer durch Foren, Discord-Server, Slack-Threads: jemand baut SaaS in Next.js, jemand führt einen 3-Personen-Entwicklershop und überlegt, ob er sich bei Agents weiterbilden oder tiefer in die Grundlagen einsteigen soll, jemand der beruflich Integrationen ausliefert und sich fragt, ob es diesen Job in 18 Monaten noch gibt. Verschiedene Länder, verschiedene Stacks, verschiedene Kontexte.

Nicht "Ich verstehe nicht, was passiert." Eher: "Ich spüre, dass sich etwas ändert, aber ich kann es nicht benennen. Und ich habe genug Übergänge mitgemacht, um zu wissen, dass das wichtig ist."

Der letzte Teil ist verräterisch. Nicht zu wissen, was passiert, ist unangenehm. Etwas nicht benennen zu können, was man deutlich spürt, ist eine völlig andere Art von Unbehagen. Das bedeutet meist, dass das Vokabular noch nicht aufgeholt hat.

Ich habe letzten Dienstag 40 Minuten damit verbracht, einen Ordner zu benennen. Kein Repo. Einen Ordner. Das Benennungsproblem in der Software ist ewig und LLMs machen es nicht besser. Sie generieren mehr plausibel klingende schlechte Namen, schneller. Das war's, weitermachen.

70 Jahre, eine Richtung

Es gibt etwas, das niemand in der Informatik lehrt, weil es die "Sprachen sind schwer"-Mystik ruiniert: seit 1957 bewegte sich jede einzelne Generation von Programmiersprachen in dieselbe Richtung, hin zum Englischen, ohne Ausnahme.

Maschinencode war binär. Assembly gab dir Mnemonics, die du fast lesen konntest, wenn du die Augen zusammenkniffen hast. Dann kamen FORTRAN und COBOL, 1957 und 1959, mit etwas, das es nie zuvor gegeben hatte: eine Codezeile, die du laut vorlesen konntest ohne Erklärung. "MULTIPLY HOURS-WORKED BY HOURLY-RATE GIVING GROSS-PAY." Das ist COBOL. Ein Geschäftsführer von 1960 konnte das ohne Vorwissen verstehen.

[INFOGRAPHIC: TITLE "70 Jahre Bewegung zum Englischen" + subtitle "eine Richtung, keine Ausnahmen". Metaphor: eine lange horizontale Straße mit 5 Meilenstein-Straßenschildern, Links-nach-rechts-Progression von binär zu Sprechblase. Style: Franco-Belgian ligne claire comic, dicke schwarze Umrisse, flache Farben, sauberer Horizont. Palette: cobalt blue #1A4FD8, signal red #E8291C, warm cream #FFF9F0, black #111111, light gray #DDDDDD. Content: 5 Schilder beschriftet MACHINE CODE (1950), ASSEMBLY (1952), COBOL/FORTRAN (1957-1959), PYTHON (1991), LLMs (2026). Jedes Schild zeigt eine kleine Entwicklerfigur, die progressiv entspannter wird, letzte Figur steht mit offenem Mund und ohne sichtbare Tastatur. Highlight: LLMs-Schild in signal red mit Strahlenkranz, Figur gestikuliert ohne Tastatur. Footer: copyright rentierdigital.xyz. NOT flat corporate infographic, NOT minimalist tech aesthetic, NOT boring timeline with dots.]

Python, als es 1991 ankam, wurde explizit darauf ausgelegt, wie Pseudocode zu lesen. Lesbarkeit war kein Zufall, es war ein Designziel, das in der eigenen Dokumentation der Sprache stand. Und jeder Übergang hatte dieselbe Reaktion von der Generation, die verdrängt wurde. "Zu viel Abstraktion." "Du verlierst die Kontrolle." "Das ist kein echtes Programmieren." FORTRAN galt 1957 als gefährlich high-level. Den Leuten, die es schrieben, wurde gesagt, Compiler könnten niemals handoptimierten Assembly erreichen. Dieselbe Reaktion, anderer Speicherstand. Sie lagen falsch. Die Leute, die Python 1991 zu langsam und nicht echten Code nannten, lagen auch falsch.

Das ist keine Revolution. Es ist die Fortsetzung einer 70 Jahre alten Bewegung.

Die Frage ist bereits obsolet

Alle fragen, ob sie noch programmieren lernen sollen. Die Frage ist bereits obsolet. Das klingt dramatischer, als es ist.

Was bei jeder vorherigen Abstraktionsschicht passierte: die Schicht darunter verschwand nicht. Assembly existiert noch. COBOL führt noch mehr Banktransaktionen aus als jede andere Sprache auf der Erde (ich glaube, es gibt heute mehr COBOL-Zeilen in aktiver Produktion als Python-Zeilen, obwohl das niemand in einem Konferenzvortrag sagen will). Die Frage war nie "verschwindet die alte Schicht?" Sie war immer "was ändert die neue Schicht daran, wann du zu welchem Werkzeug greifst?"

Zum ersten Mal in der Geschichte des Computing ist die neue Abstraktionsschicht keine Sprache, die etwas lesbarer ist als die vorherige. Es ist ein System, das bereits menschliche Sprache versteht und sie direkt ausführen kann. Der syntaktische Vermittler ist zum ersten Mal optional. Nicht weg. Optional.

Das ändert, was die echte Frage ist. Der virale X-Post, der "80% des Codes von AI in 2025 geschrieben, dann 100%, dann 12%, dann 300% der Bugs in 2028" verspottete, erreichte über 1 Million Views, weil die Fragestellung absurd ist und die Leute das sofort erkannten. Es ist keine Prozentfrage. Es ist eine Schichtenfrage.

Aber es gibt eine zweite Frage in der Schichtenfrage, und die ist die unbequeme: was passiert, wenn deine Spezifikationen direkt ausführbar werden? Wenn die Spec kein Dokument ist, das du einem Entwickler gibst, der Code schreibt, sondern etwas, das das LLM direkt ausführt, ohne Vermittler, ohne Übersetzung? In einem AI-first-Workflow heute gibt es noch einen Menschen, der die Spec liest und Code schreibt, der Intent in etwas Ausführbares übersetzt. Das LLM assistiert, beschleunigt, generiert manchmal den meisten Code. Aber der Übersetzungsschritt ist noch da. Die Frage, die die Leute unruhig macht, ist nicht "verschwindet dieser Schritt?" Es ist "für welche Problemkategorien verschwindet er zuerst, und wie schnell bewegt sich diese Linie?" Die 70-Jahre-Bewegung hat gerade ihr logisches Ziel für diese Kategorien erreicht. Nicht für alle Probleme. Noch nicht mal für die meisten. Aber die Richtung hat sich in 7 Jahrzehnten nicht geändert.

Tokenmaxxing und Vibe Coding sind Symptome, keine Strategien

Hier soll ich dir sagen, dass eines davon richtig und das andere falsch ist. Beide sind Symptome derselben Sache.

Tokenmaxxing ist das, was du machst, wenn du glaubst, mehr Kontext hilft immer. Vibe Coding ist das, was du machst, wenn du glaubst, das LLM regelt alles, wenn du aus dem Weg gehst. Keines ist eine Strategie. Beide sind das Verhalten von jemandem, der die Schichtverschiebung spüren kann, aber noch kein mentales Modell dafür entwickelt hat.

Eine Geschichte, die in der Community die Runde macht: ein Builder lieferte 540k Zeilen aus. Darunter 276k Zeilen Tests. 33 Cron Jobs. Die Nachbesprechung war brutal. Die Tests kontrollierten einen Agent, der keine Kontrolle brauchte. Die Cron Jobs überwachten ein System, das sich bereits selbst verwaltete. All dieser Code war ein Käfig. Der Instinkt war richtig (kontrolliere, was wichtig ist), das Modell war falsch (Code ist noch immer, wie du Kontrolle im neuen Paradigma bekommst). YOU DIED. Nächstes Mal vielleicht erst das Gefängnis bauen, nachdem du bestätigt hast, dass der Gefangene eins braucht.

Derselbe Impuls, entgegengesetzte Richtung: jemand baut 2 parallele Pipelines für dieselbe Aufgabe. Eine ist beeindruckend, mit Feedback-Schleifen und kaskadierenden Agents. Die andere sind 4 Dateien. Sie legen beide vor ein LLM und fragen, welche erweitert werden soll. Bei der Wahl zwischen architektonisch beeindruckend und etwas, das einfach in 4 Dateien funktionierte, wählte das Modell jedes Mal die 4-Dateien-Version.

Beide Muster sind genau das, was frühe COBOL-Programmierer machten, als sie Zugang zu einer High-Level-Sprache bekamen: sie strukturierten ihren Code wie den Assembly, den sie vorher kannten, weil sie noch kein neues mentales Modell hatten. Das alte Modell auf eine neue Schicht angewandt produziert Verschwendung in beide Richtungen, ob das nun 540k Zeilen Käfigbau sind oder 1000x Token-Burn für eine Aufgabe, die 4 Dateien brauchte.

Der praktische Ausgangspunkt, um nicht in eine dieser Fallen zu tappen, ist die Blueprint-Methode in Vibe Coding, For Real, strukturiert genug, dass du nicht blind vibe-codest, leicht genug, dass du nicht den Käfig baust. Und auf Infrastrukturebene wendet why CLIs beat MCP layers for AI agents dieselbe Lektion auf Tooling an: weniger Abstraktion, mehr Vorhersagbarkeit.

3 Einwände. 3 historische Parallelen.

Die 3 ernsthaften Einwände gegen diese Schichtverschiebung verdienen echte Antworten.

Die Kosten. Agentic AI verbraucht bis zu 1000x mehr Token als ein Standard-LLM-Aufruf. Microsoft, Meta und Amazon zogen sich alle dieses Jahr von internem Tokenmaxxing zurück. 1 Infrastruktur-Builder nannte öffentlich $1,3M in Token in einem einzigen Monat. Das ist echtes Geld. Die Parallele: frühe Compiler-Läufe waren teuer. IBM rechnete 1957 nach CPU-Zyklen ab. Die Frage war immer, ob der Produktivitätsgewinn die Kosten rechtfertigte, und das tat er. Token-Kosten fallen etwa alle 18 Monate um das 10-fache. Mintlify senkte den Token-Verbrauch um das 30-fache, indem sie Markdown statt HTML an ihre Agents lieferten. Cloudflare senkte um 80%. Der Kosteneinwand ist ein Tooling-Problem mit Lösungen, die bereits in Produktion sind.

Die Zuverlässigkeit. Die ETH Zürich-Studie (438 Coding-Aufgaben, April 2026) fand etwas Kontraintuitives: AGENTS.md-Dateien, die von LLMs generiert wurden, reduzierten den Aufgabenerfolg um 3% und erhöhten die Kosten um 20%. Von Menschen geschriebene AGENTS.md: plus 4% beim Erfolg. Die Interpretation ist hier wichtig: das ist ein Beleg dafür, dass die Praktiken für diese Schicht 2 Jahre alt sind, nicht 20, nicht dass LLMs grundsätzlich nicht vertrauenswürdig sind. FORTRAN war 1957 unzuverlässig. Es dauerte Jahre akkumulierter Produktionsfehler, bevor Teams ihm in kritischen Pfaden vertrauten. Wir sind beim 1959-Äquivalent mit agentic AI. Die Praktiken bilden sich jetzt heraus, genau wie sie es immer getan haben.

Die Sicherheit. Real, und noch nicht gelöst. Buffer Overflows wurden in den 1970ern entdeckt und werden heute noch in Legacy-Code gefunden. SQL Injection wurde 1998 formal beschrieben und steht noch in den OWASP Top 10. Sicherheitsprobleme, die durch neue Abstraktionsschichten eingeführt werden, sind Engineering-Probleme, die mit der Zeit gelöst werden, mit Zwischenfällen unterwegs. Die LLM-Schicht hat bereits ihre eigene Version. Das ist kein Argument gegen die Schicht.

Was du wirklich entscheidest

Die 7 Entwickler konnten ihr Unbehagen nicht benennen. Hier ist, was es ist: die Grenze ihres Jobs hat sich verschoben. Der Job ist nicht verschwunden. Die Grenze hat sich verschoben.

Code verschwindet nicht. Er wird zur Sprache der deterministischen Schichten, der Teile, wo Falschliegen etwas Echtes kostet. Eine Zahlungsvalidierung, ein Webhook, der basierend auf einem festen Enum zum richtigen Handler geleitet wird, eine Auth-Grenze, eine Operation, die genau einmal erfolgreich sein muss oder gar nicht — diese Probleme leben in Code, weil Code auditierbar, testbar, deterministisch ist. Du tokenmaxxst dich nicht durch eine Finanztransaktion.

Natürliche Sprache übernimmt die intentionalen Schichten: eine Produktbeschreibung aus Nutzereingabe generieren, entscheiden, welcher Content für ein Nutzersegment angezeigt wird, eine Antwort auf ein Support-Ticket entwerfen, das in einen Edge Case gelandet ist, den deine Spec nicht abgedeckt hat. Diese Probleme leben in Prompts und Specs, weil sie um ausgedrückte Absicht gehen, wo Iteration am Verhalten wichtiger ist als exakte Ausführung. Dass die Spec direkt ausführbar wird, ist dort der Punkt, kein Risiko.

Die konkrete Frage für einen Builder heute ist nicht "schreibe ich noch Code?" Es ist "wo lebt dieses spezifische Problem?" Zahlungsvalidierung lebt in Code, und genauso das Routing eines Webhooks zu einem festen Enum oder die Durchsetzung einer Auth-Grenze. Produktbeschreibungen aus Nutzereingabe generieren lebt in einer Spec, und genauso das Tuning einer E-Mail-Betreffzeile an die Geschichte eines Nutzers. Die Linie bewegt sich, während LLMs in deterministischen Kontexten zuverlässiger werden. Aber das mentale Modell, um sie zu ziehen, ist jetzt verfügbar.

Der Professor, der sein Curriculum bis September entscheiden muss, hat eine klarere Antwort, als er denkt. Lehre, warum Code überhaupt existiert. Was ein Typ ist, was eine Exception ist, was es bedeutet, dass eine Operation idempotent ist. Nicht PHP speziell, weil spezifische Sprachen jedes Jahr weniger wichtig werden. Studenten, die verstehen, warum Determinismus wertvoll ist, werden wissen, wonach sie greifen und wann, egal wie der Stack in 4 Jahren aussieht.

How to stop gambling on prompts and start shipping ist ein praktisches Framework, falls du auf der intentionalen Seite festhängst.

Die Leere am Ende des Satzes, die diese 7 Entwickler nicht füllen konnten, war keine Unwissenheit. Es war Klarheit, die ankam, bevor das Vokabular da war.

Die Verschiebung ist bereits passiert. Jetzt muss das Vokabular aufholen.

Quellen

Dieser Post kann Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision — kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern.