Nach 17 Jahren des Schreibens von Open-Source-Code, warum halte ich es für sinnlos, dass Coding Agents Funktionen stapeln?

In der heutigen Zeit, in der die KI - Programmierwerkzeuge in eine Phase des Chaos eintreten, scheinen wir uns bereits an die Anhäufung verschiedener Funktionen gewöhnt zu haben. Doch aus der Sicht von Mario Zechner, dem Gründer von libGDX und 17 - jährigem Open - Source - Veteran, wird alles immer unkontrollierbarer.

"Wenn Sie feststellen, dass die KI hinter Ihren Rücken Ihre Kontextinformationen heimlich ändert, ohne dass Sie davon wissen, ist das Verlust der Kontrollfähigkeit äußerst gefährlich."

In letzter Zeit hat Mario auf der von Tessel veranstalteten Entwicklerkonferenz nicht nur Claude Code und OpenCode öffentlich kritisiert, sondern auch sein minimalistisches "Revolutionswerk" - pi - vorgestellt. Dies ist ein Terminal - Programmier - Agent, der nur über vier Werkzeuge (lesen, schreiben, bearbeiten, bash) verfügt, den kürzesten System - Prompt unter den gängigen Agenten hat, aber eine extreme Erweiterbarkeit aufweist und es den Entwicklern ermöglicht, die Kontrolle wieder zu erlangen.

Dieser Artikel basiert auf dem Vortragsvideo und wurde von InfoQ bearbeitet.

Die Kernaussagen sind wie folgt:

• Claude Code ist derzeit wie ein Raumschiff. Es hat so viele Funktionen, dass Sie möglicherweise nur 5 % davon genutzt und 10 % davon kennengelernt haben. Die restlichen 90 % sind die "Dunkle Materie" im Bereich der KI und Agenten. Niemand weiß, was es hinter den Kulissen tatsächlich macht.
• In den bestehenden Programmierframeworks sind viele Funktionen möglicherweise nicht unbedingt erforderlich, um gute Ergebnisse zu erzielen. Es werden keine Dateiwerkzeuge, keine Sub - Agenten und keine Internetrecherche benötigt, gar nichts.
• Wir befinden uns derzeit in einer Phase, in der wir "herumexperimentieren und dann die Ergebnisse beobachten". Niemand weiß, wie ein perfekter Programmier - Agent aussehen sollte. Wir brauchen bessere "Experimentier" - Methoden. Programmier - Agenten müssen selbstmodifizierbar und äußerst plastisch sein, damit wir neue Ideen schnell testen können und herausfinden können, ob wir einen neuen Branchenstandard oder Workflow entwickeln können.
• Der einzige Zeitpunkt, an dem wirklich die Codeüberprüfung und Typüberprüfung erforderlich sind, ist der, wenn der Agent glaubt, dass er seine Arbeit vollständig erledigt hat.

1 ChatGPT→Copilot→Aider→Claude Code

Im April 2025 kam Peter Steinberger (Gründer von OpenClaw) zu mir und Armin Ronacher (Mitgründer von Sentry und Erfinder des Flask - Web - Frameworks) und sagte: "Die aktuellen Coding - Agenten haben endlich die Stufe erreicht, an der sie wirklich arbeiten können." Meine erste Reaktion war: "Oh, halt doch endlich die Klappe!" Ich konnte es einfach nicht glauben. Aber einen Monat später verbrachten wir 24 Stunden in einer Wohnung und waren die ganze Nacht lang in der Welt der clankers, wipe coat und wipe slop vertieft.

Wir haben ständig Dinge gebaut, eine Menge von ihnen, aber die meisten davon haben wir selbst nie benutzt. Dies war die neue Normalität von 2025 bis 2026: Wir haben viel Code geschrieben und viele Werkzeuge entwickelt, aber nur wenige davon haben wir tatsächlich eingesetzt. Am Ende dachte ich: Ich hasse alle bestehenden Coding - Agenten und Entwicklungsframeworks. Wie schwierig kann es denn sein, einen eigenen zu schreiben? Damals sagte Peter: "Ich möchte einfach nur ein kleines eigenes Ding machen." Die folgenden Ereignisse kennen Sie vielleicht bereits.

Heute möchte ich Ihnen meine nicht so spektakuläre Geschichte erzählen, aber ich hoffe, dass ich in ihr einige Branchenkenntnisse teilen kann, die ich in den letzten Monaten gesammelt habe.

Lassen Sie uns zunächst die Evolutionsgeschichte der Coding - Agenten besprechen.

Vor 2025 war die Situation im Wesentlichen wie folgt: Man kopierte Code von ChatGPT, aber der Code war meistens fragmentiert und konnte normalerweise nur einfache Funktionen schreiben, die man nicht selbst schreiben wollte. Dann kam GitHub Copilot, das in Visual Studio Code integriert war. Man musste nur immer wieder auf die Tastatur tippen, obwohl es manchmal funktionierte, aber meistens nicht. Manchmal gab es sogar "nett" einen Code nach, der unter der GPL - Lizenz steht, wie z. B. der schnelle Algorithmus zur Berechnung des Kehrwerts der Quadratwurzel von John Carmack. Später kam Aider, und damals gab es auch AutoGPT.

Schließlich trat Claude Code auf die Bühne. Ich erinnere mich, dass sie im November 2024 die Beta - Version veröffentlicht haben, aber es wurde erst im Februar oder März 2025 wirklich populär. Damals fand ich, dass es einfach fantastisch war. Das Claude - Team war ausgezeichnet. Sie waren sehr aktiv in den sozialen Medien und alle waren Genies.

Ehrlich gesagt haben sie im Wesentlichen die gesamte Kategorie geschaffen. Obwohl es zuvor Aider und AutoGPT gab, hat kein anderes Tool diese Höhe erreicht. Dies ist das sogenannte agentic search (Intelligentensuche) - Paradigma: Es geht nicht wie bei Cursor, das zuerst in Ihre Codebasis geht, Indizes erstellt und komplexe Builds durchführt (obwohl das auch nicht unbedingt funktioniert). Das Claude - Team hat das Modell durch verstärkte Training dazu gebracht, Dateiwerkzeuge und bash - Werkzeuge zu nutzen und so Ihre Codebasis in Echtzeit zu erkunden, die Informationen zu finden, die zur Codeverstehung erforderlich sind, und direkt zu ändern. Das Ergebnis war erstaunlich. Wir haben überhaupt nicht geschlafen, denn die Menge des erzeugten Codes war um ein Vielfaches höher als bei der reinen manuellen Schreibweise.

Damals war es einfach und vorhersehbar und passte perfekt zu meinem Workflow. Aber später sind sie in eine Falle geraten, in die viele von uns fallen: Wenn diese clankers so viel Code schreiben können, warum lassen wir sie nicht alle denkbaren Funktionen implementieren? Klingt gut, oder? Wir fügen diese Funktion hinzu, jene Funktion, immer wieder... Am Ende haben wir ein Monster ähnlich dem, das Homer Simpson entworfen hätte, geschaffen. Claude Code ist jetzt wie ein Raumschiff. Es hat so viele Funktionen, dass Sie möglicherweise nur 5 % davon genutzt und 10 % davon kennengelernt haben. Die restlichen 90 % sind die "Dunkle Materie" im Bereich der KI und Agenten. Niemand weiß, was es hinter den Kulissen tatsächlich macht.

2 Claude Code ist kein stabiles und gutes Werkzeug

Persönlich finde ich, dass es nicht nützlich ist, denn ich bin der Meinung, dass Entwickler wissen müssen, was der Agent tatsächlich tut. Wir befinden uns jetzt auf der Veranstaltung von Tessel, und sie mögen es auch, Context - Management/Engineering zu betreiben. Aber ich habe schließlich festgestellt, dass Claude Code in Bezug auf Beobachtbarkeit und Kontextmanagement kein gutes Werkzeug ist. Und wer kann die endlose und unverständliche Blinkung von Claude Code ertragen?

Thariq Shihipar, der Experte für Entwicklerbeziehungen bei Anthropic, sagt manchmal auf Twitter unverständliche Dinge, wie: "Unsere Terminal - Benutzeroberfläche ist jetzt eine Spieleengine."

Ich bin aus der Spieleentwicklung hervorgegangen, das ist mein Fachgebiet. Wenn ich solche Worte höre, tut es mir wirklich weh. Es ist nur eine Terminal - Oberfläche. Sie denken, es ist eine Spieleengine, weil Sie React in der Terminal - Oberfläche verwenden, was dazu führt, dass das Neu rendern des gesamten UI - Baums 12 Millisekunden dauert. Bitte tun Sie das nicht. Es ist wirklich keine Spieleengine.

Später hat es auch Mitchell, der Ghostty geschrieben hat, nicht mehr ausgehalten. Er sagte: "Das klingt etwas beleidigend. Legen Sie die Schuld nicht auf Ghostty oder andere Terminals. Es liegt einfach daran, dass Ihr Code schlecht ist." Ein Terminal braucht weniger als 1 Millisekunde, um einen Frame zu rendern und kann Hunderte von Frames pro Sekunde darstellen. Also nehmen Sie das nicht als Ausrede.

Obwohl sie später die Blinkung behoben haben, sind andere Probleme aufgetreten. Sie werden das Gefühl haben, dass sie vollständig auf das sogenannte vibe coding umgestiegen sind. Dies fällt besonders auf, wenn Sie Claude Code täglich verwenden. Ich will nicht ihre Bemühungen und Ergebnisse herabwürdigen. Claude Code ist immer noch der Marktführer in dieser Kategorie. Sie haben alles begonnen und es sehr gut gemacht. Ich bin nur ein alter Mann, der einfache und vorhersehbare Werkzeuge mag, und es passt nicht mehr zu meinem Workflow und meinen Anforderungen.

Außerdem haben sie hinter den Kulissen viele Änderungen an Ihrem Kontext vorgenommen. Im Sommer 2025 habe ich eine Reihe von Werkzeugen geschrieben, um die Anfragen von Claude Code an das Backend abzufangen und zu sehen, welche zusätzlichen Texte sie in meinen Kontext einschleusen. Ich habe festgestellt, dass diese Operationen sehr überflüssig sind und sich täglich ändern. Möglicherweise wird heute eine Version veröffentlicht, morgen eine andere, und die Zeit und die Art der Injektion ändern sich ständig. Dies kann Ihren bestehenden Workflow direkt durcheinander bringen. Es ist kein stabiles Werkzeug.

Ich verstehe ihre Position. Sie müssen experimentieren, und die Nutzerbasis ist riesig. Es ist wirklich schwierig, auf der Grundlage einer großen Nutzergruppe zu experimentieren. Aber sie achten nicht auf das Gefühl der Nutzer, und deshalb müssen wir alle leiden: Sie verwenden gerade dieses neue Werkzeug und versuchen, einen vorhersehbaren Workflow aufzubauen. Dann ändert der Werkzeughersteller eine unbedeutende Kleinigkeit unter der Motorhaube, und die LLM geht beim Bearbeiten Ihrer aktuellen Aufgabe einfach aus dem Ruder. Das ist nicht nachhaltig. Ich brauche Kontrollfähigkeit. Ich kann nicht darauf hoffen, dass sie mir eine sogenannte "stabile Umgebung" bieten.

Als Preis für das UI - Design müssen sie die Beobachtbarkeit reduzieren. Ich persönlich mag das nicht, aber das ist nur eine persönliche Präferenz. Ich weiß, dass die meisten Menschen mit der von Claude Code gezeigten Informationsmenge zufrieden sind. Außerdem hat es offensichtlich keine Modellauswahlmöglichkeit, da es ein natives Werkzeug von Anthropic ist. Das ist kein Nachteil, aber es hat fast keine Erweiterbarkeit. Obwohl sie ein Hook - System haben, wenn Sie die Funktionen, die pi erreichen kann, vergleichen, werden Sie feststellen, dass ihre Integration nicht sehr tief ist. Und es basiert im Wesentlichen darauf, einen Prozess beim Auslösen eines Hook - Ereignisses auszuführen. Wenn Sie diesen Prozess wiederholt starten müssen, ist der Aufwand wirklich sehr hoch.

Später war ich mit Claude Code völlig enttäuscht. Es ist nicht, dass es schlecht ist, sondern es passt einfach nicht mehr zu mir. In dieser Zeit hat es sich für mehr Massennutzer geeignet gemacht, was bedeutet, dass sie den richtigen Weg gehen, aber es passt nicht zu mir, einem alten Hasen.

3 Das Grunddesign von OpenCode hat mein Vertrauen erschüttert

Also habe ich angefangen, nach Alternativen zu suchen. Zuerst war es der Codex CLI. Anfänglich mochte ich ihn nicht, weder die Oberfläche noch das Modell, aber jetzt ist die Leistung des Modells wirklich beeindruckend. Dann war es AMP. Die Kernmitglieder dieses Teams haben zuvor bei Sourcegraph gearbeitet und sind dann selbstständig gegangen. Sie sind extrem hervorragende Ingenieure. Sie haben tatsächlich ein sehr kommerzielles Coding - Harness entwickelt und es geschafft, den Markt zu gewinnen, indem sie "Funktionen abschneiden" anstatt "Funktionen hinzufügen". Viele ihrer Designlogiken stimmen mit meinen überhaupt überein. Wenn Sie ein kommerzielles Programmierframework wollen, empfehle ich Ihnen auf jeden Fall AMP. Factory hat einen ähnlichen Ansatz und ist sehr solide, nur nicht so radikal und experimentierfreudig wie AMP.

Dann war es OpenCode, ein von vielen genutzter Open - Source - Rahmen. Ich habe eine Affinität zu Open - Source - Projekten. Ich habe 17 Jahre in der Open - Source - Community gearbeitet und viele Projekte aller Größen verwaltet. Open - Source hat für mich eine große Bedeutung. Also dachte ich: Da OpenCode so nah an mir ist, probiere ich es mal aus. Und ehrlich gesagt, abgesehen von AMP, ist das OpenCode - Team die praktischste und am besten auf den Boden gegründete Gruppe in dieser Branche. Sie versuchen nicht, Sie mit Funktionen zu verblüffen, die Sie nie brauchen werden, sondern bemühen sich, ein sehr stabiles Kernerlebnis aufrechtzuerhalten. Ich stimme auch vollkommen mit ihrer Überlegung überein, was ein Programmier - Agent für unsere Berufstätigkeit bedeutet.

Aber das Problem bei OpenCode ist, dass es im Kontextmanagement völlig versagt. Beispielsweise ruft es in jedem Dialogrundgang eine Funktion namens SessionCompaction.prune auf, die alle Einträge vor den letzten 40.000 Token löscht. Jeder, der etwas von prompt caching (Prompt - Zwischenspeicherung) weiß, weiß, dass dadurch Ihr Cache völlig zerstört wird.

Es gibt eine interessante Geschichte zwischen OpenCode und Anthropic. Meiner Meinung nach ist die Einstellung von Anthropic später logisch: "Sie dürfen das nicht tun." Obwohl das Ganze nicht öffentlich eskaliert ist, ist die Sache einfach: Wenn Sie in einem Fitnessstudio sind und die Regeln nicht befolgen und die Infrastruktur missbrauchen, werden Sie natürlich gesperrt. Obwohl ich keine Beweise habe, vermute ich, dass dies der Grund für die angespannte Beziehung zwischen Anthropic und OpenCode ist. Ich stehe voll und ganz auf der Seite von Anthropic. Lassen Sie die Infrastruktur der anderen in Ruhe.

Es gibt noch andere Fallstricke. Beispielsweise hat OpenCode standardmäßig eine LSP (Language Server Protocol) - Unterstützung. Nehmen Sie an, Sie geben einem Agenten die Aufgabe, eine Reihe von Dateien zu ändern. Wie wird er es in der Praxis machen? Er wird die Dateien nacheinander ändern. Welche Wahrscheinlichkeit besteht, dass der Code nach der ersten Runde der Änderungen kompilierbar ist? Wenn Sie den Code Zeile für Zeile ändern, wie lange dauert es, bis er wieder kompilierbar ist? Die Antwort ist: Es geht gar nicht. Möglicherweise bricht der Code nach der ersten oder zweiten Änderung immer noch ab.

Wenn Sie in diesem Moment an den LSP - Dienst fragen: "Hey, ich habe gerade diese Zeile geändert. Ist der Code kaputt?" wird der LSP sicherlich antworten: "Ja, völlig kaputt." Dann wird diese Funktion die Fehlermeldung direkt hinter dem Tool - Aufruf einfügen und an das Modell zurückgeben: "Sie haben etwas falsch gemacht." Das Modell ist verwirrt: "Was soll das? Ich bin noch nicht fertig!" Wenn so etwas öfters passiert, wird das Modell schließlich einfach aufhören zu arbeiten, und das Ergebnis wird sehr schlecht sein. Deshalb bin ich besonders gegen das Anbinden von LSP, wenn der Agent arbeitet. Der einzige Zeitpunkt, an dem wirklich die Codeüberprüfung und Typüberprüfung erforderlich sind, ist der, wenn der Agent glaubt, dass er seine Arbeit vollständig erledigt hat.

Außerdem hat OpenCode kürzlich eine Änderung vorgenommen: In einer Sitzung wird jede Nachricht als eine separate JSON - Datei gespeichert. Dies zeigt mir,