Anthropic published findings from a study in which Claude interviewed roughly 80,000 people about their views on AI. The methodology deserves a moment: using the technology being studied to conduct the research. The advantages are real, consistency, scale, availability across languages, the ability to run open-ended conversational probing rather than fixed survey items. The risks are real too; any interviewer shapes what gets said, and a model with particular training carries particular frames. Setting that aside, 80,000 conversations is a sample size that fixed-question surveys rarely reach.
The finding that Martin Fowler highlights is that the expected structure does not match what people said. The assumption going in would be two camps: optimists who see AI as transformative and good, pessimists who see it as dangerous and bad. That is how the discourse looks from outside, particularly in online spaces where extreme positions get the most circulation. The study found something different. People organize around what they value: financial security, learning, human connection. Someone focused on economic stability watches AI advance with simultaneous hope, maybe it creates new paths and new categories of work, and fear, automation has historically displaced specific labor categories faster than new ones appear for the people displaced. Both can be true at once, and for most people they are.
Fowler describes his own position plainly: when asked whether he is an AI booster or an AI doomer, his answer is yes. The intellectual excitement about AI reshaping his profession is genuine. So is the concern about harms. That is the response of someone paying attention to both sides as they materialize, not a diplomatic hedge.
The binary framing has always served discourse better than it serves description. It simplifies, which is useful for arguments and useless for understanding. The values-based finding matches how most thoughtful people actually talk about AI in unguarded conversations, holding the hope and the worry at the same time because they are responding to the same technology from inside their specific circumstances.
The Geography Makes Sense Once You Think About Stakes
The geographic finding is the more striking result. Less developed countries show higher AI optimism on average. This is often framed as puzzling, but it resolves once you think about what AI access means in different contexts.
In countries with functional institutions, accessible healthcare, available legal systems, and established educational infrastructure, AI mostly competes with things that already exist. A competent lawyer in a wealthy country has good substitutes for legal AI assistance. A student in a country with strong universities has real educational alternatives. In these contexts, AI adds efficiency at the margin, but the baseline is already high. The downside risks are more concrete: job displacement in labor markets where those jobs represent stable middle-class income, misinformation layered onto existing media environments, automated hiring tools that encode historical bias at scale.
In a country where seeing a specialist means days of travel and uncertain availability, where formal legal advice is economically out of reach for most people, where quality educational materials require access that most people do not have, the same technology arrives in a different context. AI can provide something close to the support that wealthy or well-connected people in that country already access. The floor is low, so the ceiling is high. The technology fills a real gap rather than competing with an incumbent.
This pattern is not unique to AI. Mobile banking in East Africa expanded far faster than in developed economies because the counterfactual was no formal banking access at all. Leapfrogging happens when the gap between current state and the technology’s floor is large enough that ordinary adoption friction stops mattering.
There is also accumulated experience shaping these priors. People in wealthy countries have years of AI-adjacent experience with algorithmic systems that optimized for engagement and degraded discourse, recommendation engines that narrowed exposure, automated decision systems that made consequential calls about people’s lives in ways that were neither transparent nor accurate. That history accumulates into skepticism. People in countries with less concentrated exposure to these specific failure modes start with a different prior. That is not the same as being less sophisticated about risk; it is a different evidentiary record.
What Developers Keep Missing About Specs
Fowler’s post also references a piece by Julia Shaw on a gap in how developers use specification-driven development. The landscape she describes is one most people building with AI tools will recognize: the internet has filled with advice to write a spec before prompting, give the agent guardrails, define constraints and behavior up front. Good advice, and increasingly followed.
Her observation is that almost no one talks about what happens after the spec is written.
Writing a spec at the start of a session is not the same as maintaining a living document that captures what actually happens during development. You write a thorough spec. You start prompting. The agent makes choices, some of which you accept, some you correct. You add features. Scope shifts. Each individual decision seems too small to document formally. Six weeks later, the codebase reflects dozens of choices that were reasonable in context but never made it back into the spec. The next session starts from a spec that describes a system that no longer exists.
Building Ralph, I have run into this repeatedly. The initial architecture documents were careful. The actual implementation drifted from them within the first week, not through negligence but through the accumulation of small decisions that each made sense at the time. The spec was not wrong; it was stale. Working from it in later sessions produced suggestions that conflicted with decisions already locked in.
The fix is not more rigorous spec maintenance in the traditional sense. It is changing what the spec is for. A design document describes intent. A decision log records what happened. Both matter, and current SDD practice handles the first and largely ignores the second. Every time an agent makes a choice worth keeping, that choice needs to live somewhere that gets read at the start of the next session. Not a commit message that disappears into history, not a code comment that gets moved with a refactor, but something that actively frames the model’s working context before it generates anything.
This is what context anchoring addresses: a living document committed to your repo that captures technology choices, invisible constraints, and the decisions made in past sessions. The spec you write at the start of a project is a plan. The document you maintain across sessions is a record of how reality diverged from that plan and why. Without the second, the first decays.
Tools like Claude Code and Cursor have independently converged on anchor files, CLAUDE.md, .cursorrules, project-level context injection, because the problem surfaces quickly in practice. But even with those files, the capture discipline is mostly absent. Developers set them up once and then stop updating them, which means they accumulate the same staleness as the original spec.
The Same Structure Underneath
These two observations share an underlying logic. AI attitudes organize around stakes: what someone values, what they stand to gain, what they stand to lose given their specific situation. The geographic optimism gap is a stakes gap, not a sophistication gap or a temperament gap. People with more to gain from AI’s floor and less prior exposure to its failure modes respond with more hope. People with a higher baseline and a longer record of algorithmic systems behaving badly respond with more skepticism. Both responses are rational given the respective evidentiary records.
The SDD gap is also a stakes problem. Developers writing initial specs are treating the planning problem as the important one. The capture problem, preserving the decisions actually made during development, is the one that compounds over time. The cost of not solving it is invisible at the start of a project and very visible six weeks in, when a new session produces output that confidently ignores four weeks of accumulated decisions.
Both point to the same general failure mode: evaluating AI’s value against the wrong baseline, and solving the visible problem while leaving the adjacent one untouched.