C to Rust in 3 Days: Blitzy Autonomously Rewrote dnsmasq
Mar 13, 2026 • Murph Vandervelde • 5 min read
119 Engineering Days. 86,000 Lines. Zero Errors. Here's How.
Let's start with what everyone's thinking: AI-generated contributions to open source are a disaster.
Over the past two years, AI copilots have made it trivially easy for anyone to generate a patch, open a pull request, and dump it on a maintainer's desk.
The problem is so significant that GitHub is actively considering a "kill switch" for pull requests because maintainers are drowning in AI-generated submissions. cURL has even cancelled their successful bug bounty program due to "AI slop".
The numbers back this up. CodeRabbit's State of AI vs Human Code Generation Report found that AI-generated PRs produce 1.7x more issues than human-authored code. Projects face those repercussions fast with critical issues already up 40% and major issues up 70%. Logic and correctness errors appeared more than twice as often.
The quality gap is stark.
What Makes Blitzy Different?
Blitzy optimizes for quality, not speed.
The platform dynamically creates and orchestrates 3,000+ specialized AI agents that produce end-to-end tested, production-ready code. The difference between Blitzy and existing agentic copilots is in what happens before touching a line of source code.
First, we start by developing a deep understanding of the codebase we are working on. Our agents ingest the entire repository: every file, every dependency, every line. They build a 300+ page technical specification for the developer to see the surface of what Blitzy has understood from the onboarding.
From there, Blitzy spins up agents that write, compile, test, and validate code against the contribution guidelines set in the project agent action plan. Every pull request passes a full QA validation pipeline, making the run equivalent to a production-grade engineering team.
The Blitzy Open Source Enhancement Initiative
Today, we are launching the Blitzy Open Source Enhancement Initiative. The program identifies high-impact community-driven projects burdened by significant technical debt and contributes free, substantive engineering work to address it with the Blitzy platform.
There is no greater calling than serving our country and ensuring our infrastructure is secure and performant. This is why our first project is from the Great Refactor, where we had Blitzy rewrite dnsmasq from C to Rust.
Why dnsmasq?
For those who are not familiar with the Great Refactor, in February 2024, the White House Office of the National Cyber Director published a report titled Back to the Building Blocks. The objective was a calling on the software industry to adopt memory-safe programming languages. CISA followed with its own guidance, going so far as to call development of new critical infrastructure software in C or C++ dangerous and significantly elevating risk to national security.
One such project, dnsmasq, is critical internet infrastructure containing:
- Lightweight DNS forwarder
- DHCP server
- Network boot toolkit that runs on routers, embedded devices, and Linux servers worldwide
The C codebase carries the inherent risks of buffer overflows, use-after-free vulnerabilities, and data races in signal handlers.
Memory management is not a theoretical concern; the risks are the exact vulnerability classes that Rust's ownership system eliminates at compile time. The hard part remains in the sheer amount of engineering hours behind migration.
Rewriting tens of thousands of lines of network protocol code from C to Rust is enormously expensive for human teams. A project of this size would typically take a systems engineering team six to twelve months. The difficulty of creating a team with this level of expertise and specialties is why the work remains unfinished.
Blitzy acknowledges the challenge and chose the project for this very reason.
Deep Codebase Understanding: Tech Spec
Before writing a single line of code, Blitzy ingested and analyzed the entire dnsmasq C codebase and created a detailed technical specification.
The analysis identified gaps that would have tripped up a less thorough approach. The discovered rules included: error handling that relied entirely on return codes and the global errno variable rather than explicit error types, security patterns that needed modernization, and areas where documentation was sparse enough that the code was the only source of truth.
What Blitzy Built
See the pull request and project guide that recaps the work. Here are the numbers:
- Executed 950 engineering hours (119 work days) in 3 days by parallelizing development
- 86,000+ lines of production Rust code across 88 source files, written autonomously
- A 6.1MB optimized release binary with full functional parity: DNS forwarding and caching, DHCPv4/v6 with lease management, DNSSEC validation, TFTP, Router Advertisement, D-Bus and systemd integration
- 592 tests (485 unit and 107 integration) with a 100% pass rate and zero compilation errors
- All 350 configuration directives are backward compatible, making it a drop-in replacement
Performance Improvements
Beyond the sheer volume of high quality code, the real impact is in the technical details. Consider memory management. In the C version, every buffer allocation is a potential vulnerability. Error handling moved from C's silently-ignorable return codes to Rust's Result<T, E> type, where the compiler itself refuses to let you forget to handle an error.
The net effect: the security vulnerability classes that the White House is warning about, the ones that account for 70% of CVEs in systems software, are gone at compile time.
Not mitigated. Not reduced. Gone.
Remaining Work
All code for the Rust rewrite of dnsmasq is written, compiles, and passes initial tests. Blitzy completed 90% of the project, with the remaining 10% focused on production readiness and validation. The run included performance benchmarking against the original C version, real-world integration testing with production configurations, a comprehensive security audit, and load/stress testing. What remains is a need to create deployment guides, operational documentation, and set up monitoring.
The bottom line is that all code is complete, and what's left is validating that it performs, scales, and survives in a production environment.
Blitzy, and we, have tested this across 592 different tests, but not for every edge case. If you find any gaps, thank you for helping improve this project. Please report the gaps to [email protected] and we can talk about next steps and platform usage, with more information found on our dev docs.
What's Next
After 950 engineering hours of autonomous work on this refactor, what is next for Blitzy?
The project is an example of what responsible open source contributions from AI should look like: full codebase understanding, production-quality output, and minimal effort for the maintainers.
dnsmasq was just the first open source project of many. Blitzy plans to push the boundaries of autonomous software development with each post while solving some of the open-source community's largest open items.
To stay current on Blitzy's Open Source Initiative, follow us on LinkedIn.
