CentOS Founder Builds Rust Kernel Ginux in 11 Days with AI
Gregory Kurtzer, founder of Rocky Linux, used Human-Directed Agentic Engineering (HDAE) to build Ginux, an independent Rust-based kernel compatible with the Linux ABI, in just 11 days. By generating approximately 139,000 lines of code with AI assistance, he demonstrated that the kernel can successfully boot Rocky Linux 10 and run systemd, validating AI's capability in complex systems software development.
Full Report
Contents3 sections
"Even with infinite tokens, a model cannot build something at the operating system level." For years, this sentiment was nearly consensus in the tech community regarding the upper limits of AI capabilities.
But Gregory Kurtzer has now answered that question in his own way. The name is familiar to those in the Linux world: he is one of the founders of CentOS and the person who single-handedly launched Rocky Linux after Red Hat decided to discontinue CentOS Linux.
On October 27, 2026, Kurtzer announced on X that within 11 days, using "Human-Directed Agentic Engineering" (HDAE), he wrote approximately 139,000 lines of code to create a brand-new Linux-compatible kernel capable of booting Rocky Linux 10 and running systemd.
The project is named Ginux, an independently developed x86-64 kernel primarily written in Rust. In other words, it is not a fork of the Linux kernel.
Ginux features its own memory management, scheduler, process model, file system, networking, and device support—all written from scratch.
Interestingly, although Ginux is not Linux, it is Linux-compatible. It implements the Linux ABI—the binary interface used by compiled programs to communicate with the kernel—allowing existing Linux binaries to run directly on Ginux without modification.
A C Compiler Provided Confidence; The Kernel Posed a Question
Behind Kurtzer's project lies a reference point: Nicholas Carlini from Anthropic once built a C compiler from scratch using 16 parallel Claude agents. That experiment took nearly 2,000 sessions and cost about $20,000, producing roughly 100,000 lines of Rust code capable of compiling a significant amount of software, including most of the Linux kernel build process. The compiler test suite and reference tools provided strong validation for the results.
The task facing Ginux is harder to validate: building a kernel from scratch and then running unmodified Linux user-space programs on top of it. Whether Linux programs can run and whether systemd can boot are the critical checkpoints for verifying if the system truly works.
In his technical report, Kurtzer broke down the research objectives into three questions:
- Capability: Can HDAE produce a standalone kernel that boots and runs some unmodified Linux distribution workloads?
- Methodology: What documentation, guidance, executable gates, and feedback loops are needed to keep this work progressing?
- Result Quality: How compatible and performant is the final system? What is the scope of these conclusions?
He wanted to know: When domain experts clearly define architecture, constraints, milestones, and acceptance criteria, how far can AI push systems software development?
Kurtzer’s experience contributing to Caos Linux, CentOS, and Rocky Linux, along with his background in Singularity/Apptainer, Warewulf, Perceus, and production infrastructure operations, influenced Ginux’s startup flow and acceptance standards.
One Agent, 11 Days, 139,000 Lines: The Key Is Guidance by a "Domain Expert"
Almost all of this implementation was completed within a single continuously running Codex task, using GPT-5.6 Sol. As stated: "The author was responsible for setting the architecture, system operations, interpreting results, and making final acceptance decisions."
The human role exists within two complementary loops of HDAE:
HDAE External Guidance Loop: Vision → Architecture & Constraints → Acceptance Gates → Human Review of Observed Behavior → Correction, Reprioritization, or Acceptance.
HDAE Internal Agent Loop (No Human Observation Required): Implementation → Build and Run in QEMU → Measure and Analyze Failures → Revision → Regression Testing.
In essence, Kurtzer provided the goals, architecture, Linux compatibility targets, operational models, failure interpretation, and stop decisions. Codex shortened the distance from technical decision-making to runnable code.
Kurtzer’s domain knowledge provided the vision, priorities, and success criteria. He noted, "The project required domain expertise to select Linux user-space contracts, distinguish between OCI transport and runtime isolation, identify broken fork/exec behaviors, define domain ownership, interpret systemd failures, and judge whether plausible-looking outputs met expectations."
Systemd was chosen as the acceptance gate because it depends on numerous system components and is the core process for booting and running the entire system. However, it is also very picky about its environment when starting inside containers, so Ginux first implemented "domains" before handling containers.
On X, someone asked Kurtzer why he chose Codex. Kurtzer replied that it wasted fewer tokens on tangents. But even so, he still had to frequently pull it back on track. There were large chunks of code he wasn't satisfied with, but he deliberately forced himself not to edit them manually—"I even closed my IDE, forcing myself not to open it. This way, when the AI made mistakes, I could only give it new instructions; often, it would delete the incorrectly written code." When pressed on how exactly he pulled it back on track—was it a list of prohibitions, or watching the output and yanking it back when it drifted?—Kurtzer’s answer was simple: Set more gates.
This is precisely what he emphasized: "Un-guided 'vibe coding' is not suitable for this project."
"Many failures produce plausible-looking outputs that violate Linux semantics, isolation requirements, or lifecycle behaviors... resulting in code that appears functional on the surface but is structurally weak, often referred to as 'AI slop.'"
"AI can also help less experienced engineers participate faster in bounded practical work, such as exploring unfamiliar code, generating tests, comparing interfaces, and implementing reviewed changes. But experience remains crucial when selecting abstractions, identifying whether results are complete, and judging whether local successes might cause system-level risks."
One agent plus one sufficiently experienced human expert goes further than a swarm of unmanaged agents.
Over the course of 11 days, the project accumulated approximately 139,000 lines of retained code across 1,037 commits, comprising 261 tracked files and 63 Rust source files.
Ultimately, Ginux can be built into a GINUX.EFI image that boots directly via UEFI, without relying on a Linux host kernel.
It is capable of running isolated "domains," each with its own processes, address space, file system, and lifecycle. The project claims that this isolation boundary is stronger than OCI containers or Linux namespaces.
Ginux can also pull and verify OCI container images, using them to assemble the root file system for domains. Leveraging this capability, it can boot Rocky Linux 10 up to systemd's multi-user.target. Some Alpine Linux programs, such as musl and BusyBox, are also able to run.
In terms of performance, the project conducted a comparative benchmark against Rocky Linux. The test conditions involved simulating an environment on an Apple Silicon Mac using virtualization, allocating only 1 CPU core and 2 GiB of memory, and running the same test program on both systems. Regarding boot time, Ginux took 12.9 seconds to bring Rocky Linux 10 to a login-ready state, whereas the Linux kernel took 42.6 seconds—making Ginux approximately 3.3 times faster. However, since Ginux does not need to load a kernel during startup and its file system is pre-cached, these figures should be treated as reference points only. A more meaningful comparison lies in the benchmarks: a three-second sysbench test was performed nine times per system, with the median results shown below:
Ginux has already come very close to Linux in these three tests—with slightly higher scores in CPU and threading, and slightly lower scores in memory, all within single-digit to low double-digit percentage differences.
The API call costs for this experiment amounted to approximately $8,000. The code is licensed under Apache 2.0 and hosted on GitHub.
Final Thoughts: Code Is Not the Moat
After releasing Ginux, Kurtzer wrote in the technical report: "A more important takeaway is that while AI can generate complex system software, compatibility, security, hardware support, standards, community, and long-term maintenance remain the true moats."
Building a small, runnable kernel is not inherently difficult; maintaining a production-grade kernel is another matter entirely—it requires supporting diverse hardware and workloads, keeping interfaces stable, fixing bugs, coordinating contributors and vendors, and ensuring a reliable release cadence. The real challenge lies in workflows, compatibility, maintenance, and community.
The competitive pressure brought by AI-generated software may first impact middleware and orchestration layers, because swapping software at these levels does not require migrating the entire hardware stack and system ecosystem. Foundational software can certainly be rewritten, but whether an infrastructure solution gets adopted depends on standards, interfaces, certifications, hardware adaptation, community sustainability, and commercial support.
He emphasized, "Without an ecosystem, innovation itself has limited value."
Linux is the clearest example. Its value extends far beyond the source code needed to launch a shell—it provides stable expectations across different processors, devices, file systems, virtual machines, distributions, vendors, and applications. Ginux currently lacks a comparable hardware matrix, standards organization, or community, and cannot guarantee that programs running today will still run tomorrow. AI can create technical components, but getting those components truly adopted requires multiple independent organizations to jointly support the same contracts.
Kurtzer concluded his 13-page technical report by noting that AI is now capable of writing code deep within the system stack. However, the core value of infrastructure stems from compatibility, hardware support, review, community trust, and long-term responsibility. Linux acquired these qualities over decades of human engineering practice across a vast range of workloads.
References:
https://zenodo.org/records/23682548
https://github.com/gmkurtzer/ginux