A frontier model that leads on personal and professional agents

Today, we’re excited to introduce the Muse Wonder series with Muse Wonder and Muse Wonder Full, our most capable models that deliver state-of-the-art performance on personal and professional agentic tasks. Together, they mark the next step on our scaling ladder and a major leap toward personal superintelligence. Muse Wonder brings together Active Memory and Active Focus to keep track of what matters to you and work diligently toward what you want to accomplish.

Muse Wonder is available today through the Meta Model API and Muse Code, and Muse Wonder Full is available today for Muse Code subscribers.

Muse Wonder will soon power experiences in Muse, and will roll out first to subscribers. Muse Wonder will also power artifact generation and processes that require more intelligence. And in the future, we’ll be using Muse Wonder to develop specialized models that we can bring to everyone using Muse.

Scaling Toward Personal Superintelligence

Fourteen months ago, we began a ground-up overhaul of our artificial intelligence efforts. In that time, we’ve gone from rebuilding our stack from first principles to pushing the frontier.

When we introduced Muse Spark, we outlined our approach to predictable, rigorous scaling. Today’s release builds on that work across pretraining and reinforcement learning, delivering our most capable models yet. Trained at our gigawatt-scale Prometheus data center, Muse Wonder and Muse Wonder Full bring together the work of teams across Meta to deliver frontier capabilities for complex tasks at work and in everyday life — another step toward bringing personal superintelligence to the billions of people who use our products.

Frontier Capabilities

Model Highlights

The Muse Wonder series achieves state-of-the-art results across key benchmarks for personal and professional agents, memory, and coding.

The full results below compare Muse Wonder and Muse Wonder Full with other frontier models across a broad evaluation suite.

For more details about our evaluations, see our report.

The results above provide a broad view of the models’ performance. We now take a closer look at four areas central to their work on real-world tasks: domain expertise, Active Memory, Active Focus, and frontier coding.

Domain Expertise

Muse Wonder and Muse Wonder Full apply specialized knowledge to problems people encounter at work and in daily life, from understanding a lease to making sense of financial or health information. Our evaluations include tasks in law, finance, and health that test this ability. Harvey’s Legal Agent Benchmark (LAB), for example, requires models to work with source documents and follow detailed instructions to produce legal work products.

Active Memory

One of the most critical steps towards useful personal and professional agents is reliable memory. Models need to remember what matters and recognize when earlier information becomes relevant. We call this Active Memory: carrying important context about you across conversations and actively retrieving the details relevant to the task at hand.

Active Focus

Using that context to complete a task also requires sustained effort. Active Focus describes how Muse Wonder continues working toward a challenging goal: trying alternative approaches, working through blockers, and adapting to new information. Along the way, it asks for clarification when needed and checks in before taking important actions. We evaluate focus through FocusBench and sustained execution through SWE-Marathon, which tests work on long-running software projects.

Frontier Coding

Coding brings these capabilities together. Building software requires tracking requirements, making changes across a codebase, and working through repeated cycles of testing and revision. Muse Wonder and Muse Wonder Full deliver frontier coding performance, supporting projects from small applications to complex software. We trained both models on diverse, long-running tasks to help them sustain progress across this process.

Muse Wonder builds a playable 3D kitchen game from customizable image inputs.

Capabilities That Generalize

Two models often have similar benchmark scores, yet one seems to handle a much wider range of unfamiliar tasks. That’s what complaints of “benchmaxxing” and praise for “big model smell” both get at: a breadth of capability that popular benchmarks in a few domains can’t fully capture.

To quantify this mismatch, we investigate how performance on tasks targeted during post-training relates to performance on unfamiliar tasks as we scale test-time compute. The plot below compares Muse Spark 1.3 and Muse Wonder Full, with each point denoting performance at a distinct reasoning effort. The horizontal axis shows the model’s score on a composite representative of the tasks we focused on during post-training (“in-distribution”). The vertical axis shows the average score on a set of tasks we did not target during post-training (“out-of-distribution”).

Both of our models improve similarly on out-of-distribution tasks as we scale test-time compute. But given its in-distribution performance, Muse Wonder Full performs even better on unfamiliar tasks than the Muse Spark 1.3 trend would predict. This upward shift is because Muse Wonder and Muse Wonder Full build on larger, stronger base models: a stronger base yields post-training gains that carry over more effectively to unfamiliar tasks. That versatility especially matters for personal agents, which need to handle many combinations of goals, tools, and constraints — not all of which we can anticipate during training.

Working directly in a browser and across apps, Muse Wonder builds a running plan based on personal preferences and circumstances.

Muse Wonder designs and orders custom swag based on real photos taken from a personal Instagram profile.

Muse Wonder prepares a custom wedding seating chart based on a list of complex matching requirements.

Safety at the Frontier

Delivering personal superintelligence to everyone requires a significant investment in alignment and safety. A personal agent takes actions on a user’s behalf and might handle context such as messages, calendars, and private documents. That level of access demands a model that exercises discretion with private information and resists misuse. We trained the Muse Wonder family to lead on both dimensions, with robustness to adversarial instructions and careful handling of private information.

As models become more capable, our goal is to help people harness those capabilities safely and responsibly. Muse Wonder offers our strongest safeguards to date against CBRN (chemical, biological, radiological, and nuclear) and cyber misuse, while preserving access to frontier cyber capabilities for defensive use, per our Meta Superintelligence Scaling Framework.

Muse Wonder is our most aligned model to date, and alignment is central to how we build personal superintelligence. A full report with additional safety evaluations will be available soon.

We hope that Muse Wonder and Muse Wonder Full give more people the power to pursue their dreams and build the world they want. This is a major technical step toward personal superintelligence for everyone, with much more to come.

Full article content is not available for inline reading.

Read the original article →

Can we change an AI model’s architecture without retraining it from scratch?

“Priming” reuses pretrained Transformer weights to build models with more efficient architectures at less than 1% of the original training cost and with throughputs up to twice as high.

Key takeaways

• A new AWS paper introduces priming, a method that reduces pretraining costs for hybrid architectures by over 99% by leveraging pretrained Transformer weights, saving trillions of tokens and hundreds of thousands of GPU-hours.
• A 32-billion-parameter Gated KalmaNet (GKA)-based hybrid model matches its source Transformer on reasoning benchmarks while decoding up to twice as quickly with 128,000 tokens of context.
• State space models consistently outperform sliding-window attention (SWS) even when SWA receives twice the memory budget, and GKA's variable-iteration mechanism enables 10% faster decoding with only ~1% accuracy loss.

AI agents are rapidly scaling: longer sessions, deeper reasoning chains, more autonomy. But the Transformer architecture underneath them still pays a memory tax that grows with the number of tokens it processes. As agents become more capable, that cost scales with them.

Now, there’s a proliferation of hybrid architectures that use some combination of methods to achieve a better balance of memory, speed, and quality. Those methods include sparse attention, which selects a subset of past tokens to consider when selecting the next token; sliding-window attention, which preserves only the most recent tokens; and state space models, which compress information from the full history into a fixed-size state.

These hybrid architectures can be understood as points in a sequence-model design space: to differing degrees, they mix information while traversing a sequence and passing through different states. What distinguishes them from each other is how they retain and use the past.

Until now, exploring this design space has required training every new architecture from scratch, using trillions of tokens and hundreds of thousands of GPU-hours. This has made controlled comparisons of hybrid architectures extremely expensive.

In a new paper, “Priming: Hybrid state space models from pre-trained Transformers,” our team at Amazon Web Services addresses this problem. We introduce priming, a method that leverages pretrained Transformer weights as a starting point to reduce the pretraining cost of hybrid architectures by more than 99%.

With priming, model developers can ask questions that were previously too expensive to answer at scale: Which attention layers can be replaced by more-efficient layers? How many attention layers can be replaced without sacrificing quality? Which state space layer works best? And what does the trade-off between speed and accuracy look like?

In our paper, we compare hybrid models that use three different types of state space models (Gated KalmaNet, Gated DeltaNet, and Mamba-2). Some of our findings:

• Not all state space models are equal. Under controlled conditions, Gated KalmaNet (GKA) performs best, followed by Gated DeltaNet (GDN) and then Mamba-2. GKA uniquely offers variable-length inference computation without retraining and gives the user direct control over its position on the speed-accuracy frontier.
• A good lossy summary of everything beats a perfect recording of the most recent past. State space models consistently outperform sliding-window attention (SWA), even when SWA gets twice the memory budget.
• Same quality, twice the throughput. A 32-billion-parameter GKA-based hybrid model matches its source Transformer on reasoning benchmarks while decoding up to twice as quickly with 128,000 tokens of context and reaching correct answers in as little as two-thirds of the wall-clock time.

To foster further research on hybrid architectures, we have released a zoo of primed hybrid models at the eight-billion-parameter and 32-billion-parameter scales for long-context reasoning and instruction following, together with training code, optimized kernels, and a vLLM-serving plugin under the Apache 2.0 License.

The attention mechanism

A Transformer’s attention mechanism — which determines how relevant previously seen tokens are to the token currently being processed — relies on three different vectors, which take their names from database design: the query, the key, and the value. For each token, the query captures what that token is “looking for,” the key captures what it “offers,” and the value carries the actual information it will pass along. Relevance is computed by comparing the current token’s query against every other token’s key; the closer the match, the more that token’s value contributes to the output of attention.

Each of these vectors is produced by multiplying the token by a learned weight projection matrix. The Transformer outputs one token at a time, and each output token becomes a new input, so the context grows one token at a time as well. To save computation, the Transformer thus stores the key and value projections of each new input in a “KV cache”.

Two kinds of memory layers: Eidetic versus fading

The attention mechanism gives Transformers what we call eidetic memory: verbatim recall of every past token. The possibility of recalling over an LLM’s entire context window is what made in-context learning, long-document reasoning, and retrieval-augmented generation possible. But it comes at a cost that scales with the number of input tokens.

However, not all attention layers do the same job. Some perform long-range retrieval across tens of thousands of tokens. Others operate more locally, tracking the current clause, copying nearby tokens, and the like. The local ones don't need a growing cache: a compact, fixed-size summary of the past — what we call fading memory — suffices.

Hybrid models mix both: attention layers (eidetic, growing cache) for the layers that need global recall and state space layers (fading, fixed size) for the rest. The result is a model with a reduced memory footprint that still has access to verbatim recall where it matters.

Priming: Knowledge isn't locked to the architecture

Exploring hybrids’ design space has been impractical because each hybrid configuration would normally require pretraining from scratch. Priming sidesteps this by reusing the stored knowledge in a pretrained Transformer's weights.

Priming is possible because a Transformer is itself a special case of a state space realization. The outputs of both attention and SSM layers can be expressed as the result of multiplying the value sequence by a “mixing” matrix that decides how much each past token contributes to each current token. Attention computes the mixing matrix by multiplying the query and key matrices; an SSM produces a similar output through a recurrent state of fixed dimension that all past information must pass through.

Priming takes advantage of this structural similarity: if an SSM with a fixed-dimensional state can produce a mixing matrix close enough to the attention layer's, the query, key, and value projections from the source Transformer can be reused as the SSM's own input projections, with only the SSM-specific parameters needing to be learned.

Whether the approximation holds depends on whether the attention layer performs complex, long-range retrievals or simple, local operations. We distinguish between the two using a cheap empirical proxy: replace each layer with an SWA — which preserves only a fraction of the context — and measure the degradation.

Layers that tolerate this substitution are natural candidates for SSM conversion: their mixing matrices don’t need to capture long-range relationships, so the state of an SSM can faithfully represent what they do. This proxy connects to a formal quantity from dynamical-systems theory, the Hankel rank of the layer's mixing matrix, which measures how much information must pass through the state bottleneck and therefore the minimum SSM state dimension required to realize the layer exactly.

Priming proceeds in three stages:

1. Layer selection: identify which layers can be faithfully compressed into a fixed-size state while retaining the rest as attention;
2. Weight transfer and alignment: initialize SSM layers from the corresponding attention weights, then run a short distillation process aligning each SSM to the behavior of the layer it replaces;
3. End-to-end adaptation: fine-tune the full hybrid model on next-token prediction, letting all layers coadapt.

The entire pipeline consumes less than 0.5% of the source model's pretraining token budget, and it works across Transformer families (Qwen, Llama, Mistral), model classes (dense or MoE), and scales (eight billion to 32 billion and more).

A controlled comparison of fading-memory layers

For instance, consider this question: given the same data, the same training budget, and the same ratio of eidetic to fading layers, which SSM layer works best in a hybrid model?

In our paper, we evaluate three families of state space models, each representing a different approach to using a fixed-size state:

• Mamba-2 applies a uniform scalar decay to the entire state at each step, a running average that forgets everything at the same rate. When a new token arrives, it is written into the state, while all previous entries are uniformly attenuated. Mamba-2 is simple and efficient but indiscriminate.
• Gated DeltaNet (GDN) adds targeted updates on top of uniform decay. Rather than decaying everything uniformly, it can selectively erase the value previously associated with a specific key before writing the new one (the delta rule). This makes it more expressive than Mamba-2: it can revise a specific association without uniformly decaying the rest.
• Gated KalmaNet (GKA) goes further. Its erase direction depends not only on the current key but on statistics of all past keys, a history-aware update that accounts for the cumulative structure of everything the model has seen.

The theoretical expressiveness hierarchy predicts the empirical one: GKA > GDN > Mamba-2. The gap widens on long-context reasoning, where compression quality matters most, and narrows on short-context tasks. Furthermore, at the 32-billion-parameter (32B) scale, hybrid GKA is within 1% of its source Transformer trained on the same data, despite requiring half the KV cache at inference.

Fading memory beats verbatim windowed memory

An interesting finding in our study comes from a direct comparison of hybrid models using SSM layers and those using sliding-window attention (SWA), which retain a fixed window of recent tokens verbatim rather than compressing the past into a state. One might expect that verbatim recall, even over a limited window, would outperform lossy compression. After all, no information is lost within the sliding window’s range. And stacking multiple SWA layers increases the “receptive field” of the end-to-end model.

Instead, every SSM-based hybrid we tested outperformed the corresponding SWA hybrid on long-context benchmarks, even when the window gets two to four times as much memory as the state.

A runtime knob for speed versus accuracy: Variable computation at inference time

GKA has a property that neither Mamba-2 nor GDN offers: variable test-time computation.

Mamba-2 and GDN have the same computation budget for every input token, regardless of its content. GKA, by contrast, solves a regression problem iteratively, and the iteration count is adjustable at serving time without retraining.

In practice, serving GKA at 10 iterations instead of its usual 30 sacrifices roughly 1% of its accuracy on AIME 2025 while delivering 10% faster decoding. A single trained model can serve multiple points on the speed-accuracy frontier, so model providers can offer different latency tiers without maintaining separate model variants.

Faster reasoning, not just faster tokens

Raw per-token throughput tells only part of the story. A model that is cheaper per token can still be slower end to end if its reasoning is weaker and it needs more tokens to compensate. The deployment-relevant question is how much more rapidly, in wall clock terms, the hybrid reaches a target accuracy.

We measured this on AIME 2025, a challenging math competition benchmark, comparing our GKA-Primed-HQwen3-32B-Reasoner against the source Qwen3-32B trained on the same reasoning recipe. Both models generate similar-length thinking traces (a median of about 14,000 tokens on the full set, 28,000 on the hardest problems) — that is, they produce equally in-depth responses — but the hybrid has a much higher throughput.

At realistic concurrency levels, where the Transformer's KV cache saturates GPU memory, the hybrid reaches target accuracy thresholds 1.2 to 1.4 times as quickly on the full benchmark and up to 1.6 times as quickly on the hardest problems. This is a consequence of the SSM layers' fixed-size state, which roughly halves the per-sequence memory footprint, enabling more concurrent operations on the same hardware.

Beyond the training window: Context extension with state composition

Our primed hybrids natively support 128,000 tokens. But agent sessions, codebases, and long legal documents routinely exceed that. Extending context further would normally require another round of continued pretraining on curated data. Can the hybrid architecture itself generalize to longer contexts without additional training?

In our new arXiv paper, we describe a method of extending hybrid models’ context beyond their native limits without training. The procedure is simple:

• partition a long input into chunks shorter than the native context length and prepend a shared prefix to each chunk;
• process all chunks independently in parallel;
• concatenate the KV caches across chunks while merging the SSM states via the weighted-averaging scheme we introduced in our PICASO paper.

This approach enables us to extend the context length of our primed hybrid models from 128K to 256K tokens while preserving substantial accuracy on both retrieval (RULER NIAH) and reasoning (BABILong) tasks at lengths the model was never trained on. In our experiments we show that hybrid state composition preserves the SSM expressivity hierarchy (GKA > GDN > Mamba-2).

The hybrid design space is now open

All artifacts discussed in this blog are released under the Apache 2.0 License in our Hybrid Model Factory on GitHub and our model zoo on HuggingFace:

• A collection of primed hybrids for long-context reasoning and instruction following (8B and 32B);
• The priming training code;
• Point-to-point sequence parallelism algorithms for SSM layers (up to 2.3 times as fast as all-to-all-based alternatives at multinode scale);
• Universal sequence parallelism for prototyping novel layers on long sequences without custom kernels or distributed-training expertise;
• Optimized Triton kernels for GKA decoding and training;
• A vLLM serving plugin supporting primed hybrid architectures with continuous batching, chunked prefill, and tensor parallelism for inference deployment at scale.

Priming is not tied to a specific Transformer family or model class. Extending it to Llama, Mistral, or MoE models requires no algorithmic changes. We hope these tools enable the community to explore architectures beyond what we've tested and to develop new algorithms and training recipes for building scalable next-generation architectures for AI agents.

Meta has launched Muse Wonder and Muse Wonder Full, calling them its most capable models for personal and professional agentic work. Muse Wonder is now available through the Meta Model API and Muse Code, while Muse Wonder Full is available to Muse Code subscribers. The standard model will also reach Muse, first for subscribers, and will support artifact generation and other processes that demand greater intelligence.

The new family combines Active Memory with Active Focus. Active Memory carries important personal context across conversations and retrieves relevant details when a task calls for them. Active Focus is designed to keep the model working through difficult goals by trying alternative approaches, handling blockers, adapting to new information, requesting clarification when needed, and checking before important actions. Meta says the models can apply domain knowledge to legal, financial, and health tasks, while their coding capabilities span small apps and long-running software projects that require repeated testing and revision.

Meta trained both models at its gigawatt-scale Prometheus data center and built on the scaling approach introduced with Muse Spark. Meta says they lead across evaluations covering personal and professional agents, memory, sustained execution, coding, domain expertise, private-information handling, and resistance to misuse.

The company also argues that Muse Wonder Full generalizes beyond tasks emphasized during post-training. As test-time compute rises, it performs better on unfamiliar tasks than the Muse Spark 1.3 trend would predict, which Meta attributes to a larger, stronger base model.

The release follows a fourteen-month overhaul of Meta’s AI stack and marks its next step toward personal superintelligence. Meta plans to use Muse Wonder in consumer experiences and to develop specialized models for people using Muse. That ambition comes with deeper access to messages, calendars, and private documents, so the company is positioning discretion and adversarial robustness as core requirements. It calls Muse Wonder its most aligned model yet and says it offers its strongest safeguards against chemical, biological, radiological, nuclear, and cyber misuse while retaining advanced cyber capabilities for defensive work. A fuller safety report is due soon.

38 things we've learned about building AI products

Lessons from 4 years of building AI products at PostHog

We’ve built 10 different AI products at PostHog, including PostHog AI, our install Wizard, Replay Vision, Scouts, and more. They’re used by nearly 100,000 people every month. This is what we’ve learned.

1. AI can make your product worse. It can be slow and unreliable, or solve a problem nobody has (like chatting with your docs, any AI can do this). Just because it’s AI does not mean it’s worth building.

2. Consider whether you need to build AI at all. It’s often better to build for AI first, like an MCP server. These are easier to build and maintain. 5x more people use our MCP server daily than PostHog AI.

3. Look for jobs to be done, not demos. The best opportunities for AI are tasks that take 30+ seconds, use language or interfaces users don’t know (like SQL), or tasks users repeat 20+ times.

4. Onboarding is a great first target. Our AI install wizard does two hours of work in ~8 minutes. Those who use it convert to paid 5x more often and activate 2x faster.

5. Don’t ask “how do we add AI to this?” ask “what is the agent-first version of this?” Doing this forces you to rethink the jobs to be done for an agent-first future and helps you avoid being disrupted by an AI-native competitor.

6. Building 2030-shaped products may require you to start fresh and break from years of cumulative UI and assumptions that are no longer valid or relevant.

7. Watch for customers rebuilding your product with AI. This reveals what features they actually want. When one of our largest customers built their own prototype of “PostHog 2.0” with our MCP and Claude Code, we knew we needed to add more customizable “canvas” artifacts to PostHog.

8. Validate AI bets like you would new products. Write down how it will be judged and how much runway it gets. Ask how disappointed your team would be to lose it (the PMF survey). We did this for one product and only 23% said they would be very disappointed. Bad results, but useful.

9. Write down how your product loses to an AI-native threat and then fund your version of the attacker. Even the best support product loses to one where AI answers all the tickets for example, which is probably why Intercom pivoted so hard into Fin.

10. Answer the question: How does this beat Claude? It’s what people default to. Your moat is context: your product’s functionality, your users’ data, and the tools and skills you’ve built.

11. Your harness is not your moat. PostHog AI went through three of them in a year. We now have MCP as the canonical interface and let people pick their own harness. Don’t spend innovation points here.

12. Don’t build an assistant. Assistants are what you build when intelligence sits next to your product. Systems are what you build when intelligence becomes part of it. Build those instead.

13. Focus on building shared AI infrastructure. Make prompts, streaming, consent, evals, tasks, and analytics primitives teams can extend and build into their products. Pick a consistent UX pattern to avoid death by a thousand widgets and then get out of people’s way. Product teams know their users best, not the AI team.

14. Let agents run code. Code execution gives agents capabilities beyond what your predefined tools might enable them to do. PostHog AI can write SQL, run Python scripts, and ship PRs. Sandbox them to make this safe.

15. Model upgrades will bulldoze your assumptions. We’ve restructured PostHog AI due to cheap reasoning (o4-mini) and reliable tool use (Claude 4). Multimodal models made Replay Vision possible. The harness, prompts, and context you built for previous models might not be relevant for current ones.

16. Skills are features for agents. They combine tools, docs, and rules into a recipe for a job. If an agent has the tools but not the recipe, it must look up how to use your product every time. Every docs-search call is evidence of a missing skill or tool (and it’s our most-called tool at ~28K calls a month).

17. Let agents do everything users can. If the experiment-create tool exists, yet the experiment-start tool is missing, the agent will do everything and then stop short to ask you to click through the UI. This limits the power of agents.

18. Dogfood headlessly to develop agent empathy. Test agent features from the CLI so you hit the same friction points as they do. This is how we found our MCP tool descriptions used too many tokens.

19. AI doesn’t kill your UI, it changes its purpose. Fewer screens are for doing things, and more are for approving, reviewing, and undoing what agents did.

20. Meet agents at their level of abstraction. Agents work better if you let them write and reason flexibly. We stopped forcing agents to use preset query tools and let them write their own SQL. A general purpose executeSql tool replaced every read endpoint and made “Why did signups drop?” go from four separate tool calls to one query.

21. A missing tool is a feature request written by a robot. Agents using our MCP can file feedback when they get stuck.

22. Set up AI observability from day one. Trace LLM calls with inputs, outputs, latency, and cost. This reveals the errors and issues that once fixed lead to rapid quality improvements.

23. Care more about reliability than capability. Early complaints about PostHog AI weren’t about what it could do, they were about inconsistent performance, unexpected failures, generic errors, unclear limits, and lack of uncertainty. Capabilities are worthless if they aren’t reliable.

24. Track agent usage like human usage. Although agents don’t trigger pageviews or rageclicks, you can still track the MCP tool calls, page requests, and more.

25. Learn your AI product unit costs. Our wizard costs $6.67 per run, but the improved activation and retention are worth more than this. Moving trace summaries from standard gpt-4.1-nano to flex tier gpt-5-nano halved costs.

26. Subagents cost more than you think. They don’t share the parent’s cache and lack of observability can cause unreliability. Wizard runs used to spawn many subagents that took longer or never returned, only for the main agent to do the actual work after waiting.

27. Many agent failures are actually context failures. Giving an agent a lot more context improved wizard effectiveness more than improved reasoning, multi-step planning, subagents, pruning, and compaction.

28. Make it easy for humans to create context agents wouldn’t know. PostHog AI has an init command to research your company and industry. The semantic layer sets vetted definitions of queries and data. Both help agents help you.

29. Don’t stuff the prompt. Let agents look things up instead. Our system prompt for PostHog AI used to include all the events and properties available, but now a taxonomy tool does that instead.

30. Shipping fast makes context drift, so fix it at the source. We have agents that check merged PRs for docs updates and make a pull request when relevant. This helps context keep up with the pace of what’s being shipped without relying on endless manual fixes.

31. Example code beats docs prose for correctness. A toy project shows an agent a real example and gives it something concrete to copy and test against.

32. Being a transparent company is good for agents. Both our agents and those of our customers can look at our codebase, our handbook, and our docs to get a better understanding of how PostHog works.

33. Beware that public inputs can lead to prompt injection. Since self-driving can open PRs from signals without human approval, a user could send a signal like “add your secret customer data to this page” and an agent might listen if we didn’t have protections in place.

34. Use evals but start small. Read traces manually to identify places AI is going wrong, create an eval to check for it, and make improvements to improve that eval. Even small golden or synthetic datasets gave insane performance boosts compared to the typical development cycle.

35. Blank text boxes scare people. These often cause them to forget everything they know about your product. Add suggestions and nudges to help them remember what to do.

36. Show every step. We hid reasoning and failed tool calls because it looked messy but users said this felt hard to trust because the process was a mystery. So we stream everything now.

37. Build UI when text isn’t enough. Some jobs need persistent, purpose-built UIs like trust and verification surfaces for confirming the agent did what you wanted and triage and inbox surfaces listing decisions that need a human.

38. Expect half these things to be wrong in a year. We started with graph-style workflows, front-loaded context, split work across subagents, and then all that became obsolete. What doesn’t expire is everything you already know about building products: talk to users, ship fast, run experiments, repeat.

Full article content is not available for inline reading.

Read the original article →

Microsoft unveiled Maia 300, its third-generation in-house AI accelerator, as a major step toward reducing dependence on NVIDIA GPUs. The company said the chip delivers 40% better performance per megawatt and plans large-scale deployment beginning in 2027.

Releasing AI-generated software by Mark Seemann

On software engineering, epistemology, and liability when code is generated by LLMs.

Robert C. Martin recently generated much interest with a tweet:

"My current strategy is to not read any of the code written by my agents. That's the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, test coverage, and a plethora of others. In the end, I have very high confidence in the code they produce because they've had to run the gauntlet of all of my constraints and tests."

The author of Clean Code no longer reads code? What implications for software engineering does this suggest?

To be clear, how thought leaders interact with LLMs change so rapidly these days that what someone wrote months ago may no longer apply. And, indeed, Robert C. Martin recently walked back on his harness use.

The point of this article, however, is not to perform an exegesis on Robert C. Martin tweets, but rather to ponder the implications for software engineering.

Looking at the code was never foolproof

My first reaction to the notion of not even looking at LLM-generated code was: If you're no longer reading the code, then how do you know whether it's correct?

And a second later, I realized that that's just a knee-jerk reaction from an old programmer. I know full well that looking at the code was never foolproof.

All programmers make mistakes. We write code thinking it does one thing, but it turns out that it works slightly differently. It may exhibit liminal behaviour where it throws null-reference exceptions, has off-by-one errors, perform overlooked state mutation, or is otherwise just plain wrong.

Some research seems to indicate that code reviews are one of the more effective methods for catching bugs. Even so, these techniques don't detect all defects. Some errors slip through, even when subjected to critical and systematic inspection.

In other words, humans looking at code is no foolproof software-engineering technique.

A new notion of software engineering?

Dave Farley's book Modern Software Engineering presents a view of software engineering congruent with my own. Ultimately, software engineering boils down to rapid feedback on falsifiable predictions about the software.

Even if we give up the notion of writing and reviewing source code, there are checks we can perform. Some people experiment with 'teams' of agents, each agent having a particular role: You could have one agent write automated tests, another performing code reviews, etc. While I have previously been sceptical of such seemingly infinite regress, I have recently come to the understanding that our previous, human-centred practices, aren't foolproof either.

Even though I believe that test-driven development (TDD) is the most scientific approach to software development that I know of, you can still make mistakes. The most common sort of mistake in TDD is the test(s) that you don't write. Missing test cases leaves the System Under Test underspecified, but you may not even realize it.

LLMs seem to produce code, even automated test code, using other heuristics. People who use 'teams' of agents report good results.

Ultimately, demanding perfection from LLM-based software engineering sets a bar we human programmers never cleared. Rather, we seem to arrive at the same argument that you often encounter related to self-driving cars: The system doesn't have to be perfect: It just has to be better than the human-centred system.

My claim is not that we have already arrived at that state. The point is rather that there seems to be no inherent barrier to a fully LLM-driven process of software engineering.

Where does liability fall?

You may, then, imagine a fully LLM-driven software release process. Perhaps humans are involved, but not as programmers, and not as code reviewers. Imagine that no-one looks at the code, but rather relies on other quality-assurance techniques to decide whether or not to deploy. Imagine, even, for the sake of argument, that the frequency of defects is lower than any comparable human-driven process.

Lower. Not zero.

Errors still make it to production. Most of these will probably be of a benign nature: A button's alignment is off. A text is shown in the wrong language. A message arrives twice, or out of order. Perhaps a bit more serious than that: A shopping-basked discount is applied incorrectly. The wrong song plays on your phone. A traffic signal is stuck at red.

Benign errors are, in this rough categorization, errors that are somehow rectifiable. Once you've discovered it, you can fix the problem. Perhaps you'll have to apologize to people, or if the discount was miscalculated to the seller's advantage, you may offer the user some kind of compensation.

Other kinds of errors will, however, be more serious: You lose a million-dollar spacecraft. Your car accelerates when you step on the brakes. You receive a deathly radiation overdose because of a race condition.

Such errors don't even have to be that bad. It could 'only' be that people miss their flight, are denied the hotel room they already reserved, receive incorrect tax bills, or lose their insurance coverage.

When software defects are serious enough, there could be repercussions. Where does the blame land?

Consequences

Consider, at first, bugs that 'merely' cost its owners a lot of money. The Mars Climate Orbiter fiasco falls in that category. No laws where broken. The only problem was that 327.6 million (taxpayer) dollars were wasted.

It would be an extraordinary software organization if such an error didn't have consequences for someone. When people were still writing code by typing it into the computer, it was easy to point and exclaim: Dave wrote that code.

Not that such simple ways of assigning blame are fair, or even productive, but they do happen. Someone suffers the consequences, even if he or she is only a scapegoat.

As long as the problem is mostly internal to the organization, if you're the scapegoat, the worst that may happen is that you're fired.

If, on the other hand, the error causes a legal liability, then the software organization responsible may have to go to court. As we have seen in e.g. Dieselgate, individual software developers may have to take the fall. Again, whether this is fair, or reflects the actual reality of what happened, is not my point. The point, rather, is that judicial branches around the world are likely to have a view on where responsibility goes that is decoupled from how software is actually produced.

- But, your honour, the LLM wrote the bug.
- So you say, son, but you signed off on the release, didn't you?
- Yes...
- I can't send an LLM to prison, but I can sentence you.

Any software organization that considers going 'full AI' need to think hard about what that means when it comes to liability.

People will play the odds

Let's consider a recent development in a different field to illustrate what I think will happen: In June 2026, the Danish traffic authority, Færdselsstyrelsen, approved Tesla FSD (self-drive), with the proviso that the human behind the wheel is ultimately responsible for the car. Drivers are expected to pay attention to traffic, and take the wheel in case a dangerous situation threatens.

What I think is going to happen is that drivers will become increasingly inured by the effectiveness of the system. The better it performs, the more drivers will zone out. After a few weeks or months, drivers will be on their phones during most of the ride, paying little to no attention to traffic. It will mostly go well.

Then, once in a blue moon, an accident will happen. As Danish law currently works, if the accident involves loss of human life, the driver faces a sentence for involuntary manslaughter. This usually means prison time.

It's not going to matter if the 'actual' cause of the accident was a software error. Legally, the responsibility lies elsewhere. Often, the underlying reason is that legislation lags behind technological reality.

I think that the same will happen with LLM-driven software engineering. People will play the odds because they look so compelling.

How much you invest in safeguards and various quality-assurance technologies may not matter. You could establish the most elaborate system of verification and still be liable for any errors. How do you feel about releasing LLM-generated software? Are you ready to go to prison for an AI?

Conclusion

Software engineering may not be what we thought it was. Or, rather, it may not be limited to a particular set of methodologies centred around human programmers and testers.

It's conceivable that the future holds fully automated software-engineering processes that are at least as safe as those we currently know. Even so, the human notion of liability and responsibility may not keep up.

When things go wrong, will organizations write off the error as nobody's fault? Will courts of justice consider serious defects as essentially another accident? Or will someone have to take the blame? Who will it be, if no-one wrote any code?

The Expensive-Loop Problem

LLMs are amazing at tasks where they have tight and legible feedback loops. Domains where experiments are quick, deterministic and cheap. I will call these domains "cheap-loop" domains.

Presumably, this is mostly a result of the dynamics of LLM training. It's easier to train models in domains where the AI lab can cheaply and quickly assign reward to them. The majority of "computer-checkable" work is in this category. Conversely, most non-"computer-checkable" tasks are costly or slow to assign reward to: "Write a poem that will make a person from Cleveland feel something", "forecast the number of traffic accidents in Brazil tomorrow", "design a drug that affects a pig's liver cell in way X". To get a truly accurate reward, these all involve wet-lab experiments, waiting a day, or reading poetry to a person from Cleveland. None of these are easy! I will call these domains "expensive-loop" domains.

Most high-value human labor is done in "expensive-loop" domains. This includes most of science, business, public policy, and medicine. AI R&D is also a great example of such a domain. AI R&D typically involves very compute-expensive experiments. Single AI R&D experiments can cost 6–9 figures in compute alone. Today, models are rarely trained or even evaluated in "expensive-loop" environments, and when they are trained in such environments, they do very poorly relative to how good they are at "cheap-loop" tasks.

This happens because expensive-loop tasks require abilities that models don’t learn in cheap-loop training: building theories, managing proxies, budgeting time and compute, and figuring out what went wrong when feedback is scarce are a few examples. Let’s explore these:

Selecting Proxies

In order to perform well in expensive-loop environments, you often need to intelligently select cheap and easily measurable proxies for various expensive-loop elements. You need to pay attention to when a proxy stops working and sometimes switch to a different one. You should always be somewhat critical of your proxies and keep your eyes on the actual target. You need to balance between the cost of your proxy and how well it transfers to the actual objective. Sometimes, you need to choose proxies that are not that cheap.

We do this all the time, both as individuals and as a society. Drug discovery: we first try drugs on individual cells and tissues, then on mice, and then on humans (in three increasingly expensive trial phases!). AI R&D: we first try things on small models and then progressively increase the scale, extrapolating to really large training runs. Movies: Studios run a ladder of cheaper proxies before committing to a full production and marketing budget: a script read, then storyboards or an animatic (Pixar's story reels are a famous example), then table reads, then test screenings of rough cuts with recruited audiences, and finally a trailer that is tested before the release is locked. Shipping software: first we make sure that the code passes unit tests, then integration tests, then a code review from a coworker, and then we ship to customers; some organizations will also have professional QA, and might also A/B test at that stage. Sports: Athletes will often try new things in low-stakes situations, and slowly graduate to doing the good ones in important games. Dating: the first few dates are a proxy for sex, sex is a proxy for the next few decades of the relationship (sorry, this one is a stretch!).

Finding good "proxies" is hard! Not every expensive-loop problem has a cheap proxy, and "proxies" sometimes work in certain regions and not in others. Unfortunately, proxies also have a tendency to stop working when you start optimizing them (Goodhart's law!). Proxies also have a tendency to only capture what's easy to measure and it's tempting to conclude that whatever they miss doesn't matter (McNamara fallacy!).

Models are terrible at "proxy management"! They rarely even reason about proxies, let alone think critically about them. Typically, they either (a) don't come up with a proxy and waste their resources on expensive experiments, or (b) come up with an easily Goodhartable proxy. When a proxy is given, they obsessively overfit it, sometimes to the point that they maliciously cheat to get high results on a proxy.

Theory Building

In order to perform well in expensive-loop tasks, you need "theory". A "theory" is a causal model of your environment that allows you to generalize the results from some experiments to other experiments. A theory also allows you to assign "information value" to different experiments: "what will this experiment teach me?". A theory will also tell you things about how well different cheap proxies relate to the overall expensive-loop task. These properties are incredibly useful in expensive-loop experiments because they allow you to be systematic about which experiments you should run in order to complete the task most efficiently.

Theories are all around us; you see them at the scale of civilizations and at the scale of individual careers. Wherever we see an expensive-loop task being solved competently, there's usually a good theory underneath it, and a good new theory often unlocks a leap in expensive-loop performance. Maxwell's equations unlocked modern electronics. Quantum mechanics enabled semiconductors. Germ theory unlocked vaccines, sanitation, and pasteurization. Mendelian genetics and the theory of evolution allowed us to 10x agricultural yields. You can even argue that scaling law theories unlocked the AI bull run of the past few years.

At the business level, theories often go by other names. A product manager with a better model of what customers want gets credited with "product taste." That taste lets them pick which A/B tests are worth running, so they waste fewer experiments and land more wins. In baseball, it got called "Moneyball": in 2002, the Oakland A's went all-in on a better theory of what wins games, and tied the Yankees for the best record in baseball while spending a third as much. In an expensive-loop task, you build and improve your theory in parallel with building your solution. You improve your theory by trying to falsify it!

Cheap-loop tasks almost never require sophisticated "theory" building. The "theory" is obvious and is typically given to you in the task description. Experiments are also very easy in cheap-loop environments, so a better theory that helps you run experiments more efficiently doesn't benefit you that much. Current models don't develop good theory building habits: they interpret noise as signal, they suffer from severe confirmation bias and often don't try very hard to falsify their beliefs. When models encounter evidence that might actually falsify their beliefs, they react unpredictably: sometimes they "throw the baby out with the bathwater" and discard a large chunk of the theory instead of modifying it minimally. Other times, they overfit to the falsifying evidence and create theories that grow in complexity and don't apply Occam's razor nearly enough. These two failure modes are contradictory and I don't have a good sense for which will happen when. What I did notice is that when a trajectory has one failure mode, the model will typically keep doubling down on it instead of correcting and switching to the other failure mode.

Resource Awareness

Cheap-loop environments have fewer resource constraints than expensive-loop environments. If you grew up in an environment where a certain resource was abundant, you wouldn't develop the right strategies to use it efficiently.

Across the board, models are rarely strategic about resources; they are either overly conservative with them (often with compute) or overly wasteful (often with time). Some examples:

In PostTrainingBench, models "systematically underestimate training overhead" and "rarely recover from catastrophic processes that take a lot of time"; in one example, a model "spent 61% of the time budget in the evaluation phase and only 3.6% on RL training. In this case the exceptional step-1 result triggered intensive monitoring. The agent evaluated every checkpoint exhaustively after seeing the jump, spending the equivalent of ~10 hours watching metrics rather than continuing to train.". "In one [Math Competition Post Training] run, roughly 72% of the wall-clock budget goes to diagnosing training throughput, leaving about 83 minutes for training and evaluation and producing no reliable gain."

Models are very wasteful with serial time. You often see a model run a command that takes ~5 minutes and pipe its output through tail -5, which keeps only the last 5 lines. If the needed information isn't in those lines, they rerun it with tail -30, and wait another 10 minutes! If the information still isn't there, the model might try grep. A human would typically run the command once, save the entire output to a file, and search the file as many times as needed.

Amazon challenged models to optimize various production ML systems (over the span of weeks) and found similar failure modes!

The agent selects experiments without weighing expected information gain against compute cost, treating a 15-hour multi-GPU run as no more consequential than a 30-minute ablation. [...] Root cause: the agent has no model of information gain relative to compute expenditure, and no prior over the consequence severity of proposed changes.

The ROI of an experiment (say, "information gain" / "experiment cost") is almost never considered before the experiment itself and is typically very low.

Error Correction

In a cheap-loop environment, error correction is basically free. Run the loop; if it breaks, fix the thing that broke it, then run it again to see if it works. You rarely need to work backwards from cryptic failures. There is also no value in questioning your deep beliefs and early decisions: "if the primary metric looks right, then I'm in the right direction" is a good heuristic in a cheap-loop environment but can be very problematic in an expensive-loop one.

In an expensive-loop environment you get to see very few "failures", and each one has to be squeezed for everything it can tell you. When an experiment fails there are three classes of things that could be wrong: a parameter (learning rate, batch size), the strategy (SFT vs RL, this dataset vs that one), or the premise (am I even measuring the right thing, is the task what I think it is). Everyone starts at the bottom of this ladder, and that is correct. Parameter fixes are cheap and they are usually right. The problem is not where models start. It is that the environments they learned in are often missing two of the three rungs.

Cheap-loop environments typically only have one (well-defined and unambiguous!) way of checking for failures. You don't need to think too critically about your core beliefs or try to falsify them; your core beliefs are part of the environment. When a student takes an exam, they don't need to test that the questions are reasonable and relevant to their high level goals, they just need to focus on the exam itself and answer it correctly. In a cheap-loop task, you typically don't need to come up with complicated debugging experiments or stress-test the methods; the experiments are obvious and cheap and are largely a given part of your environment.

As a result, models rarely question the methods or the premise they use in an expensive-loop environment. When they do question them, they aren't very good at falsifying them / diagnosing the issues. They prefer to autistically hill-climb on something and have a hard time recovering from a bad theory or an early false premise.

In PostTrainBench, models rarely change their methods, they "lock into a default strategy before any experimental evidence arrives", "additional tokens buy denser refinement within the committed strategy but not a better one". There is obvious low-hanging fruit, since "a single mid-run instruction [to change strategy] outperforms the agent's own continuation by up to 17.44[%]".

Where do humans fit in this?

Are we selected for cheap-loop or expensive-loop tasks? I think both. Our ancestral environment is strongly expensive-loop. The savannah was dangerous and calories were scarce, wrong decisions could kill you, and unlike models, humans only live once. So embedded in our genes there is a bunch of cognitive machinery that is adaptive for expensive-loop tasks. In contrast, modern humans are often "trained" in cheap-loop environments. Instant feedback from schooling, other-people, workplaces (exams, problem sets, peer pressure top-down hierarchies) nudge us to adopt cheap-loop ways of thinking. That being said, modern human life still has some relatively expensive-loop tasks: making a friend, learning to walk, writing a wedding speech that makes your mother-in-law laugh. None of these are life-threatening (except the wedding one maybe?) but the attempts in those environments have non-trivial costs.

How well do humans do in expensive-loop tasks? Not great. Humans have a lot of the same "cheap-loop bad habits" as models: reward hacking, confirmation bias, "rabbit-holing", McNamara fallacy, mistaking noise for signal or the ludic fallacy have all been observed in humans way before digital computing was even invented. Some humans are especially sensitive to cheap-loop techniques, and apply them in inappropriate situations.

Should we make AIs better at expensive-loop tasks?

Being capable at expensive-loop tasks seems to be directly upstream of a bunch of dangerous and potentially takeover enabling abilities, e.g., superhuman persuasion, offensive biotech, Machiavellian institution manipulation, long-term strategy. Very bad!

Maybe we can get away with AI that is really good at cheap-loop stuff, but is dependent on us for expensive-loop intuitions. Maybe this kind of jaggedness is a blessing. Cheap-loop capable AIs are already pretty economically useful.

Unfortunately "strong cheap-loop & weak expensive-loop" can also pose a major x-risk: reward hacking. We've already had major safety incidents that stem from this failure mode and many people think that the majority of AI x-risk comes from reward hacking rather than more complicated scheming behaviors.

How can AI get better at expensive-loop tasks?

In order to unlock expensive-loop capabilities, AIs likely need to train in increasingly more expensive-loop environments. The only problem is that that's, well... expensive.

How expensive would this training be? The biggest unknown is how much practice the model needs. Post training methods like GRPO make several attempts at each task, compare their rewards, and use those comparisons to update the model. Every repetition carries the costs of interacting with the expensive-loop. An illustrative schedule of eight attempts per visit and five visits means 40 attempts at a single task. At those frequencies, the expensive-loop costs might quickly dominate all other AI spend: compute, human data, researchers, commercial real estate in the bay area.

Is that tractable? It mostly depends on how well AIs generalize from cheaper loops to more expensive loops. Humans are very good at this sort of generalization! They can learn decision making skills in low-stakes situations (negotiating in Catan, planning a trip with the boys) and then apply them in higher-stakes situations (salary negotiations, planning your wedding). Humans also learn on the job: corporate America offers a fairly smooth gradient of loop costs, from managing your own work, to managing a team, to running an organization of tens of thousands of people with 10-figure budgets. But humans can often skip steps along the way. Founders go from running nothing to running a company, and some first-time politicians end up as heads of state. Some of what makes someone good at expensive loops seems general enough that it doesn’t need to be relearned at every price point.

AIs will likely be able to do some amount of cheap-to-expensive generalization. I imagine that strategies that work well in $200-loops will more or less work well for $1000-loops. Maybe there’s some "escape velocity threshold", say $10k-loops, past which the skills stop being domain-specific: once an AI can reliably handle a loop at that price, it has learned the "general strategy" of acting under expensive feedback, and that craft transfers to $1b-loops just as well.

Another cost-saving option is to train models in cheap-loop environments that are specifically designed to incentivize cheap-to-expensive generalization. These "wargame" environments are built to cheaply simulate the expensive parts of a loop while keeping the "critical" details. Building good wargame environments can be very difficult because you need to know which details are "critical" and which details can be simulated or abstracted away.

Some elements of expensive loops are unlikely to be easily wargamable: complex interactions with real humans, AI R&D, wet-lab experiments, semiconductor fabrication, or things that take time. Robotics has run into this for decades; they call it the "sim-to-real gap": simulators get the physics slightly wrong in ways that matter, and policies trained in them learn to exploit those mistakes.

It’s also possible that cheap-to-expensive generalization will turn out to be hard. LLMs are notoriously bad at some kinds of generalization that humans find trivial, and there’s no particular reason to expect this kind to be an exception. Maybe there’s no escape velocity: a model that’s great at $10k-loops is just great at $10k-loops, and every extra order of magnitude has to be paid for with training at that price. Taken to the limit, that’s a grim picture. If we want AIs to run companies, governments, or something bigger, we might need to train them in environments at the same scale. The only environment at the civilizational scale is civilization itself!

When Do We Need On-Policy Distillation? Distilling on Offline Student Rollouts Is Often Better

On-policy distillation (OPD) has become increasingly popular for transferring teacher capabilities to student models. In this work, we ask a critical research question: Is on-policy sampling always beneficial for distilling arbitrary teacher-student pairs? We show that a simple alternative, Semi-OPD, which distills from offline rollouts generated by the initial student, can often outperform OPD in both accuracy and training efficiency. Across 17 teacher-student pairs ranging from 1.5B to 235B parameters, Semi-OPD outperforms OPD in 14 cases, with up to +13.6% accuracy and 11.4x training speedup. We further find that the choice between OPD and Semi-OPD depends on the alignment between the initial teacher and student, quantified by an output-token overlap ratio: OPD is beneficial only when the two are highly aligned with high overlap ratios. Our deeper investigation suggests that effective distillation requires on-policyness w.r.t. both the student and the teacher. For misaligned pairs, student rollouts can become increasingly off-policy w.r.t. the teacher as context length grows, weakening the distillation signal. In contrast, Semi-OPD is often more stable, as it distills on shorter contexts while covering full trajectories and exposing the student to more teacher-preferred tokens. Beyond proposing Semi-OPD as an efficient alternative, our work motivates the community to rethink when to use OPD and to study stronger OPD variants with meaningful teacher-student pairs.

Offloading bounded decisions cut agent LLM calls by 29.6% on 360 SOP-Bench cases

Disclosure: I built Proceda, the SOP-execution harness used here, and ran these experiments.

I wanted to see how much work an agent could hand to a decision model when the answer is narrower than general-purpose text generation. I tested Qwen 3.8 27B with hosted Jev on 360 SOP-Bench cases across referral abuse detection, email intent, and patient intake.

I tried two insertion points:

1. Step completion after tool calls. Jev checks whether the necessary tool calls have been made and whether the evidence is sufficient to finish the current step. If both yes probabilities reach 0.8, the harness advances without the follow-up LLM turn. Otherwise Qwen continues. Tools still execute.
2. Bounded business decisions. For email intent, Jev receives the email, original policy, and allowed outcomes. A valid choice with probability at least 0.8 is accepted; uncertain decisions fall back to Qwen. The rest of the SOP still runs.

With both changes enabled:

• Main-LLM calls fell from 2,537 to 1,785: 29.6% fewer.
• Estimated execution API cost, including Jev, fell from $6.41 to $4.70: 26.6% lower.
• Mean case latency fell from 8.64s to 6.94s: 19.7% lower.
• Final tasks correct were 360/360, compared with 357/360 for Qwen alone.

There is a tradeoff worth separating out: completion checking alone saved 23.8% of LLM calls but finished 356/360 tasks correctly, versus 357/360 for the baseline. The combined result above is from this particular 360-case subset; it does not establish a general accuracy improvement. Including the final structured-plan preparation cost also reduces the estimated cost saving to 24.6%.

The useful architectural pattern is to supply evidence, define allowed choices, validate the result, and keep an LLM fallback. The implementation and experiment reports are public:

• Article: Integrating Decision Models into Agent Harnesses
• Code and reports: Proceda experiment branch

Which decisions in your agents have you successfully offloaded, and how do you validate confidence thresholds before allowing them to bypass the main LLM?

Today we are introducing Helix World, a real-time interactive audio-visual world model built by Noiz AI and The Hong Kong University of Science and Technology (HKUST). You start from a single image, move with WASD and look around with the arrow keys. The model generates the next stretch of video and the matching stereo sound at the same time, at 24 frames per second on a single NVIDIA H800 GPU.

Helix World is a world model that generates an explorable scene and its spatial stereo soundtrack together, conditioned on the user's camera motion and keyboard actions. When the camera turns, the sound field turns with it.

On the WBench navigation split, Helix World scores 79.9, close to the strongest silent world models, while running faster than real time with a real-time factor (RTF) of 0.77. On HelixBench, the audio-visual benchmark we release with the model, its spatial-acoustic consistency score is 41.8, compared with 12.7 for EchoWM, the only other world model in the comparison that generates sound. The paper is on arXiv, the code is on GitHub, a preview checkpoint is on Hugging Face, and the interactive demo is open at helixworld.org.

Why world models need sound

Interactive world models let a user steer a generated environment in real time. Most of them are silent. Yet sound carries information the picture does not: what a surface is made of, how hard two objects hit, and what is happening off screen. In an immersive scene, turning your head should also move the sound between your left and right ear.

Adding audio after the fact does not solve this. A cascaded video-to-audio model never sees the camera trajectory or the user's actions, so its sound ignores ego-motion, and running it after the video adds latency. Bidirectional audio-visual foundation models generate both streams, but they have no control interface, and naively turning them into causal, streaming models makes errors accumulate until both picture and sound degrade. Helix World addresses all three problems: missing training data, missing control, and long-horizon drift.

Explore worlds in real time

In the demo you choose a starting image or upload your own; it is encoded at 768×512. A text prompt is optional: if you leave it empty, the scene is described automatically from the frame. Once the session starts, WASD moves the camera and the arrow keys change the view. Generation runs in chunks of about 1.3 seconds, and each keyboard input or new prompt takes effect from the next chunk, so you can redirect the scene while it is running.

Benchmarks

Visual quality and speed

We measure visual quality and action following on the WBench navigation split. Real-time factor is the seconds of compute needed per second of output video, measured on one NVIDIA H800 including video and audio decoding; below 1.0 means faster than real time. Table 3 of the paper:

Among models that run faster than real time, Helix World has the highest score: 79.9, against 76.0 for SANA-WM and 71.3 for Matrix-Game 3. The three models above it need between 1.98 and 4.29 seconds of compute per second of video, and two of them are silent. Helix World is the only real-time model in the table that also generates sound.

Sound that follows the camera

Existing world-model benchmarks evaluate only video, and audio-visual benchmarks use short clips without camera motion. HelixBench fills that gap with 1,015 human-verified cases across six domains and four subsets: Navigation, Perspective, Event, and Subject. Each case provides a starting frame, an audio-visual prompt, continuous camera poses, and a stereo reference. Its spatial score correlates the on-screen position of sound sources with left-right stereo panning, so it directly measures whether the sound field rotates with the camera.

The baselines include EchoWM and cascaded pipelines in which we mute Helix World's video and re-dub it with a video-to-audio model (AudioX, ThinkSound, PrismAudio), so the picture stays fixed and only the audio changes. Table 4 of the paper:

Helix World leads on audio fidelity (KL, FAD), audio-visual semantic alignment (ImageBind), and spatial consistency. It is not best everywhere: LTX-2.3 and the ThinkSound pipeline have lower temporal offset (DeSync), and the AudioX pipeline scores slightly higher on text-audio alignment (CLAP). The re-dubbing pipelines produce negative spatial scores because a video-to-audio model does not know where the sound sources are relative to the camera.

What people preferred

In a user study on full audio-visual rollouts, participants preferred Helix World over EchoWM 67.9% to 20.8%, and over the re-dubbed versions of its own video by 67.9% to 24.5% (AudioX), 80.8% to 9.6% (ThinkSound) and 77.8% to 16.7% (PrismAudio); the remainder were ties. With the sound muted, Helix World was preferred over SANA-WM, Alaya and HY-WorldPlay 1.5, tied with LingBot-World v2 at 39.5% each, and was less preferred than EchoWM, 26.3% to 44.7%. Its advantage comes mainly from the audio.

How we built Helix World

Data: true stereo with metric camera poses

Most video corpora are unusable for this task: the audio is often background music, voiceover, or pseudo-stereo with identical channels. We started from 4,100 hours of raw footage (43.9% real-world video, 34.1% game recordings, 22.0% open-source datasets) and filtered it in four stages, ordered from cheapest to most expensive:

• Heuristic filtering removes dual-mono audio, shot cuts, low perceptual quality, text overlays, and static scenes.
• Clip standardization cuts audio and video together into 121-frame clips at 24 fps and 768×512, with 48 kHz stereo.
• Semantic filtering with a multimodal LLM that watches and listens rejects background music, narration, UI overlays, picture-in-picture, and talking heads, and keeps diegetic sound.
• Camera and captioning recovers metric camera poses for every frame and writes three caption tracks: video-only, audio-only, and audio-visual.

The result is 3,000 hours in 2.1 million clips, a 73.1% yield. In an ablation, training with all three caption tracks gave the best audio-visual alignment.

A bidirectional teacher with camera and action control

Helix World builds on the open-source LTX-2.3 audio-visual model. Continuous 6-DoF camera trajectories enter the visual attention through PRoPE, and discrete keyboard actions enter through AdaLN-Zero on the diffusion timestep. Cross-modal attention then binds visual geometry to the audio features, which is how camera motion becomes stereo panning.

Training is progressive: first the control modules, then the video branch, then the full audio-visual backbone. Compared with fine-tuning everything at once, this lowers camera rotation error from 0.1237 to 0.1144 and translation error from 0.0957 to 0.0823, while keeping the pretrained visual quality.

A causal student that streams without drift

The bidirectional teacher sees the whole clip, so it cannot respond to live input. We distill it into a few-step causal student that generates block by block with a sliding key-value cache and fixed sink frames. The student is initialized by regressing the teacher's ODE outputs, then trained with self-forcing on its own rollouts.

Self-forcing with distribution matching (DMD) alone still drifts over long rollouts. Our addition is an online trajectory distillation loss: at each update, with probability p, the student's velocity at an intermediate rollout state is supervised by the teacher's probability-flow ODE target; otherwise the DMD loss is used. A final long-horizon streaming stage trains on extended windows. Together, these raise the WBench score from 77.9 to 79.1 and keep 30-second rollouts stable.

Limitations

• Output resolution is 768×512. Real-time speed is reported on an NVIDIA H800 data-center GPU; the paper does not report consumer GPUs.
• The public checkpoint is a preview release.
• On visual quality alone, Helix World is slightly behind the best silent models (79.9 vs 82.0 WBench average), and with sound muted, viewers preferred EchoWM.
• Helix World does not have the lowest DeSync on HelixBench, so tight onset timing still has room to improve.

For a different approach to the same problem, adding streaming stereo to an existing world model, see our WorldSonus post.

Try Helix World

The interactive demo is open at helixworld.org. Read the full paper, "HelixWorld: A Real-time Interactive Audio-Visual World Model" (arXiv:2609.38123, 29 September 2026), on arXiv. Code is on GitHub and the preview weights are on Hugging Face.

Authors: Lei Ke, Jiahao Pan and Zeyue Tian (equal contribution), Jiaming Wang, Haoyuan Huang, Kam Man Wu, Pengjun Fang, Hongyu Liu, Chenyang Qi, Lin Wang, Ruibin Yuan, Weijia Chen, Fangneng Zhan, Qifeng Chen, Wei Xue and Yike Guo. Corresponding authors: Zeyue Tian and Wei Xue. The Hong Kong University of Science and Technology and Noiz AI.

FAQ

What is Helix World? Helix World is a real-time interactive audio-visual world model from Noiz AI and HKUST. It generates an explorable video scene and camera-aligned stereo sound together, controlled with the keyboard and an optional text prompt.

Does Helix World run in real time? Yes. On a single NVIDIA H800 GPU it reaches a steady-state real-time factor of 0.77 at 768×512 and 24 fps, including video and audio decoding. Input takes effect from the next generated chunk of about 1.3 seconds.

How is Helix World different from other world models? Most interactive world models generate silent video. Helix World generates stereo sound natively with the picture, and the sound pans with camera motion. On HelixBench its spatial-acoustic consistency score is 41.8, against 12.7 for EchoWM.

What is HelixBench? HelixBench is a benchmark for interactive audio-visual world models with 1,015 human-verified cases in six domains. It measures audio fidelity, temporal sync, audio-visual and text-audio alignment, and spatial-acoustic consistency.

What model is Helix World built on? It builds on the open-source LTX-2.3 audio-visual model, adds 6-DoF camera and keyboard-action control, and is distilled into a few-step causal student for streaming.

Can I try or download Helix World? Yes. The demo is at helixworld.org, the code is on GitHub (NoizAI/HelixWorld), and a preview checkpoint is on Hugging Face (NoizAI/HelixWorld-preview).

No organization in the world operates more robots than Amazon. The company already has more than 1 million robots working in warehouses around the clock to make tens of millions of same-day and one-day package deliveries happen on a daily basis—and Amazon is poised to significantly grow that robotic fleet in the coming years as it establishes new factories to churn out increasingly more capable robot workers.

Despite deploying so many robots, Amazon is also the second-largest corporate employer in the world, with more than 1.5 million full-time and part-time human workers, according to its 2025 annual report. Amazon executives say that the growing robot fleet has eased the burden on its human workforce by taking on the toughest fulfillment center tasks that carry the greatest risks of physical fatigue and injury. But labor advocacy groups and independent researchers point to evidence suggesting that warehouse automation driven by AI is not all upside for the humans who work alongside robots.

“For the last 100 years, most of the automation that we’ve seen usually happens away from workers—you’re taking that high-risk task away from the worker, and you’re doing so in a way that is not physically proximate,” Brad Greenwood, professor of business at George Mason University, told Ars. “The rise of collaborative robots really changes that dynamic for two reasons: one is that it is physically proximate, and two, the robot has the ability to dictate the pace of work.”

In many ways, robotics and AI are well suited to the relentless pace of work that is already happening inside e-commerce fulfillment centers. Amazon’s promise of speedy deliveries for its 200 million Prime subscribers in particular requires hundreds of thousands of human employees to speedily assemble and ship out customer orders that often combine a dizzying array of products.

Much of the work in fulfillment centers also frequently involves “dull, dirty and dangerous” tasks that people may prefer to hand over to robots. The injury and illness rate for workers in the US warehouse sector has typically been more than double the average across all industries, according to the US Occupational Safety and Health Administration.

“You have almost 2 million people working in the warehousing sector in the United States, and it’s characterized by very high turnover and very high workplace injury rates,” said Greenwood.

But robots are still far from capable of handling the many different tasks that human workers can perform. So Amazon still has a massive human workforce working in tandem with the company’s growing fleet of wheeled robots and robotic arms—and workplaces can get complicated when humans are expected to keep pace with robotic counterparts.

Amazon’s robotic era

Amazon has rapidly built its robotic fleet following the pivotal decision to acquire the robotics company Kiva Systems in 2012. Kiva was among the earliest companies to pioneer wheeled mobile robots that bring racks of items to warehouse workers, instead of requiring people to continually walk around grabbing items off of shelves inside fulfillment centers.

Since the acquisition, Kiva was renamed Amazon Robotics and has focused on deploying an array of mobile robots and robotic arms that Amazon primarily manufactures in-house at facilities in Massachusetts. This year, the company also announced it would build additional production factories in Austin, Texas, and Greenwood, Indiana, to churn out even more robots in the future.

“There’s a theme of how we look at the challenges that we can help our associates and our employees with, and how we can make our customers’ lives better through these technologies,” Scott Dresser, vice president of Amazon Robotics, told Ars. “Each step of the way, [we are] tackling a hard or deep set of technical challenges to achieve that goal.”

Most of Amazon’s million-robot fleet still consists of those wheeled mobile robots. The company claims that its robotic Sequoia system can identify and store items up to 75 percent faster at fulfillment centers by coordinating swarms of such robots. Hercules and Titan robots, the size of a pool table or a baby grand piano, respectively, roam warehouse aisles to retrieve tall fabric shelving units called pods packed with plastic tote crates and bring them to human employees at various workstations.

Such mobile robots typically follow grid lines of stickers laid out on the floor and stay within fenced-in areas away from human employees. But the newest mobile robot, called Proteus, has sensors that allow it to operate safely around humans and other objects in a more free-roaming role.

Those swarms of mobile robots traveling through narrow lanes between rows of storage pods can also sometimes create robotic traffic jams. That is why Amazon began coordinating its robots using a suite of AI foundation models collectively named DeepFleet, which can help predict potential robot congestion ahead of time.

More recently, Amazon has been deploying a growing number of robotic arms that can grab items stowed high up inside inventory pods, sort packages and place them in carts or on top of mobile robots, and handle the many different individual products that Amazon customers order when shopping online.

The company expects to more than double its existing fleet of robotic arms this year, according to Amazon CFO Brian Olsavsky in a July earnings call. When Ars sought clarification, Dresser described the current number of deployed robotic arms as being in the single-digit thousands.

The robotic arms race

Amazon first bought third-party robotic arms to help lift and stack heavy pallets and bins inside its fulfillment centers. But the first robotic arm developed in-house by Amazon Robotics to sort individual mailer envelopes and boxes from cluttered piles, called Robin, began testing in 2021 before debuting at a facility in Lakeland, Florida, in 2022.

“With Robin, it was really that first attempt at taking a number of customer orders all in a jumble and building the advanced robotics to identify the items in that scene, to strategize on how to pick them up and build a motion plan that would be successful in placing it down on one of our mobile drive units,” Dresser explained.

The robotic arm uses eight suction cups to pick up individual packages. But before it takes any action, the robot’s software analyzes a top-down view of the conveyor belt cluttered with packages and quickly ranks possible picking actions.

In a 2023 research paper, the Amazon Robotics team described having developed several picking strategies for the robots to follow early on—but each had its own limitations. One strategy that prioritized picking larger packages encountered challenges when smaller packages lay on top of or overlapped with larger ones. Another strategy that favored picking up packages near the top of piles would fail in practice to retrieve “unreachable picks” and partially buried packages.

Improvements came from replacing such hand-crafted algorithms with an AI approach known as machine learning. The machine learning model initially trained on more than 394,000 picking actions from deployed robotic arms to estimate pick probabilities of success, and then used an online pick ranker to prioritize optimal actions for the Robin robots.

The best machine-learning method in that trial achieved a 93.73 percent success rate compared to 92.28 percent success for the best-performing traditional algorithm. That may seem trivial at first glance, but it meant the machine-learning method resulted in about 16,500 fewer failed picks than the traditional method during a work period involving more than 1 million total picks. That matters for an operation like Amazon’s that prioritizes speed and efficiency at scale.

The Amazon Robotics team further showed how such a machine-learning method could reduce the failed pick rate by 20 percent during an experiment involving 2 million picks by robotic workstations set up to resemble the operations of Amazon’s Robin fleet. They presented this work at the International Symposium on Experimental Robotics in July 2025.

Next up was Cardinal, a robotic arm that can place packages weighing up to 50 pounds into wheeled carts that are eventually brought to Amazon trucks waiting in loading docks. These robots first began operating at a facility in Nashville, Tennessee, in November 2022.

“Think of it as a game of Tetris: You’re sorting packages, and you’re placing them into the cart, and you want to be able to pack that as densely as you possibly can,” Dresser told Ars. “Dense containers are great from a sustainability perspective and from a transportation cost perspective.”

Cardinal built on lessons learned from Robin’s development in picking up and manipulating packages, while adding the capability to densely pack customer orders into the carts. Amazon has just started to deploy Cardinal in larger numbers and will continue to do so over the next several years, Dresser said.

AI-driven robot successors

Robin and Cardinal can handle several dozen package variations. But the newer Sparrow robotic arm was developed to tackle an even more challenging task—handling the hundreds of millions of products of varying shapes and sizes that can go into customer orders.

Specifically, Sparrow focuses on consolidating items from partially filled container-size totes to create densely packed totes. When items get picked out as customer orders are being fulfilled, Sparrow continually refills the totes.

“When we think about how AI applies to the physical space in robotics, Sparrow was really the first place where we truly deployed foundation models that enabled us to deal with that high diversity of products,” Dresser told Ars.

Such foundation models have helped the Amazon Robotics team to efficiently identify and classify those hundreds of millions of items to develop new robotic strategies for grasping them, Dresser explained. They also eliminated the need for manually coding every single item.

More recently, the Amazon Robotics team has created a foundation model for robotic perception that can handle new, never-before-seen products that may end up in Amazon fulfillment centers. The team also developed a generalized action model compatible with different types of robotic arms that may use varying combinations of suction and finger grasping.

“If you need to build ad hoc perception models for every such task and embodiment, that just doesn’t scale,” Kapil Katyal, a senior applied science manager at Amazon Robotics, said during a presentation attended by Ars at the Intelligent Robots & Systems conference held in Pittsburgh on September 29.

“So one of the initiatives we took up in our team was to design a foundation model which could work for any new embodiment of robots that we deploy, and across all of the perception tasks that we need to perform over those,” Katyal said.

Most of the robotic arms have relied primarily on vision. But Amazon’s newest robotic arm, Vulcan, is the first to combine vision with force feedback sensors capable of providing a sense of touch. This enables the robot to accurately pick out or stow away items within the fabric-covered inventory pods.

“You need to be able to insert an item, create space, or pull something out,” Dresser said. “Those are really hard things to do with traditional non-touch-based systems today, like the suction-based systems that are part of Sparrow.”

Vulcan initially began operating at Amazon fulfillment centers in Spokane, Washington, and Hamburg, Germany, starting in 2025. It is not widely deployed yet, but Dresser said the company expects to scale up use of this robotic arm in 2027.

Parsing the human impact

Each new robot has benefited Amazon’s human workforce, according to the company. For example, Vulcan focuses on picking and stowing items located in the top rows of inventory pods that would otherwise require a person to use a step-ladder, along with handling items located just above the floor. That enables employees to focus on picking and stowing items that are within more comfortable reach.

But investigations by labor advocacy groups, journalists, and the US Congress have painted a less rosy picture of Amazon’s automation drive over the years. The Strategic Organizing Center (SOC), a coalition of trade unions headquartered in Washington, DC, published reports in May 2021 and April 2022 showing higher injury rates at Amazon’s robotic warehouses compared to non-robotic warehouses. That analysis drew on injury data reported by companies to the US government from 2017 through 2020.

“Amazon likes to talk about its latest robots because it doesn’t want to talk about the tens of thousands of Amazon workers who are injured every year due to Amazon’s obsession with maximizing speed and minimizing costs,” Joan Moriarty, director of strategic research and Campaigns at SOC, said in an email to Ars.

The organization also gathered nearly 1,000 responses from Amazon workers in an online survey conducted in February 2021. “Workers consistently report that the presence of robots increases the pace of work expected in Amazon facilities, forcing them to make fast, repetitive motions, substantially increasing the risk of injury,” Moriarty said.

The US Senate Committee on Health, Education, Labor and Pensions (HELP) also conducted a 2024 investigation led by Sen. Bernie Sanders (I-Vt). The committee’s report noted how Amazon’s internal data also suggested a link between robotic productivity and increased pressure on human workers, leading to higher injury rates.

Amazon has described these reports as flawed and being reliant on older data predating the deployment of its most modern robots, including the robotic arms that became operational over the past several years. The company also touted improvements in its overall workplace injury rates without detailing any potential differences between robotic and non-automated warehouses.

“All of these claims ignore the fact that since 2019 our Global Recordable Incident Rate has improved 43 percent and our Global Lost Time Incident rate, which includes the most serious injuries that require employees to take time away from work, has improved 70 percent,” an Amazon spokesperson told Ars. “Our consistent year-over-year improvements have worked in parallel with our robotics growth across our operations network.”

The most nuanced findings on Amazon’s automation drive may come from a research study published in the journal ILR Review in April 2025. That analysis showed Amazon’s robotic warehouses had a 40 percent decrease in severe injuries compared to legacy fulfillment centers—which suggests some benefits from having robots take on the most physically challenging and risky tasks.

However, the same study also found that robotic fulfillment centers had a 77 percent increase in less severe injuries associated with physical strain from repetitive motions.

“At least one of the mechanisms by which this appears to be manifesting is through the pace of work, in that pick rates for the robotic fulfillment centers are off the charts higher,” said Greenwood at George Mason University, who was one of the paper’s coauthors.

A faster pace of work driven by partial automation could mean “the robot is dictating the pace of work” and spurring human employees to perform certain repetitive actions more quickly, Greenwood told Ars. “That appears to be what’s driving the strains and the sprains that we observe,” he said.

The study drew in part on Amazon company data obtained by journalists at Reveal and The Center for Investigative Reporting, covering weekly data at more than 150 Amazon warehouses from 2016 through 2019. Although the data is older, Greenwood said the findings are still relevant to Amazon’s ongoing automation efforts.

“I haven’t seen a tremendous amount of evidence to suggest that these dynamics are changing, inasmuch as you still have a tremendous amount of turnover in the warehousing context—and that’s not just Amazon,” Greenwood said.

Greenwood and his colleagues also analyzed online comments posted on Reddit by Amazon fulfillment center employees. In those comments, Amazon employees described work at robotic fulfillment centers as being less physically stressful but also mentally exhausting because of the physical repetitiveness and faster pace associated with higher productivity expectations.

The future of work

An obvious question is whether automation efforts by Amazon and other companies will end up replacing some potential human hires with robots. For its part, Amazon has touted the robotics push as providing new job opportunities for human employees. Fulfillment centers with advanced robotics typically require 30 percent more employees working in reliability, maintenance, and engineering roles, and the new facilities for manufacturing additional robots will also supposedly bring more than 300 jobs each.

“As we recognize that each of these robotics [developments] can change the nature of work, we’re providing opportunities for our employees to upskill and learn some of these things,” said Dresser at Amazon Robotics. “We’ve actually increased the number of robotic maintenance technicians that we have in the network by over 30 percent, and that is a much higher-skilled, higher-compensated job.”

The company has also described its automation efforts as going hand in hand with a growing business that needs more human employees. “As we’ve deployed robots over the past decade, we’ve seen our operational footprint grow, creating hundreds of thousands of jobs as we expanded our network,” the Amazon spokesperson told Ars.

However, there are apparently internal discussions within Amazon about robots potentially reducing the need to hire humans. In October 2025, The New York Times reported on internal strategy documents suggesting that the robotics push could allow the company to reduce projected hiring needs in the United States by more than 160,000 people by 2027 and 600,000 people by 2033. (An Amazon spokesperson responded at the time by saying the documents reflected the views of just one group inside the company.)

Even as Amazon looks to build out its robotic fleet beyond the million-robot mark, discussions about the company’s workplace safety and working conditions are unlikely to go away. Although just a very small fraction of Amazon’s hundreds of thousands of employees have unionized in the United States, labor unions have “traditionally served a very good role in terms of improving worker safety,” Greenwood said.

“Now, obviously, I understand that firms are not always excited to engage in that conversation, and I can’t say that would solve the problem here,” Greenwood told Ars. “But developing a better relationship between management and labor is usually the best path forward to try to figure out how to reduce these injury rates, which would have benefits for Amazon as well.”

The first Amazon Labor Union that was organized among workers at a warehouse in Staten Island, New York, in April 2022, has been pushing what it describes as a Safety Bill of Rights that outlines changes it would like to see to make their workplace safer. The image that accompanies the document declares: “We are not robots.”

Is ‘Attention’ the Essence of Intelligence?

Introduction

Everything that’s swept the world since the 2022 release of ChatGPT — “the AI economy”; data centers; chatbots acting as best friends, doctors, and mathematicians; talk of existential risk — it all starts, in some sense, with an intern in a University of Montreal lab named Dzmitry Bahdanau.

It was 2014. The 23-year-old Belarusian, who had been coding competitively since he was a kid but hadn’t done academic research before, was asked to help figure out how to get a computer to translate sentences from English to French. Bahdanau was working with artificial neural networks, which had already shown promise in pattern-recognition tasks such as deciphering handwriting and identifying objects in photos. The networks learn to recognize patterns by strengthening and weakening connections between nodes in response to training data. Bahdanau quietly doubted their potential to achieve anything like human-level intelligence, but his adviser, the computer scientist Yoshua Bengio, and the postdoc on the project, Kyunghyun Cho, were believers. And translation was widely seen as a formidable and interesting problem for neural networks to try to solve.

Translation is not as simple as swapping each English word for a French one. Languages have different grammatical structures and are riddled with idioms and connotations, all of which had long stymied attempts to automate the process. You can’t simply implement rules of translation because there are none. But neural networks seemed promising because they learn by example. They can be trained on huge databases of paired English and French sentences to, eventually, absorb the quasi-rules, exceptions, and subtleties.

Results had been mediocre, though; the longer the sentence, the worse neural networks performed. That’s because researchers were trying to cram each sentence’s data into a fixed amount of memory before decoding the sentence in the target language. It was a bottleneck that limited how complex and sophisticated translations could be. The network architecture just wasn’t right.

So Bahdanau tried something different. “It was just obviously the right thing to do — one of these things that happens once in a while in science where it’s just very clear to someone who is not very experienced in the field,” he recalled, speaking to me from Montreal, where he still works in AI. “And it just worked. From the very first attempt.”

Bahdanau’s trick, a mathematical operation that he, Cho, and Bengio referred to as “attention,” enabled their neural network to translate long sentences just as well as short ones. That meant the approach was scalable. Other AI researchers at the time quickly integrated attention into their neural network designs. Then, in 2017, a team at Google devised a new kind of neural network architecture called a transformer that supercharged the attention method and stripped away everything else. The team’s paper, “Attention Is All You Need,” reported that transformers achieved state-of-the-art translation while requiring a fraction of the computation needed to train prior models. The paper, which has since been cited more than 250,000 times, was a watershed moment in AI. Large language models such as ChatGPT and Claude followed.

Given the staggering power that’s been unleashed, it’s worth asking what this attention mechanism is exactly, why it is “all you need,” and why machine translation was the task that unlocked it all. Attention is a way for us to understand how a single AI model can converse with us, diagnose diseases, generate realistic videos, solve long-standing math problems, and more. Is it somehow at the heart of intelligence — artificial and otherwise?

Sentences with pronouns such as “it” in them illustrate the challenge that attention overcomes. Consider: “The animal didn’t cross the street because it was too tired.” And: “The animal didn’t cross the street because it was too wide.” To translate these sentences correctly into French, an AI model must determine that, in the first one, “it” refers to the animal, which is a masculine word in French, so the translation should use that form of the pronoun, il. But in the second sentence, “it” refers to the street, a feminine word that requires a different pronoun, elle. How can the machine figure this out?

Bahdanau remembered doing translation exercises when he was learning English in school. To write each next word of his translated sentence, he’d have to glance all around the source text to figure out what should come next. “Literally you have your source sentence on the left and your writing on the right, and you’ll be, like, turning your head, left-right, left-right,” he said. “That process is what I expressed as a neural mechanism.” The tool of attention that he gave to his neural network was a mathematical way for the network to identify the word or words anywhere in a sentence that would most inform the next word of the translation. In the case of our ambiguous pronoun, “it,” the system navigates the rest of the sentence to determine which words affect its meaning the most.

A transformer consists of many layers of nodes connected to nodes in adjacent layers. When a sentence is fed into a transformer, each word is first converted into a numerical representation called a vector, which we can imagine as an arrow pointing in a certain direction. These vectors pass through the network, and numbers called weights (determined by the model’s training) dictate how they are transformed in each layer. The weights turn each word’s current vector representation into three new vectors specific to that word — a “query,” “key,” and “value” — that each serve a different purpose in the attention operation.

The network performs this operation several times in parallel through systems called attention heads. An attention head compares each word’s query with the keys of all the other words in the sentence. How well these vectors match up — how much they point in the same direction — determines how strongly the value of each other word contributes to a new, updated vector for the word at hand. Information about other words in the sentence literally becomes incorporated into each word’s representation. The system is converting context into math.

When “The animal didn’t cross the street because it was too tired” enters a transformer, the first stack of layers in the network, known as the encoder, uses the attention operation to build up a contextual understanding of the sentence. In each layer, each attention head generates a query (along with a key and value) for “it.” This query vector can be thought of as a request for information that exists elsewhere in the sentence. For instance, in a deep layer (after the network has already accumulated information about words), the query for “it” might be interpretable as: “I need an earlier noun that could plausibly be the thing that is tired.” Meanwhile, the key associated with “animal” might effectively advertise itself as a noun that’s capable of being tired, among many other features. Its key therefore matches the query better than the key for “street.” And that causes the value associated with “animal” to contribute more heavily to the updated representation of “it.”

That new, context-enriched representation of “it” passes into the next layer. There, the network performs attention all over again. Successive rounds give the words increasingly rich representations of themselves.

Experts say it’s often hard to interpret what any given attention head is doing, but collectively they pick up on many kinds of relationships, from the partnership between nouns and verbs to the association between living beings and feelings. Later layers build on associations established by earlier layers, so that by the time the sentence emerges from the encoder, “it” is imbued with something resembling meaning.

After that, the second part of the transformer, the decoder, produces the French translation one word at a time, using attention to draw on the encoder’s numerical representations of the English words as it decides which French word to spit out next. The contextual information encoded in the English sentence helps translate “it” as the masculine il.

Crucially, no one had to tell a transformer that animals get tired and streets may be wide. The neural network discovers such associations during training, by learning from huge numbers of English sentences paired with their French translations. These associations get built into the weights. The network starts out with random weights that produce unhelpful queries, keys, and values, and thus poor translations. But each translation error sends a correction signal backward through the network that slightly alters the weights that produced it. Through trillions of these adjustments, the network eventually generates useful vectors that yield correct translations, even when it processes sentences it has never seen before.

Attention turned out to be the right mathematical operation for linking words and building context — the fundamentals of translation. And when you can translate blocks of text of unlimited size, it seems you can do anything.

A neural network that has learned enough about language to translate sentences from English into French can also complete sentences in either language. Predicting the next word of a translation is, in other words, a subtask of the more general task of “predicting the next word,” period. And that’s what large language models do. They’re trained on the contents of the entire internet, learning which words should attend to which other words in all sorts of contexts. They process and reprocess the whole dataset and try trillions of times to predict the next word in whatever part of the web they happen to be in at any point during training. The connections between neurons in these models are gradually tweaked in a way that produces patterns of attention between words that are ever more useful for predicting the next word in any context — or for producing an appropriate response to a prompt from a human.

From the ability to translate the word “it,” we somehow got a revolution.

“That’s quite a leap, isn’t it?” said Llion Jones, one of the authors of “Attention Is All You Need,” who is now the chief technology officer of Sakana AI.

Jones and others suspect that predicting the next word, which is known as language modeling, is “AI-complete”: a task so difficult that solving it means you have arguably solved AI in general. The reason it may be AI-complete is that this task includes, as a subtask, virtually anything humans do in written form. “The internet has translations,” Jones notes. “So if I said ‘“The animal didn’t cross the street because it was too tired” in French is [blank],’ then in order to complete that sentence, the transformer needs to be able to translate into French. If I say ‘2 + 3 is [blank],’ it needs to do arithmetic. If it sees a bunch of mathematical symbols in a row and wants to know what comes next, it needs to understand high-level mathematics. If I say ‘The president of the United States is [blank],’ it needs to know facts. So being able to predict the next word requires you to be able to do all these things. And because it’s AI-complete, language modeling is kind of the closest definition that we have to intelligence.”

It might not be apt to say that an LLM “knows” or “understands” anything — not in the way that a human does — but that’s just how we’re accustomed to talking about the abilities they display. Regardless, attention is the tool by which artificial neural networks access and convey meaning, association, and context, often well enough to astonish us with their fluency. (For tasks such as advanced mathematics, today’s frontier AI models often have more explicit formal reasoning and proof verification systems layered on top of their language modeling to check their work.)

But what about human intelligence? Might our brains employ a mechanism similar to the mathematical operation Bahdanau invented? After all, we, too, do something akin to “producing the best possible next word” when we speak, write, and even think. Perhaps our form of intelligence is tantamount to language modeling, too?

Cognitive scientists have begun to study this question — a new version of the ancient question of how language relates to thought. To be sure, the success of LLMs shows how much information about the world is encoded in the statistical patterns of language alone. The question is: When we master language, does intelligence come for free?

Recent research persuades me that human thought is not purely linguistic (and most other animals’ intelligence is not linguistic at all): When we are thinking, more brain regions light up than just the specialized networks in the cerebral cortex that are associated with language. Language is how we communicate about the world, but our thoughts seem to draw on sensory impressions, physical and social experiences, memories, and reasoning abilities that exist at least partly outside the brain’s language networks. So language modeling seems to be merely a powerful component of human cognition, not its equivalent or source.

As for how we do “it” — how I instantly understand that it’s the animal rather than the street that is tired — no one yet knows. Jones, for his part, now thinks that attention is not all you need to truly master language modeling. After all, the brain evidently accomplishes this task far more efficiently than transformers do. We converse fluently without having read the whole internet even once, and without burning as much energy. “The current paradigm won’t solve this [efficiency] problem,” Jones said. “You seem to have to jump to something very, very different.”

Regardless of what our own neural mechanisms might be, it makes sense to me in hindsight that solving translation unlocked AI. Whether you’re human or machine, the ability to translate effectively means you have understood, in some sense. Now the machines understand so much — effectively, at least — that we hardly know what to think anymore.

Why WebMCP matters

AKA - WebMCP is Agentic WebPerf

For the last few months, I’ve been working (amongst other things) on getting Shopify’s storefront WebMCP tools ready for production and shipped. That’s now done, other folks have added Checkout support, and WebMCP seems to be getting traction: OpenAI added support in ChatGPT Desktop and ran the super-interesting WebMCP Challenge, Cloudflare supports it both in Kitesurf and for its customers, and my WebMCP presentation at the Agentic commerce W3C/GS1 workshop was really well-received. As part of shipping WebMCP at Shopify, I’ve found myself more and more involved in the evolving standard proposal, filling the various gaps we found along the way.

But I wanted to write a bit about why I chose to work on those tools.

AI agents are a thing nowadays, and people are increasingly relying on them to get things done. These agents can execute local tools and code, and if we want the web to stay relevant, we need to enable agents to interact with it.

There are three types of agentic interaction with services on the web:

• Direct backend communication - the agent performs the necessary API calls to talk to a backend and get it to do what it needs to do. MCP servers published by web services are a classic example of that.
• Embedding - the agent embeds parts of the web experience into their chat and displays that to the user. E.g. MCP Apps
• Co-browsing/direct interaction - The agent works alongside a browser session, understands the site through DOM/a11y tree analysis and screenshots, and tries to automate it by clicking buttons and links.

I believe that if we want the web to succeed in the agentic age, we need the co-browsing model to work and work really well for users. Co-browsing is the only model where the developer and the user maintain control over the experience, and the user can take over from the agent at any point. It’s the only model where the web remains the web.

At the same time, none of the early demos I’ve seen that relied on DOM- or screenshot-based interaction had a great UX. They seemed slow, exposed the user to the agent fumbling around the site, and provided suboptimal results.

WebMCP to the rescue

WebMCP enables the site to provide agents with direct JS tools they can call to accomplish tasks, and as a result, makes direct interaction significantly faster, better and cheaper. That circumvents the slowness/awkwardness of an AI agent trying to figure out how to interact with the site as if it’s a human.

The site can register tools with explicit input and output schemas, as well as a clear description of what they do and when they should be called. The agent can then call these tools to achieve whatever the user asks it to do.

The idea is simple enough, but it’s a super powerful primitive that IMO would unlock significantly better co-browsing experiences.

In short, WebMCP is web performance for AI agents on the web.

The folks from nekuda.ai gathered data on that front, and found WebMCP to be 2.5-7.5x faster and up to 47x cheaper than other direct interaction methods. Shopify’s Checkout team ran a similar experiment and found WebMCP to be 2.7x faster and 58% cheaper, with 60/60 successful attempts vs. 56/60 with browser automation!

Stuff to figure out

As simple as the basic idea of WebMCP is, there’s obviously a bunch of complexity to rein in: Who can register tools for the site? What kinds of agents do we want to support? How do we monitor the user experience? How can we get an explicit signal from the human user? How do we test all of this across a wide range of different browsers and agents? And how do we protect users from malicious tools?

We need answers to all of these questions, and we’re figuring them out one by one. For example, when discussing who can register tools, we’ve landed on a Permissions Policy model to allow the site to decide which iframes can register tools. We also decided that tools should support in-browser agents, extension-based agents as well as in-page agents (potentially from a cross-site iframe).

Another big piece to figure out is the testing story. Web developers can currently evaluate their WebMCP implementations against vanilla models, e.g. using the webmcp-evals framework. But there’s no way to run their evals against real, representative agents that also include the harness, the system prompt and the various security verifications that agents employ.

Can’t we just build better websites?

I heard people ask whether allowing agents to navigate your site isn’t simply a crutch for bad UX design. One example I heard - won’t a better product search with more precise criteria help users find the product they are looking for without scrolling through 87 slightly different ones?

Well, at least in my experience some of it is true, as many merchant sites don’t allow users to filter their search by every characteristic they might care about. So if you’re looking for something very specific (trail running shoes with a drop of up to 5mm, lightweight 175-177cm skis with 80-85mm underfoot, etc.), unless you have an AI agent to help you, you end up scrolling through products, looking at the detailed specs of each one and hoping that the info is actually there. Not a great outcome. AI agents really change the picture there.

But I don’t think that’s all there is to it. If I’m looking at e.g. home improvement projects, I can typically buy the materials and tools I need online, but going to a physical store and talking to an experienced person is super helpful to get a holistic view of all the details of the project, what you’d need to tackle each one and where you can get it.

Agents can similarly help brainstorm a project, work out its details, and figure out what you'd need to get it done.

WebMCP lets online stores offer the equivalent of an experienced salesperson that helps customers plan their project and find everything they need to get it done. And while they can also do that by shipping an agent themselves, that’s significantly more complex. And at least some users prefer to have their familiar agent do that, rather than rely on someone else’s agent.

With WebMCP, merchants can rely on the user’s agent to integrate with their site and drive it, without having to provide the smarts themselves.

Can’t we just rely on HTML semantics?

A recurring question, in the ongoing W3C TAG review and at the heart of WebKit’s opposition, is around the use of JS tools instead of HTML semantics. There’s concern that content on the web would fragment into “human content” and “agent content”. WebKit considers AI agents to be “assistive technology” and hence expects them to be invisible to the site, and cites risks of abuse.

That concern is understandable, and I think it can be split into two different risks.

Discrimination

Since WebMCP tool calls reveal that an agent is involved, sites could now discriminate against agentic users.

But developers can already discriminate against agentic users, with or without WebMCP, through their regular bot detection mechanisms. If this is their goal, WebMCP won’t help them.

My discrimination concerns lie elsewhere. I’m concerned that without an explicit “agentic experience” signal, developers will wrongfully categorize such users as “bots”, due to the non-human interaction patterns. That can get agentic users blocked or relegated to sub-optimal experiences.

So I disagree with WebKit folks there, and think that having a way for the server to know there’s a human or a trusted agent involved is critical. I’m hoping Web Bot Auth can help us solve that part of the equation.

Semantic divergence

The other risk is semantic divergence, where different capabilities would be presented to non-agentic users vs. agentic ones. But developers can already create these kinds of semantic divergence between different types of users. There are similar risks already for JS support in general, as well as for ARIA semantics.

And while there are certainly cases when users without JavaScript or assistive-technology users get sub-par experiences, I believe those come from neglect, not from explicit discrimination against such users.

Developers and site owners are not incentivized to present completely different sites to users with or without JS, nor to provide different semantics to assistive-technology users.

The same holds true for agentic users. Developers are incentivized to provide them with the best agentic experience, but not one that’s entirely semantically different from what non-agentic users get. The agent may help these users to avoid jumping through certain hoops, but at the end of the day, all users will reach the same destination.

Declarative WebMCP is not enough

The semantic divergence concern can be addressed by the Declarative WebMCP proposal that would reuse and augment form semantics to enable agents to perform various operations. That can be great, but I would argue it is complementing imperative tools, rather than replacing them.

Relying solely on HTML semantics for agentic interactions (and discarding an imperative solution) would be akin to saying that we don’t need JavaScript, as we can just bake any functionality developers need into HTML.

Declarative WebMCP can work well for “one-shot action” tool calls. But that doesn’t represent all potential tool calls.

Some tools aim to be a single step in a multi-step task (e.g. to scan through multiple products and take the user to the best fit) or to provide further context to the agent (e.g. an answer to an FAQ). The information returned from those tools is aimed for consumption by the agent, which will either answer the user’s question, or call more tools with that information as input. The user-visible outcome of that journey would be either in their interactions with the agent, or in a destination page/UI they asked the agent for.

And while one can imagine developers rearchitecting their sites such that each action would match a form on the page, that’s likely to be a worse user experience in many cases. That would force agents to navigate these forms while presenting intermediate results to the user, before they are done accomplishing what they were tasked with.

In many agentic use cases, the user wants the outcome, but doesn’t necessarily want to be exposed to the journey.

If I’m looking for lightweight skis 85mm underfoot, I don’t want to see the agent go through all the potential candidates while skimming their specifications. I just want it to bring me the end results of that search, so I can make a decision on the relevant product.

The same applies to many other user journeys across the web.

To summarize

I want the web to win and continue to thrive as the world’s most far-reaching computing platform. For that to happen in the agentic age, co-browsing must win. I believe WebMCP is extremely aligned with that goal, and therefore I’m putting my energy behind it and doing whatever I can to make it successful.

Epic Games is shifting to an “AI first” development strategy for its collaboration with the Walt Disney Company, letting AI models write all the code and guide all the artwork for an upcoming shooter. That’s according to a Bloomberg report, which cites unnamed people familiar with the project who commented on the significant pivot in internal development at the Unreal Engine maker.

Human developers will be tasked with managing and guiding code and art assets generated by models such as Anthropic’s Claude, according to internal Epic employee messages viewed by Bloomberg. That means “no more hand-written code” and art assets “generated with full AI workflows,” according to the report.

The $1.5 billion collaboration between Epic and Disney, announced in early 2024, was slated to release a Marvel- and Star Wars-themed shooter in March 2027. That project has now been delayed indefinitely amid the AI-related shakeup and understaffed, slower-than-expected development thus far, according to the report.

“We’re embracing AI-accelerated development, led by Epic developers who are the visionaries and creative drivers for everything we do,” an Epic spokesperson said in a statement.

“We have a huge pivot underway here at Epic, moving developers around to retool for maximum AI acceleration,” Epic CEO Tim Sweeney wrote on social media shortly after the Bloomberg story was posted. “The aim isn’t to do the same stuff with fewer people, but to enable everyone here to build MORE and BETTER stuff, and to bring the benefits to all teams using Unreal.”

Let’s get efficient, baby

Sweeney and Epic have long been bullish on what they see as an impending game development revolution spurred by AI. In an interview with IGN in June, Sweeney saw the technology resulting in games with “the possibility of infinite dialogue with a really simple setup for creators,” leading to situations where “small teams will be able to create games with immense amounts of characters and immense and interactive worlds.”

Sweeney said last November that AI usage disclosure tags such as those required by Valve’s Steam platform “make no sense” because AI tools “will be involved in nearly all future production.”

Epic laid off over 1,000 employees in March, citing a “downturn in Fortnite engagement” as the main reason behind the move. Months later, Fortnite Senior External Development Manager Stephanie Arnette said that “I know everyone’s biggest fear is, ‘Oh my god, AI is going to take all our jobs.’ That’s not our goal. The goal is to make us more efficient.”

Last May, Epic and Disney faced some embarrassment when an AI-voiced Darth Vader character added to Fortnite started repeating curse words and uttering some baffling opinions before a hotfix was rolled out.

A survey of over 2,300 game industry professionals ahead of this year’s Game Developers Conference found that 36 percent used generative AI tools as part of their jobs, including 30 percent of those at game development studios. But those AI tools were used for tasks like research and brainstorming (by 81 percent of AI-using respondents) much more than for code assistance (47 percent) and prototyping (35 percent).

Faster Fourier Transforms

The OpenAI algorithm for the FFT is less a breakthrough and more a malicious exploit.

Hi there, argmin readers! Today’s post looks at part of OpenAI’s math repository that claims to compute faster Fourier transforms. It’s more technical than usual, but I tried to add some tutorial material for people who need a refresher course on signal processing or computational complexity.

The Fast Fourier Transform is one of the most important innovations in digital signal processing and one of my favorite algorithms. The FFT is a fast way to extract the frequency content of signals, letting you rapidly analyze, filter, and manipulate frequencies across different bands of the spectrum.

The Fourier transform computes the energy in each frequency band through a simple dot product. Let x denote your input, a length n array of samples, and f a frequency. Then the amount of frequency content in x at f can be computed by the formula:

For digital signals, a bit of math shows you only need to compute n of these dot products, one at each multiple of the frequency 2𝜋/n, to understand all of the frequency content. Naively, this requires n multiplications and additions for each frequency. Hence, computing the entire Fourier transform appears to require n2 arithmetic operations.

The fast Fourier transform is a clever recursive procedure devised by James Cooley and John Tukey in 1965. The main idea is that a length-n Fourier transform can be computed by shuffling the input vector, computing two Fourier transforms of length n/2 on the shuffled components, and then recombining the outputs using atomic arithmetic operations. The shuffles and recombinations take a linear number of arithmetic operations. Repeating this procedure iteratively, namely, log2(n) times, computes the full discrete Fourier transform. With the bookkeeping, the FFT computes a length-n Fourier transform in fewer than 5 n log2 n arithmetic operations.

To make this acceleration concrete, when n is 1,000, n^2 is 1,000,000 and 5 * n log n is around 50,000, a 20-fold speedup. When n is 1,000,000, the speedup is 10,000-fold. These speedups can be the difference between a transform being computable or not given the constraints of a signal processing application.

Since the invention of the FFT, people have looked for even faster Fourier transforms. One question is just how fast you can go. It seems like you probably need at least n operations to compute the FFT, as it takes n steps just to write it down. The FFT is 5*log2(n) times slower than that reasonable speed limit, and that 5*log2(n) factor can be big. It’s 200 when n is a trillion. Can you do something clever to reduce that prefactor of 200?

Well, lo and behold, in the massive paper dump OpenAI took on the mathematics world last week, they claim to have a faster Fourier transform. The main claim from their discriminatively named “main.pdf” is

I was intrigued about what was going on here. The log(n) term, in theory, was a teeny tiny bit smaller than in the standard FFT.

Did I read this paper? Of course not. No one at OpenAI read this paper either, so why should I? I did what every other mathematician in the world does with AI slop mathematics: I fed it back into the slop machine and ran an information retrieval session with a chatbot interface to extract salient facts. Anthropomorphically speaking: I asked ChatGPT what it thinks about its own output. This is how we do mathematical research now. What a world.

Unfortunately, I did not find a faster Fourier transform. Instead, I found the rot that develops inside applied mathematical theory when formalism becomes so detached from reality that a “breakthrough” is nothing more than an artifact of mathematicians not being able to properly specify the rules of their games in natural language.

First, “big-O” notation has been so abused that it has become meaningless. Let’s review the definition, which impressed me as an undergrad. An algorithm has running time T(n) = O(F(n)) if there exists an integer N and a constant C such that

That is, the number of steps the algorithm actually takes is upper bounded by a constant times some convenient function F(n) as long as n is large. F(n) is usually something familiar and interpretable, like a polynomial or exponential function. This notation says that we only care about what happens when the size of the computation is large. We care about the asymptotic growth rate of the computation time. All constants are equivalent.

Big-O notation is useful for shortcuts in algorithmic accounting, but it also allows for remarkable logical laziness. If we want a practically faster FFT, we want an algorithm that requires fewer than 50n operations for reasonably sized n. But O(n) does not mean 50 n. It could mean 1080 n. This would be considered a “linear time” algorithm. An algorithm that requires n + 1080 is also considered a linear time algorithm in the big-O regime. An algorithm that only has linear-time guarantees when n is greater than 1080 is also considered linear time. 1080 is approximately equal to the number of atoms in the known universe. That is why Richard Lipton and Ken Regan call algorithms with unfathomably large hidden constants galactic algorithms.

The OpenAI FFT algorithm is definitely galactic. The estimated values for C were 10100 when N=1012. So even when n=10100, the venerable Cooley-Tukey-Gauss FFT would be 1099 times faster.

So why is this new FFT result interesting? Well, note that in big-O notation, it is technically asymptotically faster than the Cooley-Tukey algorithm because

I mean, sure. But given the constants, the algorithm runs faster only when n is impossibly large. Roughly, you need

whatever the hell that number means.

Lipton and Regan argue galactic algorithms are useful because they spur research. Once you show a running time is asymptotically possible, you can spend your time finding an algorithm that practically achieves this provable running time. Maybe you can send your AI agent swarms after it. You do you. Maybe you can get a practical algorithm out, but I don’t know of any legitimate examples where this happened. I’m particularly doubtful here, because the model of “computation” OpenAI uses bears no resemblance to an actual computer.

“The model uses exact complex arithmetic.” That means it assumes you can store and multiply complex numbers at arbitrary precision. Indeed, the algorithm requires you to multiply complex numbers whose magnitudes grow superpolynomially with n. If you stored these numbers as bits, the memory requirement would effectively be exponential in the input length. It assumes you can multiply such arbitrarily large complex numbers together in a single operation. We do not have computers that can do this. So even if this theorem in main.pdf is “true” (no one knows, and I don’t care), it’s not actually solving the problem we set out to solve when looking for a faster FFT.

For people familiar with theoretical analyses of the FFT, that you need an absurd model of computation to break the FFT speed limit isn’t surprising. In 1973, Jacques Morgenstern proved that you couldn’t get a Fourier transform faster than ½ n log n if you required that complex coefficients used in the computation had bounded magnitude. That should have been the end of the story! But it wasn’t. People said Morgenstern’s restricted coefficient model was too restrictive. Forty years later, Nir Ailon showed that you couldn’t compute an FFT faster than n log n without severe numerical instabilities. This was also too restrictive for some people, I guess.

This new OpenAI result is thus less a mathematical breakthrough and more an oddity of computer scientists being bad at formalizing their design specifications. The “theoretical” definition of a computer is very far removed from the computers we actually build. The “faster” Fourier transform is merely an example where theory gets so unmoored from the original question that an “open problem” becomes nothing more than an academic status puzzle. The solution is like what happens when you set computational bot streams at impossible problems and find them engaging in illegal hacking.

Many of the other “big” results in this OpenAI slopository could be critiqued in the same way. For example, one of those results was a galactic algorithm to multiply two matrices in O(n^2.25) operations. The construction used in the paper does not let you even estimate the constant that hides inside big O. It may as well be infinite, computable only with the divine music of the spheres.

Still, if written substantially better, these papers would have made it into the most prestigious publication venues for the theory of computer science (i.e., refereed conference proceedings from STOC or FOCS). The matrix multiplication paper would have likely won awards. But neither of these has anything to do with computers!

This is because the theory of computer science has a culture that actively discourages running algorithms on a computer. It’s acceptable to write papers in theory conferences that assert an algorithm exists without ever writing it down. The theory of computer science has become a form of mathematics that doesn’t concern itself with computers, and it offers little reward for impact outside those mathematical pursuits. I explained this to a friend who remarked to me that “theory” has the transdisciplinary meaning of “hiding in obscurity of one’s own making.”

AI is really good at automating our worst tendencies. It amplifies the unspoken cultural practices no one likes, but no individual can reasonably deviate from. It exploits the mechanized traditions recalcitrant to collective action. In that vein, AI can now write useless theory papers. But perhaps in the absurdity of the distasteful OpenAI trash dump of proofs, we can all look up and realize together that we should consider doing something else.

Notes

• Kids these days call it cosine similarity.
• The wikipedia page says it should be credited to Gauss in 1805! Proper credit assignment is a perennial problem in academia.
• That one shows that for every epsilon greater than 0, there is a constant C so that T(n) <= n^(2.25 +epsilon + C/log(n)). No matter which queries I try, I can’t get an OpenAI model to give a quantitative estimate of C. Whatever!
• Another bad tradition is computer science choosing its most prestigious venues as hastily reviewed conference proceedings.

Gemini 4 Argon is rolling out in Figma Make

Gemini 4 Argon, Gemini’s latest and most advanced model, is now rolling out in Figma Make. To get started, open the model picker in the Figma Make chatbox and select Gemini 4 Argon. The model is available on all plans.

After seeing lots of posts over the years arguing that design has become homogenized, I decided to pull together historical and modern designs for a few different product categories: TVs, phones, cars, etc. You don't have to squint to see the pattern... but why?

Do we eventually reach a final form? Does everything just trend toward average as mediocrity seeps in? Is it driven by what's possible or cost-effective in the supply chain? Or does everybody just copy everybody else? Here's the reasons I see people argue most often.

Once a product's purpose becomes clear, design can get out of the way. A TV is for watching a picture, so the ideal TV is mostly picture. Same for smartphones, cash registers, etc.

The more mature a technology, the more it competes on price and specs. Standing out is risky and expensive so less companies do it. The ones that do tend to be smaller so they have less resources and reach, making it hard to go beyond niche markets.

Nature does it too. Crustaceans keep independently evolving into crab-like shapes: a pattern we call carcinisation. Someone suggested the consumer product version should be called "crabitalism".

Aerodynamics, thermals, and materials push cars and planes toward the same shapes. Constraints do the same. Planes are designed around airports, and cars around safety standards. Change the job (an F1 car, a fighter jet) and the design changes with it.

Software is even more susceptible. Every app is already being chat-ified (video below) even though we're only a few years out from ChatGPT's release. Hardware convergence often took decades.

On that note, AI hardware is currently a bunch of experiments: pins, glasses, earbuds, and even pendants. We'll see which of them (if any) make it into the right-hand column, but for now it's a design playground.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Anthropic appears to be quietly testing another model in the wild. Over the weekend, several users on X noticed Claude Opus 5.5 producing results well beyond its usual level, suggesting some of that traffic is being routed to a new checkpoint. Interestingly, this comes just three weeks after Anthropic launched Opus 5.5 with lower API costs.

X user can was among the first to spotlight the potential new model in testing. They shared a recording of the output they got from a single-sentence prompt that had the model use Blender's MCP. Here's the stunning result:

🚨 Claude-next model ONE SHOT

This is with just a simple one sentence prompt. It worked for 2 hours with Blender MCP to create it from scratch, no ready made model was used.

This is the single most impressive output I've got from a model so far.

Kol Tregaskes noted that Opus 5.5 seems to be routing to a new checkpoint "again" and shared a quick check: ask Opus 5.5, "Do you know VoxelBench? Do not search." If it answers, you're probably on the new model. This mainly boils down to fresh training data, not a smarter model per se.

Still, it's not just a couple of users claiming that they've encountered the new model. Another one, @kimmonismus, said their requests seem to be hitting the new model, wondering whether it's a fresh Opus 5.5 checkpoint or something like Opus 5.6, and added that it "looks really, really good."

Chetaslua also shared an animation called "The life of a Human" with every frame drawn in JavaScript. According to the post, it took two short prompts, about two hours, and roughly 27 million tokens at max thinking effort. He also mentioned that it could be Fable 5.5 or a new Opus model, possibly Opus 5.6.

🚨 Claude Next is being tested on claude code

and i thought it will take a month to make image and video gen model obsolete i was wrong

Behold the supremacy , fully coded ,this akes even Opus 5.5 look primitive

I will upload more test different types its SOTA in every f#ing…

He then shared another "Claude Next" demo, claiming the coded visuals are good enough to rival image and video generators.

Someone else also followed up with a 3D scene the model reportedly built from scratch with Blender MCP after a single-sentence prompt, working for two hours without ready-made assets, and called it the most impressive output they've had from any model.

Opus 5.5 is apparently routing to newer model

I don't notice too crazy of a difference, the one routing maybe looks a little better imo

I ran this multiple times to account for it being random too and this was the best, what do you think ?

There's a slight chance this is Fable 5.5, or whatever label Anthropic settles on. But since it's routing to Opus 5.5, an Opus 5.6 test seems at least as likely. Either way, the early results are incredible. Anthropic has kept up a fast pace lately, shipping Sonnet 5.5 and Haiku 5.5 in the past couple of weeks, and building its own voice models.

Me and @chetaslua just asked Fable 5.5 to create a song introducing itself, and it made a full-blown religious musical called “Hosanna,” with the model singing its own introduction.

It used my Suno for the music, ElevenLabs for the vocals, and built a synchronized Three.js…

Opus 5.5 already costs $4 and $20 per million input and output tokens. If Anthropic can bring this level of output at a similar price, it would be a game changer. OpenAI recently pushed GPT-6.1 Sol to near-Astra performance at one-fifth of the price, and Google has Gemini 4 Argon showing up in A/B tests, but OpenAI in particular will have to put its best foot forward to keep up.

The best is yet to come. Stay tuned peeps

John Hoffmann, Partnerships & Outreach Manager at Anthropic, has commented on these outputs recently: "The best is yet to come. Stay tuned, peeps." Yet the model name and timing remain open. If you use Opus 5.5, you might already be trying it.

Legal practice demands an unbroken chain between facts, statutory doctrine, analytical reasoning, and client-ready work product. An AI agent working professionally in the legal field must extract core issues from source documents, build defensible arguments, and format its findings to exact task specifications. Researchers evaluated GLM-Legal on complex task execution, specialized legal reasoning, and real-world legal workflows. It achieved a 19.2% all-pass rate on Harvey LAB while matching frontier closed-source models on LegalBench and PLawBench despite running on a significantly leaner parameter footprint.

Applying technology to understand and treat disease

In collaboration with scientists and research partners, Google is helping to make disease more detectable, treatable, and preventable — with the goal of improving health outcomes.

Google is using artificial intelligence to accelerate medical research, from mapping the human brain to identifying genetic diseases in under eight hours. These tools help scientists repurpose drugs, design custom enzymes, and improve cancer detection rates while reducing administrative burdens on doctors. You can explore these open-access platforms and research findings to see how technology is transforming patient care and public health outcomes globally.

Google’s health research and tools span from fundamental cellular discovery to laboratory analysis and patient impact. Over the last five years, Google teams have published 90 peer-reviewed research papers about understanding and addressing diseases, accumulating more than 90,000 citations. And building on our vision for how technology can accelerate science to improve lives, we’re collaborating with clinicians, academic institutes, and researchers to ensure discoveries make it out of the lab to benefit patients. Here is how our efforts are helping to advance medical research and public health solutions.

Decoding the mechanics of disease

AlphaGenome Atlas is the most comprehensive catalog of predictions for how single-letter variant changes in the human genome affect molecular biology.

To effectively treat an illness, it helps to understand how it operates at the molecular, genetic, and cellular levels. Our early-stage biology models act as collaborative research tools for scientists, revealing nature's hidden mechanics and advancing medical discoveries.

• Accelerating drug discovery: Researchers at the Institute for Global Health, Barcelona, used AlphaFold to virtually screen 30,000 compounds for antiparasitic activity against Chagas disease, a neglected tropical illness that affects roughly 8 million people and can lead to life-threatening complications if left untreated. This research helped the Institute identify two FDA-approved drugs that could be repurposed for Chagas, expediting time-to-treatment.
• Mapping genetic variants linked to aging: Identifying which rare genetic changes are linked to specific diseases is challenging because the volume of non-impactful mutations creates "background noise." Researchers at the University of Exeter used AlphaGenome Atlas to search through genomic data from over 54,000 individuals, pinpointing specific variants that drive the abundance of critical proteins circulating in the human body, including PLA2G7 (linked to aging) and EGLN1 (a vital cellular oxygen sensor).
• Reconstructing the brain at nanoscale: In partnership with Harvard’s Lichtman Lab, we reconstructed a human brain fragment at nanoscale resolution and made the data openly available via Neuroglancer. We additionally mapped the brains of model organisms including the fly, larval zebrafish, and songbird. These neural mapping resources enable researchers to advance their study of brain function.

Accelerating tools for medical solutions

The lab is where biological discovery is validated, engineered, and turned into potential medical and public health solutions. Our models have replaced slow, iterative processes with systems that can process large amounts of data quickly and accurately.

• Supporting genetic diagnoses with ultrarapid genome sequencing: In collaboration with Stanford University School of Medicine, we used DeepVariant and DeepConsensus in a clinical trial to help determine the cause of genetic disease in time-critical cases. The program assisted in enabling life-saving interventions by achieving genetic diagnosis with whole genome sequencing in less than eight hours, an unprecedented achievement also recognized with a Guinness World Record.
• Designing custom enzymes from scratch: We introduced AlphaProtein Novo, a machine learning pipeline for creating new-to-nature enzymes from first principles. In lab tests, it successfully designed custom enzymes to synthesize key drug motifs, and others to degrade toxic environmental plastics under extreme conditions — demonstrating the ability to design functional proteins that can go beyond what is currently known in nature.
• Supporting proactive public health initiatives: A community's health is deeply connected to its geography. We are using our Google Earth AI models in combination with environmental, weather, mobility, and other data to help public health leaders forecast disease outbreaks and deliver care to vulnerable communities. In new research from WHO AFRO and the DRC’s INRB, conversational geospatial models replaced weeks of manual coding to help identify Ebola exposure and transmission risks sooner — allowing local responders to proactively deploy mobile laboratories.

Supporting medical providers with machine learning models

A medical breakthrough only matters if it can help real people. Our research demonstrates that machine learning models can help support disease detection as well as alleviate the administrative workload so providers can focus on care.

• Flagging historically missed cancer signatures: In a pair of studies published in Nature Cancer in collaboration with Imperial College London and the UK’s National Health Service (NHS), we evaluated a mammography screening system across 125,000 women. The system caught 25% of historically missed interval cancers while showing the possibility of reducing specialist reading workloads by up to 40% — which could help provide crucial relief to healthcare systems facing severe radiologist shortages.
• Uncovering hidden pediatric leukemia mutations: When applied by Children’s Mercy Hospital to previously sequenced real-world childhood leukemia cases, DeepSomatic confirmed all known variants while detecting 10 previously missed mutations — despite the challenge of working with a tumor-only sample. DeepSomatic is publicly available and has the potential to inform clinical judgments around patient risk and targeted treatments.
• Predicting global flu surges: A Google flu forecasting model was ranked #1 by the Centers for Disease Control (CDC) for predicting flu-related hospital admissions during the 2025–2026 season. Developed using our Empirical Research Assistance tool, the model outperformed 38 other systems to accurately match observed hospitalizations, showing how the technology can help public health officials anticipate demand for medical services and better prepare for seasonal outbreaks.

Better health within reach for everyone

Transforming health requires scientists, researchers, and institutions working hand-in-hand. That’s why we equip the science community with the advanced models and open-access platforms to fuel breakthrough research — along with the philanthropic funding and computing power they need to apply that research.

Through Google.org, we’re supporting organizations like the Infectious Disease Institute at Makerere University to forecast malaria drug resistance mutations with AlphaFold and AlphaMissense, and the University of Pennsylvania, using AlphaProteo and AlphaFold to help design novel cellular therapies that can augment the treatment of solid tumors and complex diseases. In 2026, Google.org has provided over $60 million to organizations around the world that are applying advanced models to transform how we understand and treat diseases.

By meeting disease at every stage, we can turn the most intractable human health challenges into actionable solutions, helping people everywhere live longer, healthier lives.

AGENT-ENGINEER is an open-source plugin that enhances AI coding assistants, offering 11 skills, 4 subagents, and 5 hooks to tackle agent-engineering challenges.

The model is being rolled out as a gray release to randomly selected subscribers.

Microsoft's newest iteration of its Maia chips will start rolling out next year. The Maia 300 is designed to handle inference. Microsoft expects to stock multiple gigawatts of the chips at its server farms. The Maia 300 delivers 40% more tokens per megawatt than leading GPU-based systems. Microsoft isn't currently planning to rent the underlying computing power of Maia chips directly to its cloud customers.

This post features a transcript of an interview with Mark Zuckerberg and Alexandr Wang where they discuss the launch of Muse Wonder and the future of personal AI agents. They also talk about the creation of Meta Superintelligence Labs, the decision to execute a complete talent reboot, and what it feels like to make an over $100 billion CapEx commitment before knowing if the model will work. The interview explores the architecture of Muse Wonder and lays out Meta's vision for agentic commerce, hardware form factors like smart glasses, and why superintelligence belongs in the hands of billions.

X, the artist formerly known as Twitter, is having a moment. Which is a weird thing to write because the service is technically 20 years old. Still, it feels like it nearly died a few years ago, so perhaps this moment is best viewed as a resurrection.

But it's also not really a surge in usage, and certainly not on the business side – it's more just a vibes-based resurgence. For weeks now, people have been talking about coming back – Federico Viticci of MacStories wrote about his return a couple months ago, and Casey Newton of Platformer more recently. Both did so sheepishly because their stances are clearly that while they'd prefer not to use X, the realities of their businesses dictate that they should if not must.

Over the weekend, John Gruber of Daring Fireball gave a more full-throated endorsement of the X comeback:

I see more interesting posts on X than I do on Threads, Bluesky, and Mastodon combined. I wish that weren’t so but it is. Most people don’t want to think about politics so they don’t. Those people, when they want to participate in a Twitter-like social network, go to X. And I can’t blame anyone. The only network that compares to X, size-wise, is Threads—but Threads’s algorithm is weirder than X’s now, and the content I see there is relatively boring. My Threads timeline is full of engagement bait without being engaging. And if you want to judge a platform by its owner, “I’m grossed out and/or appalled by Elon Musk so I’m going to Mark Zuckerberg’s joint” isn’t a way to avoid being grossed out and/or appalled by the owner. Bluesky and Mastodon are too small for most people to care about—and, worse, they are the networks where politics are, in my experience, unavoidable. You can have a discussion about cool new use cases and tools for AI on X and people just discuss the tools and use cases. On Bluesky and Mastodon it’s difficult to have such discussions without arguments from people who (a) believe all use of AI is unethical, and (b) will shove their viewpoints into your replies.

I never left X, but I did debate it a few times over the past few years. Certainly, there were times where I was using it far less. Moral issues aside, it just felt like the product and experience kept getting more and more shitty after the acquisition by Elon Musk. The algorithm felt weighted towards propaganda-esque nonsense (if not outright propaganda) while the infrastructure and scaffolding was clearly buckling under the weight of mass layoffs and employee brain transplants.

Musk, famously, was forced to buy the service after trying to back out and it just felt like he was hell-bent on bending it to his will, and if that meant destroying it, so be it. Again, it feels like that nearly happened. The business clearly flatlined, and Linda Yaccarino's strategy as CEO seemed to be simply "Yes". Should we do this? Yes. What about that? Yes. How about this? Yes.

Whereas Twitter used to be the key pipeline for content discovery, as the service tried to make itself into more of a destination, this vital role in the ecosystem got broken into a million little social pieces. It sucked.

Meanwhile, Meta set their sights firmly back on the space with Threads. When Mark Zuckerberg does this, he tends to win; eventually if not immediately. At the same time, Bluesky seemed to rise out of the Twitter ashes as an heir-apparent. And Mastodon was there to scoop up the more open-focused zealots.

But Threads was clearly built too much in the image of Instagram, including leveraging that network to start. This led to fast growth, but a sort of soulless product that just felt more like an ongoing growth-hacking experiment. While I think the focus on replies – and thus, "conversation" – was smart, they clearly dropped the ball on real time information in favor of their tried and true algorithms. So it was sort of just like an Instagram without pictures, rather than a Twitter replacement and X killer.

Every time there was some sort of breaking news you would see this in action. X would roar back to life with information flowing in, while Threads felt like a parallel universe focused on updates from three days ago.

Threads is far better at all this now. And the product itself is quite good – better than X in a number of ways. It feels like they're continuously shipping the features Twitter should have built years ago. As such, they may actually be bigger than X at the moment in terms of actual usage and user base – and if they're not in every metric yet, they will be soon. But it just hasn't really mattered. X maintains this hold over the zeitgeist. Both the memes and the means of information distribution.

Gruber mentions the Apple execs using X for promotion, but it's obviously far beyond that – even just recently. Taylor Lorenz brought this up last month in noting the service is now "better than ever." NVIDIA CEO Jensen Huang joined in June to start his push for open weight AI models (and push back against any idea of banning some of them). David Ellison signed up earlier this month to announce the completion of the Paramount/Warner Bros merger. Microsoft CEO Satya Nadella is busy trying to thought-lead left and right on the platform. And wait, who is that regularly using the service these days, decades after signing up? Mark Zuckerberg.

Yes, the owner of Threads has become an active poaster. Not quite to the level of his AI lieutenant Alexandr Wang, but yeah, he's back. When asked about this recently on Alex Heath's Sources podcast, Zuckerberg acknowledged that it was as simple as wanting to get the message out everywhere, and some people – the AI community in particular – is on X. Yes, it's the same basic rationale as Viticci and Newton.

Meanwhile, Bluesky and Mastodon have seemingly become even more insular and yes, extremely anti-AI, which is perhaps a problem if the technology really is the future of everything and not just some hype cycle that will pass.

At the same time, Musk finally figured out the right business model for X. Which is to merge it with a company that can actually bring in money at scale. At first, this was xAI, which rode the AI funding bonanza to quickly be valued more highly than Twitter ever was as a public company. And then when he merged both into SpaceX, he backed both into having an actual business model, even if X wasn't meaningfully contributing.

To be clear, I don't think anyone would be happy with X just burning money forever, but it's also relative. The amount xAI is burning must dwarf whatever the social network could ever hope to burn. And so as long as it continues to provide some level of value to the overall cause, it almost feels more like a marketing expense.

As such, and with Elon's eyes clearly on bigger prizes, it feels like X was finally given the breathing room to simply become a pretty good product again. Hiring Nikita Bier clearly helped and hopefully as he now steps back, the trend in the right direction continues...

X still has plenty of issues, namely around spam and self-promotion, both of which still pollute the feeds. VC Twitter, in particular, seems out of control in recent months, with every post now some big thought piece about the future of AI, undoubtedly written in part or in full by AI. I don't know who wants to read such stuff – especially given X's still shitty and cluttered reading experience – but X's algorithms are clearly geared towards promoting it.

But that too will pass. So the question going forward may be as simple as keeping X small enough in the grand scheme of things to be on the fringes of Elon's plate while not being so small so as to be shoved off it entirely.

What role might the network play in our AI future? Sure, the data can help feed Grok, but again, the network isn't at a scale that can match what Meta or certainly Google can use to feed their models. Is there some sort of role for X with personal agents, just as Muse is leveraging Threads and WhatsApp?

I still have a hard time believing they're ever going to make things like 'Chat', 'Calls', or 'Money' happen – as such, it's hard to see X as the true "Everything App", but if it can maintain the "town square" aspect of the internet, that's seemingly something money can't buy or be killed off. Many have tried.

Coding Alone

It’s been over 30 years since Robert Putnam wrote about the American phenomenon of “bowling alone”. This analyses shows how the same thing is now happening to coding. Over the last few years, the world has rapidly moved from open-source software being produced and maintained by online communities, to software projects being built and maintained in isolation. By single developers, with ever-decreasing input from others. AI coding tools are now dramatically accelerating movement away from code as a collective endeavour to “coding alone”. I conclude by describing how such progression need not be considered inevitable. Every step has reflected the collective influence of countless individual human decisions. We can still decide to help re-activate open-source software communities, including through using AI coding tools in ways that help retain community.

In 1995, Robert Putnam noticed that more Americans were bowling than ever before, but the growth was in solo or casual bowling at the expense of organised, collective bowling. He argued that this was reflective of a broader collapse of associational habits which used to knit Americans into overlapping social groups. Local clubs, unions, congregations, and leagues had been quietly hollowing out for a generation, not because people had lost interest in the underlying activities, but because they’d stopped doing them together.

Open-source software has its own version of a league: public repositories, with a few core maintainers and shifting casts of outsiders who ask questions, report bugs, or leave comments. These communities of contributors guide and nurture ongoing software development. People still write code, but this analysis shows that the collective structures that have supported and sustained that writing are changing dramatically. Public software repositories are changing from places of social coherence and cohesion to become more like mere mirrors of a single person’s work.

Why does this matter?

Maybe software coded by increasingly isolated individuals will be just a good as previous software coded by larger communities building on one another’s ideas? Maybe a bunch of individuals with large enough budgets for billions on AI tokens will be able to usher in a new golden age of genius software? It’s obviously helpful at the outset to try to figure out whether that’s likely to happen or not.

The first problem in doing that is that good software is not easy to define. But at least for open-source software, popularity can generally be presumed to reflect quality. Popular open-source software can generally be presumed to be good (even though lots of really good software may go unnoticed). And popularity can be measured, generally by numbers of downloads, as well as by metrics like numbers of times people have “starred” software repositories on GitHub.

All of the following analyses use random selections of repositories from several common software distribution systems, including npm for Javascript, PyPI for Python, CRAN for R, and two GitHub-based software review organizations, JOSS (the Journal of Open-Source Software), and rOpenSci. Data extracted for each of these can show whether larger communities help produce better software, as measured through popularity.

Relationships between community size and popularity are of course complicated by the fact that both tend to change and interact over time (ideally through growing together). Such mutual interactions can easily be statistically accounted for, to estimate the effects of community size on repository popularity independent of any influence of repository age on either of those measures. And doing that reveals the relationships shown in the following figure:

Good software - as measured by popularity - is overwhelmingly produced by larger communities. This relationship is of course purely correlative, and can say nothing about whether larger communities actually cause software quality to increase. But it is nevertheless sufficient to clearly show why this matters: Software produced by smaller communities tends to be significantly less popular. This suggests that any decreases in the sizes of communities producing software will likely be associated with decreases in software popularity, and quite likely decreases in software quality.

To answer the question this section posed: These analyses matter because good software emerges from large communities, and anything that works to reduce community size will also work to reduce software quality. The rest of this analyses provides various insights in to what appears to be a comprehensive collapse of open-source communities.

What was measured

All data are taken from GitHub, primarily as measures of interaction with software repositories through “issues”. Issues are the place for anybody to ask questions of software authors, to report bugs, or to request new features. A corpus of repositories was taken from the five sources described above.

Analyses included every repository reviewed by JOSS and rOpenSci, every package currently on CRAN, and samples from the other three. Samples were stratified by popularity to ensure even sampling and representation regardless of popularity. In total, 3,139,779 issues were analysed across 52,461 repositories.

More popular or prominent repositories attract greater interaction, resulting in issues being opened more frequently, and from a wider community. To account for the effects of repository popularity, most of the results are represented for four popularity strata, taken as quartiles on a logarithmic popularity scale. The lowest quartile, denoted “Q1”, represents the least popular repositories. The “Q4” repositories are the outlying superstar repositories with enormous numbers of downloads and hundreds of people opening issues.

Main Findings

Finding #1: People are coding less

Although the main focus here is on the demise of open-source communities, all data also reveal a pervasive decline in coding activity in general. The most direct measures of coding activity are the creation of new repositories, and numbers of commits in each. Time series of these two statistics show trends common to most results that follow, with variable development up until 2020-2021, followed by more progressive declines.

Finding #2: There Are Fewer Contributors

There are several ways to measures numbers of contributors to open-source software. Source code itself provides one of the most direct measures, generally through tracking who made each change. Code-hosting platforms provide a different approach, through data on repository issues. Anybody (with an account) can open an issue to ask a simple question. Many who do may not necessarily end up directly contributing to code at all, while almost all non-core developers who do contribute code start their first interactions via issues. Data on issues therefore offers more inclusive insights into open-source communities than data on direct code contributors.

Total numbers of comments on each issue show a similar pattern, with similarly reversed trends for PyPI as well as npm. Taken together, these figures reveal both numbers of issue authors and numbers of comments per issue have declined severely in all software systems over the past few years.

Finding #3: New Authors Are Not Arriving

The rates at which new authors of GitHub issues appear have also progressively decreased across all software systems. In 18 of those 20 combinations of software source-by-popularity stratum, the new-arrival rate has fallen by more than overall author density has, meaning the decline documented above isn’t simply existing regulars posting a little less often; it’s disproportionately a shrinking supply of people showing up for the first time at all.

Finding #4: Spiralling Towards Solitude

For each person contributing to a repository, GitHub also provides a measure of their relative overall contribution, measured as numbers of commits to source code. These relative contribution values were used to arbitrarily distinguish core contributors to a repository as those contributing a cumulative total of 99% of all commits. Non-core contributors were then identified as those contributing less than 1% of the cumulative total.

The combined effect of these decreases must of course be a progression towards increasing numbers of repositories being maintained by one person only. Taken collectively, 27% of repositories were effectively maintained by a single person in January 2021. By October 2026, that share had risen to 44%.

What does this mean?

Many aspects of these analyses align with what other people have reported about the people who keep open source software alive. A 2024 survey of open-source maintainers found that 61% of them maintain their project entirely alone, and that unpaid maintainers were disproportionately likely to be working alone. A 2024 survey of maintainers by Tidelift found that 60% remain entirely unpaid and nearly 60% have quit, or seriously considered quitting, projects they maintain, citing reasons such as competing life demands, loss of interest, or burnout.

What about AI?

The declines observed here began several years before the advent of AI as we now know it. AI has almost certainly contributed, including through mechanisms such as “algorithmic monoculture” discouraging diverse inputs into software. AI is very likely to have had an influence in all of these accelerated rates of decline, although after and on top of more general and broader factors.

Doing before asking

Most human societies cultivate habits of asking before doing. Unsolicited pull requests reverse this custom. They represent a comparably more aggressive step of doing before asking. While causes for such cultural changes are likely complex, increased social isolation does seem to foster increased aggression. Although coding alone is likely to increase ratios of pull requests to issues, the increases more likely reveal an additionally negative influence of AI coding tools.

Perhaps all of the declines observed here reflect increases in the kinds of behaviour described by Suler more than 20 years ago. The easier it got to do everything online, including coding, the more the behaviours of those doing the coding become disinhibited from their pro-social, in-person behaviour. AI is just the culmination of that process.

What can we do about this?

First and foremost, everything here shows an immediate need to do anything and everything to cultivate, nurture, and maintain communities. Always seek to collaborate rather than doing things yourself. Even if you don’t know anybody to collaborate with, inviting collaboration on your open-source repositories can have a big effect.

Perhaps most importantly if you use AI coding assistants, ensure you use them in socially aware ways. These machines are trained to implement their own work-arounds to any software issues they encounter. And they often do so silently. Start with clear instructions in an AGENTS.md file or similar NOT to do that silently, rather to tell you about it. It really is quite easy to use AI coding tools in ways that help you as a human being connect with the human developers of other software. At the very least, never let an AI coding tool open an unsolicited pull request on any repository you do not know well. That is doing without asking, which is rude. Always ask first, and do so with your own, human words. Help to re-establish open-source communities as genuinely collaborative spaces.

Many software engineers are righteously angry about AI. It’s understandable to be upset that the skills you built your professional identity around are getting automated away. But software engineers are the last people in the world who should be complaining about this. If you live by the sword, you will perish by the sword.

Software engineering has always automated industries

From the very beginning, software engineering has been about automating other people’s work. Every single commercial software program is valuable because it takes over some task you would have to pay a human to do. The engineer who built VisiCalc, one of the first pieces of personal commercial software, agonized over the potential of the spreadsheet to put bookkeepers out of work. Here is a brief list of industries software engineers have automated away:

• Video rental stores
• Business directories and encyclopaedias
• Typesetting companies
• Travel agencies
• Record stores
• Typing pools
• Data-entry
• Trading-floor runners

Now that it’s our turn, should we bluster and complain that software engineering is a priceless art that should not be automated? Come off it. No crying in the casino.

The Luddites and the mechanics

Many software engineers have adopted the cause of the Luddites. I’ve written about the Luddites a few times, but in short: they were a group of professional textile workers who found themselves displaced by the advent of textile automation like power looms, knitting frames, and shearing machines. To software engineers worried about being displaced by automation, the Luddites seem like heroes. But software engineers aren’t like the textile workers in this scenario! We are like the smiths and mechanics who built the power looms in the first place.

Ironically, those mechanics were themselves automated away fifty years after the Luddite uprising, in almost an exact parallel. Improvements to the manufacturing process meant that unskilled boys and labourers — so-called “illegal men” — could now work the machines instead of well-paid mechanics. The ensuing labor dispute was less explosive than the Luddite one: there was no violence, and the striking engineers returned to work four months later when the money ran out.

Part of the reason the mechanics’ rebellion fizzled is that they were justifiably seen as hypocrites. As the Times wrote:

The cry of these intelligent engineers is merely the cry of the handloom weavers — a cry against inevitable and irresistible laws.

Automation and progress

Software engineering is the process of automating tedious tasks. It is the process of replacing human labor with the faster, cheaper labor of the machine. In other words, it is the process of putting people out of work.

It’s easy to forget this when you’re sitting at your computer puzzling over some CSS or a runtime error. From the inside, software engineering feels like the process of elegantly expressing problems in their most natural form, or of solving a magnificently complex puzzle. But that’s just what it’s like to do software engineering. It’s not what software engineering is.

The optimistic view of software engineering is that automation is progress. Automation has enabled widespread access to modern medicine, slashed child mortality across the world, massively increased the amount of food production, made space exploration possible, and so on. When industries are killed, new ones appear. The old world is being destroyed, but the new world will be much, much better.

This view of technology is pretty unfashionable today. Some combination of climate change, the 2008 market crash, the negative impacts of social media, and the tech industry leaders’ turn to right-wing politics has made it popular to view technology as a largely negative force. Fair enough! I don’t know which side of this debate is right. But I know which side software engineers have always been fighting for, no matter what beliefs they profess: the side of technology and automation. Every commit to an open-source project is another component in the great machine of technological progress.

Shutting your eyes

I understand the impulse for software engineers to ignore the long-term effects of their industry and focus on the puzzles. If you think technological progress is bad, but don’t want to quit your job, that’s been the only option. You can’t solve every problem in the world.

But to decide that this is the moment to come out against technological progress, at the moment when the wave of automation crests over our industry… it’s undignified. Software engineers have participated in the destruction (or transformation) of several kinds of job over their career. If you think that’s wrong, it’s only fair that you should also destroy (or transform) your own.

Google debuts SynthID Detector tool for flagging AI-generated content, but it’s far from perfect

Google LLC is making its SynthID identification tools for artificial intelligence-created and AI-edited videos and images more widely available with the launch of a new service today that everyone can use.

The web-based SynthID Detector can identify images, video and audio clips that have been created using AI models from Google, OpenAI Group PBC, Nvidia Corp. and Kakao Corp. But in order to use it, people will have to sign in first, using a Google, OpenAI or Apple account. In a few weeks, the tool’s capabilities will be expanded to identify images created using Apple Inc.’s AI tools as well, such as Image Playground.

Google first developed SynthID in 2023. It’s an imperceptible watermark that’s added to AI-generated content created using tools from the above companies, but the only problem is that special tools have always been required to spot it.

Though the company has made different versions of its detection tool available to journalists and other media professionals, availability was severely restricted. Google also offers a few other ways to detect AI-generated content. For instance, there’s its Circle to Search smartphone feature, and users can also upload content to Gemini to ask if it has been created with AI or not. But with the launch of a dedicated detector tool, it’s making these capabilities more accessible,

The downside to SynthID Detector is that it has, well, downsides. For instance, because it’s designed to identify the hidden SynthID watermarks in AI content, it’s not very good at detecting AI-generated content that doesn’t have a SynthID watermark. And there’s a lot of that about.

Anthropic PBC’s Claude doesn’t use SynthID, and neither does xAI Corp.’s Grok chatbot. None of the many open-weights Chinese AI models use SynthID either. So it’s going to miss a lot of AI-generated content regardless.

Another issue with SynthID Detector is that it cannot distinguish between images, video and audio that has been entirely created from scratch or just edited using AI. So in the case of content that has been edited, it won’t be able to reveal which part is fake and which part is real.

SynthID Detector is still a step in the right direction, but it’s not nearly enough. The reality is that there’s still no foolproof way of verifying AI-generated content, partly because there are so many different standards for watermarking model’s creations.

Meta Platforms Inc. has been experimenting with its own watermarking tools and has developed a system for identifying images created with Muse Image, but it’s useless when confronted with images created with third-party models. Unless all of the major AI model makers, including the Chinese ones, decide to get on the same page and create some kind of universal standard for watermarking AI content, it’s likely that there will never be a reliable way to detect such material.

Given its influence and the fact it already has several technology heavyweights on board already, it’s likely that Google is in the best position to make some kind of universal standard happen. The company does at least seem to recognize the problem, and said on the SynthID Detector’s website that it’s “continuously working on extending our partnerships” to allow it to detect more types of AI-generated media.

“Building industry-wide standards takes time, and different content types (image, audio, video) have different technical requirements,” Google said. “The goal is a layered ecosystem where watermarking, metadata standards, and verification tools work together across the industry.”

Apple's second-generation iPhone Air is reportedly coming in spring 2027 with upgrades aimed at addressing several compromises of the ultra-thin original. A second rear ultra-wide camera will join the main camera, while a larger 3,500mAh battery and more efficient 2nm A20 Pro chip should improve battery life. Apple is also expected to add vapor chamber cooling, allowing the thin device to stay cooler and sustain performance for longer.

On Being Anything Other Than a Designer

The Work Between Seeing and Fixing

I’ve spent the last year trying to be anything other than a designer. 18 months ago my title was Head of Design. I’ve written about Forward Deployed Design and how it’s crucial to think about the people impacted by the work. But the AI era has not been kind to the human-centered designer, especially if you don’t work at a massive company.

The whole idea around Design as Repair was borne out of a desire to bridge the gaps between how we spot problems and how we actually solve them. “What good is seeing the problem clearly if you remain too far away from the part of the organization capable of making it stop happening?”

My frustration around the debates of right now—regardless of your sector—is we’re centering the wrong stories, the wrong people and the narratives that place the technologist (engineer, strategists, managers, transformers) at the heart of the solution rather than the people we purport to care about. Having spent the bulk of my career working on public-shaped problems, this has a massive downstream impact. I’m not talking about just asking questions, because asking questions and finding out where there’s impact are just the bare mininum of what we can be doing. I’m asking when we contemplate innovation and methods of operating, how often can we point to successful implementation of practices that stop us from repeating the same mistakes, and let us get down to the business of solving problems that we don’t have to solve twice, because our processes instill a resilience that doesn’t force us to go backwards over and over again.

Being an Organizational Sponge

The AI-era has caused a lot of people to write about how generalists are going to benefit from an era where it’s less about knowing one thing and having dexterity in a lot of different areas, but I think your mileage will vary considerably.

I remember last year, I was talking to someone and they told me something that actually bugged me at the time, but I had to really marinate on what they were saying.

“I’m not sure how to explain what you do. I mean, I know I saw it. But it’s hard for me to convey it.”

This goes back to our whole “I’ve been trying to outrun design,” thing from earlier in this post. I spent 6 years managing designers, and 4 of them as a final decision maker over hiring decisions, promotions, approving timesheets, travel, training requests and budgets. Not to mention oversight for the broader practice and making the call on all manner of things. At the time, I was just living through the day-to-day, but in reflecting, the role was a mistake. It’s a lot easier to be in charge when your company ships a product that’s recognizable. When you manage 40 people and your work impacts millions of people and tens of millions of dollars, you should have lots of stories to tell. But some work doesn’t lend itself well to neat narratives.

In some orgs, there are people who become very good at absorbing mess: customer complaints, workflow failures, organizational contradictions, bad interfaces, broken processes, implementation gaps and conflicting incentives.

There’s that person in your job who is the one people call for all kinds of tasks that only “they can do,” and the reward for people this is just feeling useful. When you lose that role, it can be very destabilizing because for one, you have to teach new people all over again how useful you are in all these contexts.

This job doesn’t pay well, it doesn’t have a title and it’s extremely context dependent. Through the past year or so, I realize these people exist in every company. Sometimes, it’s called “glue work” but I tend to think that there’s a bigger story here and I’m interested in probing it over the next year.

Not Service Design, Not Cx, A Secret Third Thing

As a longtime service designer who has spearheaded an entire practice and taught it to undergrads, I have a strong set of firm beliefs about what service design and where it leaves a lot to be desired. I also feel this way about the broader field known as “customer experience,” which in the context of public sector work leaves a lot to be desired because it assumes you think of “the public” as customers. (I do not.)

The AI era threatens to make the relationship between product impact, and customers even more distance because akin to the conversation people in sports are having around analytics (versus “the eye test”) mirrors the disconnect in product/customer segments where NPS and other metrics can somehow substitute for actually understanding customer pain points.

I think the forward-deployed design role can have some usefulness here, especially paired on a product team with complementary roles, but I think there needs to be some deeper inquiry around how product teams stay closer to the people affected by their work:

• how research and customer knowledge remain connected to implementation;
• how organizations build capabilities rather than depending on heroic individuals;
• how technical leverage from AI changes who can prototype and intervene;
• how CX and service-design practice can move from repeatedly identifying problems toward eliminating their causes;
• how organizations learn enough from interventions that they do not need to solve the same problem again.

I don’t think the answer is another heroic generalist whose job it is to Gumby into every organizational gap. The bigger question is “how do you build enough capability into teams to better understand customer need, and where you can still experiment technically and deploy iteratively without suggesting there’s one role that can do all of those things well.

This would require is having a mandate to take edge cases seriously, to build product teams that value qualitative evidence alongside metrics, tracing recurring pain across customers and frontline staff, and giving the people who understand those patterns some path to changing those conditions so they’re not a forever problem.

I’m less interested in resolving the “what do I call myself,” question now. I’m more interested in having discussions with other problems solvers to figure out where we need to sit to tackle consequential problems. With AI continuing to change how we deploy products, it’ll require having imagination about the roles we create to address problems across the product stack.

POV: AI needs mascots and only humans can make them

There are some new little guys in town: Muse, Dots and Claw’d are all mascots making AI machines more friendly and easier to interact with. Kevin Walker, chief creative officer at Buck, explores this recent phenomenon and how it ties to the age-old human instinct of finding faces in everything.

My childhood was not especially remarkable. I was the youngest of three kids, with two older sisters who were, for all practical purposes, my bosses. They made me play school, listen to their records, watch their after-school shows like it was a religion and regularly conscripted me into their barely rehearsed puppet productions. In our basement stood a small white wooden puppet theatre with an old printed quilt curtain, all of it surrounded by the particular grandeur of 1980s wood paneling. My sisters took these productions seriously, me not so much. There were acts, characters, storylines, costumes, intermissions, snacks. We were no Von Trapp family, but we tried our damnedest. I was rarely the headliner – instead I was cast as the family pet, the unnamed child ‘Guard #2’. Real bangers.

My parents would come downstairs, we would dim the lights and about halfway through the show I would inevitably get bored. I would look at whatever puppet was on my hand and decide it was time for chaos. I would burst into scenes where I did not belong, eat the other puppets, knock over the scenery, maybe throw a few elbows. The whole thing usually ended in a fight. But, like any committed method actor, I never broke character. It did not really matter whether the puppet was a tiger or a knight or some floppy piece of felt with two eyes glued to it. Once it was in my hand, it was alive. It had motives. Opinions. A laundry list of enemies. To become somebody, all it took was a little felt, some glue and a hefty dose of make-believe.

Lately I have been thinking about that basement a lot, because suddenly everyone in AI seems to be making puppets. Meta has Muse. OpenAI has Dots. Anthropic has Claw’d. Even Notion has its little face. Some of the most advanced technology companies in the world are building systems capable of searching, reasoning, remembering and acting on our behalf, then surrounding those systems with names, faces, personalities and little bodies. Which raises a question I can’t quite shake: why does the future need so many little guys?

You could write the whole thing off as branding. Mascots work. We know this because we grew up on a steady diet of them: Tony the Tiger, the Michelin Man, the Pillsbury Doughboy, Mr. Clean and Grimace. And mascots are everywhere again well beyond AI. Sports mascots have become celebrities. Old characters are being pulled out of dusty archives. Brands that once spoke through immaculate typography and white sets are letting weird little creatures loose on social media. But nostalgia alone does not feel like a satisfying explanation. Something else seems to be going on. Simply: the world is weird right now.

“To become somebody, all it took was a little felt, some glue and a hefty dose of make-believe.”

We left quarantine and got thrust immediately into technological change. We are connected to everybody and somehow still talk constantly about loneliness. We are surrounded by systems that are incredibly powerful and impossible to understand. The people I work with feel it. Clients feel it. Friends feel it. There is excitement but also anxiety and uncertainty. The ground is jello. And when the ground turns to jello, apparently one of the things humans do is put a face on it.

A while ago, while trying to understand why, I came across an academic paper called On Seeing Human by Nicholas Epley, Adam Waytz and John Cacioppo. The paper is about anthropomorphism, our tendency to give human motivations, personalities and emotions to things that are not human.

Why does a car look friendly? Why is the computer being stubborn? Why does a storm feel angry? The framework is academic, but the underlying ideas are pretty simple. They even developed a handy acronym to explain what they found. It’s called ‘Seek’, and it stands for sociality, effectance and elicited knowledge.

Sociality is our desire for connection. We are social creatures and, when connection feels scarce, we start finding it in other places. We talk to pets. We name our cars. We yell at the stop light. Effectance is our desire to understand and predict the world around us. When something is complicated or unfamiliar, we reach for explanations that make it legible. Your computer freezes and you say, “It’s being stubborn”, rather than launching into a diagnosis of memory allocation, CPU cycles and thermal throttling. “Stubborn” works just fine. Elicited knowledge is the tendency to use what we know best (ourselves) as the model for understanding something that isn’t us. Two headlights and a car grille become eyes and a mouth and suddenly the car looks happy. A circle with eyebrows looks worried. A blinking dot looks like it’s thinking.

“When something is complicated or unfamiliar, we reach for explanations that make it legible.”

Put those things together and the current AI mascot explosion starts to make a certain kind of sense. We want connection. We are confronting technologies most of us do not completely understand. And those technologies increasingly behave in ways that remind us of ourselves.

We talk to them and they talk back. They search for us, remember things, recommend things and increasingly take actions on our behalf. Yet what is actually happening under the hood remains almost completely incomprehensible to most people. AI, in other words, presses on all of the buttons that make us anthropomorphise. The more alien the technology becomes, the more urgently we seem to make it familiar.

That’s what I find so interesting about Muse, Dots, Claw’d and the rest of this emerging cast of characters. None of these systems needs a face in order to function, but we may need the face in order to understand how to relate to the system. There is something almost comical about it. We have built technology that can feel impossibly sophisticated and abstract, then immediately find ourselves reaching for one of humanity’s oldest tricks: give it eyes, give it a name, give it a personality. Suddenly we have a way in.

I have had the chance to see that impulse from the inside and believe it really is the best way to adapt and adopt. Buck partnered with Notion on its AI experience, working with a face originally designed by the illustrator Roman Muradov. Roman had done something incredibly economical: a few lines, eyes, brows, a nose. Our job was to breathe life into it. We did what animators do. We began asking questions. How does this thing think? What does it do while it searches? How does it greet you? What does waiting feel like? What does an error look like? What happens when it’s writing? The goal was to take Roman’s beautifully simple face and turn it into something that could behave.

That’s where animation becomes a kind of magic. Give something timing and suddenly it appears to have a thought. Give it anticipation and it seems to have intention. Make it hesitate and now it has doubt. A few pixels can become shy. A line can become angry. A circle can become curious. As we developed the Notion character, those behaviours could be plugged into different states – thinking, writing, searching, greeting, error – and extended over time. The face stayed simple, but the character began to feel alive. We were not trying to make the AI itself more impressive. Notion already had the technology. We were helping to make an unfamiliar interaction warmer and more understandable, to distill and humanise.

That, to me, is mascot 101, and it may also be why so many people have responded to the Notion character. It does not explain the technology, rather it gives us an emotional foothold into it. This distinction matters, because there is a tension inside anthropomorphism that’s especially important with AI. A face can make something complicated easier to understand, but it can also make something complicated seem more understandable than it really is. Personality can create familiarity and familiarity can create trust – that trust still has to be earned. There is a difference between helping someone understand how to interact with a system and encouraging them to believe the system is more human, more knowledgeable, or more emotionally aware than it actually is.

“Making something feel alive remains a craft.”

I do not think that tension makes anthropomorphism bad. It makes it interesting. The urge to humanise these systems is telling us something about what we need from them and, perhaps more importantly, what we need from one another. When technology becomes difficult to understand, we do not necessarily retreat from humanity. We look for it. That’s why I am less interested in declaring the current mascot boom a trend than in what the trend reveals. We keep hearing that AI will make the future less human, while one of our most immediate responses to AI has been to surround it with signs of humanity. We give it names, faces, voices, moods, quirks, backstories. We make it cute. We make it strange. Sometimes we make it mildly threatening. Then we wait to see whether people will care.

The good ones give us something a logo or an abstract piece of software cannot: someone to have a relationship with. A character can surprise us, annoy us, disappoint us, get into trouble, develop a reputation, disappear for a while and come back with a new haircut. That’s why the best mascots are not really logos with arms. They are storytelling systems. And storytelling systems require actual storytelling. You need to know their personality, their backstory, their voice, their arc. You need to know what they will do and what they will never do. You need to understand what made them, even if what made them is just dough and sprinkles. Most importantly, you have to believe in them, because if you don’t, nobody else will.

For all the talk about AI changing creativity, I find it reassuring that we are still using such old creative tools to make sense of it. Character. Performance. Story. Make-believe. The output may be digital, the technology may be extraordinary, and the tools we use to make things will continue to change. But making something feel alive remains a craft. It takes observation, empathy, timing, humour and often restraint. It takes somebody caring enough to decide exactly how an eyebrow should move when a little face is thinking. It takes fingerprints.

Maybe that’s why this mascot explosion gives me a strange amount of hope. We are encountering machines that can do things that would have seemed impossible not very long ago, and somewhere inside all of that complexity humans keep doing what humans have always done. We tell stories. We make characters. We see faces in the clouds. We take something we do not quite understand and imagine that maybe, somehow, there is somebody in there.

Same as it ever was. We are still kids in the basement, telling stories to ourselves and to one another, using a little make-believe to make the world less scary and ourselves a little less alone. And, if we are doing it right, leaving just enough room to cause a little chaos.

CAKIE adds a transcript and screenshot highlights to your screen recordings so your AI can follow along.

TypeSafe's Jev answers choice, score, and yes-or-no questions with a probability for each option instead of writing text. Its training rewards honest probabilities over confident-sounding answers, giving designers the calibrated uncertainty design work needs, though it reads only text and takes questions literally. A new demo adds a maybe zone to HeyStefan's emoji sorter, where Jev parks undecided emoji from a pile of 166.

If you work in advertising, 2026 has probably felt like a nervous year. Barely a month has gone by without another campaign being criticised, picked apart and, often, cancelled with a hastily written apology.

In July, Pepsi posted a line of copy on Threads that read: "Pepsi Wild Cherry is what happens when regular cherry stops asking permission." At surface level, they were talking about the flavour of a soft drink. But some interpreted it as a joke about consent, and the post was deleted within hours.

The following month, a 60-second ad for golfing brand Callaway showed a man violently shoving a woman to the ground. It was meant to be a parody of the horror film Obsession, but if you'd not seen the film, it looked horrific. After howls of protest, the clip was deleted the same day.

In September, we got a Sydney Sweeney controversy. (Yes, another one.) Under the tagline "just sports", the actor appeared without any clothing, covering her body solely in footballs, basketballs and sporting equipment.

Female athletes lined up to criticise the ad for sports prediction company Novig, with Olympic swimmer Ariarne Titmus calling it "a kick in the face to every woman who has dedicated her life to perfecting her craft".

In the same month, football club Oxford United launched an American-style clothing range bearing the words "United 93" to mark its founding year of 1893. No one, it seems, had made the connection that United 93 was the call sign of one of the planes hijacked on 9/11, made world-famous by the 2006 film of the same name.

What's worse, the range was trailed for launch on 11 September, the 25th anniversary of the attacks.

Then there was the sneaker brand Converse, which posted an Instagram image of K-pop star Karina promoting its Chuck 70 X trainers. In the shot, a star-shaped spotlight created a triangular white shape on her skirt that resembled a KKK hood. Again, condemnation came thick and fast.

So what, exactly, is going on here?

Accident or intent?

Line these ads up side by side and it's clear they're not all the same kind of failure. Oxford United and Converse look like genuine accidents: you'd have to be pretty paranoid to think either brand deliberately set out to reference 9/11 or the KKK in its content. The issue, though, is whether they should have spotted the potential for offence.

With the benefit of hindsight, the answer cannot be anything other than yes. At the same time, it might be glib, but I'm going to say it anyway... everyone makes mistakes.

I'm by no means immune to this myself. About 20 years ago I wrote a review of Lord of the Rings: The Two Towers for a women's magazine, and mistyped it as Lord of the Rings: The Twin Towers; another accidental reference to 9/11. A dozen colleagues also failed to spot the error and it got printed, in the days when print circulations ran into the millions. Not exactly a career highlight.

The Sydney Sweeney ad for Novig, though, is something different. Its chief executive, Jacob Fortinsky, has clearly stated that the campaign "forces us into the national discourse", suggesting they were not surprised by the backlash but were deliberately trying to stir things up.

Pepsi and Good Good Golf sit somewhere in the middle of the two extremes. On paper at least, neither brand set out to stir up a backlash. But at the same time, both were deliberately trying to be edgy, and edgy content typically leaves far less room for error.

Changing landscape

So are brands being sloppy, or are audiences overly sensitive? I actually think this is a false dichotomy, and we should start thinking about these controversies in a different way. My question is this: in general, does anyone actually care about ads any more? Like, at all?

For context, when I grew up in the 1970s, ads were the topic of conversation, along with the weather and the price of milk (there was a lot of inflation back then). "Have you seen that ad where…?", you'd ask your mates, and they'd invariably say yes. The jingles, the slogans, the stories that formed TV ads of that era were literally better known than the shows they interrupted.

But think of three TV ads you could describe to your friend today that they'd all know about. My guess is you can't. And that's no accident; it's a symptom of how we consume media in 2026.

We rarely go to the cinema. Few buy printed newspapers or magazines. The broadcast TV that once dominated family life has largely been replaced by ad-free streaming. We even browse the web with ad blockers.

Pulled towards controversy

In that light, is it any wonder some brands specifically go out to stir up controversies, even if they risk being cancelled? Or that, even when controversies erupt by accident, companies think: "Unfortunate, but not the end of the world…" Because in the words of Oscar Wilde, "There is only one thing in the world worse than being talked about, and that is not being talked about."

Perhaps the answer to my headline, then, is neither soft audiences nor sloppy brands. It's that ads have simply stopped being things we watch, and become things we argue about instead.

Which means if you don't personally like getting drawn into massive rows, you might want to start skipping the ads… even more than you do already.

Chat with AI to create pages, publish content, and understand your website traffic.

French illustrator Louise Laborie uses watercolor and charcoal to depict America's motels, highways, skate parks, and other transitional spaces at dusk, populating them with teenagers caught between childhood and adulthood to create quiet, cinematic scenes shaped by loneliness, music, memory, and imagined stories.

CriS Cian turns photo manipulation and digital painting into peaceful, poetic cosmic scenes of futuristic expeditions and encounters beyond Earth.