Mario Zechner, who built libGDX and the pi coding agent, used his AI Engineer Europe 2026 keynote to tell engineers to slow down: agents compound errors, do not learn from them, and push the pain to later. For a freelance developer that "later" has a legal name. Under a Werkvertrag you carry two years of warranty on code you may never have read. The answer is not to stop using agents but to price review as the paid part, keep critical code human-written, and treat "no" as a deliverable. METR, DORA and Stack Overflow point the same way.
An employee who lets an agent flood a codebase shares the pain with a team. A freelancer signs for it alone. That is the difference that makes a keynote for AI engineers in London a business question for anyone in DACH who bills for software.
Mario Zechner, the Graz developer behind libGDX and the minimal coding agent pi, which became the agent core inside OpenClaw, gave that keynote on 10 April 2026. He called it a tragedy in three acts. Act one is why he stopped using the big harnesses and built his own. Act two is what happened when thousands of agent instances started filing pull requests against his open-source projects. Act three is the one that matters here, and he titled it, more or less, slow down.
What he actually said
The core claim fits in one line, delivered to a room that had spent two days celebrating speed.
"Agents are compounding errors, with zero learning, no bottlenecks and delayed pain. The delayed pain is for you." (Mario Zechner, lightly cleaned from the auto-transcript)
His argument runs like this. A human developer is fallible but learns, and is a bottleneck: there is a limit to how many mistakes one person can add per day. Humans also feel pain, so when a codebase gets bad enough, somebody quits, blames someone or bands together to refactor. Agents do none of that. Ten agents on one codebase produce, in his words, "enterprise-grade complexity within two weeks with just two humans", because each decision an agent makes is local, and the patterns it fills gaps with were learned from the internet's old code.
The two lines freelance developers should keep:
"You know what we call a sufficiently detailed spec? It's a program. So if you leave blanks in your spec, what do you think happens?" (Mario Zechner)
"You cannot trust your codebase any more, and also not your tests, because your agent wrote your tests." (Mario Zechner, lightly cleaned)
His prescription is not abstinence. Scope agent tasks so the agent is guaranteed to find everything it needs. Give it something to evaluate itself against where you can. Let it run on boring, non-critical work and on reproduction cases. Then evaluate, keep what is reasonable, and, for anything critical, "read every line". How do you know what is critical? "You read the code." In the written version on his blog, published two weeks before the talk, he puts it as: "Anything that defines the gestalt of your system, that is architecture, API, and so on, write it by hand." And: "Learning to say no is a feature in itself."
The other Austrian, and the numbers
It would be easy to file this as one grumpy maintainer. The more interesting reading is that Mario is arguing with a friend.
Peter Steinberger, the Austrian developer who created OpenClaw and who, as Mario tells it, is the reason he started using coding agents in April 2025, described the opposite style in December 2025: "These days I don't read much code anymore. I watch the stream and sometimes look at key parts, but I gotta be honest - most code I don't read." He commits straight to main. He knows where the components are and how the system is designed, and says that is usually all that is needed. Two months later he joined OpenAI to work on agents.
Both are exceptional developers. The freelancer's question is which of the two you are allowed to be when someone else is paying and the warranty runs on your name. Three pieces of evidence help.
Faster feels different from being faster. In July 2025, METR ran a randomised trial with 16 experienced open-source developers on 246 real issues from their own repositories. With AI tools allowed, they took 19% longer. Before the study they expected a 24% speed-up; afterwards they still believed AI had made them about 20% faster. Small sample, early-2025 tools, experienced people in mature codebases, so do not over-generalise. But a freelancer billing by the hour should notice that the feeling of speed and the measured speed pointed in opposite directions.
Throughput up, stability down. The 2025 DORA report, nearly 5,000 respondents, 90% of them using AI at work, found for the first time a positive relationship between AI adoption and delivery throughput, and at the same time a continued negative relationship with delivery stability. Their reading: "AI accelerates software development, but that acceleration can expose weaknesses downstream." Downstream, for a freelancer, is the month after acceptance.
Almost right is the expensive kind of wrong. In the Stack Overflow 2025 survey, 84% of developers use or plan to use AI tools. The top frustration, named by 66%, is "AI solutions that are almost right, but not quite". 45.2% say debugging AI-generated code takes more time. About a third trust the accuracy of the tools; nearly half distrust it. That is the everyday version of Mario's compounding: not one catastrophic bug, but a stream of almost-right code that someone has to read.
What this means when your name is on the Werkvertrag
Most fixed-price software work in Germany is a Werkvertrag. You owe a result, the client accepts it, and from acceptance the defect claims in § 634a BGB run for two years on most software work. Our Werkvertrag vs Dienstvertrag guide has the mechanics. The point here is simpler: "the delayed pain is for you" is not a metaphor for a freelancer. It is a limitation period.
Four consequences follow.
Review capacity is your real capacity. Mario's slide shows one codebase under one human, one agent and ten agents, and asks how much of the output you can review. For a solo developer the honest answer is: as many lines as you can read with attention in a day, and no more. That number, not your token budget, sets how many agents you can run. Anything above it is unreviewed code you have warranted.
Per hour and per outcome fail in different ways. On an hourly Dienstvertrag, the METR result is the risk: you may bill fewer hours than the work took because the agent made you feel fast, or, worse, bill hours the client can see were spent watching a stream. On a fixed price, the warranty tail is the risk: the fix in month fourteen is unpaid. The fix for both is the same. Put reading into the quote as a named line, and quote the outcome with a reserve for the tail. Our hourly-rate guide is where that reserve gets its number.
Who wrote the tests matters contractually. If the agent wrote the code and the only tests, you have no independent evidence that the result meets the Leistungsbeschreibung. Write the acceptance tests yourself, or at least the ones that map to the contract's acceptance criteria. That is the freelancer's version of "critical code, read every line".
"No" is a deliverable. Mario's "learn to say no, fewer features but the ones that matter" reads, for a freelancer, as scope discipline. An agent will happily build the four extra features the client mentioned on a call. Each one lands inside the same warranty. The change-request process exists for exactly this.
None of this argues against agents. The market data in our piece on whether AI agents replace freelancers shows demand shifting toward people who can verify, not away from them. And the research in using AI without losing your edge says the same thing from the skills side: the person who still understands the system is the one who keeps the client. Mario's friction argument, that having to write the thing is what builds the understanding in your head, is the developer's version of that finding. The companion piece on agentic loops for knowledge-work freelancers takes the same logic outside code.
A working rule set for a freelance developer
- Sort by criticality before you start. Authentication, payments, data migrations, anything that touches the client's customer data: written by hand or read line by line. Boilerplate, scaffolding, reproduction cases for bug reports: let the agent run, then evaluate.
- Never let the agent own both the code and the only tests. You write the tests that map to the acceptance criteria.
- Bound agent tasks to what fits in their context. Modularise so the agent is guaranteed to find what it needs, which is Mario's first property of a good agent task.
- Keep the system small enough to hold in your head. When you can no longer say where a component lives, stop adding and refactor.
- Tell the client how you work. Which parts are generated, which are reviewed, what the tests cover. Our piece on disclosing AI use to clients has the wording.
What to do on Monday
- Open your current project and mark every file as critical or not. Read the critical ones this week, in full.
- Rewrite your quote template with a "review and acceptance testing" line and a warranty reserve on fixed-price work.
- Check who wrote your tests. If it was the agent, write the three that map to the contract's acceptance criteria yourself.
- Write down your daily review budget in lines or files, and cap concurrent agent tasks at what fits.
- Practise one "no" this week: a feature the agent could build in an hour that the contract does not cover.
Clients who understand this are the ones worth having, and they are increasingly the ones asking for it. A free 9am profile lets you say in one line how you work with agents, so the DACH companies searching for developers who verify can find you.
This article is an editorial analysis. Mario Zechner's talk is embedded above with credit; stage quotes are lightly cleaned from the automatic transcript.
