"Programmieren ist gelöst"? Der flackernde Bug sagt Nein

"Programmieren ist gelöst"? Der flackernde Bug sagt Nein

Hier ist die Sache, die niemand, der die "Programmieren ist gelöst"-Linie pusht, neben sein Slide-Deck stellen will: das meistdiskutierte AI-Coding-Tool der Welt wurde mit einem Bildschirm-Flacker-Bug ausgeliefert, und es brauchte ungefähr ein Jahr an Patches, einen Rollback und schließlich einen Workaround-der-immer-noch-hinter-einem-Feature-Flag-steckt, bevor irgendjemand es als erledigt bezeichnen konnte.

Kein Hardwareproblem. Kein Infrastrukturproblem. Keine üble Distributed-Systems-Race-Condition, die ein Forschungsteam brauchte. Ein Terminal-Neuzeichnungs-Bug. Die Art von Ding, die ein kompetenter Engineer an einem Nachmittag fixt — nur dass dieser hier zwei Modellgenerationen überlebte.

Ich möchte bei dieser Lücke einen Moment verweilen, denn sie ist das ganze Argument.

Die Geschichte, die ich ständig höre — auf X, in Podcasts, in diesen atemlosen "die Ära des Software-Engineers endet"-Threads — geht so: manuelles Prompting ist tot, Programmieren ist im Grunde ein gelöstes Problem, und der kluge Zug jetzt ist, aufzuhören Code zu schreiben und stattdessen Loops zu schreiben, die eine AI durch Prompt-Zyklen jagen, bis irgendeine Gewinnbedingung erreicht ist. Das Schwierige, das übrig bleibt, sagt die Geschichte, ist Infrastruktur, Nutzerfeedback und Hardware. Programmieren? Das ist der einfache Teil. Das ist erledigt.

Ich benutze jeden einzelnen Tag AI-Coding-Tools. Ich bin nicht hier, um dir zu sagen, dass sie nicht funktionieren — das tun sie absolut, und ich zeige dir genau wo. Aber "Programmieren ist gelöst" ist die Art von Behauptung, die in einer Keynote smart klingt und in dem Moment auseinanderfällt, wenn man auf die Belege zeigt. Und der sauberste Beleg, den ich habe, ist ein Bug, der so langweilig ist, dass er den Punkt fast von selbst macht.

Lass uns eintauchen.

Was "Programmieren ist gelöst" tatsächlich behauptet (und wer es sagt)

Bevor ich eine Position anfechte, will ich sie so stark formulieren, wie die Leute, die sie vertreten, es tun würden. Erst Steelmanning. Das ist die einzig ehrliche Art, das zu tun.

Die vollständigste Version des Arguments kommt aus dem Inneren von Anthropic selbst. Boris Cherny — der Schöpfer von Claude Code — sagte in Interviews Mitte 2026, dass AI Programmieren praktisch gelöst hat, und dass er seit acht Monaten keine einzige Zeile Code mehr von Hand geschrieben hatte (Fortune, Juni 2026). Das Framing, das darum herum wuchs, ist noch schärfer: hör auf, Claude eine Nachricht nach der anderen zu prompten, sagt das Argument — bau Loops. Konstruiere ein Harness, das das Modell über Stunden, manchmal Tage, beobachten, planen, handeln und reflektieren lässt, iterierend gegen Tests und Akzeptanzmetriken, bis es in einen bestehenden Zustand konvergiert (explainx.ai's Darstellung der Harness-Engineering-These).

In dieser Weltsicht verschiebt sich die Aufgabe des Menschen. Du schreibst keine Funktionen. Du schreibst die Bewertungsfunktion — die Gewinnbedingung — und der Loop schleift sich dorthin. Ein besseres Modell zu wählen optimiert die falsche Variable; bessere Feedback-Infrastruktur zu bauen ist das eigentliche Spiel. Ich habe selbst über die Mechanik dieses Ansatzes in meiner eigenen Analyse von langlaufenden Agent-Harnesses geschrieben, und ich sage offen: als Technik ist es real und kraftvoll.

Dann gibt es die Zahl, die jeder zitiert. Anthropic berichtete, dass zusammengeführte Codezeilen pro aktivem Contributor bis Q2 2026 ungefähr das 8-fache der Vor-2025-Baseline erreichten — in manchen Nacherzählungen gerahmt als "zwei Jahre Coding-Output, jedes Quartal, pro Person" (OfficeChai). Bis Mai 2026 soll Claude über 80% des zusammengeführten Produktionscodes intern geschrieben haben (VentureBeat).

Das ist eine wirklich verblüffende Reihe von Behauptungen. Wenn ich hier aufhören würde, würdest du den Tab schließen, überzeugt, dass Programmieren erledigt ist.

Warum bin ich also nicht überzeugt? Wegen eines Details, das in Anthropics eigener Ankündigung vergraben ist — und wegen eines Bugs. Nehmen wir zuerst das Detail.

Der Vorbehalt, den Anthropic in seine eigene Fußnote setzte

Hier ist etwas, das die Hype-Threads fast nie einschließen, und es ist der ehrlichste Satz im ganzen Gespräch.

Als Anthropic die 8x-Zahl veröffentlichte, warnte der eigene Blogpost des Unternehmens, dass die Zahl "fast sicher eine Übertreibung" sei, weil das Zählen von Codezeilen Volumen belohnt, nicht Qualität — und die Pro-PR-Zeilenzahlen mussten auf das 99. Perzentil gekappt werden, nur um Ausreißer-Commits zu filtern (wie in der Produktivitätsberichterstattung berichtet).

Lies das nochmal. Die Organisation, die das stärkste "Programmieren ist gelöst"-Argument macht, hat ein Warnlabel an ihre eigene Schlagzeilen-Metrik geheftet. Codezeilen sind ein berüchtigt kaputtes Proxy — jeder Engineer, der lang genug dabei ist, weiß, dass mehr Code oft schlechter ist, nicht besser. Ein Tool, das dich den achtfachen Diff generieren lässt, ist nicht selbstverständlich ein Tool, das Programmieren gelöst hat. Es ist vielleicht einfach ein Tool, das Tippen gelöst hat.

Und das ist die Naht, an der ich ziehen will. Denn es gibt einen Unterschied zwischen drei Behauptungen, die durcheinanderlaufen, wenn Leute sagen "Programmieren ist gelöst":

1. AI beschleunigt die Codeproduktion. Wahr. Offensichtlich, messbar wahr.
2. AI verbessert die Codequalität bei gutem Einsatz. Oft wahr, mit echten Vorbehalten.
3. Programmieren, als schwieriges menschliches Problem, ist erledigt. Das ist der Sprung. Und er überlebt den Kontakt mit den Beweisen nicht.

Die ersten beiden sind echte Fortschritte. Ich würde jeden bekämpfen, der einem Junior-Dev sagte, diese Tools zu ignorieren. Aber die dritte Behauptung — die erledigt-Behauptung — ist, wo das Marketing der Maschine davonläuft. Und der Beweis ist kein philosophischer Einwand über Kreativität oder Handwerk. Er ist viel peinlicher als das. Es ist ein Flackern.

Der Flacker-Bug, den niemand leise fixen konnte

Wenn Programmieren gelöst wäre — wenn man einfach einen Loop auf ein Problem richten und ihn zu einer Gewinnbedingung schleifen lassen könnte — dann sollte das bestausgestattete AI-Coding-Team der Welt, das sein eigenes Tool dogfoodet, 80% seines Codes mit genau dem fraglichen Modell schreibt, einen Terminal-Rendering-Bug ohne Stolpern zerquetschen können.

Das ist nicht das, was passierte.

Claude Code ist eine Terminal-App — agentische AI-Coding, die in deiner Kommandozeile lebt, veröffentlicht im Februar 2025. Von Anfang an hatte es ein berüchtigtes Bildschirm-Flacker-Problem. Der Terminalinhalt scrollte schnell, schüttelte sich und blitzte Text von früher in der Sitzung — verursacht dadurch, dass der Renderer den gesamten Terminal-Puffer bei jedem Streaming-Update neu zeichnete, anstatt zeilenspezifische, inkrementelle Updates zu machen. Du kannst die Spur selbst nachlesen über einen Friedhof von GitHub-Issues: #769, und einen langen Schwanz von Follow-ups wie #16939, #18084, und #18827, verteilt über Windows Terminal, VS Code, Cursor und die integrierten Terminals von Android Studio.

Jetzt achte auf die Timeline, denn die Timeline ist das Argument:

• Anfang 2025 und danach: Flackern wiederholt gemeldet. Besonders brutal in xterm.js-basierten Terminals (VS Code, Cursor), wo das vollständige Puffer-Neuzeichnen 2–3 Mal pro Sekunde den Bildschirm stroboskopieren ließ.
• Circa Dezember 2025: Anthropic adressiert es öffentlich, behauptet angeblich eine große Flackerreduzierung mit einem neu geschriebenen differenziellen Renderer — ungefähr ein Drittel der Sitzungen sah laut Community-Berichten des Rollouts noch mindestens ein Flackern.
• Kurz danach: Instabilität. Eine flackerfreie Rendering-Änderung wurde ausgeliefert, und eine Regression folgte — Issue #41965 dokumentiert, wie v2.1.89's "flackerfreies" Alt-Screen-Rendering standardmäßig den Terminal-Scrollback zerstörte. Der Fix schuf ein neues Problem. Dinge wurden zurückgerollt. Ende 2025: immer noch nicht sauber gelöst.
• Circa 1. April 2026: Ein "No Flicker Mode" kommt — CLAUDE_CODE_NO_FLICKER=1 — mit einem Alternate-Screen-Buffer-Ansatz, dem gleichen Trick, den Vim benutzt, wenn es dein Terminal übernimmt und es unberührt zurückgibt, wenn du beendest (piunikaweb). Es funktioniert. Aber es ist eine Umgehung, kein Root-Cause-Fix: es umgeht das Neuzeichnungsproblem, indem es woanders rendert. Und es wurde ausgeliefert als Research Preview, hinter einem Feature Flag, mit einem Begleit-Flag zum Deaktivieren der Mauserfassung, weil das seine eigene Friktion einführte.
• Ende Mai 2026: Ein neueres Terminal-Interface zeigte immer noch uninformative, "mysteriöse" Fehlermeldungen — die Fehlerbehandlung selbst unausgereift.

Ein unabhängiger Engineer betitelte seine Darstellung "Der Fix, an dem ein Jahr gearbeitet wurde." Jemand anderes brachte einen Drittanbieter-Patch namens Claude Chill heraus, nur um mit dem Flackern umzugehen, und er schaffte es auf die Hacker News-Titelseite. Wenn Nutzer externe Tools bauen, um dein Rendering zu fixen, ist das Rendering nicht gelöst.

Hier ist, warum dieser eine Bug so viel Gewicht trägt: es gibt keine Hardware-Ausrede. Keine Infrastruktur-Ausrede. Keine "der wirklich schwere Teil ist woanders"-Fluchtluke. Bildschirmflackern in einem Terminal ist ein reines, in sich geschlossenes Softwareproblem — genau die Kategorie, von der das "Programmieren ist gelöst"-Narrativ sagt, sie sei der einfache Teil, der erledigte Teil. Und es brauchte ein Jahr, einen Rollback und einen Flag-gesteuerten Workaround bei dem Unternehmen, das auf der Erde am besten positioniert ist, um es zu fixen.

Wenn Programmieren gelöst wäre, wäre dieser Bug an einem Wochenende gestorben. Das ist er nicht. Das ist kein Gotcha. Das sind Daten.

"Schreib einfach Loops" funktioniert — bis es den unglamourösen Bug trifft

Ich will fair zur Loop-These sein, denn ich mag sie wirklich. Ich betreibe Loop-basierte Automatisierung in meiner eigenen Arbeit — ich habe über das Planen von Claude Code in Cron-Loops und über den breiteren Wandel von einem manuellen SDLC zu einem agentischen Entwicklungslebenszyklus geschrieben. Wenn das Problem eine klare, maschinell überprüfbare Gewinnbedingung hat — Tests bestehen, Typen stimmen, der Benchmark wird grün — ist ein gut gebauter Loop ein wunderschönes Ding zum Zuschauen. Er konvergiert. Es ist das Nächste an "stelle die Bewertungsfunktion ein und geh weg", das ich in fünfzehn Jahren Softwareschreiben erlebt habe.

Aber beachte die Form der Probleme, bei denen Loops glänzen: sie alle haben eine klare Gewinnbedingung.

Ein flackerndes Terminal hat das nicht. Was ist der Test, der grün wird? "Es sieht weniger ruckelig aus für ein menschliches Auge über vierzig verschiedene Terminal-Emulatoren, jeder mit seinem eigenen Renderer, auf drei Betriebssystemen, bei variierenden Bildwiederholraten"? Dafür gibt es keine Assertion. Kein expect(screen).not.toFlicker(). Die Gewinnbedingung ist unscharf, umgebungsabhängig und teilweise subjektiv — was genau der Grund ist, warum ein Jahr Loops es nicht herausschleifen konnte. Der Loop ist nur so schlau wie die Bewertungsfunktion, die du schreiben kannst, und einige der wichtigsten Softwareprobleme sind genau die, die du nicht sauber bewerten kannst.

Das ist der Teil, den das "Programmieren ist gelöst"-Framing überspringt. Es nimmt stillschweigend an, dass jedes verbleibende Problem wie ein Unit-Test aussieht. Die meisten schwierigen tun das nicht. Sie sehen aus wie Flackern. Sie sehen aus wie "die Fehlermeldung ist technisch korrekt, sagt dem Nutzer aber nichts." Sie sehen aus wie die Projekt-Lade-Schwachstelle, die Forscher im Quellcode-Leak fanden, wo API-Anfragen abgefeuert wurden, bevor der Vertrauens-Prompt erschien — ein Design-Versehen, das kein Test fing, weil niemand daran dachte, dafür zu bewerten.

Wenn du lieber jemanden hättest, der diese agentischen Loops richtig baut und pflegt — mit den Leitplanken und der langweiligen-aber-kritischen Fehlerbehandlung, die die Demos überspringen — das ist ein großer Teil dessen, was ich übernehme. Du kannst sehen, was ich geliefert habe auf fiverr.com/s/EgxYmWD.

Also ist der Loop nicht falsch. Er ist eng. Es ist ein fantastisches Werkzeug für die gut spezifizierte Mitte des Problemraums und nutzlos an den unscharfen Rändern — und die unscharfen Ränder sind, wo Software tatsächlich in Produktion bricht. Das "gelöst" zu nennen heißt, den Teil, den man messen kann, für die ganze Arbeit zu halten.

Die menschlichen Kosten davon, so zu tun, als wäre der schwere Teil vorbei

Jetzt will ich über den Teil reden, der mich wirklich stört, denn der Bug ist nur der Beweis — hier geht es um den Einsatz.

Das "Programmieren ist gelöst, ship einfach in Prod, schreib den Loop, triff die Gewinnbedingung"-Narrativ landet nicht im Vakuum. Es landet auf Entwicklern, die gerade, in diesem Moment, ausgebrannter und ängstlicher um ihre Jobs sind, als ich sie seit langem gesehen habe. Und die Botschaft macht beides schlimmer.

Hier ist der grausame Mechanismus, und er ist gut dokumentiert. Wenn Organisationen entscheiden, dass AI Programmieren trivial gemacht hat, sparen sie die gewonnene Zeit nicht als Slack — sie behandeln jede gesparte Minute als eine Minute, die als mehr Output zurückgeschuldet wird. PR-Volumen springt 40–60% nach oben, und der Engpass verschiebt sich einfach downstream zum Review. Jetzt ertrinken die gleichen Menschen in Code, den sie nicht geschrieben haben, dem sie nicht voll vertrauen können, und unter Druck stehen, schnell zu genehmigen. Das ist nicht weniger Burnout. Es ist eine neue, schlimmere Art von Burnout, und sie trifft die Leute, die AI am stärksten umarmt haben. Es gibt sogar ein ganzes Genre von "AI sollte Developer-Burnout beheben" Post-Mortems inzwischen, was dir sagt, wie das Experiment läuft.

Setzt man die beiden Hälften zusammen, wird die Unehrlichkeit schärfer. Management hört "Programmieren ist gelöst" und setzt Erwartungen, als wäre es wahr. Entwickler leben in der Lücke zwischen dieser Behauptung und der flackernden, fehlermeldungsspuckenden, gelegentlich kaputten Realität — und werden für die Lücke verantwortlich gemacht. Dir wird gesagt, der schwere Teil sei vorbei, während du deinen Dienstag damit verbringst, zu debuggen, warum der Loop selbstbewusst etwas subtil Falsches ausgeliefert hat, mit einer Fehlermeldung, die nichts erklärte.

Es kursiert eine derbe Metapher für diese Art von Botschaft — dass jemand etwas mit deinem Bein macht und behauptet, es sei das Wetter. Ich halte es geschmackvoll, aber das Sentiment stimmt. Ausgebrannten Engineers zu sagen, dass ihre harte, reale, immer noch notwendige Arbeit "der einfache Teil" ist — während sie hinter genau den Tools aufräumen, die als Lösung bezeichnet werden — ist kein Optimismus. Es ist Gaslighting, verkleidet als Produktivitätsstatistik.

Und ich sage das als jemand, der offen, fast peinlich süchtig nach Claude Code ist. Ich bin nicht der Widerstand. Ich bin ein Heavy User, der dir sagt, dass das Marketing Schecks ausstellt, die das Tooling noch nicht einlösen kann.

Was wirklich gelöst ist, was wirklich nicht

Lass mich spezifisch sein, denn vager Pessimismus ist genauso nutzlos wie vager Hype. Hier ist mein ehrliches Hauptbuch nach täglicher Nutzung dieser Tools durch 2025 und in 2026.

Wirklich beschleunigt durch AI heute:

• Boilerplate, Scaffolding, Glue-Code, Konfiguration — fast sofort, fast fehlerfrei.
• Gut spezifizierte Refactors mit starker Testabdeckung — Loops zerquetschen diese.
• Absicht in einen ersten Entwurf übersetzen — was 45 Minuten dauerte, dauert 6.
• Eine unbekannte Codebase oder API erkunden — schneller als Doku.

Wirklich verbessert, mit Vorbehalten:

• Codequalität, wenn du das Harness (Tests, Lint, Typen, Akzeptanzmetriken) gebaut hast, gegen das der Loop bewerten kann. Kein Harness, kein Qualitätsgewinn — nur schnelleres Chaos.

Wirklich NICHT gelöst:

• Unscharfe, nicht bewertbare Probleme — Rendering über heterogene Umgebungen, UX-Feinschliff, "das ist technisch richtig, fühlt sich aber falsch an."
• Fehlerbehandlung und Failure-Mode-Design — die unglamourösen 80%, die Demos nie zeigen und wo Claude Code selbst noch stolpert.
• Wissen, was man bauen soll, und ob es überhaupt existieren sollte.
• Das Urteilsvermögen, den Loop zu überstimmen, wenn seine Gewinnbedingung subtil das falsche Ziel ist.

Beachte, dass die "nicht gelöst"-Spalte genau dort ist, wo der Flacker-Bug lebt. Das ist kein Zufall. Der Bug ist kein Ausreißer — er ist eine repräsentative Stichprobe der Arbeit, die der Hype als erledigt erklärt hat.

Also ist Programmieren gelöst? Nein — und die ehrliche Antwort ist nützlicher als der Hype. Programmieren ist beschleunigt, manchmal dramatisch. Die gut spezifizierten Teile sind zunehmend automatisierbar durch Loops. Aber der harte, unscharfe, urteilsschwere Kern — der Teil, der Software Engineering zu einem Beruf macht und nicht zu einem Tippgeschwindigkeitswettbewerb — ist genau so ungelöst wie zuvor, und die eigenen Bug-Tracker der Tools beweisen es.

Häufig gestellte Fragen

Ist Programmieren tatsächlich von AI gelöst in 2026?

Nein — Programmieren ist dramatisch beschleunigt, nicht gelöst. AI-Tools glänzen bei gut spezifizierten, maschinell überprüfbaren Aufgaben (Boilerplate, Refactors, bestandene Tests), kämpfen aber immer noch mit unscharfen, nicht bewertbaren Problemen wie Cross-Environment-Rendering, UX-Feinschliff und Failure-Mode-Design. Der Beweis ist, dass selbst AI-Coding-Tools mit langlebigen Bugs ausgeliefert werden, die ihre eigenen Loops nicht fixen können.

Was bedeutet "schreib einfach Loops" beim AI-Coding?

"Schreib einfach Loops" bezieht sich auf Harness-Engineering — anstatt eine AI eine Nachricht nach der anderen zu prompten, baut man ein System, das das Modell durch wiederholte Beobachten-Planen-Handeln-Reflektieren-Zyklen laufen lässt, bis es eine definierte Gewinnbedingung wie bestandene Tests erreicht. Es ist eine wirklich kraftvolle Technik, aber sie funktioniert nur, wo man eine klare Bewertungsfunktion schreiben kann, was viele reale Probleme ausschließt.

Warum ist der Claude Code Flacker-Bug bedeutsam?

Der Flacker-Bug ist ein reines Softwareproblem ohne Hardware- oder Infrastruktur-Ausrede, trotzdem brauchte es ungefähr ein Jahr, einen Rollback und einen Flag-gesteuerten Workaround, um ihn anzugehen — bei dem Unternehmen, das am besten positioniert ist, um ihn zu fixen. Das macht ihn zum saubersten Gegenbeispiel zur Behauptung, dass "Programmieren der einfache Teil" moderner Software ist. Für die vollständige Timeline siehe den Abschnitt oben.

Verursacht AI-Coding Developer-Burnout?

Berichte und Post-Mortems durch 2026 legen nahe: ja — nicht weil AI weniger Arbeit macht, sondern weil Organisationen gesparte Zeit in mehr Output umwandeln, PR-Volumen um 40–60% steigern und die Last auf überwältigtes Code-Review verschieben. Das "Programmieren ist gelöst"-Narrativ verschärft dies, indem es Erwartungen setzt, die nicht zur chaotischeren Realität passen, mit der Entwickler tatsächlich konfrontiert sind.

Der Beleg, auf den ich immer zurückkomme

Ich habe mit einem flackernden Terminal eröffnet, also lass mich dort schließen.

Wenn dir jemand sagt, Programmieren sei gelöst, stell eine Frage: wenn das stimmt, warum haben die Leute, die es am lautesten sagen, ein Jahr damit verbracht, einen Bildschirm zu fixen, der nicht aufhören wollte zu zittern — und dann den Fix hinter einem Feature Flag ausgeliefert? Es gibt keine Hardware, der man die Schuld geben kann. Keine Infrastruktur, hinter der man sich verstecken kann. Nur ein hartes, unglamouröses Softwareproblem, das tut, was harte Softwareprobleme schon immer getan haben: sich gegen die Leute zu wehren, die es unterschätzt haben.

Nutze die Tools. Bau die Loops. Ship schneller — ich tu es, jeden Tag, und es tut mir gut. Aber halte die Linie bei der Wahrheit: Programmieren ist nicht gelöst, es ist verstärkt. Der schwere Teil ist nicht verschwunden. Er ist dorthin gezogen, wo die Loops nicht hinreichen, und er gehört immer noch dir.

Und ehrlich gesagt? Das sind gute Nachrichten. Denn es bedeutet, dass das Urteilsvermögen, das du über Jahre aufgebaut hast, der Teil ist, der nicht automatisiert wurde — es ist der Teil, der wertvoller wurde. Lass dich nicht von einer Produktivitäts-Folie vom Gegenteil überzeugen.

Heute Abend ist das Einzige, was sich lohnt: das nächste Mal, wenn du auf einen Bug triffst, den deine AI selbstbewusst nicht fixen konnte, fühl dich nicht hinterher. Mach einen Screenshot davon. Dieser Bug ist der Teil des Jobs, der immer noch dir gehört — und es ist der Teil, der bezahlt.

Lass uns zusammenarbeiten

Du möchtest AI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (Maßanfertigungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io