Mario Zechner

Mario Zechner created libGDX and pi, open-source tools for cross-platform game development and customizable coding agents. Based in Graz, Austria, he leads pi’s technical direction at Earendil. His experience with libGDX and RoboVM gives his insistence on forkable software a concrete history: when RoboVM’s commercial owners discontinued it, community contributors kept the technology alive.

Research, games, and the right to fork

Mario’s career at Know-Center began in 2006 with software and applied research in information retrieval, natural language processing, statistical machine learning, and visualization. He developed reusable components for industry partners, later led mobile software architecture at MIR Partners, and returned to Know-Center as a deputy division manager responsible for an engineering and research team, product strategy, and development practices. Alongside this work, he wrote Beginning Android Games and created libGDX.

LibGDX lets Java developers build desktop, mobile, and browser games from one codebase. It supplies low-level functionality for 2D and 3D games while leaving developers free to organize their programs. Its users included the makers of Ingress and Slay the Spire; it also powers Spine, the commercial animation tool Mario has worked on. In 2016, he largely handed stewardship to a team of core contributors who continued maintaining the framework.

LibGDX brought him into RoboVM, the ahead-of-time compiler and runtime for JVM code on iOS created by Niklas Therning and Henric Müller. Mario built its first proprietary add-on, a debugger. The team combined an open-source compiler core with commercial tools, including debugging and Xcode integration. Xamarin acquired RoboVM and subsequently closed its core; after Microsoft acquired Xamarin, it shut RoboVM down.

Mario had helped manage the community and had to announce the closure, despite lacking control over that decision. LibGDX contributors then forked the available code, restored iOS compilation, and rebuilt capabilities including debugging and Xcode integration. Their MobiVM fork preserved libGDX’s iOS support. In his account of RoboVM and pi’s move to Earendil, the right to fork is a practical safeguard: users can continue essential software even when its owner changes direction.

Mario also built Heisse Preise, a grocery-price project that collected prices daily, with community contributors helping extend the work. It brought his software skills to a problem outside developer tools: making grocery prices easier to compare. Yet he questioned how much the project could help shoppers who depended on discount brands priced similarly across stores. In his 2024 retrospective, he distinguished the ability to collect and compare prices from the practical savings available to those shoppers. The project’s usefulness depended on whether the information gave people a meaningful choice.

Pi: a small core developers can change

Mario began using Claude Code in April 2025 and initially valued its simplicity. As it evolved, unexpected changes to prompts and tool definitions, inserted reminders, and limited visibility into model context disrupted his workflows. He investigated that behavior directly: claude-trace and cchistory made request-response inspection and cross-version prompt comparisons possible. His August account of those tools turned a complaint about unpredictable behavior into a way to examine what the coding assistant actually sent to the model and what changed between releases.

He built pi around four default tools: read, write, edit, and shell execution. Its original architecture separated provider integration, the agent loop, terminal rendering, and the coding interface. Planning modes, subagents, and integrations could be added without becoming requirements for every user.

The terminal interface involved its own deliberate compromise. Mario chose native scrollback and differential rendering, retaining the terminal’s scrolling behavior while updating changed portions of the display. His account of building pi describes the memory and layout costs he accepted for that design. Minimalism did not mean eliminating every cost; it meant choosing which costs served the experience he wanted.

Pi’s self-modifying agent extensions are TypeScript modules that can add tools, commands, interfaces, providers, and context-management behavior. Bundled documentation and examples let pi help write an extension; developers can reload it during the same session and inspect the effects. Mario connects this short feedback loop to game development, where quickly seeing a change makes iteration easier. Extensions can be distributed through npm or GitHub. His pi-skills collection supplies reusable capabilities such as web search and browser automation, with compatibility across coding assistants including Claude Code and Codex CLI.

This flexibility carries a security tradeoff. Pi runs with the permissions of the process that launches it and has no built-in system for restricting filesystem, process, network, or credential access. Users who need those restrictions must provide suitable sandboxing or containerization.

Funding pi without repeating RoboVM

Peter Steinberger incorporated pi into OpenClaw’s agentic core, bringing Mario’s project a wider audience and an influx of automated, low-quality contributions. Mario introduced a filter requiring prospective contributors to explain their proposed work in concise, human-written issues before their pull requests would be admitted. He also experimented with clustering related reports and temporarily closing trackers to keep maintenance from becoming an uninterrupted obligation.

In April 2026, Earendil announced its acquisition of pi and Mario’s arrival. He became a shareholder, with responsibility for pi’s direction alongside Armin Ronacher and Colin Sidoti. His explanation of the decision describes a tension between wanting to develop pi further and declining to build a company solely around it. He wanted a small team and sustainable funding while remaining an engineer and protecting time with his young son.

The RoboVM experience shaped his conditions for commercialization. Pi’s core remains MIT-licensed, allowing others to use, modify, fork, and commercialize it. His April announcement proposed fair-source additions that would become open source after a delay, alongside proprietary enterprise features and infrastructure. Those additional tiers were plans at the time of the announcement. The existing core would remain available for users to continue independently.

Context and the cost of generated code

Mario’s criticism of coding agents concerns how they are built and used, even as he develops one himself:

• Feedback at the right time. Model context includes prompts, tool definitions, retained outputs, and diagnostics. Mario objects to automatically injecting compiler diagnostics after every edit: an unfinished change can contain temporary errors, and intervening too early can divert the model from completing it. He wants developers to be able to inspect and change this behavior.

• Generation bounded by review. His warning about complexity and essay on slowing development down describe a compounding problem. An agent misses existing code, duplicates it, or adds unnecessary abstractions; the resulting system becomes harder for subsequent agents to search and understand. Increasing generation speed can accelerate this cycle beyond a person’s capacity to review the changes.

• Evaluation with explicit limits. Mario favors tasks whose scope gives an agent enough context and whose results it can evaluate. But an optimization metric captures only part of the job: improving startup time, for example, does not establish correctness or maintainability. He recommends using agents for bounded experiments, routine work, and reproducing user-reported bugs, then assessing and finalizing their output.

For consequential architecture and APIs, Mario wants developers involved in shaping the code themselves. Reading and writing it introduces friction, but that effort builds the understanding needed to recognize a bad design, repair a failure, or decide that a feature should never be built.