Daily Reading for 2026-09-11

AI-Assisted Phishing and Social Engineering

Threat actors are weaponizing AI in phishing on two fronts: as a tool and as a theme. Microsoft observed a campaign that used generative-AI-crafted email templates to impersonate CEOs and fabricated invoices, pushing a nearly $50,000 ACH payment to accounts-payable teams across more than a million emails in three days. Separately, attackers are borrowing the trust of AI brands — ChatGPT, Copilot, Claude, DeepSeek — to run credential-phishing, malvertising, and stealer-delivery campaigns, including a ChatGPT-themed kit harvesting credit cards and a Claude-themed AiTM flow. For defenders the throughline is that AI lowers the cost and raises the believability of social engineering, and AI-brand lures now carry the same urgency shoppers once reserved for invoices and shipping notices.

Watch for:

• New AI product or model launches being immediately impersonated in brand-themed lures
• Adversary-in-the-middle and device-code flows layered onto AI-brand pretexts
• Gen-AI-crafted BEC and invoice-fraud templates targeting finance and accounts-payable
• Malvertising and fake AI installers distributing stealers, often via initial-access brokers

Wardley signals:

• Components: ChatGPT, Copilot, Claude, DeepSeek (AI brands as trust vectors); generative AI for email templating; AiTM phishing kits; stealer malware (Vidar); initial-access brokers (Storm-3075); Microsoft Defender detection tooling

• Evolution stage: Gen-AI phishing templates — Product moving toward Commodity as weaponization is industrialized via brokers; AiTM phishing kits — Product; AI-brand impersonation — Product; Defender’s AI threat detection — Product

• Doctrine: “Listen to your ecosystem” (Microsoft tracks adversary reuse of its own AI products); “Bias towards data”; “Use appropriate tools”; “A bias towards open” (research disclosure to harden the ecosystem)

• Climatic patterns: “Efficiency enables innovation” — cheap AI lowers the cost of social-engineering production; “Components can co-evolve” (AI product cycles and phishing kits move together); “Creative destruction” reshapes the attack economy

• Diffusion markers: Copy-cat campaigns spanning multiple AI brands within days; commoditization as Storm-3075 brokers AI-themed payloads to downstream actors; ecosystem moves toward AI-brand-themed lure kits

• Protecting organizations from AI-assisted executive impersonation and invoice fraud

• Detect and disrupt AI-themed attacks with Microsoft Defender

wardley-beta
%% Q1 users: security teams / defenders
%% Q2 needs: detect and disrupt AI-powered phishing and social-engineering campaigns
%% Q3 capabilities: campaign detection, threat intelligence, AI-signal triage
%% Q4 components: the phishing campaign, attacker generative AI, AI-brand lures, invoice fraud, phishing kits, defender detection
%% Q5 maturity: attackerGenAI Custom->Product; phishingKit Product; defenderDetection Product
%% Q6 managed by: Microsoft Defender and enterprise SOCs
anchor defenderNeed [0.95, 0.93]
component campaign [0.55, 0.60]
component attackerGenAI [0.35, 0.50]
component aiBrandLure [0.42, 0.55]
component invoiceFraud [0.45, 0.50]
component phishingKit [0.60, 0.38]
component defenderDetection [0.75, 0.68]
campaign -> defenderNeed
attackerGenAI -> campaign
aiBrandLure -> campaign
invoiceFraud -> campaign
phishingKit -> aiBrandLure
defenderDetection -> defenderNeed

Threat Modeling Diagram Style

Adam Shostack’s Threat Model Thursday examines what makes a threat-modeling diagram good and useful, drawing on the new edition of his Threat Modeling book. The post separates readability from style from rules: readable diagrams align with how people read, keep lines short, and label the unusual; calm, styled diagrams fan in and out around a central system, use a grid and straight lines, and avoid crossings; and rigorous diagrams use unique labels, explicitly show trust boundaries, and let only data flows cross them. The value proposition is that a diagram is only worth building if it can be understood and then used to ask or answer questions about the system being modeled — otherwise the effort to read it outweighs its payoff.

Watch for:

• The expanded diagram-guidance chapter landing in the new edition of Threat Modeling
• Adoption of readability and style rules in training and team diagram reviews
• Tooling that enforces alignment, unique labels, and explicit boundaries

Wardley signals:

• Components: Threat-modeling diagrams; the Threat Modeling book and its new edition; diagram notation and tooling; training practice

• Evolution stage: Threat-modeling practice — Product (established method with growing guidance); diagram notation and tooling — Product moving toward Commodity as conventions standardize

• Doctrine: “Set exceptional standards”; “Use appropriate methods”; “Common Language” (a shared diagram vocabulary); “Understand what is being considered”

• Climatic patterns: “Components can co-evolve” — the practice of diagramming evolves alongside the tooling and the book’s guidance; “Evolution consists of multiple waves of diffusion”

• Diffusion markers: Guidance propagating through training and a new book edition; standardization of readability/style/rule conventions across teams

• Diagram Style (Threat Model Thursday)

wardley-beta
%% Q1 users: threat-modeling practitioners and their teams
%% Q2 needs: produce a diagram that is readable, calm, and usable for asking questions
%% Q3 capabilities: diagram design, readability/style rules, notation, tooling
%% Q4 components: the diagram, readability, style rules, notation, tooling, guidance
%% Q5 maturity: readability/style Product; notation Product->Commodity; tooling Product
%% Q6 managed by: practitioners, guided by the Threat Modeling book and training
anchor modelerNeed [0.95, 0.93]
component diagram [0.60, 0.68]
component readability [0.68, 0.50]
component styleRules [0.55, 0.50]
component notation [0.65, 0.38]
component tooling [0.78, 0.35]
component guidance [0.45, 0.55]
diagram -> modelerNeed
readability -> diagram
styleRules -> diagram
notation -> readability
tooling -> notation
guidance -> notation

China AI Model Distillation Advisory

The NSA, CISA, and FBI issued a joint advisory warning that China-based AI companies — DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun, and Z.AI — are running industrial-scale knowledge-distillation campaigns that extract proprietary capabilities from U.S. frontier AI models such as Claude, GPT, Gemini, and Grok. Since at least late 2024 they have pulled billions of tokens across millions of requests, using native APIs, cloud providers, third-party aggregators, and a gray market of proxy “transfer stations” to bypass geographic restrictions, evade safeguards, and breach terms of use. The agencies frame distillation as the core of these firms’ AI strategy rather than a supplement, and recommend mitigations to reduce the impact of these aggressive, targeted extraction activities.

Watch for:

• Follow-on mitigations and technical guidance from the authoring agencies
• Frontier-provider API and terms-of-service tightening in response
• Disruption or enforcement against aggregators and gray-market proxies
• Whether distillation-driven model gains show up in benchmark releases

Wardley signals:

• Components: U.S. frontier AI models (Claude, GPT, Gemini, Grok); knowledge-distillation techniques; API access, third-party aggregators, and proxy “transfer stations”; terms-of-service and access controls

• Evolution stage: Distillation as a practice — Product rapidly industrializing into Commodity-like mass extraction; frontier models — Product; access-enforcement tooling — Product

• Doctrine: “Exploit the landscape”; “There is no core”; “Listen to your ecosystem” applied adversarially; “Understand what is being considered”

• Climatic patterns: “Everything evolves through supply and demand competition”; “Competitors’ actions will change the game”; industrial policy and access constraint as accelerators/de-accelerators

• Diffusion markers: Knowledge spreading at industrial scale without consent; aggregator and proxy markets standardizing bulk extraction; campaign techniques diffusing across multiple Chinese firms

• 🚩 NSA, CISA, and FBI Warn of Industrial-Scale Distillation Campaigns Targeting U.S. Frontier AI Models

wardley-beta
%% Q1 users: U.S. frontier AI providers and the agencies protecting them
%% Q2 needs: protect proprietary model capabilities from industrial-scale distillation
%% Q3 capabilities: access control, terms-of-service enforcement, threat intelligence
%% Q4 components: frontier models, distillation practice, extraction pathways, Chinese AI firms, access controls, joint advisory
%% Q5 maturity: frontierModels Product; distillation Custom->Product (industrializing); accessControls Product
%% Q6 managed by: U.S. AI companies, with NSA/CISA/FBI joint advisory as oversight
anchor usProviderNeed [0.95, 0.93]
component frontierModels [0.80, 0.68]
component distillation [0.50, 0.55]
component extractionPathways [0.60, 0.40]
component chineseAI [0.40, 0.60]
component accessControls [0.62, 0.35]
component jointAdvisory [0.55, 0.50]
frontierModels -> usProviderNeed
distillation -> frontierModels
chineseAI -> distillation
extractionPathways -> distillation
accessControls -> extractionPathways
jointAdvisory -> accessControls

Passkey-Themed Social Engineering and Cloud Compromise

Microsoft Security Research is tracking cloud intrusions that begin with passkey-themed social engineering and end in Microsoft 365 identity persistence and cloud data theft. Attackers call or message users pretending to be IT help desk, using an urgent passkey, MFA, or SSO update as a pretext to steer them through adversary-in-the-middle (AiTM) phishing or device-code authorization flows. From there they add their own authentication methods for persistence, run reconnaissance across Microsoft Graph, and pull data from SharePoint, OneDrive, and Exchange — activity observed since May 2026. Microsoft notes the recurring sequence of identity compromise, persistence, reconnaissance, and exfiltration is a more durable investigation signature than fast-changing domains and IPs, and advises defenders to chase it across identity, Graph, and cloud storage signals.

Watch for:

• Passkey, MFA, and SSO-themed AiTM and device-code lures aimed at identity teams
• Unauthorized authentication methods and MFA persistence added after sign-in
• High-volume Microsoft Graph, SharePoint, and OneDrive collection activity
• Sequence-based detection linking identity compromise to cloud exfiltration

Wardley signals:

• Components: Passkey/MFA/SSO infrastructure; AiTM phishing kits and device-code flows; Microsoft Graph; SharePoint, OneDrive, and Exchange; identity and cloud security tooling

• Evolution stage: AiTM phishing kits — Product; passkeys as an authentication standard — Product moving toward Commodity as adoption grows; identity-threat detection — Product

• Doctrine: “Know your users” and “Focus on user needs” turned adversarial (attacking the identity user journey); “Use standards” (passkeys becoming a standard that is being weaponized); “Bias towards data”

• Climatic patterns: “Components can co-evolve” — new authentication flows and the attacks against them evolve together; adoption cycles with chasms as passkey usage spreads

• Diffusion markers: Phishing kits adopting passkey/SSO pretexts; identity-centric compromise patterns spreading across cloud tenants; recurring sequence observed since May 2026

• 🚩 Passkey-Themed Social Engineering Leads to Microsoft 365 Identity Persistence and Cloud Data Theft

wardley-beta
%% Q1 users: cloud tenants and their identity/security teams
%% Q2 needs: stop passkey-themed social engineering from ending in identity persistence and cloud data theft
%% Q3 capabilities: identity monitoring, session revocation, Graph/SharePoint anomaly detection
%% Q4 components: passkey lure, AiTM kit, device-code flow, identity persistence, cloud data, identity signals
%% Q5 maturity: aiTmKit Product; deviceCodeFlow Product; identitySignals Product->Commodity
%% Q6 managed by: Microsoft Security Research and tenant defenders
anchor tenantNeed [0.95, 0.93]
component passkeyLure [0.40, 0.55]
component aiTmKit [0.55, 0.40]
component deviceCodeFlow [0.50, 0.42]
component identityPersistence [0.60, 0.35]
component cloudData [0.70, 0.60]
component identitySignals [0.72, 0.50]
passkeyLure -> tenantNeed
aiTmKit -> passkeyLure
deviceCodeFlow -> passkeyLure
identityPersistence -> aiTmKit
cloudData -> identityPersistence
identitySignals -> cloudData

N-able N-central RCE Vulnerabilities

Huntress reports an actively exploited zero-day in N-able’s N-central, CVE-2026-86218, a pre-authentication remote code execution vulnerability rated CVSS 10.0 — the maximum score and higher than two earlier N-central CVEs published the prior day. It allows unauthenticated access to the N-central server, and N-able has confirmed it was observed being exploited in the wild; a fourth hotfix, 2026.3 HF4, supersedes HF3 and is required for on-premises instances, while hosted instances were patched automatically. For managed service providers this is an urgent patching event: the vulnerability sits in a remote-monitoring-and-management product whose compromise can cascade across every managed endpoint, and exploitation-in-the-wild makes unpatched N-central servers a race.

Watch for:

• Uptake of N-central 2026.3 HF4 across on-premises MSP deployments
• Public exploit disclosure or expansion of the in-the-wild activity
• Additional related CVEs following the two released on 9/5
• Guidance or compromises surfacing across the managed-endpoint base

Wardley signals:

• Components: N-able N-central (RMM); pre-auth RCE exploit; 2026.3 HF4 hotfix; MSP-managed endpoints; Discord/MSP community channels

• Evolution stage: RMM tooling — Product (mature, widely deployed); exploit chains for RMM — Product; the zero-day disclosure and hotfix flow — Commodity-style operational response

• Doctrine: “Manage failure”; “Set exceptional standards”; “Know the details”; the vendor’s rapid disclosure illustrates “Do better with less”

• Climatic patterns: “Success breeds inertia” — the risk of unpatched, widely-deployed RMM; “Increased stability of lower order systems increases agility” is broken when a pre-auth hole sits under everything

• Diffusion markers: Exploitation in the wild within days of disclosure; fast knowledge spread through MSPGeek, Discord, and community channels; rapid patch guidance propagating across the MSP ecosystem

• 🚩 Actively Exploited Critical N-able N-central Vulnerabilities Allow Unauthenticated Remote Code Execution Across Managed Endpoints

wardley-beta
%% Q1 users: managed service providers and their customers
%% Q2 needs: keep N-central servers and managed endpoints secure against a pre-auth RCE
%% Q3 capabilities: patch management, incident response, exploit awareness
%% Q4 components: N-central RMM, pre-auth RCE, exploit-in-wild, hotfix, patch ops, managed endpoints
%% Q5 maturity: ncentralRMM Product; preAuthRCE Product; hotfix Commodity (rapid response)
%% Q6 managed by: MSPs, with N-able releasing hotfix HF4 and community channels tracking
anchor mspNeed [0.95, 0.93]
component managedEndpoints [0.80, 0.70]
component ncentralRMM [0.70, 0.60]
component preAuthRCE [0.45, 0.50]
component exploitInWild [0.50, 0.45]
component hotfix [0.60, 0.40]
component patchOps [0.65, 0.35]
managedEndpoints -> mspNeed
ncentralRMM -> managedEndpoints
preAuthRCE -> ncentralRMM
exploitInWild -> preAuthRCE
hotfix -> ncentralRMM
patchOps -> hotfix

Help Desk Vishing

This Security Risk Advisors threat brief (TB20260910) covers help-desk vishing: a social-engineering attack in which callers impersonate an organization’s IT help desk by phone to trick employees into disclosing credentials, approving multifactor-authentication changes, or granting remote access. The article body was unavailable (the source is a PDF that could not be text-extracted), so this summary is derived from the title and the feed. The brief belongs to SRA’s recurring threat-brief series, which tracks active social-engineering and phishing tactics that defenders should expect to see. Help-desk vishing is notable because it targets the human help-desk process itself — the exact channel users are trained to trust — making credential and MFA-reset lures especially effective.

Watch for:

• Voice-based vishing lures impersonating help desks to harvest credentials or reset MFA
• Vishing combined with SMS or email follow-ups to reinforce the fake help-desk pretext
• Updates to the SRA threat-brief series on related social-engineering tactics

Wardley signals:

• Components: Help-desk vishing; voice phishing (vishing) tooling; credentials and MFA/SSO systems; IT help-desk processes; the SRA threat-brief series

• Evolution stage: Vishing as an attack — Product with commoditized call tooling; social engineering generally — Product; help-desk authentication processes — Product moving toward Commodity

• Doctrine: “Bias towards data” (threat briefs grounded in observed incidents); “Use appropriate methods” (targeting a trusted user channel); “Know your users” turned adversarial

• Climatic patterns: None clearly apply from the limited available content

• Diffusion markers: Recurring entries in the threat-brief series suggest standardized vishing playbooks spreading across attackers; help-desk social engineering as a growing tactic

• TB20260910 – Help Desk Vishing

wardley-beta
%% Q1 users: employees and the organizations defending them
%% Q2 needs: recognize and resist help-desk vishing before credentials or MFA are lost
%% Q3 capabilities: caller verification, credential/MFA protection, awareness training
%% Q4 components: vishing call, help-desk impersonation, credential harvest, MFA reset, awareness training
%% Q5 maturity: vishingCall Product; helpDeskImpersonation Product; awarenessTraining Product
%% Q6 managed by: security teams and the SRA threat-brief series
anchor employeeNeed [0.95, 0.93]
component vishingCall [0.45, 0.55]
component helpDeskImpersonation [0.50, 0.50]
component credentialHarvest [0.60, 0.40]
component mfaReset [0.55, 0.45]
component awarenessTraining [0.70, 0.50]
vishingCall -> employeeNeed
helpDeskImpersonation -> vishingCall
credentialHarvest -> vishingCall
mfaReset -> credentialHarvest
awarenessTraining -> employeeNeed

Datacenter Power Constraints

This SemiAnalysis deep-dive opens a series on why behind-the-meter (BTM) power for datacenters is so hard, exploring the generation, interconnection, and grid constraints that make on-site or co-located power supply far more complex than it appears. The article body was unavailable (the Substack post is paywalled and could not be text-extracted), so this summary is derived from the title and the feed. The throughline is that AI’s compute buildout has made power the binding constraint on datacenter growth, pushing operators beyond the grid toward behind-the-meter generation — only to collide with equipment, fuel, permitting, and interconnection realities. For technical readers the question is not just how much power AI needs, but how reliably that power can be delivered at the point of consumption.

Watch for:

• Buildout and interconnection backlog for behind-the-meter generation
• Grid and regulatory constraints shaping datacenter power procurement
• Hyperscaler strategies for on-site or co-located power supply
• The rest of the SemiAnalysis series on BTM power economics

Wardley signals:

• Components: Datacenters; behind-the-meter generation (solar, gas, nuclear, storage); grid interconnection and transmission; power procurement; AI compute demand

• Evolution stage: BTM power — Genesis/Custom (early, uncertain, per-site bespoke); AI compute capacity — Product under intense demand; grid/transmission — Commodity infrastructure under strain

• Doctrine: “Exploit the landscape”; “Focus on the outcome”; “Know the details”; “Use appropriate tools” for each site’s power mix

• Climatic patterns: “Evolution to higher order systems results in increasing local order and energy consumption”; “Higher order systems create new sources of value”; Jevon’s Paradox — efficiency gains feed growing power appetite

• Diffusion markers: AI buildout driving power demand across the industry; BTM generation strategies spreading among hyperscalers; power increasingly named as the constraint

• What is So Hard About Behind-The-Meter Power For Datacenters? Part 1

wardley-beta
%% Q1 users: hyperscalers and datacenter operators
%% Q2 needs: secure reliable power to sustain AI compute growth
%% Q3 capabilities: power procurement, behind-the-meter generation, grid interconnection
%% Q4 components: AI compute, datacenter, behind-meter power, power generation, grid interconnect, procurement
%% Q5 maturity: aiCompute Product; behindMeterPower Genesis->Custom; gridInterconnect Commodity under strain
%% Q6 managed by: hyperscalers and utilities, shaping BTM generation buildouts
anchor operatorNeed [0.95, 0.93]
component aiCompute [0.75, 0.70]
component datacenter [0.65, 0.60]
component behindMeterPower [0.45, 0.50]
component powerGeneration [0.50, 0.45]
component gridInterconnect [0.60, 0.40]
component procurement [0.55, 0.35]
aiCompute -> operatorNeed
datacenter -> aiCompute
behindMeterPower -> datacenter
powerGeneration -> behindMeterPower
gridInterconnect -> behindMeterPower
procurement -> powerGeneration

Datasette Security Releases

Simon Willison released two Datasette security patch versions, 1.0a39 and 0.65.4, covering the current alpha series and the stable 0.65.x family. The fixes address issues found during an extensive audit he and Alex Garcia ran using frontier models — Claude Fable 5.1, GPT-5.6, and GPT-6 Astra — after bugs were reported by Sevban Dönmez. The most important detail is the workflow: the two humans split the work so one wrote automated tests exposing each issue while the other implemented the fix, giving every problem two independent human eyes on top of the coding agents. Willison says they will fold frontier-model security audits into all Datasette development going forward, making this release as notable for its process as for its patches.

Watch for:

• Adoption of 1.0a39 and 0.65.4, especially for public instances mixing public and private tables
• Disclosure of the specific audited vulnerabilities
• Frontier-model security audits becoming a standard part of Datasette development
• Whether the agent-assisted red-team workflow spreads to other projects

Wardley signals:

• Components: Datasette; SQLite; frontier models (Claude Fable 5.1, GPT-5.6, GPT-6 Astra) as security auditors; automated tests; open-source maintenance

• Evolution stage: Datasette — Product (mature, security-stable); frontier-model code auditing — Genesis/Custom (novel, just proving out); automated testing — Commodity practice

• Doctrine: “A bias towards open”; “Use appropriate tools”; “Set exceptional standards”; “Focus on the outcome”; “Think small teams”

• Climatic patterns: “Efficiency enables innovation” — agents lower the cost of thorough auditing; “Components can co-evolve” (the practice of agent-assisted review co-evolves with the tooling)

• Diffusion markers: A reusable two-human-plus-agents red-team workflow; declared intent to institutionalize frontier-model audits; likely emulation by other open-source maintainers

• Datasette 1.0a39 and 0.65.4 security releases

wardley-beta
%% Q1 users: Datasette maintainers and deployers
%% Q2 needs: ship a secure Datasette with public and private tables
%% Q3 capabilities: security auditing, test-driven fix workflow, patch release
%% Q4 components: Datasette, SQLite, frontier-model audit, test-driven fixes, security release
%% Q5 maturity: datasette Product; sqlite Commodity; frontierAudit Genesis->Custom (novel practice)
%% Q6 managed by: Simon Willison and Alex Garcia, with frontier-model agents assisting
anchor maintainerNeed [0.95, 0.93]
component datasette [0.70, 0.65]
component sqlite [0.80, 0.50]
component frontierAudit [0.45, 0.55]
component testDrivenFixes [0.60, 0.45]
component securityRelease [0.65, 0.40]
datasette -> maintainerNeed
sqlite -> datasette
frontierAudit -> datasette
testDrivenFixes -> frontierAudit
securityRelease -> datasette

Nix in the Browser

Simon Willison highlights trynix.dev, Farid Zakaria’s “magnum opus of Nix work”: a qemu-wasm-powered x86_64 Linux virtual machine that runs entirely in a browser through WebAssembly, bootable with any Nix package from the past thirteen years. Packages are URL-addressable — visiting trynix.dev/?pkg=python3@3.6.2 and clicking Load opens an interactive shell against a 2017 Python — so any historical package can be inspected without installing anything. Zakaria is building on top of it with trynix-preview, a GitHub Action that comments a link on a pull request letting you boot the PR’s build in the browser, with no servers. It is a neat demonstration of WebAssembly reaching the point where full legacy system emulation is practical in the browser.

Watch for:

• trynix.dev expanding package and revision coverage across Nix history
• Adoption of trynix-preview for reviewing pull-request builds in the browser
• WebAssembly full-system emulation maturing for interactive and CI workflows

Wardley signals:

• Components: trynix.dev; qemu-wasm; Nix/NixOS package store; WebAssembly; in-browser Linux VMs; GitHub Actions (trynix-preview)

• Evolution stage: Browser full-system emulation — Genesis/Custom (novel, rapidly improving); Nix — Product; WebAssembly — Product moving toward Commodity as runtime support broadens

• Doctrine: “Bias towards open”; “Use appropriate tools”; “Focus on the outcome”; “Think fast, inexpensive, restrained and elegant”

• Climatic patterns: “Components can co-evolve” (Wasm + qemu + Nix converging); “Efficiency enables innovation” — cheap browser compute unlocks new workflows

• Diffusion markers: URL-addressable, shareable package runs; a GitHub Action spreading the capability; hobbyist ecosystem building new tools on top

• Any Nix package, live in your browser

wardley-beta
%% Q1 users: developers and package maintainers
%% Q2 needs: run and inspect any Nix package directly in the browser
%% Q3 capabilities: in-browser VM emulation, package bootstrapping, PR review
%% Q4 components: trynix, Nix store, qemu-wasm, WebAssembly, PR review
%% Q5 maturity: trynix Genesis->Custom; nixStore Product; webAssembly Product->Commodity
%% Q6 managed by: Farid Zakaria and the open-source community building on top
anchor devNeed [0.95, 0.93]
component trynix [0.55, 0.60]
component nixStore [0.60, 0.50]
component qemuWasm [0.50, 0.45]
component webAssembly [0.75, 0.40]
component prReview [0.65, 0.60]
trynix -> devNeed
nixStore -> trynix
qemuWasm -> trynix
webAssembly -> qemuWasm
prReview -> trynix

Shopify Native Mobile Development

Simon Willison relays Shopify’s decision to move its mobile apps back from React Native to separate native Swift and Kotlin codebases. Shopify had switched to React Native in 2020 to stop building features twice, let developers work across the stack, and spend less time chasing parity — reasons that were valid for six years, as the post fairly credits. The shift back is driven by one factor: AI agents can now do enough of the implementation, translation, testing, and review work that dual-platform native maintenance is no longer the deciding cost it was in 2020. Native still means building on two platforms, but agents change the economics. Shopify’s three maintained React Native libraries are finding new homes (react-native-skia, flash-list) or being archived (restyle) by end of 2026.

Watch for:

• Shopify’s transition timeline and the fate of its React Native libraries
• Whether AI agents genuinely sustain dual-platform native maintenance at scale
• Other React Native shops re-evaluating their cross-platform bet
• Migration of react-native-skia and flash-list to new maintainers

Wardley signals:

• Components: React Native; native Swift and Kotlin codebases; AI coding agents; react-native-skia, flash-list, restyle libraries

• Evolution stage: React Native — Product (mature, well-understood); native mobile development — Product/Commodity; AI agents for cross-platform translation — Genesis/Custom, newly viable and shifting the decision

• Doctrine: “Use appropriate tools”; “Focus on the outcome”; “There is no core”; “Bias towards the new”; “Be pragmatic”

• Climatic patterns: “Efficiency enables innovation” — agents change the cost equation and punctuate the platform choice; “Creative Destruction” as the prior React Native bet is unwound; “Components can co-evolve”

• Diffusion markers: Library ecosystem moves (re-homing, archiving); a high-profile reversal other companies will watch; agents commoditizing cross-platform implementation

• Native is now the future of mobile at Shopify

wardley-beta
%% Q1 users: Shopify's mobile engineering organization
%% Q2 needs: build and maintain mobile apps efficiently across iOS and Android
%% Q3 capabilities: cross-platform implementation, translation, testing, and review
%% Q4 components: React Native, native Swift, native Kotlin, AI agents, React Native libraries
%% Q5 maturity: reactNative Product (mature); aiAgents Genesis->Custom (newly viable); native Swift/Kotlin Product
%% Q6 managed by: Shopify mobile teams, with AI agents shifting the cost equation
anchor shopifyNeed [0.95, 0.93]
component nativeSwift [0.65, 0.55]
component nativeKotlin [0.65, 0.50]
component aiAgents [0.45, 0.50]
component reactNative [0.60, 0.60]
component rnLibraries [0.55, 0.35]
nativeSwift -> shopifyNeed
nativeKotlin -> shopifyNeed
aiAgents -> nativeSwift
aiAgents -> nativeKotlin
reactNative -> aiAgents
rnLibraries -> reactNative