---
title: 'In the News: September 20, 2026 (Morning)'
description: 'GitHub rewrote the Copilot agent runtime into 832,378 lines of Rust using its own agents, for about $120,000 in tokens and three weeks of one developer.'
canonical_url: 'https://darkfactory.dev/news/2026-09-20-morning'
markdown_url: 'https://darkfactory.dev/news/2026-09-20-morning.md'
collection: news
date_published: '2026-09-20T07:25:00-04:00'
date_modified: '2026-09-20T07:25:00-04:00'
---

# In the News: September 20, 2026 (Morning)


GitHub has published the full accounting of a rewrite it says was not
affordable before agents: the Copilot agent runtime, ported from TypeScript
to 832,378 lines of production Rust, for roughly $120,000 in tokens and about
three weeks of one developer's time. Spotify published its own numbers the
same day, reporting that merged changes more than doubled year over year
without a matching rise in rework, and that what ran short at Spotify was
verification rather than code quality. A third piece sets out an orchestration
loop and a taxonomy of checks that pass without checking anything, with no
measurements behind either.

## 1. GitHub ported the Copilot agent runtime to Rust with agents, and published the bill

**[Migrating the GitHub Copilot runtime to Rust, using Copilot](https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)** · Stephen Toub, GitHub · The GitHub Blog, September 16, 2026

Toub reports that roughly 430,000 lines of production TypeScript passed
through the port, and that by August 21 the runtime stood at 832,378 lines of
production Rust plus 468,689 lines of Rust unit tests. It was done in place on
the main branch rather than in a long-lived branch: 128 port pull requests,
each replacing a TypeScript component with a shim calling Rust and deleting
the old code in one change, shipped across 135 releases in about fourteen and
a half weeks. His token spend was about 136.3 billion tokens for a bill of
about $120,000. The developer time is an estimate rather than a measurement,
derived from the port accounting for about 20 percent of his pull requests
over the window.

The session logs are instrumented and he publishes them: 12,760,995 events,
and 1,130,921 tool calls, 61 percent of the total, issued by subagents rather
than the main session. Of roughly 2,600 messages he typed himself, he had
Copilot classify the intent, and 31.0 percent were review, testing and CI,
17.4 percent were challenges to a technical or design decision. Dozens of
regressions were traced and fixed, sorted into recurring shapes that include
TypeScript's single number type being guessed wrong in Rust, ambient Node
behavior that the porting agent could not see, and paired operations where
only one half was ported. On whether the compiler caught them: "every
regression in the corpus was merged to main, which means it successfully
compiled." Against that, the share of issues in the public copilot-cli
repository carrying a bug label or a failure term barely moved, 22.9 percent
in January to April against 23.7 percent in May to August.

**Why it matters:** The operating rule Toub draws out is about custody of the
test, not about Rust. Agents that can edit the implementation must not also be
able to weaken the thing that says the implementation is correct, which he
states as protecting the oracle from the agent. He backs it with his own
count: with one exception, every regression that involved a missing feature
came down to insufficient end-to-end tests, and one port deleted the
end-to-end test covering the callbacks it dropped. The cost line is the other
usable number here. A migration priced at one developer-quarter plus $120,000
sits in a different approval bracket than one priced at a team-year, and that
is the change he is actually claiming.

## 2. Spotify looked for an AI quality signature in its own incidents and did not find one

**[AI Changed How Spotify Builds. What We Learned (and Fixed) About Quality at Higher Velocity](https://engineering.atspotify.com/2026/9/ai-changed-how-spotify-builds-what-we-learned-and-fixed-about-quality-at-higher-velocity)** · Tyson Singer, Head of Technology and Platforms, SVP, Spotify · Spotify Engineering, September 16, 2026

Spotify says it added two questions to its monthly major-incident
retrospective during its AI ramp-up: whether AI-authored code contributed
directly, and whether the increased volume of change pressured review,
testing, rollout or observability. Across the incidents reviewed it reports no
AI-authored code as a material direct contributor. The second effect it does
report: the volume of change increased faster than some of its verification
controls could adapt. Merged changes more than doubled year over year in
August, from roughly 8,100 to 17,000, with quality and optimization work
rising from 27 percent of that mix to 31 percent and maintenance and
configuration falling from 31 percent to 25 percent. Singer's summary of the
whole exercise: "AI increased the capacity to produce change. The next
constraint became our ability to verify it."

Two things sit behind that headline. Spotify rebuilt its rework rate metric to
weigh the age of the code being changed, and sets its own flat result against
the industry-wide rise in code churn reported by FAROS. That comparison is
Spotify measuring against a metric it redefined and has not published the
definition of, so it is not like for like. Separately, code complexity and
pull request size are both creeping up, and Spotify declines to move the
thresholds, writing that "we are deliberately not rewriting the thresholds to
make ourselves feel better." The concrete failure it does name is an automated
dependency upgrade that passed every safety check and still broke production,
after which it expanded rollback capacity and began scheduling automated
changes inside the owning team's working hours.

**Why it matters:** If code churn is the number you watch for AI-induced
quality debt, Spotify is arguing that churn and rework answer different
questions and that the age-weighted one is the better proxy. The thresholds
point is the more transferable half. Complexity and diff-size limits were
calibrated for what one person could hold in their head, and a team that
quietly raises them because agents now produce larger units of work has
removed a signal rather than fixed one.

## 3. A verification taxonomy, attached to an orchestration pattern that is not new

**[Orchestrating Claude Code Agents: The Chief of Staff Pattern](https://asyncdot.com/blog/chief-of-staff-pattern-orchestrating-claude-code-sessions/)** · Asyncdot · September 19, 2026

The piece carries no personal byline. It describes one long-lived session that
assigns work, re-runs every command an executing session claims to have run,
and reads diffs rather than transcripts, while short-lived sessions do the
implementation and a durable external board holds the state. It is unusually
direct that the arrangement is old, naming orchestrator-worker,
coordinator-implementor-verifier, maker-checker and Git's integration manager
as the existing names. On its own label: "It is not an established term, and
you should not have to recognize it."

What is less widely written down is the middle section. It names one defect
class, an instrument that reports success for work it did not do, and
enumerates six shapes it takes: a vacuous assertion that passes whether or not
the feature works, a silent no-match where zero findings read as clean, an
errored check whose failure to run is swallowed, a wrong reference keyed on
the wrong window, a stale premise whose expected value was read off broken
code, and a scope mismatch where a green check over a subset is presented as
the whole. It also argues for running the verifier before implementing, so
that a check which was already green cannot be mistaken for a check that
passed. Nothing in the article is measured, and the two tools it recommends
are a session manager called cmux and a planning board the studio publishes
itself, with a pitch for the studio's fixed-price development work at the end.
Its Hacker News thread was at 23 points and 20 comments about five and a half
hours after posting, read at 11:15 UTC on September 20.

**Why it matters:** The six shapes are the part that survives the missing
measurements, because each one is a check you can go and test against a
harness you already run. The general defense it draws out is cheap and
specific: a count of zero and a failure to run have to be
distinguishable in your output, and a claim that
nothing bad was found needs a positive control in the same run, or the tool
that is broken and the tool that is clean produce the same result.