Daily Reading for 2026-09-07 - Learning in Public

Daily Reading for 2026-09-07

William Glaser
6 mins to read
daily-reading
Home / Daily Reading / Daily Reading for 2026-09-07

Daily Reading for 2026-09-07

OpenAI Research Acceleration

OpenAI has declared an RSI day for Recursive Self-Improvement — widely read as the arrival of their new AGI — and Simon Willison’s link blog frames what that means from the inside. The headline is an essay, “An Alien Mind”, by Chief Scientist Jakub Pachocki, which doesn’t even bother to expand the acronym. The practical angle for technical readers is how OpenAI’s own research team now works: 2026 was the year agentic engineering took off, and the piece includes details plus a chart of AI spend per researcher. The sharpest signal is the late-July acceleration in that spend — Willison’s guess is it coincides with internal access to the model later released as GPT-6 Astra.

Watch for:

  • OpenAI’s “An Alien Mind” essay and any concrete RSI/AGI timeline details it reveals
  • Whether other labs publish comparable agentic-engineering productivity data to OpenAI’s researcher-spend chart
  • The GPT-6 Astra rollout and whether early internal access explains the July acceleration

Wardley signals:

  • Components: Coding agents (agentic engineering), the underlying frontier models (the GPT-6 Astra lineage), and OpenAI’s internal research tooling.

  • Evolution stage: Coding agents are moving from Custom to Product — still a competitive differentiator for frontier labs rather than a commodity.

  • Doctrine: Illustrates “Exploit the landscape” and “There is no core” — the lab bends its whole research process around agentic leverage rather than protecting a fixed core.

  • Climatic patterns: “Efficiency enables innovation” and the componentisation effect — agentic tooling raises research efficiency, enabling faster iteration on the AGI itself.

  • Diffusion markers: Agentic engineering spread from a niche to the default research workflow inside OpenAI within roughly a year — a steep adoption curve.

  • Research acceleration: The view inside OpenAI

wardley-beta
%% 1. Users: OpenAI researchers and the broader frontier-AI research community
%% 2. Needs: faster research iteration, AI that helps improve AI (recursive self-improvement)
%% 3. Capabilities: agentic research workflows, automated experiment execution, frontier inference on demand
%% 4. Components: research coding agents, frontier models (GPT-6 Astra lineage), internal agent tooling, training infra, the RSI/AGI program
%% 5. Maturity: frontier LLMs are Product; coding agents are Product; agent tooling is Custom/Product; RSI/AGI is Genesis; training infra is Commodity
%% 6. Management: OpenAI research leadership and Chief Scientist; internal platform teams run the infra
anchor userNeed [0.95, 0.93]
component researchAgents [0.62, 0.68]
component frontierModels [0.74, 0.52]
component agentTooling [0.50, 0.40]
component rsiProgram [0.12, 0.26]
component trainingInfra [0.85, 0.16]
researchAgents -> userNeed
frontierModels -> researchAgents
agentTooling -> researchAgents
rsiProgram -> agentTooling
trainingInfra -> frontierModels

DNS Abuse and Scam Domains

A striking indictment of the Domain Name System’s abuse problem, via Terence Eden and an Interisle report surfaced by Andrew Campling. The numbers are bleak: 85 million new generic top-level domain registrations in 2025, and 8.5 million of them were already on blocklists by May. Eden argues a 10% abuse rate is the likely floor and the real figure is probably closer to 20% — roughly one in five newly registered gTLD domains is a scam. For technical readers this reframes DNS not as neutral infrastructure but as a heavily weaponised registration market, and it raises hard questions about why ICANN has debated the issue for years without material change.

Watch for:

  • ICANN policy action (or continued inaction) on gTLD registration abuse
  • Whether registrar-level controls or blocklist improvements move the ~20% abuse share
  • New abuse measurements for alternative TLDs and ccTLDs outside the Interisle sample

Wardley signals:

  • Components: Domain registration (the gTLD marketplace), abuse blocklists and reporting systems, and the DNS itself as public infrastructure.

  • Evolution stage: Domain registration is a mature Commodity (utility) — which is precisely why abuse can scale so cheaply.

  • Doctrine: “Effectiveness over efficiency” and “Manage failure” are violated — registries optimise registration volume while externalising scam risk onto users.

  • Climatic patterns: “Success breeds inertia” — ICANN’s past success with a permissive multi-TLD model is blocking the change abuse statistics now demand.

  • Diffusion markers: Scam operation has commoditised and industrialised (85M registrations at a ~20% abuse share) — a diffusion of criminal practice faster than any defensive standardisation.

  • The purpose of DNS is to spread scams

wardley-beta
%% 1. Users: internet users navigating the web, plus security teams defending them
%% 2. Needs: trustworthy domains; detect and block scam registrations fast
%% 3. Capabilities: domain registration governance, abuse detection and blocklisting, takedown response
%% 4. Components: gTLD domain registration, DNS infrastructure, abuse blocklists, scam operations, ICANN governance
%% 5. Maturity: DNS infra and domain registration are Commodity; scam operations are Commodity; blocklists are Product; ICANN governance is Custom
%% 6. Management: registries/registrars and ICANN set the rules; security community runs blocklists
anchor userNeed [0.95, 0.93]
component domainRegistration [0.80, 0.55]
component scamOperations [0.74, 0.42]
component abuseBlocklists [0.60, 0.30]
component dnsInfra [0.86, 0.20]
component icannGovernance [0.28, 0.16]
domainRegistration -> userNeed
dnsInfra -> domainRegistration
scamOperations -> domainRegistration
abuseBlocklists -> domainRegistration
icannGovernance -> domainRegistration

Technical Debt and Greenfield Rewrites

A sharp, field-tested take on the “burn it down and rewrite it” strategy, framed as a reply to a comment about overwhelming technical debt. Greenfield replacement rarely works, the author argues: the old system stays live as the core business, so it keeps changing and its developers lose incentive, while the ambitious new team discovers nobody fully understands the behaviour being replaced. Pressure to ship eventually produces a second system handling a subset of features — two systems instead of one, with real risk the replacement is quietly abandoned. The practical recommendation: shore up the legacy system with automated tests and attempt targeted refactors before reaching for the siren call of a rewrite, citing Will Larson’s “Migrations” essay.

Watch for:

  • Evidence for or against Will Larson’s “migrations” approach versus greenfield rewrites
  • Case studies of two-systems-in-production outcomes and abandoned replacements
  • Tooling advances that make incremental refactoring of legacy systems cheaper

Wardley signals:

  • Components: The legacy production system, the replacement system under development, automated testing/CI tooling, and the migration/refactoring practice itself.

  • Evolution stage: Automated testing and migration tooling sit at Product heading toward Commodity; the legacy core is Custom-built (bespoke, poorly documented) — the root of the problem.

  • Doctrine: Violates “Focus on the outcome” and “Know your users”; endorses “Manage inertia” and “Use appropriate methods” (migration over rewrite) instead.

  • Climatic patterns: “Inertia can kill an organisation” and “Success breeds inertia” — the legacy system’s stubborn operational success is what undermines the rewrite.

  • Diffusion markers: The two-systems anti-pattern is near-universal engineering folklore, but the migration/refactor counter-practice is only beginning to standardise, with Will Larson’s essay as a canonical reference.

  • There’s No Limit to How Bad Code Can Get

wardley-beta
%% 1. Users: engineering teams and organisations operating a legacy production system
%% 2. Needs: reduce technical debt and stay maintainable without breaking the running business
%% 3. Capabilities: incremental migration/refactoring, automated testing, safe change management
%% 4. Components: legacy production system, technical debt, migration/refactoring practice, automated testing, greenfield replacement
%% 5. Maturity: automated testing is Product/Commodity; migration practice is Product; legacy system is Custom; tech debt and greenfield replacement are Genesis/Custom
%% 6. Management: engineering teams and engineering leadership choose the migration strategy
anchor userNeed [0.95, 0.93]
component legacySystem [0.40, 0.64]
component techDebt [0.22, 0.46]
component migrationPractice [0.60, 0.36]
component automatedTesting [0.70, 0.24]
component replacementSystem [0.16, 0.32]
legacySystem -> userNeed
techDebt -> legacySystem
migrationPractice -> legacySystem
automatedTesting -> migrationPractice
replacementSystem -> legacySystem