Daily Reading for 2026-09-13

Running Routes with GPT-6 Astra

Simon Willison handed ChatGPT Work with GPT-6 Astra (Max) a long-running task: design 5K and 10K loops from his house using OpenStreetMap data. The agent geocoded his address with Nominatim, pulled local roads and trails from Overpass, computed the loops locally over 27 minutes, and returned an embedded map plus downloadable GPX and GeoJSON files. The win is undercut by a transparency gap — the executed code was invisible in the UI, and thread compaction destroyed the working Python before he could request it. Willison argues compacting agent systems must preserve pre-compacted text and expose it through tool calls, a pointed lesson for anyone relying on agent output.

Watch for:

• Whether ChatGPT Work surfaces the actual code an agent runs (tool transcripts) in its UI
• How agent vendors handle compaction for long-running threads: is pre-compacted text preserved and retrievable?
• Uptake of agent “visualize”-style skills that render outputs via allow-listed CDNs

Wardley signals:

• Components: ChatGPT Work / GPT-6 Astra agent runtime; OpenAI’s visualize skill; OpenStreetMap; Nominatim (geocoding); Overpass (map-data query); GPX/GeoJSON formats; D3.js

• Evolution stage: agentic tool use — Product (rapidly adopted, feature-differentiated); OSM / Nominatim / Overpass — Commodity (open geodata utility); D3.js — Commodity (established library)

• Doctrine hits/misses: “A bias towards open” — hit, OSM as the data backbone; “Know the details” — miss, executed steps hidden behind the UI; “Focus on the outcome” — hit for the delivered loops, but auditability gaps undercut trust

• Climatic patterns: Efficiency enabling innovation — commodity geodata plus an LLM agent composes a novel consumer capability; evolution of communication mechanisms accelerating diffusion of the pattern

• Diffusion markers: long-running consumer agent tasks (“work for minutes, deliver a file”) entering the mainstream UI; user expectations shifting toward agent transparency and audit trails

• Generating running routes with GPT-6 Astra and ChatGPT Work

wardley-beta
%% Q1 users: a technical runner planning local running routes
%% Q2 needs: a safe, pleasant 5K/10K loop from home, with downloadable route files and confidence the route is real
%% Q3 capabilities: route-loop planning, geospatial data retrieval, map visualization, route export
%% Q4 components: ChatGPT Work / GPT-6 Astra agent runtime, route planner, OSM geodata (Nominatim + Overpass), visualize skill, GPX/GeoJSON export
%% Q5 maturity: agent runtime Product (feature-differentiated); route planning Product; OSM geodata Commodity; visualization Product; export Product-to-Commodity
%% Q6 managed by: OpenAI's ChatGPT Work platform under user prompting
%% note: signals named agentic tool use as Product and OSM as Commodity — aligned; export nudged toward Commodity as a stable open format
anchor runnerNeed [0.95, 0.93]
component routePlanner [0.55, 0.62]
component agentRuntime [0.35, 0.50]
component geodataApi [0.85, 0.35]
component mapViz [0.70, 0.45]
component routeExport [0.80, 0.40]
routePlanner -> runnerNeed
agentRuntime -> routePlanner
geodataApi -> routePlanner
mapViz -> agentRuntime
routeExport -> routePlanner

California Brown Pelicans at Pacifica Pier

Simon Willison’s weblog posts a short naturalist note: Pacifica Pier shut down in early June after a crack in its concrete walkway made access unsafe, and California Brown Pelicans have since taken the pier over entirely. It’s a tiny, self-contained observation — infrastructure failure creating habitat — and a deliberately light, non-technical palette-cleanser in this digest. There is little to synthesize beyond the closure-to-takeover chain, and the entry is best read as a curiosity note than a signal-bearing item. For a technical reader it is also a welcome reminder that not everything in the digest needs an engineering signal — sometimes a pier full of pelicans is exactly that.

Watch for:

• When Pacifica Pier’s crack repair is scheduled and whether the pier reopens
• Whether the pelican colony persists or relocates once foot traffic resumes
• Other coastal closures where wildlife moves into mothballed infrastructure

Wardley signals:

• Components: Pacifica Pier (public concrete walkway infrastructure); California Brown Pelicans (wildlife population); coastal inspection and maintenance practice

• Evolution stage: coastal pier infrastructure — Commodity (standard public works, routine maintenance); pelican occupation — outside the map (biological anecdote, not a tech component)

• Doctrine hits/misses: none clearly apply — this is a wildlife observation with no real Wardley doctrine signal

• Climatic patterns: none identified

• Diffusion markers: none identified

• California Brown Pelican

wardley-beta
%% Q1 users: local residents and birdwatchers visiting Pacifica Pier
%% Q2 needs: safe access to the pier and the chance to observe wildlife on it
%% Q3 capabilities: pier access, structural inspection and maintenance, wildlife observation
%% Q4 components: Pacifica Pier infrastructure, walkway inspection, pelican colony, birdwatching practice, coastal management
%% Q5 maturity: pier infrastructure Commodity (standard public works); walkway inspection Custom/Product (crack detection); pelican colony Genesis (nature, unmanaged); birdwatching Product
%% Q6 managed by: the city and coastal agency, with the pelican colony self-managed by nature
%% note: signals judged this category has no real tech components — map kept minimal and honest: pier as Commodity asset, wildlife as Genesis-level unmanaged component
anchor visitorNeed [0.95, 0.93]
component pierInfra [0.88, 0.42]
component walkwayInspection [0.55, 0.55]
component pelicanColony [0.25, 0.60]
component birdwatching [0.60, 0.68]
component coastalMgmt [0.70, 0.30]
pierInfra -> visitorNeed
walkwayInspection -> pierInfra
coastalMgmt -> walkwayInspection
birdwatching -> pierInfra
pelicanColony -> pierInfra

Paul Ford on Software Developers in the AI Era

A Paul Ford quote (from his essay “A.I. Was Supposed to Give Us New Killer Apps. What Happened?”) argues the software developer is not obsolete. The fear of tireless robots replacing people is giving way to a soberer realization: cutting-edge software still requires humans to think and work together, maximize their skill sets, and practice their crafts. Ford’s sharpest point is that AI doesn’t merely write good software — it makes it easy to do someone else’s job badly, which is why so many AI-era projects fail. “Now that everyone can code, it’s become clearer why many shouldn’t.” A useful counterweight to pure-automation narratives.

Watch for:

• Reception of Ford’s “killer apps” essay and whether its craft-based argument gains traction
• Evidence on AI-era software project failure rates and quality regressions
• Whether “everyone can code” shifts toward professional craft and review in hiring and team practice

Wardley signals:

• Components: AI code-generation tools (LLM coding assistants); software engineering craft and practice; human development teams; “everyone can code” tooling

• Evolution stage: AI code generation — Product (rapid adoption, feature differentiation); software engineering practice — Custom/Product (still a skilled, non-commodity capability)

• Doctrine hits/misses: “Use appropriate tools” / “Know your users” — hit, cutting-edge work still needs human judgment and collaboration; “Focus on the outcome” — miss, AI makes it easy to do someone else’s job badly, undermining outcomes

• Climatic patterns: Efficiency does not mean a reduced spend (Jevon’s Paradox) — higher output per developer may not shrink the need for skilled humans; evolution to higher-order systems creates new sources of value while the writing-code component commoditises

• Diffusion markers: Widening adoption of AI coding tools across the industry; a stabilising counter-narrative (“craft still matters”) spreading as high-profile AI project failures accumulate — a reality-check on the hype curve

• Quoting Paul Ford

wardley-beta
%% Q1 users: engineering leaders and development teams deciding how to use AI in software delivery
%% Q2 needs: deliver cutting-edge, reliable software and judge when AI-generated code is appropriate
%% Q3 capabilities: software design and integration, code generation, review and quality assurance, craft development
%% Q4 components: AI code-generation tools, engineering craft and judgment, code review/QA practice, human development teams, low-barrier "everyone can code" tooling
%% Q5 maturity: AI code generation Product (rapid adoption, feature differentiation); engineering craft Custom/Product; code review Product; dev teams Custom/Product; everyone-can-code tooling Product
%% Q6 managed by: development organizations and engineering leaders, with AI tooling vendored by model providers
%% note: signals named AI code generation as Product and engineering practice as Custom/Product — aligned; added codeReview as the QA node Ford argues AI undermines when misused
anchor teamNeed [0.95, 0.93]
component engCraft [0.45, 0.70]
component codeReview [0.66, 0.55]
component aiCodeGen [0.58, 0.52]
component devTeams [0.38, 0.48]
component everyoneCanCode [0.72, 0.45]
engCraft -> teamNeed
codeReview -> engCraft
aiCodeGen -> codeReview
devTeams -> engCraft
everyoneCanCode -> aiCodeGen