Can Bölük set out to test the limits of an AI coding model. What emerged in under a week was pon, a new Python 3.14 runtime that skips the interpreter and bytecode entirely. Written primarily in Rust, the project compiles modules straight to native machine code using the Cranelift backend. No CPython interpreter. No reference counting. Instead, a custom garbage collector called Green Tea handles memory.
The repository dropped on GitHub today. Within hours it drew attention across developer forums. https://github.com/can1357/pon describes the system in direct terms. Every module gets parsed by the Ruff parser, lowered to a shared intermediate representation, and compiled either just-in-time inside the running process or ahead-of-time into a standalone executable. The goal sounds ambitious yet familiar. Bölük calls it “the bun/v8 of Python.” A runtime that passes the full CPython test suite, delivers faster performance through multi-tier JIT compilation, produces single-file binaries, and ships its own package manager and tools.
Bölük brings an unusual background to the effort. The security researcher and reverse engineer maintains a long track record in Windows kernel development, low-level systems, and program analysis. His earlier projects include Selene, a kernel-mode paravirtualization system in Ring 2, and multiple PatchGuard bypass techniques. On his blog he has explored optimizing intermediate language compilers and speculated about undocumented x86 instructions. That experience shows in pon’s architecture.
The design avoids many traditional Python runtime elements. Reference counting gives way to Green Tea GC. A byte-exact differential testing harness compares pon’s output against CPython 3.14.0 at the binary level. Any deviation fails the test. So far 209 modules pass under the JIT path and 172 under ahead-of-time compilation. The numbers remain early. The roadmap targets full test suite conformance, broader standard library support, and performance improvements that aim for at least five times the geometric mean speed of CPython.
Two compilation tiers exist today. Tier 0 produces fully boxed, dynamic code. Tier 1 introduces type specialization, inline caches, and on-stack replacement. The shared IR enables both JIT and AoT paths from one representation. “One IR, two backends, one runtime ABI,” the README states. This separation keeps the runtime consistent whether code runs interpreted in process or as a native binary.
Performance matters. Yet correctness comes first. The differential harness uses immutable corpus files once they land. Any change in behavior against CPython triggers immediate review. Such rigor addresses a common complaint about alternative Python implementations. Many deliver speed but break subtle edge cases or C extension compatibility.
Bölük did not write the bulk of the code alone. He ran an experiment with Anthropic’s Fable model. The prompt was simple. Write an ahead-of-time compiler for Python 3.14 in Rust with the Green Tea garbage collector and make no mistakes. Over six days and roughly $1,400 in API costs, the system produced working JIT code generation and a package manager modeled after uv. The total estimated cost at published API rates reached $12,578.
He shared the results on X. “Ending the Fable experiment here,” the post read. “After 6 days and ~1400$ in Anthropic subs, we have Py3.14 JIT codegen and pon package-manager!” The thread highlights successes with numpy, even though full conformance remains incomplete. Installing wheels required the runtime to support Meson and Cython builds, yet it succeeded. “Although not 100% conformant, numpy working is pretty impressive,” he noted.
Reactions poured in quickly. Hacker News picked up the story within hours. Discussions focused on the unusual origin story, the choice of Rust for a Python runtime, and Cranelift’s suitability for JIT work. Some developers expressed skepticism about AI-generated code quality. Bölük addressed the concern directly in follow-up posts. The output contains unsafe Rust. Any experienced engineer would isolate and abstract those sections, he wrote. Still, he found the model’s persistence impressive. Unlike previous models that declared tasks complete prematurely, Fable continued refining for days within the same session.
The package manager draws inspiration from pubgrub, the same solver used in uv. It aims for fast resolution and reproducible installs. Combined with ahead-of-time builds, this could let Python developers distribute standalone binaries without shipping the interpreter or dependencies. Think smaller deployment footprints and faster cold starts. For serverless or edge environments the appeal is obvious.
Yet challenges remain substantial. Python’s dynamic nature resists static compilation. The C API, extensions built against CPython internals, and the massive standard library all demand careful handling. Pon currently supports a subset of modules. Full compatibility with the scientific Python stack or complex frameworks will require significant additional work.
Bölük’s prior writing offers context on his approach. In a 2020 blog post about writing an optimizing IL compiler he admitted limited formal background. “I have no prior experience… so I might not use correct jargon,” he explained. That self-taught ethos runs through his projects. From kernel exploits to hypervisor detection to this Python runtime, he favors building systems from first principles.
Green Tea GC represents another custom piece. Details in the repository remain sparse, but it replaces reference counting with tracing collection. This choice avoids the overhead of increment and decrement operations on every assignment. For long-running applications or those with complex object graphs the difference can matter. Multi-tier JIT further helps. Simple code runs quickly in tier 0 while hot functions graduate to optimized native code.
Cranelift serves as the code generation backend. The compiler infrastructure project, originally from Mozilla, emphasizes fast compilation over peak optimization. That fits JIT use cases where compile time directly affects startup and responsiveness. For ahead-of-time builds the same backend produces standalone executables that link against the pon runtime.
Comparisons to other Python compilers arise naturally. PyPy offers a tracing JIT but retains an interpreter core. Nuitka translates to C++ and produces executables but still depends on Python runtime libraries. Mojo and Taichi target specific domains with restrictions. Pon attempts a broader compatibility target while removing the interpreter completely.
The timing feels notable. Python’s popularity in data science, web services, and automation continues to grow. Deployment friction remains a frequent complaint. Single-binary executables could lower barriers for distributing tools and applications. Faster runtime performance would benefit compute-intensive workloads without forcing developers to rewrite in Rust or C++.
Bölük shows no signs of slowing. Recent X posts discuss further refinements to pon. Meson end-to-end tests now pass, expanding build tool support. He continues to experiment with Fable on other tasks while expressing measured enthusiasm. “I like fable quite a lot, don’t get me wrong. I’m actually pretty impressed with the results, even if it’s unsafe soup.”
Industry observers will watch how pon evolves. The project sits at an interesting intersection. It combines modern compiler technology, garbage collection research, differential testing, and AI-assisted development. Success could influence how future language runtimes get built. Even partial success might push the broader Python community to reconsider what a runtime can look like.
For now the code lives on GitHub. Developers can try pon run or pon build on simple scripts. Numpy works in limited capacity. The test harness keeps the implementation honest. And the experiment that started it all continues to spark discussion about the role of large language models in systems programming.
One detail stands out in Bölük’s thread. He ran the AI agents with a diversity setting enabled. It caught mistakes repeatedly. The final code may not win awards for elegance, but it runs. That alone marks a step beyond many previous attempts to generate complex compilers automatically.
The broader question lingers. Can a runtime born from an AI coding sprint mature into a production alternative to CPython? The technical foundation looks promising. The author possesses the low-level expertise to steer it. And the open-source nature invites contributions. What happens next will depend on how quickly the team expands test coverage, improves performance, and fills missing pieces of the Python standard library.
Python Compiled to Bare Metal: How One Engineer Built a JIT Runtime in Rust first appeared on Web and IT News.
