Microsoft has announced one of the biggest codebase modernisation projects in computing history: roughly one billion lines of C and C++ getting translated to Rust, with AI-assisted tooling doing the heavy lifting. If you’re evaluating a legacy modernisation roadmap, the question is pretty obvious: when can we actually use this, and can we trust what it produces?
This article covers four things: what Microsoft has actually built, what the US government is funding through DARPA TRACTOR, what is available today, and what the quality evidence actually says — including the caveat most coverage quietly glosses over.
For broader context on Microsoft’s billion-line Rust migration project, see the pillar article in this series.
What Has Microsoft Actually Built — and What Has It Not Released?
Microsoft’s AI-assisted translation work lives inside Microsoft CoreAI, specifically the EngHorizons group — the “Future of Scalable Software Engineering” team — led by Distinguished Engineer Galen Hunt. Let’s be clear about what this is: as of late 2025, it is internal research infrastructure. Not a product. Not a public API. Not something your team can access.
Hunt’s original LinkedIn post described a personal goal: eliminate every line of C and C++ from Microsoft by 2030. He later walked it back: “Windows is NOT being rewritten in Rust with AI.” His team’s own framing: “My team’s project is a research project. We are building tech to make migration from language to language possible.” They do mention deploying capabilities “across Microsoft and across the industry.” That last part matters. But intent is not a product timeline.
One thing worth clearing up: the CoreAI pipeline is not GitHub Copilot. Copilot helps individual developers at the line-or-function level. The CoreAI pipeline analyses entire repositories, builds structural models, and applies modifications algorithmically across millions of lines. Completely different systems.
How Does the Pipeline Work: Algorithmic Graphs, AI Agents, and the 1M Lines Target?
Hunt has described the architecture publicly. Two stages.
Stage one is algorithmic: the infrastructure builds a scalable graph over the entire source codebase, capturing dependency topology, call chains, and ownership semantics.
Stage two is AI-driven: AI agents, guided by the graph, apply targeted code modifications. The ordering is the key insight. The AI layer operates under constraints the graph provides — which prevents the failure mode you get with naive LLM translation. Paste a file into ChatGPT, ask for Rust, and you get code that may look fine in isolation but breaks dependencies across a larger system. Research confirms fewer than 20% of C programmes over 150 lines can be satisfactorily translated by LLM-only methods without manual intervention.
The Rust borrow checker acts as the mechanical quality gate: translated code must compile against it to be considered correct. Memory safety enforced by the toolchain, not by review.
The pipeline’s “North Star” goal: 1 engineer, 1 month, 1 million lines. Hunt is explicit this is a research direction target, not a demonstrated result.
What Is the DARPA TRACTOR Programme and Why Does It Matter?
DARPA‘s TRACTOR programme — Translating All C To Rust — is a US government-funded research initiative to develop fully automated C-to-Rust translation with memory safety guarantees. (You may see “TRANSLATORS” in press coverage; TRACTOR is the correct name.) It runs in parallel to Microsoft CoreAI, independently initiated, with a national security framing.
The key thing it tells you: AI-assisted C-to-Rust translation is not just a Microsoft proprietary direction. The US government has independently decided it’s worth funding.
The most concrete public results come from Asari AI, one of the programme’s participants. They’ve translated four production C libraries to Safe Rust: libmcs, gzip, libyaml, and zlib — more than 40,000 lines of low-level, performance-critical code. GTD GmbH validated the libmcs translation against ESA flight software standards. A senior Rust developer who reviewed the gzip output said he couldn’t tell it was machine-translated. Costs ranged from $50 to $500 per library without explicit cost optimisation — the first public signal for what AI translation actually costs at library scale with real verification.
TRACTOR outputs and tooling are expected in the 2026–2027 timeframe. That is the date range to watch.
For guidance on how AI translation fits into a migration planning framework, see the migration strategy article in this series.
What Does the Quality Evidence Actually Say About AI-Translated Code?
Most AI tooling coverage omits this. It shouldn’t be omitted.
CodeRabbit‘s December 2025 “State of AI vs Human Code Generation” report analysed 470 open-source GitHub pull requests. AI-generated PRs contained roughly 1.7x more issues overall, logic errors were 75% more common, and security issues ran up to 2.74x higher. Their conclusion: “AI accelerates output, but it also amplifies certain categories of mistakes. Quality isn’t automatic.”
Worth noting: the report covers developer-facing AI tools, not translation pipelines like CoreAI. Treat it as a risk signal, not a directly comparable measurement. The practical implication is simple — budget for increased review and testing overhead. The human workload shifts from writing to verifying.
The quality metric that matters most for migration is the Safe Rust vs Unsafe Rust ratio of the output. C relies on raw pointer manipulation with no direct Safe Rust equivalent. Basic transpilers emit unsafe blocks — compilable, but memory safety guarantees are bypassed. C2Rust produces 100% unsafe output. Research tools like Laertes and CRustS improve this ratio, but the only approach producing idiomatic Safe Rust at assessed production quality is Asari AI’s under TRACTOR.
Memory safety and logical correctness are separable. AI-translated Rust that passes the borrow checker is memory-safe regardless of logic errors — those are different problems requiring different mitigations.
What Is Available Right Now for Teams That Cannot Wait?
No commercial product currently delivers automated C/C++-to-Rust translation at production quality. Here’s what actually exists.
C2Rust is the most mature open-source option, maintained by Immunant and Galois. It parses C99 source and generates compilable Rust — but entirely unsafe Rust. Think of it as C expressed in Rust syntax. It’s a migration starting point, not a finished product. Post-C2Rust research tools like Laertes, Crown, and CRustS can improve the safe/unsafe ratio, but all are research-stage and require expertise to apply.
The proven production path is incremental manual migration with FFI interop — module by module, with Rust components linked into existing C++ builds using Corrosion for CMake integration. Meta used exactly this approach migrating a billion-user messaging library. It works. It’s slower than AI-assisted translation will eventually be, but it’s available today.
cargo-deny is the dependency governance tool to add when introducing new Rust — licence compliance, security advisories, supply chain policies.
The manual tooling is proven. The AI-assisted path that makes it cheaper is still being built.
When Will AI Translation Tooling Be Publicly Available — and What Will It Take to Trust It?
Here’s the plain timeline based on current evidence.
Microsoft CoreAI’s pipeline: internal research only, no public access, no announced product timeline. DARPA TRACTOR outputs: expected in 2026–2027. Commercial third-party AI translation products: likely in the 2027–2028 window as the market matures.
The 2026–2027 TRACTOR window is the most meaningful near-term signal. DARPA programmes typically produce publicly accessible outputs — Asari AI’s translated libraries are already available as reference implementations.
On trust: memory safety is mechanically verifiable via the borrow checker — AI-translated Rust that compiles without unsafe blocks is, by definition, memory-safe. Logical correctness requires test coverage and review, and the bar varies by context. A FinTech payment processor is not a logging utility.
One more thing worth knowing: regulatory pressure may force your timeline ahead of AI tooling availability. NSA and CISA have both urged organisations to shift to memory-safe languages. If you face procurement requirements tied to memory-safe code, your timeline is set by regulators, not by when Microsoft ships a tool.
For what the Microsoft announcement signals for the industry, see the pillar article in this series.
AI Translation vs Manual Migration: Timing, Risk, and the Decision Framework
This is not a binary choice — it’s a question of when.
Manual incremental migration with FFI is the proven, available path today. High control, high confidence, demonstrated at scale. AI-assisted translation is a future cost modifier on that same path — once the tooling exists for external use.
Four things to factor in:
Codebase size. Under roughly 500,000 lines, manual incremental migration is more economical than waiting. For larger legacy codebases, AI translation will make compelling economic sense — once available.
Risk tolerance. FinTech and HealthTech regulated codebases need higher verification confidence regardless of translation method. Use the CodeRabbit findings as a planning input for test coverage budget, not as a reason to rule out AI translation entirely.
Migration urgency. If you have a 2025 or 2026 compliance deadline, manual incremental migration is your only option. AI tooling is not here yet.
Available Rust expertise. Manual migration requires in-house Rust knowledge for writing and review. AI-assisted translation may lower the bar for generation, but you still need engineers who can verify output. Neither path eliminates the need for Rust on the team.
Start incremental manual migration now. Use FFI, Corrosion, and cargo-deny. Structure migrations in well-defined module boundaries — as Meta’s was — so they’re AI-tooling-compatible when that time comes. Waiting for AI translation to ship before starting anything is not a strategy.
For a complete migration planning framework covering how AI translation fits a full roadmap, see the dedicated article in this series.
Frequently Asked Questions
Can I use Microsoft’s AI translation pipeline for my own C++ codebase?
No. It’s an internal research project with no public access, no announced release date, and no third-party API as of late 2025. It is not a product.
What is the DARPA TRACTOR programme and when will it produce usable output?
TRACTOR (Translating All C To Rust) is a DARPA-funded programme for fully automated C-to-Rust translation with memory safety guarantees. Public outputs and tooling are expected in the 2026–2027 window. Asari AI has already demonstrated translation of four production C libraries with independent ESA-level verification.
How is AI-assisted translation different from asking ChatGPT to rewrite my code in Rust?
ChatGPT works on snippets without structural context. CoreAI builds an algorithmic graph of the entire codebase first, then uses AI agents guided by that graph — preserving dependency topology and ownership semantics. Research shows fewer than 20% of C programmes over 150 lines can be satisfactorily translated by LLM-only methods without manual intervention.
Can AI-generated Rust code be trusted for production use?
For memory safety, yes — the borrow checker provides a mechanical guarantee. For logical correctness, AI code produces demonstrably more defects (CodeRabbit: 1.7x more issues per PR, 75% more logic errors). Budget for increased review and testing. The bar for a payment processor is not the same as for a logging utility.
What is C2Rust and is it the same as Microsoft’s pipeline?
C2Rust converts C99 to compilable but entirely unsafe Rust. It’s a migration starting point, not a finished product, maintained by Immunant and Galois. Fundamentally different from Microsoft CoreAI’s research pipeline.
What is the “unsafe Rust” problem in automated translation and why does it matter?
C uses raw pointer manipulation with no direct Safe Rust equivalent. Basic transpilers emit unsafe blocks — compilable, but memory safety guarantees are bypassed. Lifting that unsafe code to Safe Rust requires inferring ownership and lifetime semantics that C does not express.
What does “idiomatic Rust” mean and why does it matter for migration output?
Idiomatic Rust uses language-native constructs — enums, Option/Result types, iterators, pattern matching — rather than C-style patterns transliterated directly. Code that is safe but not idiomatic is harder to maintain and review. Idiomaticity is a real quality bar, not a cosmetic one.
What will AI translation tooling cost when it becomes available?
The only public data: Asari AI translated libraries at $50–$500 each with independent verification. Commercial pricing for proprietary codebases doesn’t exist yet. Translation costs will likely be modest — the dominant cost will be verification and testing overhead.
Is it realistic to translate one million lines of code per engineer per month?
This is Galen Hunt’s stated North Star goal — a research direction-setter, not a demonstrated result. No current tool approaches this throughput.
What open-source tools exist today for incrementally migrating C++ to Rust?
C2Rust (unsafe transpiler, actively maintained), Laertes, Crown, CRustS, and C2SaferRust (research-stage safety-lifting tools), Corrosion (CMake/C++ build integration), and cargo-deny (dependency governance). None replace human judgement — they reduce the mechanical workload.
What is the difference between “AI-assisted translation” and “AI-assisted coding” tools like Copilot?
Copilot is a productivity multiplier for individual developers. AI-assisted translation operates at the whole-codebase level, using algorithmic structural models to guide modifications at scale. The intelligence in CoreAI is in the graph architecture, not in completing a developer’s next line.
When should you start planning for AI translation rather than manual migration?
Under approximately 500,000 lines, manual incremental migration with FFI is more economical now. For larger codebases with timelines extending beyond 2027, building AI translation into the planning model makes sense — structure migrations in well-defined module boundaries and the option stays open when tooling arrives.
