Mario Zechner, Erfinder von libGDX und des Coding-Agents pi, hat seine Keynote bei der AI Engineer Europe 2026 genutzt, um Engineers zum Bremsen zu raten: Agents häufen Fehler an, lernen nicht daraus und verschieben den Schmerz nach hinten. Für Freelance-Developer hat dieses „hinten" einen juristischen Namen. Mit einem Werkvertrag trägst du zwei Jahre Gewährleistung für Code, den du vielleicht nie gelesen hast. Die Antwort ist nicht, auf Agents zu verzichten, sondern Review als bezahlten Teil einzupreisen, kritischen Code selbst zu schreiben und „Nein" als Lieferung zu verstehen. METR, DORA und Stack Overflow zeigen in dieselbe Richtung.
Wenn ein Angestellter einen Agent auf die Codebasis loslässt, teilt sich das Team den Schmerz. Ein Freelancer unterschreibt allein dafür. Genau dieser Unterschied macht aus einer Keynote für KI-Engineers in London eine Geschäftsfrage für alle in DACH, die Software abrechnen.
Mario Zechner, der Grazer Entwickler hinter libGDX und dem minimalen Coding-Agent pi, der später zum Agent-Kern von OpenClaw wurde, hat diese Keynote am 10. April 2026 gehalten. Er nannte sie eine Tragödie in drei Akten. Akt eins: warum er die großen Harnesses verlassen und sein eigenes Werkzeug gebaut hat. Akt zwei: was passierte, als tausende Agent-Instanzen Pull Requests gegen seine Open-Source-Projekte schickten. Akt drei ist der, um den es hier geht, und er heißt, leicht gekürzt: langsamer.
Was er wirklich gesagt hat
Der Kern passt in einen Satz, gesagt vor einem Saal, der zwei Tage lang Geschwindigkeit gefeiert hatte.
„Agents häufen Fehler an, ohne zu lernen, ohne Flaschenhals und mit verzögertem Schmerz. Der verzögerte Schmerz ist für euch." (Mario Zechner, übersetzt und bereinigt aus dem Auto-Transkript)
Sein Argument geht so: Ein Mensch macht Fehler, lernt aber daraus und ist ein Flaschenhals, denn es gibt eine Grenze, wie viele Fehler eine Person pro Tag einbauen kann. Menschen spüren außerdem Schmerz. Wird eine Codebasis schlimm genug, kündigt jemand, schiebt es auf andere oder alle setzen sich zum Refactoring zusammen. Agents tun nichts davon. Zehn Agents auf einer Codebasis liefern, in seinen Worten, „Enterprise-Komplexität innerhalb von zwei Wochen mit nur zwei Menschen", weil jede Entscheidung eines Agents lokal ist und die Muster, mit denen er Lücken füllt, aus dem alten Code des Internets stammen.
Zwei Sätze, die Freelance-Developer behalten sollten:
„Wisst ihr, wie wir eine ausreichend detaillierte Spec nennen? Ein Programm. Wenn ihr also Lücken in der Spec lasst, was glaubt ihr, passiert dann?" (Mario Zechner)
„Ihr könnt eurer Codebasis nicht mehr trauen, und euren Tests auch nicht, weil euer Agent eure Tests geschrieben hat." (Mario Zechner, übersetzt und bereinigt)
Sein Rezept ist keine Abstinenz. Schneide Agent-Aufgaben so zu, dass der Agent garantiert alles findet, was er braucht. Gib ihm, wo es geht, etwas, woran er sich selbst messen kann. Lass ihn auf langweiliger, unkritischer Arbeit und auf Reproduktionsfällen laufen. Dann bewerten, das Brauchbare behalten und bei allem Kritischen: „jede Zeile lesen". Woher weißt du, was kritisch ist? „Du liest den Code." In der Blogfassung, zwei Wochen vor dem Vortrag erschienen, steht es so: „Alles, was die Gestalt deines Systems bestimmt, also Architektur, API und so weiter, schreib von Hand." Und: „Nein sagen zu lernen ist selbst ein Feature."
Der andere Österreicher, und die Zahlen
Man könnte das als einen einzelnen grantigen Maintainer abheften. Die interessantere Lesart: Mario streitet mit einem Freund.
Peter Steinberger, der österreichische Entwickler hinter OpenClaw, der laut Mario der Grund war, warum er im April 2025 überhaupt mit Coding-Agents angefangen hat, beschrieb im Dezember 2025 den entgegengesetzten Stil: „Heutzutage lese ich nicht mehr viel Code. Ich schaue dem Stream zu und sehe mir manchmal die Schlüsselstellen an, aber ehrlich gesagt: Den meisten Code lese ich nicht." Er committet direkt auf main. Er weiß, wo die Komponenten liegen und wie das System gebaut ist, und sagt, mehr brauche es meistens nicht. Zwei Monate später wechselte er zu OpenAI, um an Agents zu arbeiten.
Beide sind herausragende Entwickler. Die Frage für Freelancer lautet, welcher von beiden du sein darfst, wenn jemand anderes zahlt und die Gewährleistung auf deinen Namen läuft. Drei Belege helfen.
Schneller fühlt sich anders an als schneller sein. Im Juli 2025 ließ METR 16 erfahrene Open-Source-Entwickler in einem randomisierten Versuch 246 echte Issues aus ihren eigenen Repositories bearbeiten. Mit erlaubten KI-Tools brauchten sie 19 % länger. Vorher hatten sie 24 % Beschleunigung erwartet; hinterher glaubten sie weiter, die KI habe sie rund 20 % schneller gemacht. Kleine Stichprobe, Tools von Anfang 2025, erfahrene Leute in reifen Codebasen, also nicht überdehnen. Aber wer nach Stunden abrechnet, sollte merken: Gefühlte und gemessene Geschwindigkeit zeigten in entgegengesetzte Richtungen.
Durchsatz rauf, Stabilität runter. Der DORA-Report 2025, knapp 5.000 Befragte, 90 % davon mit KI im Arbeitsalltag, fand erstmals einen positiven Zusammenhang zwischen KI-Einsatz und Lieferdurchsatz, und zugleich weiter einen negativen Zusammenhang mit der Stabilität der Auslieferung. Die Lesart der Autoren: „KI beschleunigt die Softwareentwicklung, aber diese Beschleunigung kann Schwächen weiter hinten im Prozess offenlegen." Weiter hinten heißt für Freelancer: der Monat nach der Abnahme.
Fast richtig ist die teure Sorte von falsch. In der Stack-Overflow-Umfrage 2025 nutzen 84 % der Entwickler KI-Tools oder planen es. Der größte Frust, von 66 % genannt: „KI-Lösungen, die fast richtig sind, aber eben nicht ganz". 45,2 % sagen, KI-generierten Code zu debuggen kostet mehr Zeit. Rund ein Drittel vertraut der Genauigkeit der Tools, fast die Hälfte misstraut ihr. Das ist die Alltagsversion von Marios Anhäufung: kein einzelner Katastrophen-Bug, sondern ein Strom von fast richtigem Code, den jemand lesen muss.
Was das heißt, wenn dein Name auf dem Werkvertrag steht
Die meisten Festpreis-Softwareprojekte in Deutschland sind Werkverträge. Du schuldest ein Ergebnis, der Kunde nimmt es ab, und ab der Abnahme laufen die Mängelansprüche nach § 634a BGB bei den meisten Softwarearbeiten zwei Jahre. Die Mechanik steht in unserem Leitfaden Werkvertrag oder Dienstvertrag. Hier zählt nur eins: „Der verzögerte Schmerz ist für euch" ist für Freelancer keine Metapher. Es ist eine Verjährungsfrist.
Vier Folgen ergeben sich daraus.
Review-Kapazität ist deine echte Kapazität. Marios Folie zeigt eine Codebasis unter einem Menschen, einem Agent und zehn Agents und fragt, wie viel vom Output du prüfen kannst. Für einen Solo-Developer lautet die ehrliche Antwort: so viele Zeilen, wie du an einem Tag aufmerksam lesen kannst, keine mehr. Diese Zahl, nicht dein Token-Budget, legt fest, wie viele Agents du laufen lassen kannst. Alles darüber ist ungeprüfter Code, für den du gewährleistest.
Nach Stunden und nach Ergebnis scheitern unterschiedlich. Beim Dienstvertrag nach Stunden ist das METR-Ergebnis das Risiko: Du stellst weniger Stunden in Rechnung, als die Arbeit gekostet hat, weil der Agent dich schnell fühlen ließ, oder, schlimmer, Stunden, bei denen der Kunde sieht, dass du einem Stream zugeschaut hast. Beim Festpreis ist der Gewährleistungsschwanz das Risiko: Der Fix im vierzehnten Monat ist unbezahlt. Die Lösung ist in beiden Fällen dieselbe. Schreib das Lesen als eigene Position ins Angebot, und kalkuliere beim Festpreis eine Reserve für die Frist ein. Woher diese Reserve ihre Zahl bekommt, steht in unserem Leitfaden zum Stundensatz.
Wer die Tests geschrieben hat, ist vertraglich relevant. Hat der Agent den Code und die einzigen Tests geschrieben, hast du keinen unabhängigen Beleg, dass das Ergebnis der Leistungsbeschreibung entspricht. Schreib die Abnahmetests selbst, mindestens die, die auf die Abnahmekriterien im Vertrag zeigen. Das ist die Freelancer-Version von „kritischer Code, jede Zeile lesen".
„Nein" ist eine Lieferung. Marios „lernt Nein zu sagen, weniger Features, aber die, die zählen" bedeutet für Freelancer: Scope-Disziplin. Ein Agent baut gern die vier Extra-Features, die der Kunde im Call erwähnt hat. Jedes davon landet in derselben Gewährleistung. Genau dafür gibt es den Change-Request-Prozess.
Nichts davon spricht gegen Agents. Die Marktdaten in unserem Stück dazu, ob KI-Agenten Freelancer ersetzen, zeigen, dass die Nachfrage zu Leuten wandert, die prüfen können, nicht von ihnen weg. Und die Forschung in KI nutzen, ohne den Vorsprung zu verlieren sagt dasselbe von der Skill-Seite: Wer das System noch versteht, behält den Kunden. Marios Reibungsargument, dass erst das eigene Schreiben das Verständnis im Kopf aufbaut, ist die Developer-Version dieses Befunds. Das Schwesterstück zu Agentic Loops für Wissensarbeits-Freelancer trägt dieselbe Logik aus dem Code hinaus.
Ein Regelwerk für Freelance-Developer
- Sortier nach Kritikalität, bevor du anfängst. Authentifizierung, Zahlungen, Datenmigrationen, alles, was Kundendaten berührt: von Hand geschrieben oder Zeile für Zeile gelesen. Boilerplate, Gerüst, Reproduktionsfälle für Bug-Reports: Agent laufen lassen, dann bewerten.
- Der Agent bekommt nie Code und die einzigen Tests zugleich. Die Tests zu den Abnahmekriterien schreibst du.
- Begrenze Agent-Aufgaben auf das, was in den Kontext passt. Modularisieren, damit der Agent garantiert findet, was er braucht. Das ist Marios erste Eigenschaft einer guten Agent-Aufgabe.
- Halte das System klein genug für deinen Kopf. Wenn du nicht mehr sagen kannst, wo eine Komponente liegt, hör auf zu ergänzen und refactore.
- Sag dem Kunden, wie du arbeitest. Welche Teile generiert sind, welche geprüft, was die Tests abdecken. Die Formulierungen stehen in unserem Stück zur Offenlegung von KI-Nutzung.
Was du am Montag tust
- Öffne dein aktuelles Projekt und markiere jede Datei als kritisch oder nicht. Die kritischen liest du diese Woche komplett.
- Überarbeite deine Angebotsvorlage um eine Position „Review und Abnahmetests" und eine Gewährleistungsreserve bei Festpreisen.
- Prüf, wer deine Tests geschrieben hat. War es der Agent, schreib die drei selbst, die auf die Abnahmekriterien im Vertrag zeigen.
- Notier dein tägliches Review-Budget in Zeilen oder Dateien und deckle parallele Agent-Aufgaben auf das, was hineinpasst.
- Üb diese Woche ein „Nein": ein Feature, das der Agent in einer Stunde bauen könnte und das nicht im Vertrag steht.
Kunden, die das verstehen, sind die, die du willst, und sie fragen zunehmend danach. Mit einem kostenlosen 9am-Profil sagst du in einem Satz, wie du mit Agents arbeitest, damit DACH-Unternehmen, die Developer suchen, die prüfen, dich finden.
Dieser Artikel ist eine redaktionelle Analyse. Mario Zechners Vortrag ist oben eingebettet und genannt; Bühnenzitate sind aus dem Englischen übersetzt und aus dem automatischen Transkript bereinigt.
