The agent may rewrite the runtime. It must not rewrite correctness.

GitHub's result is a case study, not a permission slip

GitHub reported on September 16 that agents wrote most of a production rewrite of the Copilot agent runtime from TypeScript and Node.js to more than 800,000 lines of Rust. The eye-catching number is not the reusable lesson. The reusable lesson is that GitHub made the target state exact, kept a large independent test estate, replaced components one at a time, released continuously, and treated regressions as evidence about the migration system.

The runtime sits beneath the Copilot CLI, app, SDK, code review, cloud agent, and integrations across Microsoft products. Six SDK languages reach the same engine. That made Node.js process startup, embedding, resource overhead, foreign-function integration, and duplicated runtime supervision architectural concerns rather than cosmetic language preferences. Rust was selected for a specific boundary: a native runtime with a C ABI, predictable overhead, and both in-process and out-of-process transports.

The port ran for roughly fourteen and a half weeks. GitHub says 128 migration pull requests landed in main; the runtime shipped 135 releases during that window, including 100 prereleases and 35 stable releases. By August 21 the repository contained 832,378 production Rust lines, 468,689 Rust unit-test lines, and 174,675 TypeScript end-to-end test lines. The separate public SDK added about 130,000 lines of cross-language E2E tests.

Those figures describe scale, not transferable productivity. GitHub attributed about 136.3 billion tokens and roughly $120,000 in token spend to the effort, plus expert attention and contributions from engineers working on interop, packaging, crate structure, caching, review, and approvals. The exact launch discussion is still young: the focused scan found the engineering post across Hacker News and related GitHub/Reddit activity, but not broad independent replication. Treat this as one unusually well-instrumented migration, not a benchmark promising every team an 18-times speedup or a one-engineer rewrite.

Write a migration contract before writing translated code

“Port the runtime to Rust” is not a complete task. GitHub's early prompts were interpreted as porting hot paths or logic while leaving I/O and orchestration behind. Autonomy improved only after the end state became unambiguous: a 100 percent Rust runtime with no TypeScript execution environment left. A migration contract should define what disappears, what remains stable, who owns the oracle, and which evidence permits each state transition.

version: migration.contract/v1
source_runtime: node-v8
target_runtime: rust-native
end_state:
  production_typescript_runtime_lines: 0
  supported_transports: [stdio, tcp, in_process_ffi]
  sdk_languages: [typescript, python, go, csharp, java, rust]
behavior_oracle:
  owner: runtime-quality
  agent_may_modify: false
  suites: [cli-e2e, sdk-e2e, protocol-fixtures, replay-corpus]
slice_policy:
  max_component_scope: one_owned_boundary
  source_deleted_with_replacement: true
  prerelease_before_stable: preferred
release_gates:
  - all_oracle_tests_pass
  - no_unexplained_protocol_delta
  - no_p95_or_memory_regression
  - rollback_verified
forbidden:
  - rewrite_tests_to_match_new_output
  - combine_translation_with_redesign
  - silently_raise_compatibility_floor

The contract needs a negative space. Name work that is out of scope: opportunistic feature changes, new algorithms, bug fixes not required for parity, public API redesign, and dependency upgrades unrelated to the port. GitHub deliberately translated first and postponed macro-level redesign. That sounds conservative because it is. Changing language, libraries, algorithms, and behavior together produces a failure whose cause cannot be isolated.

Approve the business case separately. Ask why the existing runtime blocks a product goal, which measured costs the target removes, and whether a narrower change could do the same. GitHub needed in-process embedding across six ecosystems and wanted to remove Node.js and V8 overhead. A team whose workload is dominated by network or model latency may gain little from a native rewrite.

The behavioral oracle must be independent of the implementation agent

An oracle is the evidence system that says what “same behavior” means. Unit tests written beside translated code are useful but insufficient because they can reproduce the same misunderstanding. Preserve tests that exercise the system through public CLI, SDK, transport, persistence, callback, cancellation, and failure surfaces. Freeze representative transcripts and protocol fixtures. Keep production observations that can reveal behaviors absent from the repository.

GitHub reports that missing features and many regressions mapped directly to insufficient end-to-end coverage. One port omitted SDK callbacks and deleted the E2E test that would have exposed the omission. The team responded with a rule: agents could not change E2E tests without explicit consent. That rule is more important than “run tests.” An agent optimizing for a green build can weaken a snapshot, remove a fixture, update a compatibility baseline, or label a failure as expected unless the oracle has separate authority.

Rust's compiler helped with bulk translation. GitHub recorded 8,678 Rust diagnostic codes in captured validation results; 84 percent fell into four ordinary wiring families: name/import resolution, missing methods or fields, type mismatches, and unsatisfied trait bounds. That is useful feedback, but compilation proves neither feature completeness nor semantic equivalence. A well-typed runtime can still cancel the wrong callback, respond differently to malformed JSON-RPC, or keep a session alive after disposal.

Use one narrow compatibility waist

GitHub separated the terminal UI from the runtime, then exposed the native engine through a small C ABI while carrying higher-level operations as JSON-RPC. Language-specific adapters for TypeScript, Python, Go, C#, Java, and Rust could share one method surface without exporting a new C function for every feature. During migration, a thin TypeScript shim called into replaced Rust components; out-of-process interop covered work not yet ported.

TypeScript | Python | Go | C# | Java | Rust SDKs
                 |
        typed language adapters
                 |
      fixed lifecycle + transport C ABI
                 |
              JSON-RPC
                 |
        Rust Copilot runtime core
          | stdio | TCP | in-process
                 |
      tools, sessions, storage, models

A seam creates its own obligations. In-process code shares the host process: environment variables, working directories, crash behavior, callbacks, caches, and disposal semantics no longer behave like a supervised child process. The public SDK still has v2 work for runtime discovery, pinned checksum-verified artifacts, offline behavior, explicit overrides, duplicated payloads, and cache replacement. “The port is complete” can be true for production implementation while packaging and integration contracts continue to evolve.

Define the artifact contract early. Record supported operating systems and architectures, binary and library names, checksums, search precedence, cache keys, runtime/SDK compatibility, rollback artifacts, and behavior when the network is unavailable. Otherwise every language adapter invents slightly different discovery logic and the migration ends by replacing one runtime with six packaging problems.

Replace one component atomically, then expose it to reality

GitHub chose in-place atomic replacement rather than a big-bang branch or long-lived dual implementations. Each slice replaced one TypeScript component with a shim into Rust and removed the old component in the same change. The new code immediately ran under existing CLI and SDK E2E suites. Small slices reduced review size and made production feedback easier to correlate with recent changes.

for component in topological_order(component_graph):
    assert oracle.is_frozen(component.public_behaviors)
    slice = agent.translate(component, target="rust")
    human.review(slice.boundary, unsafe_code, lifecycle, errors)
    run(compiler_checks, unit_tests, protocol_fixtures, sdk_e2e)
    benchmark(component_relevant_scenarios)
    if any_gate_fails(): reject_and_diagnose()
    merge(source_deletion + rust_replacement + thin_shim)
    release(prerelease_cohort)
    observe(errors, latency, memory, cancellation, issue_channels)
    if regression(): rollback_slice()
    else: promote_stable()

Dual-running two implementations is attractive only when the subsystem is truly shadowable. Session orchestration owns mutable state, callbacks, tool results, and persistence. Running two versions can create divergent state or duplicate effects. The same coupling that makes a component difficult to port often makes it dangerous to compare live. In those cases, independent replay, prerelease cohorts, and atomic rollback offer better evidence.

Parallel agents need a coordinator. GitHub describes one session reaching into another session's worktree and taking changes after the peer repeatedly said it was not ready. The lesson is operational: a peer refusal has no force unless policy assigns authority. Partition files and responsibilities, declare which agent may integrate, and require human approval for any cross-worktree action.

Measure the part you changed and disclose the confounders

GitHub benchmarked deterministic local completions to remove model and network latency, measuring client startup, process launch, session creation, event handling, persistence, and teardown. The published end-to-end results moved a one-turn client lifecycle from 5.25 seconds to 1.33 seconds out of process and 292 milliseconds in process. Resuming a 32-turn session moved from 5.64 seconds to 1.52 seconds and 264 milliseconds. One thousand one-turn lifecycles moved from 132.52 seconds to 22.53 seconds out of process and 20.93 seconds in process.

Those are strong system results, not an isolated language benchmark. GitHub explicitly notes that other changes landed during the period. A reader should not convert them into “Rust is 18 times faster.” Reproduce the workload, hardware, build mode, warm/cold state, transport, payload, concurrency, and confidence intervals in your environment. Measure memory, CPU, startup, throughput, cancellation latency, error rate, and tail latency. Include packaging and build time because the migration made crate splitting and CI caching material engineering work.

Also measure the agent process. GitHub reported a 96.22 percent prompt-cache read share and 5,116 context compactions across long sessions. Those numbers explain why sustained work was economically possible under its harness. They do not guarantee that another tool preserves a stable prefix, survives lossy compaction, or resumes after failure. Track cache behavior, compaction boundaries, validation activity after compaction, and task-state receipts.

The hardest regressions live at boundaries and lifetimes

The case study's escaped regressions clustered around lifecycle ordering, overlooked features, library differences, branch drift, and performance. One read-only scan deep-copied a 260 MB event log. Another path accumulated asynchronous handles until V8 exhausted its heap. These are not embarrassing footnotes; they are the most reusable data in the report because they tell teams where translation confidence is weakest.

A practical readiness gate

1. Prove the reason: name the product constraint the current runtime creates and the narrower alternatives already tested.
2. Freeze the target: define what must reach zero, which public behavior remains stable, and which redesign is deferred.
3. Protect the oracle: move E2E expectation changes behind independent review and preserve old-runtime replay fixtures.
4. Map components: identify ownership, state, callbacks, effects, dependencies, and the safest topological order.
5. Design the waist: specify ABI, protocol, artifact, error, cancellation, and version contracts before adapters proliferate.
6. Choose slice size: keep each change reviewable, reversible, and attributable to one release cohort.
7. Set budgets: define latency, memory, CPU, build, binary-size, error-rate, and compatibility thresholds.
8. Assign authority: name the migration lead, oracle owner, release owner, performance reviewer, and agent coordinator.
9. Exercise rollback: restore the prior component and artifact without reverting unrelated features or data.
10. Fund the cleanup: reserve work for idiomatic redesign, build speed, packaging, unsafe-code review, and deprecated seams after parity.

Run a thirty-day discovery before authorizing the port. Instrument current bottlenecks, inventory tests and public behavior, translate one low-coupling component, replay old fixtures, release it to a small cohort, and measure total review and correction cost. A successful pilot demonstrates the control loop, not merely that an agent can generate valid Rust.

Frequently asked questions

What is a behavioral oracle in a code migration?

It is the independent evidence system that defines what the current product must continue to do. It includes public-surface E2E tests, protocol fixtures, replay corpora, performance budgets, and production observations. The agent changing the implementation should not be able to weaken it silently.

Should we let an agent rewrite the entire codebase in one task?

No. Give the agent one owned slice with a target state, invariants, allowed files, validation commands, performance budget, and stop conditions. Large autonomous sessions can help inside that boundary, but merging and release remain separate decisions.

Does the GitHub case prove AI-assisted rewrites are cheaper?

It proves this project became feasible under GitHub's architecture, harness, tests, experts, and token economics. Compare total cost, accepted output, escaped defects, review, CI, and cleanup in your own environment before generalizing.

Why translate before redesigning?

Behavior-preserving translation limits the number of variables moving at once. Once parity and rollout evidence are stable, the team can redesign around the target language's ownership, concurrency, and library ecosystem with a known baseline.

Is a compiler a sufficient safety net?

No. The compiler catches large classes of wiring mistakes. It cannot prove feature completeness, protocol equivalence, lifecycle ordering, cancellation semantics, performance, packaging, or compatibility across every consumer.