Daily Reading for 2026-09-10
Daily Reading for 2026-09-10
Cloud Web Application Threat Matrix
Microsoft released a new MITRE ATT&CK-aligned threat matrix for cloud-hosted web applications and serverless platforms, building on its earlier Kubernetes and storage matrices. It maps attack paths that cross application code, managed runtimes, workload identities, deployment pipelines, and connected cloud resources — including subdomain takeover, code injection in connected repositories, compromised registry images, exposed admin interfaces, and serverless trigger injection. For defenders the value is a single taxonomy to surface visibility gaps, prioritize hardening, and plan investigations across a hybrid app-plus-platform boundary that separate application and cloud reviews tend to miss.
Watch for:
- Subdomain takeover and misconfigured admin interfaces (e.g. exposed Azure Kudu) as recurring initial-access vectors
- Whether the matrix gets adopted alongside the existing Kubernetes/storage matrices in vendor security tooling
- Mapping to concrete MITRE ATT&CK technique IDs and integration into cloud security posture tools
Wardley signals:
-
Components: Microsoft’s cloud web applications threat matrix, MITRE ATT&CK framework, cloud-native app platforms (Azure App Service, AWS Lambda, GCP Cloud Functions), container registries, workload identities
-
Evolution stage: the matrix is Custom-to-early-Product — a vendor taxonomy consolidating around MITRE ATT&CK (a Commodity standard), with web-app/serverless coverage still forming
-
Doctrine hits/misses: “Set exceptional standards” and “Use appropriate tools” (standardizing on MITRE ATT&CK); “Challenge assumptions” (investigating app and platform together instead of separately)
-
Climatic patterns: “Commoditisation <> Centralisation” and components co-evolving (threat-modeling practice evolving with cloud-native platforms); evolution in multiple waves with chasms
-
Diffusion markers: following Microsoft’s Kubernetes/storage matrices signals standardization and copy-cat across a growing ecosystem, likely feeding into security tools
-
Threat matrix: Mapping threats across cloud web applications
wardley-beta %% 1. Users: Cloud security teams / defenders %% 2. Needs: Understand, prioritize, and investigate threats to cloud-hosted web apps and serverless platforms %% 3. Capabilities: Threat taxonomy, visibility gap analysis, hardening prioritization, investigation planning %% 4. Components: cloud web apps threat matrix, MITRE ATT&CK, cloud-native platforms (App Service/Lambda/Functions), container registries, workload identities %% 5. Maturity: ATT&CK = Commodity (standard); matrix = Custom/Product; cloud platforms = Product; registries/identities = Commodity %% 6. Management: Microsoft and vendor security tooling; defender adoption anchor securityTeams [0.90, 0.93] component threatMatrix [0.58, 0.60] component cloudApps [0.32, 0.72] component mitreAttck [0.86, 0.34] component cloudPlatform [0.48, 0.42] component workloadIdentity [0.38, 0.22] threatMatrix -> securityTeams cloudApps -> threatMatrix cloudPlatform -> cloudApps mitreAttck -> threatMatrix workloadIdentity -> cloudPlatform
Passkey Social Engineering Campaign
Microsoft Security Research documents an active cloud intrusion campaign running since May 2026 that uses passkey-themed social engineering to compromise identities. Callers posing as IT helpdesk steer employees through adversary-in-the-middle (AiTM) phishing or device-code authentication flows; attackers then add unauthorized authentication methods, run broad Microsoft Graph reconnaissance, and pull data from SharePoint, OneDrive, and email via REST APIs. The recurring sequence — identity compromise, persistence, reconnaissance, content discovery, and exfiltration — is more durable for detection than fast-rotating domains, so defenders should investigate across identity, Graph, and collaboration signals and revoke sessions.
Watch for:
- AiTM / device-code flows that leave little endpoint forensics, making social-engineering reports the earliest evidence
- Rapidly rotated phishing domains (company-name.malicious-domain.com pattern) and Nicenic-registered infrastructure
- Unauthorized authentication method additions and unusual sign-ins as early persistence signals
Wardley signals:
-
Components: passkey/MFA/SSO identity infrastructure, AiTM phishing kits, device-code auth flows, Microsoft Graph, SharePoint/OneDrive/Exchange, Defender for Endpoint, cloud/workload identity
-
Evolution stage: AiTM phishing and device-code abuse are Product-stage, rapidly diffusing attack tooling; identity detection/governance is Custom-to-Product and catching up
-
Doctrine hits/misses: “Manage failure” and “Know the details” (reconstructing attacks from fragmented evidence); “Challenge assumptions” (passkey lures as pretext, not the real objective)
-
Climatic patterns: “Red Queen” — no choice over evolution as defenders and attackers co-evolve; creative destruction as infrastructure rotates
-
Diffusion markers: a campaign spanning multiple accounts and tenants with proxy-associated infrastructure and copy-cat phishing infrastructure indicates ecosystem-scale diffusion
-
Passkey-themed social engineering leads to identity and cloud compromise
wardley-beta %% 1. Users: Enterprise identity/security teams defending against the campaign %% 2. Needs: Detect identity compromise, revoke persistence, and stop data exfiltration %% 3. Capabilities: Sign-in anomaly detection, auth-method review, Graph/collaboration monitoring, session revocation %% 4. Components: passkey/MFA identity, AiTM phishing + device-code flows, Microsoft Graph reconnaissance, SharePoint/OneDrive/Exchange data, identity detection tooling %% 5. Maturity: AiTM/device-code attack tooling = Product (diffusing); identity detection/governance = Custom/Product; MFA/Graph = Commodity %% 6. Management: Microsoft Security Research + enterprise identity teams anchor securityTeams [0.90, 0.93] component phishingInfra [0.28, 0.62] component identity [0.48, 0.55] component graphRecon [0.60, 0.50] component dataExfil [0.55, 0.38] component detection [0.72, 0.32] identity -> securityTeams phishingInfra -> identity graphRecon -> identity dataExfil -> graphRecon detection -> securityTeams
Appsec Roundup
Shostack’s July/August 2026 appsec roundup sweeps the EU’s 83 pages of CRA guidance for SMEs, new research on AI in security requirements and threat modeling, and the open debate over whether LLMs can actually fix vulnerabilities — 1Password’s Off-by-1 Labs finds model-generated patches are often flawed, while Google reports LLMs now generate candidate fixes for most Chrome vulnerabilities. It also flags the Mythos attack that took down a third-round PQC candidate using about $100k of tokens, and rounds up a stack of notable security books. The thread across items: AI is being folded into security work, with contested evidence on how well it performs.
Watch for:
- Whether LLM-driven vulnerability patching matures from flawed candidates to reliable fixes
- Post-quantum cryptography fallout from the Mythos attack on third-round candidates
- How CRA guidance reshapes secure-by-design requirements for SMEs
Wardley signals:
-
Components: EU CRA regulation, LLM vulnerability-patching tools, threat-modeling methodologies, post-quantum cryptography, security requirements engineering, Chrome’s security program
-
Evolution stage: LLM vulnerability remediation is Custom-to-Product (rapid claims, contested efficacy); CRA is Commodity-grade regulation; PQC is Custom evolving under attack
-
Doctrine hits/misses: “Use appropriate tools” and “Set exceptional standards” (LLMs vs human review of fixes); “Bias towards data” (evidence-based evaluation of AI patch quality)
-
Climatic patterns: “Red Queen” and creative destruction (a PQC candidate replaced); “Capital flows to new areas of value” (AI security tooling investment)
-
Diffusion markers: vendors and labs publishing competing results on AI patching signals standardization and copy-cat around a forming practice
wardley-beta %% 1. Users: Application-security practitioners and researchers %% 2. Needs: Track the shifting appsec landscape, regulations, and AI's role in security %% 3. Capabilities: Trend awareness, vulnerability remediation, secure-by-design compliance %% 4. Components: LLM vulnerability patching, EU CRA regulation, post-quantum cryptography, threat modeling, security requirements engineering %% 5. Maturity: LLM patching = Custom/Product (contested); CRA = Commodity (regulation); PQC = Custom under attack; threat modeling = Product/Commodity %% 6. Management: Vendors, labs, and regulators shaping the roundup's topics anchor practitioners [0.90, 0.93] component llmPatching [0.45, 0.60] component threatModeling [0.70, 0.55] component craRegulation [0.62, 0.40] component pqcrypto [0.50, 0.35] component vulnTooling [0.55, 0.28] llmPatching -> practitioners threatModeling -> practitioners craRegulation -> threatModeling pqcrypto -> llmPatching vulnTooling -> llmPatching
Threat Modeling 2nd Edition
Shostack & Friends announces the second edition of the threat-modeling classic, Threat Modeling: Designing for Security in an AI World, coming February 2027, with a limited-time Barnes & Noble preorder promotion (25% off for members). The new edition expands the structured-approach mechanics to cover the systems, software, and emerging AI technologies that didn’t exist when the first edition was published. For practitioners it signals that the threat-modeling practice is being deliberately updated for an AI-software era, alongside renewed demand for training built around these methods.
Watch for:
- Publication in February 2027 and whether the AI-era techniques gain adoption in secure-by-design guidance
- Whether second-edition methods feed into CRA and other regulatory secure-by-design requirements
- Ongoing demand for threat-modeling training (including LLM-based intensive courses)
Wardley signals:
-
Components: the Threat Modeling book (2nd edition), threat-modeling methodology/practice, AI software supply chains, secure-by-design regulatory guidance
-
Evolution stage: threat-modeling practice is Product-to-Commodity (established, becoming standard practice); its AI-era extension is Genesis-to-Custom, exploring new territory
-
Doctrine hits/misses: “Set exceptional standards” and “Challenge assumptions” (rethinking threat modeling for AI systems); “Use appropriate methods”
-
Climatic patterns: components co-evolving (practice with activity — threat modeling evolving alongside AI software development); education and standardisation
-
Diffusion markers: second edition plus preorder promotion plus training courses signal a practice being refreshed and disseminated; the first edition’s #1 status shows an established audience
wardley-beta %% 1. Users: Security practitioners, engineers, and teams adopting threat modeling %% 2. Needs: Updated threat-modeling methods that cover AI-era systems %% 3. Capabilities: Structured threat modeling, AI-system security analysis, secure-by-design %% 4. Components: threat-modeling practice, AI software systems, training/education, secure-by-design guidance %% 5. Maturity: threat modeling = Product/Commodity; AI-era extension = Genesis/Custom; training = Product; secure-by-design = Commodity (regulatory) %% 6. Management: Shostack + Friends and the broader practitioner community anchor practitioners [0.90, 0.93] component threatModeling [0.72, 0.58] component aiSystems [0.42, 0.50] component training [0.66, 0.45] component secureByDesign [0.80, 0.35] threatModeling -> practitioners aiSystems -> threatModeling training -> threatModeling secureByDesign -> threatModeling
Microsoft Patch Tuesday
Security Risk Advisors’ September 2026 Microsoft Patch Tuesday briefing summarizes the monthly set of Microsoft security updates released around the second Tuesday of the month. These routine bulletins aggregate patched CVEs across Windows, Office, and related products and steer defenders toward which updates are most urgent to apply. For a technical reader the monthly cadence is the standard signal for triaging the release, prioritizing fixes against actively exploited vulnerabilities, and scheduling deployment across an environment.
Watch for:
- High-severity or actively exploited CVEs in the September release
- Updates touching identity, Exchange, or other critical infrastructure
- Any zero-day fixes warranting immediate, emergency deployment
Wardley signals:
-
Components: the Microsoft Patch Tuesday release process, CVE/vulnerability data, Windows/Office product families, patch-management tooling
-
Evolution stage: Patch Tuesday is a mature Commodity cadence (regular, expected, operational); patch-management tooling is Product-to-Commodity
-
Doctrine hits/misses: “Manage failure” and “Manage inertia” (staying current on patches); “Use standards” (applying the vendor’s cadence)
-
Climatic patterns: none clearly apply beyond a steady operational cadence
-
Diffusion markers: the monthly cadence is institutionalized and standardized across the industry
wardley-beta %% 1. Users: Enterprise defenders and patch managers %% 2. Needs: Triage, prioritize, and deploy the monthly Microsoft security updates %% 3. Capabilities: Patch cadence, CVE triage, patch deployment and management %% 4. Components: Patch Tuesday release, CVE/vulnerability data, Windows/Office products, patch-management tooling %% 5. Maturity: Patch Tuesday = Commodity (regular, expected); CVE data = Commodity; patch management = Product/Commodity; Windows/Office = Commodity %% 6. Management: Microsoft release engineering + enterprise patch teams anchor defenders [0.90, 0.93] component patchRelease [0.80, 0.55] component windows [0.50, 0.60] component cveData [0.70, 0.40] component patchMgmt [0.62, 0.30] patchRelease -> defenders windows -> patchRelease cveData -> patchRelease patchMgmt -> cveData
Digital Workers vs Personal Assistants
SRA distinguishes two kinds of AI agents in security operations: the personal assistant, which runs on one person’s permissions and tribal knowledge, and the digital worker, an autonomous Non-Human Identity (NHI) with its own identity, scope, and audit trail, triggered by workflows rather than prompts. Most teams call scattered personal-assistant use an “AI strategy,” but only governed, reusable digital workers give security leaders reviewable, revocable, repeatable capability. The author argues the two are different problems, not upgrade paths for one another, and that matching the agent type to the job is what separates real capability from a convenience trick.
Watch for:
- Adoption of NHI/identity governance for autonomous security agents
- Whether “digital worker” becomes standard terminology alongside personal-assistant tooling
- Real SOC workflows built as governed digital workers rather than ad-hoc chat use
Wardley signals:
-
Components: AI security agents (personal assistant vs digital worker), Non-Human Identity (NHI) governance, SOC workflows, LLM platforms (Claude/Copilot/Gemini/ChatGPT), SCALR AI
-
Evolution stage: personal-assistant AI is Commodity (ubiquitous, expected); digital-worker/NHI governance is Custom-to-Product, still forming
-
Doctrine hits/misses: “Provide purpose, mastery & autonomy” and “Distribute power and decision making” (autonomous workers); “Use standards” (governed identity)
-
Climatic patterns: evolution of higher-order systems creating new value; practice co-evolving with AI activity
-
Diffusion markers: vendors building digital-worker platforms (SCALR AI) and the NHI concept spreading across security identity tooling
wardley-beta %% 1. Users: Security leaders and SOC teams %% 2. Needs: Governed, reviewable, repeatable AI automation vs quick informal assistance %% 3. Capabilities: Autonomous agent execution, identity/scope governance, auditability, workflow automation %% 4. Components: personal assistants, digital workers, Non-Human Identity (NHI) governance, SOC workflows, LLM platforms %% 5. Maturity: personal assistants = Commodity; digital workers/NHI governance = Custom/Product; LLM platforms = Product/Commodity %% 6. Management: Security leaders + platform vendors (e.g. SCALR AI) anchor securityLeaders [0.90, 0.93] component personalAssistant [0.75, 0.60] component digitalWorker [0.50, 0.52] component nhiGovernance [0.60, 0.35] component socWorkflows [0.40, 0.45] component llmPlatform [0.80, 0.40] personalAssistant -> securityLeaders digitalWorker -> securityLeaders nhiGovernance -> digitalWorker socWorkflows -> digitalWorker llmPlatform -> personalAssistant
AI and GDP Growth
This piece interrogates Chad Jones’ AI-macroeconomics estimates, which suggest even infinite automation raises GDP only modestly — 2%, 11%, or 19% depending on the share automated — under an elasticity of substitution of 0.2. The author argues these low-end figures assume displaced workers never reallocate to non-automated tasks; with immediate reallocation, automating half of GDP could roughly double it, or raise it by 138% at elasticity 0.2. The sharper question is not whether AI helps reallocation relative to past transitions, but how fast AI can accelerate both automation and reallocation at once.
Watch for:
- Empirical estimates of AI’s effect on GDP and on labor-reallocation speed
- Whether reallocation keeps pace with automation across industries
- The elasticity-of-substitution assumption driving the wide growth range (2% vs 138%)
Wardley signals:
-
Components: AI/automation technologies, labor reallocation, GDP/elasticity economic models, AI-augmented training (e.g. smart glasses)
-
Evolution stage: AI-driven automation is Product-to-Commodity for many tasks; the economic modeling of it is still Genesis-to-Custom (contested, uncertain)
-
Doctrine hits/misses: “Bias towards data” and “Challenge assumptions” (questioning the zero-reallocation assumption); “Embrace uncertainty”
-
Climatic patterns: “Creative Destruction” (automation reshaping GDP); “Efficiency does not mean reduced spend (Jevon’s Paradox)”; capital flows to new value
-
Diffusion markers: the debate spreading across economics and tech commentary, with AI itself accelerating task reallocation
wardley-beta %% 1. Users: Economists, policymakers, and tech analysts %% 2. Needs: Estimate AI's macroeconomic impact on GDP and labor %% 3. Capabilities: GDP modeling, labor reallocation analysis, elasticity estimation %% 4. Components: AI automation, GDP/elasticity models, labor reallocation, productivity %% 5. Maturity: AI automation = Product/Commodity for many tasks; economic modeling = Genesis/Custom (contested) %% 6. Management: Academic economists and public discourse anchor economists [0.90, 0.93] component aiAutomation [0.55, 0.60] component productivity [0.70, 0.55] component gdpModels [0.45, 0.50] component laborRealloc [0.60, 0.40] component elasticAssumption [0.38, 0.28] aiAutomation -> economists productivity -> aiAutomation gdpModels -> economists laborRealloc -> gdpModels elasticAssumption -> gdpModels
On-Device vs Datacenter Inference
SemiAnalysis asks where a robot’s inference should run — on-device versus in the datacenter — weighing the latency, power, and capability tradeoffs for embodied AI. The framing highlights a central architectural decision for robotics: whether compute-heavy reasoning happens locally on the robot or remotely in datacenters, and how that choice shapes the economics, reliability, and responsiveness of deployed systems. It is a formative split that will define the hardware and network footprints of the robotics stack as deployment scales.
Watch for:
- On-device vs datacenter inference cost and latency benchmarks for robotics
- Edge accelerators vs datacenter GPUs driving which architecture wins per workload
- Whether hybrid inference (local plus cloud) becomes the dominant pattern
Wardley signals:
-
Components: on-device edge inference, datacenter inference, robot/embodied AI platforms, edge accelerators, datacenter GPUs, robotics compute
-
Evolution stage: robotics inference is Custom-to-Product, with on-device vs cloud still contested and evolving
-
Doctrine hits/misses: “Use appropriate tools” and “Be pragmatic” (choosing deployment per task); “Focus on the outcome”
-
Climatic patterns: evolution of communication mechanisms (networked inference) increasing the speed of evolution; efficiency/componentisation effects
-
Diffusion markers: robotics inference emerging as a distinct architectural debate as robot adoption grows (copy-cat across vendors)
-
Where Does a Robot Think – On-Device vs Datacenter Inference
wardley-beta %% 1. Users: Robotics companies and embodied-AI developers %% 2. Needs: Decide where robot inference runs for latency, power, and capability %% 3. Capabilities: On-device and datacenter inference, robotics compute, hybrid deployment %% 4. Components: on-device inference, datacenter inference, edge accelerators, datacenter GPUs, robot platforms %% 5. Maturity: robotics inference = Custom/Product (contested); edge accelerators/GPUs = Product; robot platforms = Custom/Product %% 6. Management: Robotics vendors and hardware suppliers anchor robotOperators [0.90, 0.93] component robotPlatform [0.40, 0.70] component onDevice [0.55, 0.60] component datacenter [0.62, 0.52] component edgeAccel [0.48, 0.38] component datacenterGpu [0.66, 0.30] robotPlatform -> robotOperators onDevice -> robotPlatform datacenter -> robotPlatform edgeAccel -> onDevice datacenterGpu -> datacenter
AI Existential Risk
Daniel Miessler frames AI existential risk not as a Skynet-style takeover but as a slow, natural path: the less competent lean on the more competent, and society already runs on technology that very few humans deeply understand. As those few retire and knowledge erodes, the list of critical systems no human can operate grows, and AI — getting smarter over time — becomes the only recourse when anything breaks. Even a benign AI controlling much of the world concentrates power and raises the odds that a much smarter or malicious AI takes over the orchestration it understands and we do not.
Watch for:
- Erosion of human operational knowledge in critical infrastructure sectors
- Concentration of control in AI-run systems, whether benign or not
- Alignment and control-risk arguments for decentralized vs centralized AI
Wardley signals:
-
Components: AI systems, critical infrastructure/technology, human operational knowledge, alignment/control techniques, centralized vs decentralized AI
-
Evolution stage: AI is Product-to-Commodity and rapidly evolving; societal reliance on it is Custom and forming; existential-risk discourse is Genesis
-
Doctrine hits/misses: “Embrace uncertainty” and “Challenge assumptions” (questioning the benign-takeover assumption); “Listen to your ecosystem”
-
Climatic patterns: “Creative Destruction” and inertia (success breeding inertia in existing systems); higher-order systems creating new value and risk
-
Diffusion markers: existential-risk framing spreading beyond sci-fi into mainstream technical discourse
wardley-beta %% 1. Users: Society / humanity (the ones relying on AI-run systems) %% 2. Needs: Understand and mitigate existential risk from AI %% 3. Capabilities: Knowledge preservation, alignment, control and governance %% 4. Components: AI systems, critical infrastructure, human operational knowledge, alignment, control risk %% 5. Maturity: AI = Product/Commodity (rapidly evolving); human knowledge = Commodity eroding; alignment/control = Genesis/Custom %% 6. Management: Technologists, researchers, and policymakers anchor society [0.90, 0.93] component aiSystems [0.60, 0.62] component criticalInfra [0.45, 0.52] component humanKnowledge [0.30, 0.45] component alignment [0.40, 0.30] component controlRisk [0.55, 0.40] aiSystems -> society criticalInfra -> society humanKnowledge -> criticalInfra alignment -> aiSystems controlRisk -> aiSystems
AI-Built Zero-Click Worm
Simon Willison quotes Calif Research’s demo of WeWorm, described as the first zero-click worm to spread through WeChat calls across iOS and Android — no user interaction required, and even answering the call plays nothing audible while the exploit still succeeds. The team found the bug and wrote a remote-code-execution exploit in about two days using AI, then built the worm in a week, work that once took a larger team months. The post underscores how AI is collapsing the cost and time of advanced exploit development.
Watch for:
- Whether zero-click VoIP/worm attacks are independently reproduced by others
- Patching urgency and hardening for mobile messaging platforms like WeChat
- AI-assisted exploit development becoming a mainstream attacker capability
Wardley signals:
-
Components: zero-click exploits, WeChat/VoIP platforms (iOS/Android), AI-assisted code and exploit generation, RCE tooling, mobile messaging security
-
Evolution stage: AI-assisted exploit development is Genesis-to-Custom (novel, rapidly advancing); zero-click mobile attacks are a Product-stage technique
-
Doctrine hits/misses: “Challenge assumptions” (that users must interact for compromise); “Use appropriate tools” (AI as force multiplier)
-
Climatic patterns: “Red Queen” (attack/defense co-evolution); “Creative Destruction”; evolution in multiple waves with chasms
-
Diffusion markers: a small team demonstrating worm-scale build speed signals the practice spreading, with high copy-cat risk
wardley-beta %% 1. Users: Mobile messaging users and platform security teams %% 2. Needs: Defend against zero-click compromise; understand AI-accelerated exploit risk %% 3. Capabilities: Mobile platform patching, exploit detection, secure messaging %% 4. Components: zero-click exploits, messaging platforms (WeChat/VoIP), AI code generation, RCE tooling, platform patching %% 5. Maturity: AI exploit generation = Genesis/Custom (novel, advancing); zero-click attacks = Product-stage technique; messaging platforms = Commodity %% 6. Management: Messaging vendors, security researchers, platform teams anchor mobileUsers [0.90, 0.93] component messagingPlatform [0.60, 0.55] component zeroClickExploit [0.35, 0.60] component aiCodeGen [0.50, 0.40] component rceTooling [0.45, 0.30] component platformPatching [0.68, 0.35] messagingPlatform -> mobileUsers zeroClickExploit -> messagingPlatform aiCodeGen -> zeroClickExploit rceTooling -> zeroClickExploit platformPatching -> messagingPlatform
Blender .blend URL Viewer
Simon Willison shares “.blend URL Viewer,” a tool that renders Blender .blend files directly in the browser by pasting a CORS-accessible or GitHub URL, with mesh geometry, materials, lighting, saved camera positions, orbit controls, and wireframe mode. It grew out of an AI vibe-coding session: ChatGPT Images 2.5 generated a Fabergé egg themed after the TV show Pluribus, then Codex running GPT-6 Astra built Blender models and this viewer in about 17 minutes. It’s a compact showcase of how quickly AI can accelerate tool-building and 3D asset generation.
Watch for:
- Whether browser-based .blend viewing gains traction as a lightweight collaboration tool
- GPT-6 Astra / Codex-generated Blender workflows becoming repeatable
- Performance limits of client-side rendering for large .blend files
Wardley signals:
-
Components: the .blend URL Viewer, Blender, browser-based WebGL rendering, GPT-6 Astra / Codex, ChatGPT Images 2.5, vibe-coding practice
-
Evolution stage: Blender is a mature Product-to-Commodity tool; AI code generation (vibe-coding) is Genesis-to-Custom; browser .blend viewing is Genesis/Custom
-
Doctrine hits/misses: “Think fast, inexpensive, restrained and elegant” (quick vibe-coded tool); “Bias towards action” and “Move fast”; “Use appropriate tools”
-
Climatic patterns: “Efficiency enables innovation (componentisation effect)”; higher-order systems creating new value; evolution of communication mechanisms
-
Diffusion markers: AI-generated 3D workflows and browser tools spreading across maker/developer communities (TIL series, tools collection)
wardley-beta %% 1. Users: Developers, 3D artists, and makers %% 2. Needs: View/share Blender .blend files in the browser; build 3D tools fast %% 3. Capabilities: Browser rendering, 3D asset generation, rapid AI-assisted tool building %% 4. Components: .blend URL Viewer, Blender, WebGL rendering, AI code generation, asset pipeline %% 5. Maturity: Blender = Product/Commodity; AI codegen (vibe-coding) = Genesis/Custom; browser .blend viewing = Genesis/Custom; WebGL = Commodity %% 6. Management: Simon Willison and the maker/developer community anchor developers [0.90, 0.93] component browserViewer [0.55, 0.62] component blender [0.70, 0.52] component aiCodegen [0.50, 0.40] component webgl [0.80, 0.35] component assetPipeline [0.42, 0.45] browserViewer -> developers blender -> browserViewer aiCodegen -> blender webgl -> browserViewer assetPipeline -> blender