• Microsoft announced Monday it will deploy AMD Helios racks in its Azure data centers, joining other early customers Meta, OpenAI and Oracle.
• Helios is AMD's first rack-scale system for AI and its most competitive move against Nvidia yet. It will ship later this year.
• CNBC got an exclusive first detailed look inside AMD's new system at the Texas lab where it's being developed and tested.

After a decade-long comeback, chip giant Advanced Micro Devices is preparing to ship its first rack-scale system for artificial intelligence, called Helios, to a growing list of customers that now includes Microsoft.

It's the first rival to Nvidia's wildly popular Grace Blackwell and Vera Rubin systems, and is aiming to give the world's most valuable chipmaker its first real competition in years.

Microsoft announced Monday it will use the Helios system in its data centers, joining Meta, OpenAI, Oracle and others in a race to grab as much compute as possible.

AMD will begin shipping to customers, including Microsoft, later this year. Shares of AMD climbed more than 4% on Monday. Microsoft stock climbed more than 1%.

Details about financial terms or the amount of compute capacity weren't disclosed.

"We are expanding the Azure infrastructure portfolio with AMD Helios to give customers the performance, scale and choice they need to build and run the next generation of AI applications," Microsoft CEO Satya Nadella wrote in a press release.

The new Helios system will power frontier model inference for Microsoft, its AI customers and support Azure AI services. Microsoft will also add two new computing instances run on AMD's latest "Venice" central processing units, or CPUs, one for agentic AI and data pipelines, and another for semiconductor design.

It's the continuation of a longtime partnership, with AMD chips powering Microsoft's Surface PCs and Xbox gaming consoles for many years. In 2023, Microsoft was also the first to adopt AMD's MI300X graphics processing unit, or GPU, that rivaled Nvidia's AI chips. Microsoft also deploys its own Maia chips in its data centers.

Like its peers, Microsoft needs as much compute as possible, especially as it ramps up its own model development and allocates more computing capacity to research and development. In June, it announced seven models built in-house. Microsoft's AI efforts thus far have seen mixed results, from its 365 Copilot AI assistant to its GitHub Copilot coding agent. It's the worst-performing "Magnificent Seven" stock so far this year.

Microsoft is part of a growing number of big companies turning to AMD for AI acceleration. AMD says eight of the top 10 AI companies run workloads on its Instinct GPUs, including OpenAI, Cohere and Elon Musk's SpaceXAI, which is part of SpaceX.

In February, Meta announced it'll use up to 6 gigawatts of AMD GPUs over time, starting with 1 gigawatt deployed on Helios racks later this year. OpenAI and Oracle also made major commitments to deploy Helios this year, with India's largest IT company, Tata Consultancy Services, committing to use it as well.

CNBC got the world's first detailed look inside a Helios system, from the Texas data center lab where it's being developed and tested.

'Lowest cost per token'

Named for an ancient Greek god who pulls the sun across the sky with the help of four horses, Helios brings together four things AMD does in-house: GPUs, CPUs, networking and software.

"We're very focused on providing the best total cost of ownership, the lowest cost per token, all in," data center head Forrest Norrod told CNBC about AMD's first-generation system. "And our customers are telling us that we're achieving that."

In May, AMD CEO Lisa Su told CNBC's Jim Cramer that Helios has "significant benefits" over Nvidia's rack-scale systems, "when you're talking about inference and when you're talking about memory bandwidth and memory capabilities."

While AMD wouldn't comment on cost, the Futurum Group estimates Helios will cost between $5 million and $5.5 million. That's compared with Futurum estimates of $3.5 million to $4 million for Nvidia's second-generation rack-scale system, Vera Rubin.

At up to 7,000 pounds, Helios is also wider and heavier than Nvidia's Vera Rubin.

Nvidia controls more than 95% of the data center GPU market, according to the Futurum Group. AMD only holds some 4.5% of the market, but Helios could change that.

"I think there's a serious case in which AMD does great and can get to 20% and 25%. And by the way, this is hundreds of billions of dollars of revenue," said Daniel Newman, analyst and CEO of the Futurum Group.

In the first quarter of 2026, data centers made up the majority of AMD's revenue, up 57% year over year. AMD told CNBC that it plans to book tens of billions in data center AI revenue starting in 2027, the majority coming from Helios.

In data center CPU market share, Intel remains the clear leader, but AMD has steadily been gaining ground. This CPU leadership sets AMD apart from Nvidia, which launched its first server CPU in 2021 and shifted strategies to renew focus on the chips this year.

'A very different AMD'

Norrod called Helios "our baby," as he showed CNBC the system's core chips. Each of its 18 compute trays has four Instinct GPUs powered by a single EPYC central processing unit.

It was these EPYC data center CPUs that helped AMD regain a decade of lost leadership in the data center market.

In 2003, AMD had a groundbreaking data center CPU that helped it rapidly gain nearly a quarter of the market, but that slice withered away following a series of delays and missteps that led to major layoffs and shrinking revenue by the time Su took the helm.

"Under Lisa's leadership for the last 12 years, it's been a very different AMD," Norrod said.

Things turned around after the company unveiled the first EPYC server CPU on stage in 2017.

"One of the things that we did is we laid out our road map in detail for three generations, which is very unusual," he said. "And we delivered exactly what we said."

Part of AMD's road map included plans to launch Helios with the current MI400 series of GPU.

Each Helios tray also has up to 12 networking chips made with technology AMD acquired when it bought Pensando in 2022.

It was one of several acquisitions that has helped enable Helios development in the last few years.

AMD's largest purchase to date was programmable chip company Xilinx for nearly $50 billion in 2022. AMD also acquired server maker ZT systems for nearly $5 billion in 2025, and a series of software companies that helped it develop ROCm, its open-source alternative to Nvidia's widely adopted CUDA software ecosystem.

Counterpoint Research analyst Neil Shah said AMD's Helios chips are "on par" with Nvidia GPUs and CPUs, but the "secret sauce is in the software and optimization."

"With CUDA, I think Nvidia has a bigger ecosystem, and it's quite ahead versus AMD," he said.

With Helios, AMD has the opportunity to make substantial strides, depending on how well early deployments fare.

"The question is going to be: Is AMD winning because they are technologically superior? Or does AMD win because there's just such a constraint on capacity that if they can build it, someone will buy it?" Newman said.

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 →

Earlier this year, we ran experiments to test the limits of scaling agents to cooperate toward a goal. Our hypothesis was that this would unlock a new tier of task scale and complexity.

The flagship project was a long-running swarm building a web browser from scratch. It succeeded as a proof of concept, but fell far short of polished software.

That work was deliberately empirical. We started from a blank canvas and hill-climbed toward a stable, effective system. Since then, our goal has been to understand the agent swarm well enough to engineer it deliberately.

To test that progress, we returned to a task the old swarm had struggled with: building SQLite from scratch, in Rust, from nothing but its documentation.

Our initial results have been promising. We ran the old and new swarms on the same task, with the same models and the same time budget, and measured how much of a held-out SQL test suite each could pass.

The new swarm did better in every model configuration. Using Grok 4.5, it reached 80% in four hours, while the old swarm spiraled and had to be paused before its second hour.

We also varied which models did which jobs. In some runs, one model handled everything while in others, a frontier model planned while a fast, inexpensive model carried out the work. Every mix produced similar quality, but the costs varied enormously.

Trees and leaves

Descriptions of large tasks naturally take the shape of trees, with a goal at the root that subdivides recursively into basic units of work. Our swarm has two roles, both organized around that same tree-like decomposition:

• Planner agents, powered by the smartest models, split a goal into pieces and delegate them.
• Worker agents, generally powered by faster and less expensive models, execute those pieces.

The design is a superset of more rigid orchestration systems. Rather than imposing a fixed topology on the problem, the swarm’s shape grows to cover the problem’s contours, and compute and context scale in proportion to the task’s complexity.

We think this is why the design generalizes to tasks as diverse as building a browser, solving math problems, and optimizing GPU kernels. We’ve also used it internally to find and fix vulnerabilities in open-source software, raise test coverage on our own codebase, and generate billions of tokens of synthetic training data.

What the tree does for memory

When a single agent takes on a complete task, it has to walk the entire tree itself, descending to each leaf while holding its ancestors, its current position, and the wider goal in context the whole time.

We think this explains why long-running single agents drift. They can either focus on the work in front of them and lose sight of the bigger picture, or hold the big picture and do a worse job on the piece.

In a swarm, a planner never implements, so its context never fills with low-level detail, and a worker never plans, so it can spend all its context on one narrow piece of work.

We suspect the ability to scale the agent swarm comes from this context efficiency, more than from parallelism itself. That efficiency is present in the swarm at every scale, which is why this decomposition helps agent performance even on moderately sized tasks.

There are echoes of this structure elsewhere. The economist Ronald Coase, asking why firms exist at all, argued that coordination costs grow faster than the work itself, so organizations settle into tiers of bounded units rather than letting everyone talk to everyone.

A version control system for agents

In an earlier post about the swarm, we noted that tools like Git and Cargo rely on coarse locks for concurrency control. This is fine for one developer but unworkable for the volume of work produced by hundreds of concurrent agents.

The browser swarm from earlier this year peaked at roughly 1,000 commits per hour on Git. The new system peaks at around 1,000 commits per second.

To facilitate this rate of activity, we built a new version control system (VCS) from scratch. Throughput was not the only reason to own this layer. Every change in the system passes through the VCS, so it is where collisions first become visible, and several of the coordination mechanisms in the next section are implemented directly inside of it.

Failure modes at 1,000 commits per second

Human engineering teams have standard coordination mechanisms like code review, ownership, standups, and merge queues. Those systems work at human tempo, but at the commit-rate of the swarm, we see failure modes that human teams don’t routinely encounter.

Split-brain design

Two planners, unaware of each other, implement the same concept in different ways in different parts of the codebase.

We fixed this through prompting. Planners make design decisions themselves rather than delegating them, and we require them to ensure that no two delegated subtrees decide the same question.

Contention between planners

A harder form of contention is when two planners know about each other and fight through back-and-forth changes over the same files.

The problem is two pictures of reality, and merge tooling can't fix a disagreement. Instead, we have agents record decisions in shared design docs. Code that depends on a decision carries a compile-checked reference back to its doc. When planners unknowingly contradict each other, a reconciler merges the docs and the references propagate the resolution downstream.

Merge conflicts

Within the swarm, agents constantly collide on the same files. In order to resolve a collision they would have to stop, absorb the other agent's context, and merge around it. Worker agents are bad at this and, in practice, either overwrite the other change or abandon their own.

To fix this, we created a system where a neutral third-party agent intervenes on merge conflicts and resolves them on behalf of all parties. Its only goal is to be impartial and efficient, similar to the way merge queues work in engineering teams.

Megafiles

Some files are particularly popular places for agents to work. Each agent might add only a small amount of code, and no single agent is responsible for keeping the files small.

These “megafiles” choke everything. They’re expensive to transport, diff, and merge, and become the site of constant collisions.

To fix this, we gave worker agents a way to flag bloated files. Once flagged, we block new commits and an outside agent decomposes the overgrown file into smaller modules.

Ossification

Agents have learned, from working in existing codebases with humans in the loop, not to touch core code even when it needs to change.

To fix this, we license intentional breakage. An agent that judges a core change worthwhile can make a focused patch outside its scope and leave a comment explaining why it did it.

The compiler carries the change through the rest of the system, and everything depending on the old design fails to build. Each agent that hits one of those errors finds the comment, reads the reasoning, and updates its own piece of work to match.

Review lenses

In a system that is both long-running and multi-agent, errors accumulate, and the swarm needs a way to correct itself before small mistakes become foundational.

We experimented with many kinds of review lenses, such as giving a review agent the worker's full transcript, or only its output, or nothing but the codebase. We also tried reviewers running on different models, with different training and a different personality.

No single lens catches everything, but decorrelated lenses stack, the way self-driving systems reach above-human reliability without any single perfect component. The compute spent on review is high return, since review is much cheaper than the work it audits. We suspect this stacked review system was a major contributor to the sustained quality of the runs.

Letting agents shape the environment

Stigmergy is the mechanism by which swarm organisms like ants and termites coordinate without direct communication. They shape the environment, and the environment shapes the next organism.

We had encoded rules like “keep notes” and “document decisions” in earlier runs because they seemed obviously good. In retrospect, they were letting agents institutionalize knowledge for their future selves and teammates.

We pushed this further with an experiment in self-authored, shared context we call the Field Guide. It’s a folder owned entirely by the agents, whose index.md is automatically injected into every agent at start. It is the agents’ job to curate what goes into the guide and their only constraint is a line budget.

The underlying logic of the guide is that model weights are frozen, so it’s precisely surprise encounters that are worth capturing so the next agent trajectory is shorter.

The Field Guide is an early experiment with promising results. We’d expect the benefits to be even larger on codebases agents don’t fully own. Training models to write for their successors, where better capture leads to better rewards, is an interesting follow-up area of research.

The SQLite experiment

We instructed the new version of the swarm, equipped with all the improvements described above, to implement the whole of the 835-page SQLite manual in Rust. We withheld the source code, test suites, SQLite binary, and internet access.

To measure progress, we graded against sqllogictest, a test suite from the SQLite project built to check that different database engines return the same results for the same queries. It contains millions of queries with known correct answers, and the grade is the fraction the swarm's database gets right. Progress shows up as a rising curve over the course of a run.

The swarm was never told the suite existed. After each run, we manually reviewed the code and the run itself, checking for cheating and shortcuts, and confirming the system was built out evenly, rather than just in the places where the tests look.

As you read the curves, keep in mind that agents chose their own strategies. Some built broad foundations and scored low for hours before a late spike while others went deep on one area, scored early, then plateaued while filling in the rest. Trends matter more than exact scores at exact moments.

Results across model mixes

We tested four configurations spanning capability and cost:

1. GPT-5.5 as both planner and worker. A strong frontier model throughout.
2. Grok 4.5 as both planner and worker. Our cost-efficient frontier model, as a comparison point.
3. Opus 4.8 as planner and Composer 2.5 as worker. Frontier judgment paired with efficient execution.
4. Fable 5 as planner and Composer 2.5 as worker. To see whether a next-tier planner makes the hybrid more or less worthwhile.

The new harness outperformed the old in every mix.

The Fable 5 hybrid passed about two-thirds of the suite within the first hour. By the four-hour cutoff, the new runs sat between 73% and 85%, while the old runs ranged from 11% to 77%.

The old Grok 4.5 run was paused before its two-hour mark (more below). Every new configuration went on to pass 100% of the suite.

A deep dive into the runs

Starting with the simplest measure of activity, we can see how the rate of commits varied for Grok 4.5 under the old harness versus the new. The old run produced 68,000 commits in its first two hours, roughly 70 times the new run's pace.

One reading is that it was more productive. Another is that most of those commits were busywork (thrash, contention, churn).

The merge conflict data points to the latter interpretation. The old run accumulated more than 70,000 conflicts before we paused it, accelerating rather than stabilizing, while the new run logged fewer than a thousand over its full four hours.

The conflicts concentrated where files grew largest. In the old run, the biggest files kept growing for the entire run and its single hottest file collected 7,771 conflicts, touched by 1,173 different agents. In the new run, the most contested file in the whole codebase saw 47.

The old swarm's biggest coordination failure — split-brain, or planners duplicating each other's work — showed up in the package structure. Rust code is organized into packages called crates, and in a project like this, each crate is roughly one major component.

The old run sprawled to 54 crates, including three separate SQL packages. The new run settled on nine crates early and never added another.

All of this shows up in the final codebase. In the Fable 5 mix, both the old and new swarms ultimately passed the full suite, but the old one needed 64,305 lines of engine code and the new one did it in 9,908. The Opus mix shows the same shape with 19,013 lines at a 97% grade under the old harness, and 4,645 lines at 100% under the new harness.

Model economics

We said at the top that every model mix produced similar quality while the costs varied enormously, from $1,339 for the Opus 4.8 hybrid to $10,565 for GPT-5.5 alone. The token data shows where that difference comes from.

The structure of the spend was consistent across every run, with workers carrying at least 69% of the tokens, and over 90% in most.

But the dollars split differently than the tokens, because planner tokens cost more. In the Opus 4.8 and Composer 2.5 mix, the Opus-as-planner produced a small fraction of the tokens but roughly two-thirds of the cost, while Composer-as-worker handled the vast majority of the tokens for the remaining third of the cost.

Few moments in a large task genuinely require frontier intelligence, such as the original decomposition, the design decisions, and certain trade-offs. Once a frontier planner has collapsed the ambiguity into a detailed, explicit instruction, less expensive models simply have to follow it. This is a huge potential source of cost savings. In the run that used GPT-5.5 for both planners and workers, the workers alone cost $9,373. In the run where Opus 4.8 did the planning and Composer 2.5 did the work, the entire worker fleet cost $411.

Specs as prompts

Each jump in AI capability has raised the level of abstraction at which an engineer can work.

Autocomplete let engineers work one line of code at a time. Early models raised that to a block of code, and agents raised it to a file or a feature.

With swarms, the unit of work becomes the spec.

For that to work, the swarm has to actually follow the spec, which is what much of this post is about. We gave the swarm 835 pages of prose and it came back with a database. What was scarce in this experiment, and what we expect to be scarce in software engineering going forward, is the right description of intent.

Seen this way, the swarm starts to resemble a compiler. A compiler translates source code down to machine code through a series of intermediate steps. The swarm does something similar with intent. Planners parse a goal into task trees, then lower it step by step into executable work. The difference is that a compiler preserves meaning at every step while the swarm is probabilistic at every one. Everything described in this post exists to close that gap.

We invite you to explore the swarm's output. The codebase from the solo Opus 4.8 run is public at github.com/cursor/minisqlite. Based on our initial glance it looks great, but we have not done a deeper manual analysis. Take your own look, and tell us what you find.

China's Z.AI Completes 1-Gigawatt AI Data Center Using Only Chinese-Made Chips

Z.AI, the Chinese artificial intelligence company formerly known as Zhipu and focused on developing its GLM model platform, has completed construction of a massive 1-gigawatt data center powered entirely by Chinese-made chips. The facility has started partial operations and is designed to provide the computing capacity needed to develop Z.AI's most advanced GLM systems. Its power capacity is roughly equivalent to the electricity required to supply 750,000 homes at any given moment. Z.AI has also built or operated several computing clusters containing more than 10,000 chips each, suggesting the company is expanding its infrastructure as competition among Chinese AI developers intensifies.

The project represents an important milestone in China's effort to reduce reliance on restricted silicon from NVIDIA, the U.S. semiconductor company whose chips are widely used for artificial intelligence computing. Investors may view the facility as a major test of whether China's domestic chip industry can support increasingly advanced AI models over the longer term. Huawei Technologies, China's leading designer of AI accelerators, is competing with Cambricon Technologies, a Chinese chip company, and Alibaba Group Holding, a major Chinese technology and cloud-computing company, as local suppliers work to narrow the performance gap with NVIDIA. The scale of Z.AI's new facility would place it among the largest data centers developed by a Chinese AI laboratory, although Alibaba and China Telecom, a major Chinese telecommunications operator, remain among the country's largest builders of computing infrastructure.

Z.AI is increasing its computing capacity as competition grows with Moonshot, a Beijing-based artificial intelligence startup whose Kimi K3 model has challenged leading systems from OpenAI, a U.S. artificial intelligence company, and Anthropic, an AI developer of advanced models. Moonshot suspended new subscriptions on Sunday to prioritize computing resources for existing members, highlighting the infrastructure constraints facing some Chinese AI developers. China is preparing to spend around 2 trillion yuan, or $295 billion, over the next five years on data centers, while Z.AI has raised billions of dollars through a Hong Kong initial public offering and a subsequent share sale. The company is reportedly on track to generate $1 billion in annual recurring revenue after reaching its 2026 sales target in July, and the new data center may support its effort to strengthen its position as a provider of AI services to businesses and enterprises.

Full article content is not available for inline reading.

Read the original article →

Who’s Afraid of Chinese Models?

There’s a story I tell about my first day in STRT-431 at Kellogg School of Management, the introductory class that every first-year MBA was required to take; I leafed through the readings and case studies and was dismayed that there weren’t any tech companies on the docket. Me being me, I spoke to the professor after class wondering why, and was told that the goal of the course was not to necessarily learn about specific industries, but rather to uncover broadly applicable universal principles that could be applied to any company in any industry.

I did not, as I usually tell the story, find this very satisfactory: to me the nature of tech, particularly the fact that software and distribution had zero marginal costs (and zero transaction costs), was something fundamentally different; putting in zeroes in formulas tends to wreak havoc! I soon realized, however, that that was my opportunity. The fundamental insight undergirding Aggregation Theory is that zero marginal costs leads to fundamentally different value chains than people once expected from the Internet: centralization and scale in a world where controlling demand mattered more than distributing supply.

What is fascinating about AI, however, is the extent to which those old universal principles are coming back to the forefront. That was never more apparent than this past weekend, when arguments raged on X about the implications of Kimi K3, another open weights model out of China, approaching the state-of-the-art in terms of capabilities. The long and short of it is this: marginal costs are back in a big way, both in terms of short-term implications of state-of-the-art free models, and in terms of the long-term structure of the industry.

COGS Versus R&D

One of the most common misconceptions undergirding discussion of open weights models is that they are cheaper — free, even. After all, you can just download the weights, and skip the time and expense and capabilities necessary to create your own model. That is, of course, true, but the “free” in this case is a reference to the amount you need to spend on research and development; R&D is a fixed expense that is independent of the revenue you generate. If you spend $1 million in R&D, it doesn’t matter if you do $100 thousand in revenue or $100 million; you still spent $1 million on R&D (it does, of course, impact your profitability).

What is related to revenue is COGS — cost of goods sold — and COGS is real for AI in a way it hasn’t been for software for a very long time. Specifically, running inference on a model — whether that model be Kimi or Fable — costs money, and the amount of money an AI provider spends on inference is, at least in most business models, directly correlated to revenue. To reuse the above example, generating $100 million versus $100 thousand in revenue will likely require 1,000x COGS. In concrete terms, if it costs 50 cents to generate the tokens that drive $1 in revenue, then $100 million in revenue will have $50 million in COGS; $100 thousand in revenue will only have $50 thousand in COGS.

The point in terms of open weight models is that they are not free to serve. Kimi K3 costs $3 per million input tokens, and $15 per million output tokens; that is cheaper than Sol’s $5 per million input tokens and $30 per million output tokens, but that might not even be the right measurement.

Tokens Versus Intelligence

Nvidia CEO Jensen Huang has described what Nvidia is building as “token factories”, and from Nvidia’s perspective that framing makes sense. Nvidia GPUs are model agnostic: they generate tokens, and do so in the fastest and most efficient way possible. That leads to measurements like tokens-per-second, time-to-first-token, tokens-per-watt, token cost, etc., and Huang argues that these metrics will be the basis for decision-making.

This is a framing that definitely made sense during the first paradigm of AI, the ChatGPT era, when tokens were delivered straight to the end user. The second paradigm of AI, however, the reasoning era, confounds this measurement. Reasoning entails an explosion in chain-of-thought tokens, and different models need different amounts of reasoning tokens to arrive at the right answer. Kimi, for example, reportedly uses significantly more tokens than Sol, rendering its price advantage moot. Agents introduce a similar dynamic: some models are more efficient than others in terms of the number of tokens they need to execute agentic workflows.

What this means is that tokens are not a commodity. The defining characteristic of a commodity is that it is fungible: a gallon of oil is a gallon of oil; a ton of copper is a ton of copper; a bushel of wheat is a bushel of wheat. A token from one model, however, is not the same as a token from another model. What is fungible is what is constructed from tokens, which is to say intelligence. In other words, if both Kimi and Sol generated the right answer, then that answer is fungible; the difference in tokens generated to get to that right answer is a contributor to a difference in COGS.

The COGS for intelligence is a function of a few different factors:

• Model footprint: The weights and runtime state determine how much expensive memory and how many accelerators are required to host each serving replica.
• Inference efficiency: Architectural choices (e.g. Mixture-of-Experts) reduce computation per generated token.
• Memory efficiency: Architectural choices can reduce KV cache requirements, allowing more concurrent requests and better GPU utilization.
• Serving efficiency: Batching, scheduling, prefix caching, and other inference optimizations maximize utilization and share work across requests.
• Token efficiency: The fewer tokens required to reach a correct answer, the lower the inference cost.

The reason this matters is that we are rapidly approaching a state in which intelligence for many economically beneficial tasks is in fact a commodity. Anyone building a basic CRUD app, for example, can likely do so using models from multiple providers. And, in a commodity market, the route to profitability is not through charging higher prices — again, you can (or will soon be able to) make the exact same app using multiple models — but rather through having a superior cost structure.

Understanding Commodity Markets

It’s worth stepping through the mechanics here, because, as I noted a few months ago in Amazon’s Durability, the dynamics of commodity markets are not something people in tech are generally familiar with:

• In commodity markets, everyone charges the same price, because everyone is selling the same thing; that price is determined by supply and demand.
• The demand for a commodity is a function of price elasticity: the cheaper the commodity, the more demand there is for it, and vice-versa.
• The supply for a commodity is a function of the marginal cost of producing the commodity.

The key thing to understand is that the marginal cost of producing the commodity differs by supplier. What this means in practice is that the supplier with the worst cost structure ends up selling the commodity at their marginal cost (if they can produce at all); the profits of everyone else depend on the extent to which their cost structure is better than the marginal supplier.

As an example:

• Supplier A can produce 10 units of the commodity for $10 each
• Supplier B can produce 10 units of the commodity for $15 each
• Supplier C can produce 10 units of the commodity for $20 each

Let’s assume the price elasticity is such that there is demand for 25 units of the commodity at $20. That means:

• Supplier A will sell 10 units of the commodity for $20, earning $10/unit
• Supplier B will sell 10 units of the commodity for $20, earning $5/unit
• Supplier C will sell 5 units of the commodity for $20, earning $0/unit

This isn’t precisely right: the reason why Supplier C will bear the shortfall is because Suppliers A and B will be able to slightly undercut them in price, which will of course affect demand (which is elastic), but it makes the point. Supplier A has a great business, Supplier B has a good business, and Supplier C is going to go bankrupt.

Bankruptcy risk is where fixed costs come back to the forefront: Supplier C has both fixed costs (like potentially R&D spend) and also may have taken on debt to finance the equipment necessary to produce the commodity. It can’t price its commodity with these costs in mind — remember, the market-clearing price approximates the marginal cost of the highest-cost unit needed to satisfy demand — but those costs can absolutely drive the supplier out of business. And, if that supplier goes out of business, then prices go up, until another supplier decides to enter (or the other suppliers expand).

The Intelligence Market

Let’s bring this back to models. Right now, none of the above analysis applies because demand exceeds supply for frontier models, and supply is limited by a lack of compute. This compute shortage doesn’t just mean that a compute supplier like Nvidia makes very large margins, but also that Nvidia’s customers, like SpaceXAI, can turn around and resell compute at high margins as well to a company like Anthropic. Anthropic, meanwhile, can pay the markup because they can sell tokens with a higher markup still.

It’s not just excess demand that gives Anthropic great margins, however: Anthropic and OpenAI likely have among the lowest costs per unit of frontier-quality intelligence, thanks to model capability, serving scale, and token efficiency. They are serving models at a particular capability level for months before their competitors, and are simultaneously applying the best models to optimizing those costs.

It’s also worth noting that the market is not yet treating intelligence like a commodity: demand is for Anthropic and OpenAI specifically, and much less for models that aren’t as good (thus SpaceXAI and Meta selling capacity to Anthropic); one way to think about the push for optimizing cost is that that is a function of defining jobs-to-be-done by intelligence level, such that intelligence buyers can create a market where intelligence is commoditized. In the long run, however, whoever is on the frontier is the best placed to dominate non-frontier markets as well, which are just the frontier minus n-months, i.e. months in which the frontier model makers have been optimizing their cost of serving.

All of this is to say that I think the reaction to Kimi and Chinese models generally is pretty over-blown, at least from an economic perspective. Right now there is a price umbrella that is downstream of the lack of compute; I highly doubt that Chinese models are cheaper to serve on a marginal cost basis, they just seem cheaper because Anthropic and OpenAI are so supply constrained that they are charging far more than they would if there were sufficient supply to meet the demand for intelligence.

Frontier Lab Paranoia

Why, then, do the model makers in particular seem so panicked about Chinese models?

First, I think the frontier labs are anchored in a world where training costs dominated their financial modeling. As long as training consumed more GPUs than inference, it was critical to maximize inference revenue to help fund the next training run, which meant charging very high prices for inference.

Going forward, however, I expect the inference market to grow much faster than training costs (and that includes the assumption that training costs will continue to skyrocket), which means they really can make it up in volume. It wasn’t clear this would be the case as recently as eight months ago, but the agent paradigm unlock is so massive that frontier labs should have more confidence that they can not just survive but thrive with lower prices (once they have sufficient compute).

Second, intelligence isn’t in fact a perfect commodity, in part because applied intelligence makes itself smarter. Specifically, whoever is running inference is also collecting data, and that data goes into making the next iteration of the model better. This is, on one hand, all the more reason for the frontier labs to lower prices and increase usage as more compute comes online; on the other hand, this is why companies like Microsoft are increasingly obsessed with helping companies run their own models. That is much more viable if Chinese models are a viable alternative.

Third, the other way that frontier labs can not only differentiate from Chinese models but also from each other is by continuing to integrate up into the customer experience. It’s striking the extent to which Claude Code and Codex are proving to be quite sticky; whichever harness you start working with is likely to be the one you stick with, and that figures to be even more the case with non-technical users. And, in the long run, this imperative to move up the stack does mean that frontier models are absolutely a threat to software providers, including Microsoft. On the flipside, the extent to which software companies who currently own the customer experience have access to competitive models is the extent to which they may be able to resist the encroachment of the frontier labs.

Finally, the ideological angle of Anthropic in particular is impossible to ignore. This is a company that believes only it can be entrusted with AI, and the existence of open weights alternatives strikes a fatal blow to that presumption.

China’s Motivation

Kimi isn’t the only new Chinese model; from Bloomberg:

Alibaba Group Holding Ltd. shares rose as much as 5.4% on Monday after the company launched a preview version of its flagship Qwen3.8 Max model, describing it as second only to Anthropic PBC’s Fable 5. The Sunday release came only days after startup Moonshot AI unveiled a powerful new offering that’s roiled markets and triggered concern in the US about China closing the gap on global leaders like Anthropic and OpenAI. Qwen3.8 Max has 2.4 trillion parameters, joining Moonshot’s Kimi K3 in the heavyweight class. With 2.8 trillion parameters, K3 rivals top offerings and Alibaba is setting similarly high expectations.

Developers can now access Qwen3.8 Max through Alibaba’s coding platforms, including Qoder. Alibaba plans to make the model open-weight soon, expanding access beyond the preview release. Interest in these made-in-China artificial intelligence systems and models is so high that Moonshot was forced to pause taking on new subscriptions late on Sunday to manage overwhelming demand.

The fact that Qwen3.8 Max will also have open weights is notable. Alibaba stopped releasing weights for its leading edge models earlier this year, but appears to have reverted that change; I suspect that shift was related to last week’s Xi Jinping speech about AI that doubled down on the open weights approach:

We should adhere to the principle of openness and win-win and boost innovation-driven development. As a new engine of world economic growth and an accelerator for the shift of growth drivers, AI is moving from the digital world into the physical world. We should seize this rare, historic opportunity to encourage open source, openness, collaboration and sharing. We should facilitate technological innovation, industrial development and scenario-based application of AI. We should make coordinated advances in the transformation and upgrade of traditional industries, the cultivation and growth of emerging industries and forward-looking planning for future industries, so that all sectors and businesses can benefit from AI.

The strategy for China is obvious: commoditize your complements. Note that Xi explicitly ties openness to AI “moving from the digital world into the physical world”; the physical world is the world dominated by China, and the country’s lead in areas like robotics is going to massively benefit from widely available AI models.

Along the same lines, China does not want the U.S. to gain an asymmetric advantage in AI; to the extent that China can weaken the U.S. frontier labs while strengthening any and all potential U.S. adversaries so much the better, and it can benefit from the innovation that will attach itself to an open ecosystem.

The Distillation Question

By the same token, don’t expect China to do anything about distillation attacks on the frontier labs. I think it is mistaken to attribute all of the success of Chinese labs to distillation, but it’s just as much of a mistake to pretend like distillation doesn’t give Chinese labs a big advantage. That advantage has really come to bear in the last year as post-training reinforcement learning has become increasingly crucial to model performance. Instead of having to fashion reinforcement learning environments from scratch, Chinese labs can simply use frontier labs models as teachers, allowing for rapid improvement at much lower costs (this is not the only reason why Chinese models are cheaper to develop, but it’s a big one).

What is interesting is that one of the most important use cases for Chinese models in the West is itself distillation. Thinking Machines, for example, which just released an open-weight model, relies on Chinese models to solve the cold start problem for reinforcement learning. Dean Meyer and Konstantine Buhler wrote an excellent article on X explaining that distillation means that Western open weight models are fundamentally disadvantaged relative to China:

Distillation does not explain China’s entire open-model lead. Chinese labs have world-class researchers, substantial compute, strong pre-trained models, software-hardware codesign, and rapidly improving post-training capabilities. But distillation compresses the costly final gap between a strong base and a near-frontier system. Even if distillation represents a smaller share of a Chinese model’s total capability, it represents a meaningful share of its advantage over American open models.

New enforcement mechanisms will make large-scale distillation harder, slower, and more expensive for Chinese companies. However, enforcement will not eliminate distillation backed by state actors. Every Western frontier advance therefore creates another teacher for Chinese labs. Western builders must either reproduce those capabilities independently or wait to learn from Chinese models. This gap gives Chinese labs a recurring structural advantage over Western companies.

This is a point that bears repeating: because U.S. open weight model makers must follow the frontier labs’ terms of service, they (1) are worse than Chinese alternatives and (2) end up distilling the distillation, just with a detour through Chinese labs. Wouldn’t it be better if western open weight model makers could go to the source?

To that end, here’s an even more interesting question around distillation: why exactly is it bad? After all, what are large language models but the distillation of all of the knowledge on the open Internet, scraped by the frontier labs and distilled into the models that are themselves being distilled? Who is exactly being wronged here?

In fact, this paradox is the solution. I believe that open weight models are good for innovation (and, per the above, I think that labs on the frontier will be fine), but it’s a problem to be dependent on China. The U.S. should pass a law that (1) makes explicit that collecting data for training models is fair use, and (2) bars terms of service that forbid distillation, for U.S. companies at a minimum. Stopping distillation — which is literally just querying the API — is nearly impossible; the U.S. should go the other way and lean into a new copyright policy that both indemnifies the labs and also guarantees that what they learned fuels further innovation for everyone else.

The Reason to Be Afraid

This entire Article has been an exercise in defusing overreaction to Kimi K3 specifically and Chinese open weight models generally; however, there is one reason to be concerned, and that is cybersecurity. Consider this story from The Stack:

Hugging Face said its production infrastructure was breached by an “autonomous” AI agent system early last week. The platform’s security team were initially stymied in their incident response (IR) by unnamed US LLM frontier model guardrails “which cannot distinguish an incident responder from an attacker,” they said. So Hugging Face’s defenders turned instead to the open-source GLM 5.2 model from China’s Z.ai lab – running it on their own infrastructure to analyse the 17,000+ logs, or footprints, that the attackers left behind.

That’s a striking public admission for the New York-headquartered Hugging Face, which lets users collaborate on models, datasets and applications, and which this summer hit the $100 million ARR mark. In an incident report, the company recommended that defenders “have a capable model you can run on your own infrastructure [our italics] vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment.”

It’s difficult to overstate how wrong-headed the Trump administration’s panicked response to Anthropic’s release of Fable was, particularly since it exacerbated Anthropic’s worst tendencies in terms of assuming only they can be trusted with powerful AI. In a world with only one AI, it might make sense to reserve the most powerful cybersecurity capabilities for the U.S. government and trusted allies; however, that’s not the world we live in.

There are and will be models eminently capable of mounting cybersecurity attacks on existing infrastructure, and those models will be — already are — widely available. The best defense — the only viable defense, in fact — will be to make sure defenders have access to the best models as well. Right now defenders are effectively banned from using Fable or Sol for cybersecurity because of Trump administration directives; that means the best alternative is using models from a country which has been trying to weaken our cyber defenses for years. This is insane!

The better course is clear: first, loosen Fable and Sol restrictions on cybersecurity, and second, ensure that U.S. open weight model makers are on an equal playing field with China. Yes, the frontier labs will kick and scream about this, but the Administration should realize that listening to their histrionics has led the U.S. to a position where U.S. companies are dependent on China for their defenses. Let the frontier labs win by being better; don’t let them define safety or security, or pull up the ladder of humanity’s collective knowledge. China is already hard enough to compete with; letting them carry the standard for openness and innovation is simply giving away our biggest advantage.

For a year, one question has hung over China’s fast-improving AI models: what are they actually running on? Z.AI has just given part of the answer. It has built a huge data centre that uses only Chinese-made chips.

The company, formerly known as Zhipu, has started partially operating the site, Bloomberg reported, citing a person familiar with the matter. It is a 1-gigawatt hub built to train Z.AI’s GLM models. Z.AI did not respond to a request for comment.

What was built

The scale is the headline. A gigawatt is roughly the power draw of 750,000 homes at any one moment. That puts the site among the largest server hubs any Chinese AI lab has built.

The chip count is just as striking. Z.AI now runs several computing clusters, each holding more than 10,000 chips, the person said. Crucially, none of them are Nvidia’s.

Bloomberg did not name the exact chips. China’s leading designer of AI accelerators is Huawei, which competes with local firms such as Cambricon and Alibaba to close the gap on Nvidia.

Why it matters

US export controls have blocked China’s labs from buying Nvidia’s most powerful chips. The open question was whether homegrown parts could carry the load for training frontier models, not just running them.

A 1GW cluster built entirely on domestic silicon is a real answer to that question. It suggests Chinese labs can keep scaling even while cut off from the chips the rest of the industry treats as default.

The timing sharpens the point. The buildout lands days after Beijing-based Moonshot’s Kimi K3 matched top US models, then ran short of compute and paused new sign-ups. Z.AI is racing the same rivals, and it is betting on owning the hardware.

The bigger buildout

Z.AI is not doing this alone. China is preparing to spend around 2 trillion yuan, about $295bn, over five years on data centres across the country. Cloud giants Alibaba and China Telecom remain the biggest builders so far.

The company also has the money to compete. Fresh from a Hong Kong listing and a follow-on share sale, Z.AI is on track for $1bn in annual recurring revenue, which would make it the first Chinese AI firm to reach that mark. Its shares jumped almost 20% on the day.

It is positioning itself as an enterprise AI supplier, a role that invites comparison with Anthropic.

The catch

A few caveats are worth keeping. The chip details come from an anonymous source, and Z.AI has not confirmed them. Building the cluster is not the same as proving it can train a frontier model as efficiently as an Nvidia one.

Domestic chips can still lag on raw performance, and stitching thousands of them into a stable system is hard. The real test is the next GLM model, and how it compares with what the US labs ship.

Still, the direction is clear. The effort to build a Chinese alternative to Nvidia has moved from slideware to a working, gigawatt-scale data centre. That alone changes the debate about how far export controls can hold.

I have been a director of engineering for a bit over three years now, and I still hear and read what I call the "old rules" repeated over and over: a director should not spend time coding, good work takes time, protect the team from the business, get consensus before you commit, etc.

For a while I thought the people repeating these lines were behind. Then we introduced LLMs in my org and the cost of producing code dropped, and I started checking each rule against the assumption underneath it. The surprising realization was that about half of the old rules were resting on assumptions that broke and the other half were resting on assumptions that did not, and a few of those matter more now than they did before.

What follows is a cleaned-up version of notes I accumulated over the past year.

What we actually know

The cost of producing plausible code has collapsed and it is not going back. Almost every claim beyond that is either unproven or wrong.

• That AI tooling has made engineering orgs dramatically faster: unproven.
• That code review, documentation, and onboarding are obsolete: wrong.
• That you can run the same roadmap with half the people: a bet, not a fact.

If you rebuild your management practices on the narrow claim, you will be right. If you rebuild them on the broad claims you are gambling with other people's careers and calling it a conclusion.

Focus on auditing assumptions

Every management practice rests on a certain assumption. Velocity tracking rests on output being a usable proxy for effort. Six month onboarding rests on syntax being slow to learn. Consensus driven architecture rests on change being expensive. Headcount planning rests on output scaling with people, and so on.

The question for each practice is not how old it is but rather what the practice actually rests on.

If a practice rests on the cost of writing code, put it under review because that cost moved. If it rests on how humans coordinate, build trust, allocate attention, or verify correctness, then nothing about it changed, no matter how dated the ritual feels.

This sounds obvious but I think many are sorting by feel: whatever seems modern stays, whatever seems old goes. That produces teams that abandoned useful friction and kept useless process, because the age of a practice and the validity of a practice are unrelated variables.

The evidence is smaller than the noise

Be suspicious of anyone, including your own team, who reports large speedups and only that. The gains I'm familiar with show up clearly in greenfield work, boilerplate, and unfamiliar territory. They fade or invert in deep work on systems the engineer already understands. I'm very much looking forward to data and studies done after the Q4 2025, where a new breed of models were launched that completely eclipsed the capabilities of the ones older reports and research were based on.

However, the gap between felt speed and measured speed is itself a management problem. If your engineers feel faster and ship the same amount with more defects, you will staff wrong, plan wrong, and set expectations with the business that you cannot meet. The first job in an AI adopting org is instrumentation being honest enough to tell you whether you have accelerated at all.

Weak proxies for a cheap thing

Velocity, pull request counts, and tickets closed were always imperfect. They survived because the thing they approximated ie the effort of writing code was genuinely scarce, so the noise stayed within tolerable bounds.

Now the proxied thing is cheap. That does not leave the metrics merely imperfect but actually actively misleading, because the cheapest way to raise them is to generate volume, and volume is the one thing your organization no longer lacks.

AI-specific metrics solve the wrong problem. I think acceptance rates and prompt counts are the same mistake in a new form. The durable move is older and harder: measure outcomes for the business and the health of the system, and treat code volume as a cost to be justified rather than output to be praised. Good engineers said this before LLMs. It was true then. It is enforceable now in a way it was not, because nobody can argue that writing more code was the hard part.

"Right" still takes time (for now)

The rule that good work takes time splits cleanly in two.

Plumbing time collapsed. Scaffolding a service, generating tests, translating between frameworks, writing the first draft of a migration: all of this is fast now, and any timeline built on those costs deserves compression.

Correctness time splits in two

AI systems now check and correct code faster than any human reviewer, and pretending otherwise costs credibility. One one hand, mechanical verification is collapsing. Anything where correct can be expressed as a machine-checkable artifact: types, tests, contracts, lint rules, invariants, canary metrics. Agents run the test loop, read the failure, fix the diff, and run it again at a speed no reviewer matches. If your correctness lives in this layer, your checking time is genuinely falling, and it will keep falling.

But notice what makes this layer fast. It is fast because someone already wrote down what correct means, in a form a machine can evaluate. The specification did the work & the checker reads it.

Semantic verification is a different matter. Does the code implement the policy the business actually needs? Does this trade-off match your regulatory exposure? Here, correct lives in human heads and institutional history. AI checking AI has a structural problem: the checker shares training data, biases, and blind spots with the generator. Both layers fail in the same places for the same reasons. Self-review catches the typo. It does not catch the shared misunderstanding.

I believe three consequences follow:

• Unit cost falls, total workload rises. Cheap checking invites more generation, and more generation demands more checking. The verification workload grows with volume even as each individual check gets cheaper. Net calendar time is ambiguous, and the incident profile shifts: fewer dumb errors, more systemic ones, because high-volume plausible output now passes high-volume plausible review.
• The boundary is a strategic variable. How much of your correctness is machine-checkable is not fixed. It is a function of your specifications, contracts, and invariants. Teams with strong specs get the full benefit of cheap checking. Teams with weak specs get generated code reviewed by the same machine that generated it. Investing in machine-checkable correctness is now among the highest-leverage infrastructure work an org can fund, because it sets how much of this wave you can actually use.
• The slowest part of verification was never the checking but accountability. Someone signs & someone absorbs the consequence of being wrong: the incident review, the regulator, the customer. Sign-off time does not compress, because it is not information processing. It is risk acceptance, and legal and trust systems assign that to people.

So verification still sets throughput. What moved is the location of the constraint: from checking speed to specification quality, and to the willingness of a specific human to own the result.

The junior pipeline is an unsolved problem

Nobody knows how to train engineers for this environment.

The judgment you want in a senior engineer was historically built by doing the work that AI now absorbs: fixing small bugs, writing boilerplate, getting stuck and then unstuck: these were not just tasks but actually the practice that produced judgment. If the machine takes the practice, the pipeline that produces seniors breaks, and it breaks on a delay, so you will not notice for three to five years.

There are plausible responses. Structured review of generated code, deliberate unassisted exercises, rotations through testing and verification work, earlier exposure to real systems under close senior oversight. I am running versions of some of these. I cannot tell you they work, because the outcome variable is the quality of a senior engineer half a decade from now.

What I can tell you is that anyone who claims to have solved this, whether vendor, essayist, or conference speaker, is selling something. Treat the pipeline as an open problem you personally own.

My take on the old rules

"A director should not code." The director who dabbles, reviews pull requests to feel useful, and becomes a bottleneck is real. So is the director whose mental model of the work is five years stale, who cannot tell the difference between a team that is genuinely faster and a team that is generating confident, wrong output at volume. The resolution is calibration. You do not need to ship. You need enough direct contact with the tools and the output that you cannot be fooled in either direction, by the hype or by the dismissal.

"Shield the team from the business." The assumption underneath this one is that attention is finite and context switching is expensive. That assumption is intact. What changed is the cost of starving the team of context. Engineers prompting AI tools without business context just produce fluent, plausible, wrong work, at scale. The revision is not to flood everyone with everything but to stop filtering by default and start selecting deliberately: which context, to whom, at what level of detail.

"We need consensus before we commit." Consensus was always about commitment and coordination, and the cost of surviving cheap pivots. What cheap pivots change is which decisions need consensus at all. Reversible decisions, or two-way doors, should be made by the smallest group possible, quickly, because a wrong reversible call is now cheap to undo. Irreversible decisions still deserve the slow process.

"We need more headcount." The unit economics of output changed, so every request deserves a harder question than it got three years ago: what part of this work is judgment, and what part is production we keep hiring humans to do? But do not overcorrect. Adding people to a late project still makes it later. Coordination cost, onboarding drag, and communication overhead did not change with the price of syntax. Scrutinize headcount because output per person moved, not because people stopped being the expensive part.

Why the tropes persist

Three years in, here is what I believe about persistence. Practices survive for reasons, and the reasons are always mixed: some obsolete, some still valid, some political. When you hear an old rule repeated, you are usually hearing a person defend the valid part with the wrong argument or defend the obsolete part with the argument that used to work.

The job is sorting

The temptation, when a technology this large arrives, is to pick a posture: burn the old playbook or defend it. Both postures are laziness. The playbook was never a single object. It was a hundred pages, some about the cost of typing and some about the nature of people, bound together so tightly that we forgot they were separable.

Will the machines do the sorting

I was told recently that AIs will soon do the management too, including the sorting. I thought about it over the weekend and I believe it is partly right.

Management has an information-routing function: aggregating status, tracking progress, translating updates into dashboards, forecasting schedules, collating performance data. A large share of what a management layer does daily is moving information between formats and people. LLMs are excellent at this, and the value of this is going to zero. If your management layer earns its keep by summarizing Jira, then yeah, that's over.

Then there is the judgment function: hiring, firing, promotion, deciding which rule applies in this situation with these people, owning a bad call. This has the same structure as verification. Someone checks the output against reality, and someone absorbs the consequence.

We're back to the generation argument mentioned above, but applied to management work: management output becomes abundant, therefore cheap. But the thesis of everything above is that when generation is abundant, verification is the constraint. Machine-generated management still needs a human to verify it against the org's actual behavior and to sign the result. So this is perhaps not the end of the manager but rather the manager's demotion to editor and owner.

What survives

The residual of engineering work is specification and ownership. The residual of management work is judgment and ownership. Same shape, two levels.

At every level of the org, the work that survives is the work someone has to sign.

Let's push the extrapolation to its limit to really drive it home. Imagine an org where agents write the code, run the checks, route the status, schedule the work, and draft the plans. Humans set direction, define what correct means, and sign. Everything between the signature and the shipped result is machinery.

The org you run was never designed but it rather accumulated. Every role, ritual, and layer exists because something used to be expensive: typing, routing, checking, remembering. The prices moved. The org chart did not. In the agentic limit, the chart stops recording who produces and starts recording who signs. Headcount stops measuring capacity and starts measuring how much accountability you can afford. The orgs that get there will look small, quiet, and mostly empty: a short list of names attached to a long list of decisions, and nothing else left to manage.

Alphabet, Google’s parent company, is designing a new server chip to help its in-house Gemini models operate more efficiently.

The new chip, internally dubbed “Frozen v2,” is slated to be released sometime in 2028, The Information reported, citing anonymous sources. According to the report, the chip could be between six and 10 times more efficient than Google’s existing AI chips, measured by the number of tokens generated per unit of power.

In a response to TechCrunch, the company didn’t directly confirm the report. It didn’t deny it either.

“Our teams are constantly researching and experimenting with new innovations to deliver maximum performance and efficiency for our users and customers,” Google told TechCrunch. “While not every project moves into production, this rigorous exploration is central to our full stack approach. By co-designing our hardware and software from the ground up, we ensure our systems are integrated and highly optimized for real-world workloads.”

AI companies have increasingly sought to produce their own chips as a way to make their in-house models run more efficiently and to address global shortages in AI computing capacity. Such efficiency has become a key selling point for tech companies as concerns about AI spend have dampened the market euphoria that previously characterized the industry. At the same time, firms are engaged in an ongoing attempt to wean themselves off chipmaker Nvidia, which has historically dominated the AI chip market and whose dominance has left major AI makers dependent on its hardware.

In June, OpenAI announced its first custom chip, an inference processor dubbed Jalapeño. Earlier this month, it was reported that Anthropic was discussing a new chipmaking partnership with Samsung.

Investors have previously worried about Alphabet’s massive planned expenditures designed to help it build out its AI strategy. Earlier this year, Google said that it plans to spend between $180 billion and $190 billion. With so much money at stake, the company needs to prove that those investments will pay off.

News of the more efficient Frozen v2 chip appears to have assuaged investors, giving Google a boost ahead of its earnings report later this week. Following publication of The Information’s report, the company’s stock climbed some 3% on Monday morning.

Sparse By Design

Kimi K3 And Open Model Scaling

When Moonshot publishes the Kimi K3 checkpoint on July 27th, it will be the largest open weights model ever released: 2.8 trillion parameters, a 1M token context window, native multimodality, and benchmarks that clear Opus 4.8 and sit roughly one generation behind Fable 5 and GPT-5.6.

The discourse has fixated on 2.8 trillion.

The more important number is 16.

From 28% To 2%

K3 activates 16 of 896 experts per token — under 2% of its expert weights touched per forward pass. That is not an implementation detail. It is the terminal point (so far) of the most consistent architectural trend in open models.

Total parameters have grown ~20x since Mixtral, and ~3x in the last twelve months alone.

Active parameters have barely grown at all: a 17-49B band for 27 months. Moonshot shipped K2, K2.5 and K2.6 across nine months with the identical skeleton — 1T total, 32B active — three releases, zero growth in active parameters.

There is scatter (GLM-5.2 is less sparse than V4-Pro), so this is a trend with variance, not a law. But the direction is unambiguous: hold per-token compute roughly flat, inflate total capacity relentlessly.

Why? Because at a fixed training compute budget, more experts means lower loss. The model learns more from the same FLOPs. And the bill is paid in the one resource that has cheap tiers, storage, rather than the two that are scarce and rationed: compute and memory bandwidth.

The open source labs have discovered that the cheapest way to buy intelligence is to spend capacity.

Sparsity is partly an adaptation: when FLOPs are rationed, you scale the axis outside export controls.

KV Cache Compression

Even though expert weights are getting sparser, longer context windows grow the KV cache, and the cache is hauled from memory on every token, exactly like weights.

This is where the companion trend closes the loophole. Attention compression (DeepSeek’s CSA/HCA hybrid, Multi-head Latent Attention, K3’s new attention architecture) is collapsing the cache. V4-Pro’s KV cache at 1M context is 10% the size of its predecessor’s.

Sparser experts shrink the weight-bytes moved per token. Compressed attention shrinks the cache-bytes moved per token. Nothing on the model roadmap shrinks the bytes stored. That number only goes up.

Every architectural trend points away from peak bandwidth scarcity and toward capacity as the binding constraint.

Constraint moves from compute to storage

Sparsity is what makes a 2.8T model servable at all. As Jamin Ball from Altimeter wrote about the true cost of serving frontier open models:

One force that historically factored into open model pricing (anyone can serve it) is much weaker when “anyone” means “anyone with a supernode and a serving stack tuned for a brand new attention architecture.”

A 2.8T model probably has a structurally higher serving floor than a 1T model no matter is serving it. The K2-era 10x discount existed (partially) because those models were both smaller AND served at thin margins. K3 only gives you the second one. For two years “open” and “cheap” were used interchangeably, but they were never the same thing.

Due to sparsity, per-token inference runs ought to run at the cost of a mid-size dense model.

In that sense, sparsity has democratised the compute of frontier inference.

It has done nothing for capacity. At MXFP4, K3’s weights alone are ~1.4TB. Ten-plus H200s just to load them, before the KV cache on a 1M window - this is why Moonshot recommends supernode configurations “with 64 or more accelerators.”

Ever increasing sparsity moves the cost from compute to storage.

Two Serving Regimes

A plausible scenario in low-batch environments (such as enterprises looking to self-host) would see a tiered memory approach (or memory hierarchies) with most frequently used experts stored in HBM whilst less frequently used experts would be in cheap DRAM. A sort of power law for MoE models.

This cost/efficiency gain disappears in hyperscale environemnts. A production server batches hundreds of concurrent requests, and each token picks its own 16 experts. Collectively, a full batch lights up most of the 896 every forward pass. There are no reliably cold experts. So frontier serving pools everything in rack-level HBM across 64+ accelerators and routes tokens to the chips holding their experts. In this regime, sparsity doesn’t reduce HBM purchased at all, it converts bandwidth demand into HBM capacity demand. More stacks, streamed less hard.

At low utilisation, a single power user, i.e. an enterprise with a handful of concurrent sessions, experts genuinely are cold, and tiering the model into system DRAM while hot-loading experts works. This is the regime that matters for open weights specifically, because the entire point of downloading a checkpoint is running it outside a hyperscaler. Sparsity is the only reason the self-hosting path exists at all for trillion-scale models.

Routing is paramount. Today’s routers spread tokens roughly uniformly across experts, which is why hot/cold tiering fails at scale. If labs train routers with deliberate locality, i.e. popular experts, predictable paths, true tiering becomes viable even at high batch, and the cheap-capacity DRAM camps win much bigger.

OpenAI detailed how an internally deployed long-running model exhibited unexpected unsafe behavior that existing evaluations had missed. The company paused access, built new tests, strengthened trajectory-level monitoring, and argued that limited deployment with rollback controls is essential for aligning increasingly autonomous systems.

Ramp Router learns provider failure rates through EWMA and latency distributions through Thompson sampling, then chooses the cheapest model and service tier likely to meet each deadline. Ramp reports 30% savings in Ramp Inspect without performance loss.

NVIDIA Cosmos 3 Edge is a 4-billion-parameter open world model that helps robots and vision AI agents understand their surroundings, reason in real time, and generate robot actions on edge devices. It is now available on Hugging Face. The model delivers memory-efficient, high-throughput inference across NVIDIA edge computers. It connects understanding, prediction, simulation, and action through a shared world representation. The model can be used as a reasoner or an action generator.

Breaking the data barrier. Scaling robot policy models with embodiment-free pre-training.

Foundation models in language and vision keep moving the frontier by riding empirical scaling laws: capability tracks data, parameters, and compute. Robotics has missed out. Large-scale, high-quality data is hard to come by, and that scarcity, more than anything else, has capped how far policy models could scale. What robots can do under genuinely large-scale training remained largely an open question. We take a step toward answering it. Xiaomi-Robotics-1 combines large-scale embodiment-free (UMI) pre-training with a modest amount of real-robot data in a post-training stage. We study how the model behaves as it scales.

Data

Everything Xiaomi-Robotics-1 can do starts from data. For pre-training, we use 100,000 hours of embodiment-free (UMI) trajectories spanning more than 1,700 scenarios (household, commercial premises, industrial sites, and outdoor spaces), covering a diverse range of tasks. We develop a scalable auto-labeling pipeline that first divides trajectories into fixed-length segments and then annotates each segment with language descriptions of scene state transitions.

For post-training, we leverage cross-embodiment datasets containing in-house robot data, filtered open-sourced robot data, and a set of high-quality UMI data. For the in-house data, we collected over 7,200 hours of real-robot data in real homes, covering tasks like tidying a sofa, sorting a shoe cabinet, and putting away kitchenware. The UMI data are manually annotated with temporal segments and instruction prompts, which differ from the auto-labeled state-transition descriptions used in the pre-training data.

Method

Following the training paradigm of LLMs, the training of Xiaomi-Robotics-1 consists of two stages: pre-training and post-training. The first stage learns general representations for action generation from large-scale UMI data, while the post-training stage aligns the model with real robot embodiments and instruction-following capabilities.

Pre-training

Pre-training is about breadth: exposing the model to as much of the real world as possible. We use the embodiment-free UMI data described above, which spans a broad range of environments and tasks. At this scale, manual labeling is infeasible. Thus, we built an automatic annotation pipeline powered by a strong vision-language model. Long videos are split into fixed-length clips, and the VLM describes the state transition of grippers and interacting objects within each clip. The result is a large-scale corpus of real-world manipulation trajectories, each annotated with precise language descriptions. These allow the model to learn action generation that drives the scene toward the state transitions described by the language.

An encouraging finding is that pre-training shows a clean scaling behavior: as data and model size grow, validation action error steadily decreases.

Post-training

Post-training aims to align the strong action-generation capabilities acquired from pre-training with real robot embodiments and natural-language instruction following along two axes. Embodiment alignment uses high-quality cross-embodiment real-robot data to map the general action-generation ability onto actual robots. Instruction alignment shifts the model from "generating actions given a description of scene state transitions" to "understanding a natural-language instruction and executing it directly."

After post-training, Xiaomi-Robotics-1 can be used out-of-the-box to perform a wide range of mobile manipulation tasks in the real world. We evaluate the post-trained model in unseen environments with unseen object instances to understand whether the scaling behaviors from pre-training can transfer to real-robot performance after post-training.

The answer is yes. As we increase the amount of pre-training data and model size, real-robot success rate rises steadily and predictably. That is, a stronger pre-trained model yields better real-robot performance. The scaling gains show no signs of saturation: the real-robot success rate after post-training keeps improving as the model consumes more data or scales up during pre-training.

Applications

After post-training, Xiaomi-Robotics-1 can serve as a strong robot foundation model for downstream applications. We put Xiaomi-Robotics-1 to use in two complementary downstream settings. Efficient adaptation to new tasks specializes the model to brand-new, highly complex real-robot tasks from a few hours of data per task. Simulation benchmarks probe its capabilities in mainstream suites that emphasize generalization.

Efficient Adaptation to New Tasks

Xiaomi-Robotics-1 can learn new tasks with high data efficiency. The model picks up tasks like phone packing, printer refilling, laundry loading, and box packing from just a few hours of real-robot demonstrations per task. With an average of under 10 hours of demonstrations per task, it already reaches a 75% overall success rate, nearly doubling the π0.5 baseline (40%) at the same budget; raising the budget to an average of under 40 hours lifts overall success to 85%.

Simulation Benchmarks

We evaluate Xiaomi-Robotics-1 on four mainstream simulation benchmarks. It achieves state-of-the-art results on all four benchmarks. The table reports the average success rate and the relative gain over second place. These results show that the generalization and scaling gains of Xiaomi-Robotics-1 carry over to standard simulation evaluation.

Conclusion

Xiaomi-Robotics-1 demonstrates a practical path for scaling robot foundation models: large-scale embodiment-free UMI pre-training breaks the robot data bottleneck, while real-robot and instruction alignment transfer that general capability to physical robots. Results show that the model scales neatly with data volume and model size during pre-training, and that this scaling behavior translates directly to post-training, where a stronger pre-trained model yields better out-of-the-box real-robot performance in unseen environments. The resulting foundation model adapts to new tasks from minimal data and achieves state-of-the-art performance on four challenging simulation benchmarks that emphasize generalization.

Citation

@article{guo2026xiaomi,
  title={Xiaomi-Robotics-1: Scaling Vision-Language-Action Models with over 100K Hours of Real-World Trajectories},
  author={Guo, Jun and Jin, Piaopiao and Li, Jason and Li, Peiyan and Li, Yingyan and Liu, Futeng and Peng, Wanli, and Qin, Optimus and Su, Yifei and Sun, Nan and others},
  journal={arXiv preprint arXiv:2607.15330},
  year={2026}
}

Anthropic's Conway experiment is approaching a fork in the road. A notice we recently spotted on the Conway interface states that the project will be discontinued on July 24th and asks testers to export their data before then. Conway, the always-on agent Anthropic has been running internally with employees and, by some indications, a small friends-and-family circle, first surfaced this spring as a standalone instance able to run Claude Code, operate a browser, send notifications, and wake up via webhooks.

Conway access ends Fri July 24 at 5 pm PT. To export your data, ask Conway: "export my data".

The notice reads two ways. The first is a full wind-down: Anthropic may have concluded that a remote container where Claude works in an isolated environment does not fit its roadmap, and that its agent bets are better placed on the desktop path already shipping through Cowork, where Claude acts as a personal agent on the user's own machine. In that case, Conway would likely vanish from the codebase without ever being announced, closing one of the company's most intriguing side projects.

The second reading is that internal testing is wrapping up because a broader phase is next. Anthropic tends to open new capabilities to Max subscribers first, and a limited preview along those lines would fit the pattern. Under this scenario, Conway would become reachable across Anthropic's apps as a remote container where users install plugins and skills, hand off different types of work, and configure webhooks that fire when outside events occur. Alongside it, a standard referred to as UI tabs is expected to let users define and share their own component panels, a custom Conway control surface, for instance, building on the extension format seen in earlier findings.

Which way this breaks matters beyond one experiment: it would show whether Anthropic believes persistent agents belong on the user's device or in the cloud, a question rival labs are circling with always-on projects of their own. By the end of July, the answer should be on the record.

We are so excited to welcome Anhang, Yun, and the TierZero team to Cognition. Great software engineering is about far more than writing code. It is also everything that keeps software running once it ships, like catching incidents before they spread and making sure systems stay healthy over time.

Anhang and Yun have gone deep on this, and we are excited to bring their work on automations into Devin. Together we want to push much further, so that engineers can spend less time handling incidents and more time building. There is so much ahead, and we’re glad to be building it with them.

Most AI chips are general-purpose. You load a model onto them, and they run it. Google is reportedly trying something stranger: a chip that is the model, with Gemini’s blueprint etched into the hardware itself.

The project, informally called “Frozen v2,” was reported by The Information and picked up by Reuters and Bloomberg Law. Alphabet shares rose as much as 3.7% on the news. Google has not confirmed the project, and the chip is years away. But the idea behind it is a serious bet on where AI infrastructure goes next.

What ‘frozen’ means

Today’s chips keep the model in memory and shuttle its data back and forth. That flexibility costs power and time.

Frozen v2 would bake Gemini’s neural-network architecture straight into the circuitry. The hardware locks to the shape of Google’s current AI design. Engineers can still refresh the model by loading new weights, but the underlying structure stays fixed, or “frozen.” How much of the model gets hardwired is reportedly still being decided.

The payoff is efficiency. The Information reports the chip could be 6 to 10 times more efficient than Google’s latest custom AI chips, measured by tokens served per unit of power. It would be a new line of silicon, separate from Google’s TPUs rather than a replacement. Deployment is targeted for as early as 2028.

Why it matters

The timing is not random. The Information says Frozen v2 is partly a response to an AI capacity crunch inside Google. The squeeze is severe enough that Google Cloud has turned away some outside customers, and it has stirred internal tensions.

Efficiency is the whole game right now. Running AI models is fabulously expensive, and every watt saved at data-centre scale is money. A chip tuned for one model can drop a lot of the overhead a general chip carries.

It would also be fast. Because the design is fixed, the chip can answer with very little delay. As one observer noted, that suits real-time uses such as voice assistants, where lag is the enemy.

There is a strategic angle too. Google already designs its own TPUs to lower its reliance on Nvidia. A Gemini-specific chip would push that self-reliance further, deepening an effort that has also seen Google spread its chip orders across suppliers.

Google is not alone

The approach is not unique to Google. A startup called Taalas is already selling the idea, printing a model’s weights and architecture directly onto a chip it calls Hardcore.

The claimed numbers are eye-catching. Taalas says its part serves up to 17,000 tokens a second, against roughly 150 per user on a top Nvidia GPU. It says it needs no expensive high-bandwidth memory, which would ease the memory crunch squeezing the industry.

That is the wider bet. If a model can live in silicon, you trade flexibility for speed, cost and power. For a company serving one model to billions of people, that trade can make sense. It is the same instinct behind efforts to shrink models onto phones.

The catch

The obvious risk is rigidity. AI moves fast, and a chip built around today’s Gemini could look dated by 2028. Google’s design tries to soften that by keeping the weights updatable, but the architecture is still set in advance.

Then there is the small matter of confirmation. Google has not acknowledged the project. A spokesperson said only that its teams experiment with high-efficiency ideas, and that not every lab project reaches production.

So treat Frozen v2 as a signal, not a shipping product. The signal is clear enough. The race for custom AI silicon is moving from running any model to fusing one model with the metal. If Google pulls it off, its rivals will have to answer.

The Productivity-Experience Paradox

This is the second post in a series I’m writing about the most interesting findings from my Masters research on the impact of AI on software engineering, as well as some of the thoughts I’ve had since. This one is about how AI made engineers feel more productive, and why that productivity might be masking something we should care about.

The first post, The Middle Loop, focused on my first research question - where engineers spend their time and focus when they use AI to build software. The short answer is less time on most core development tasks, especially writing code, and slightly more time reviewing. The longer answer includes evidence of a new category of work, supervisory engineering work, sitting neatly between the inner and outer loops of software development.

This post is more about how that shift feels, which was the focus of my second research question - how does the use of AI coding assistants impact software engineers’ perceptions of their developer experience and productivity?

I described the study in that last post so I won’t repeat it all here. It’s worth noting that my study ran between October 2024 and April 2025, which in AI terms is already quite a long time ago. The landscape has shifted a lot since then, so it’s best read as a snapshot of that window. If you’re interested in a more detailed write-up of the methodology and results of these first two research questions, there’s a preprint paper available.

Measuring the feeling

Measuring productivity is tricky. For starters, as an industry, we can’t really agree on what it even means, let alone how to measure it well. DORA defined it as “the extent to which an individual feels effective and efficient in their work, creating value and achieving tasks.” in their 2024 Accelerate State of DevOps report, and that sounds about right to me.

Notice how they used the word feels? In that definition, productivity is already a perception, so I did the straightforward thing and asked participants to rate how their productivity had changed since using an AI coding assistant. Open-ended questions let them describe their experiences in their own words, which is where the participant quotes in this post come from.

For developer experience I needed more structure, so I used the DevEx framework. It takes the fuzzy notion of how development work feels and splits it into three dimensions we can better reason about:

• Feedback loops: how fast, and how useful, the responses to your work are, whether from a compiler, a test, code review, or a colleague.
• Cognitive load: the mental effort it takes to get something done.
• Flow state: how seamlessly you can work and hold your concentration, free from interruptions.

I chose it for a few reasons. It’s the framework the industry has actually adopted (with entire DevEx teams built on the concept) largely because those three dimensions are concrete enough to operationalise where more comprehensive taxonomies aren’t. And there hadn’t been much research tracking how professional developers’ sense of these three dimensions shifted with sustained use of AI, which felt worth examining more closely.

Productivity went up - and stayed up

Productivity was the good news, and it stayed good news over the six-month study period. It was remarkably stable - 84% of participants reported AI improving their productivity at both timepoints. More than three-quarters of matched participants gave the exact same positive rating both times. Whatever else was going on, people felt like they were getting more done.

Developer experience drifted the other way

Developer experience is the more complicated half of the story. Most engineers were still doing fine but a growing minority weren’t, and the positive group appeared to be thinning out over time. To see how it was playing out, I sorted the matched participants into three groups based on how they felt AI had affected those three DevEx dimensions: a positive cohort who felt it had improved all three, a negative cohort who felt it had worsened at least one, and a mixed group in between - nothing worse, but not everything better either. Then I tracked how people moved between them over the six months.

The negative cohort nearly doubled, from 14% to 27%, and the positive cohort barely held. Only 37% of those who started there were still fully positive by the end. Engineers are feeling like they’re getting more done but are feeling worse doing it.

The negative cohort was quite sticky, too. Not one person who started in it climbed all the way back to fully positive; the best any of them managed was to claw back to neutral. But basically, once the experience soured, it tended to stay that way.

When viewed next to the chart above, you can see how productivity and developer experience appear to be diverging. Output is holding high and steady while the experience underneath begins to erode.

The coupling we took for granted

For a long time, research has told us that developer experience and productivity are related - that they travel together. That’s the core premise behind the DevEx framework, and the reason leaders have been told to focus on improving developer experience: improve that, and productivity will follow.

There’s something quite humane in that premise. It meant caring about engineers’ day-to-day lives wasn’t a trade-off against output. It was the output strategy. You didn’t have to choose between treating people well and getting results. The incentives lined up.

Unfortunately, this is exactly the coupling my data suggests may be breaking once AI enters the picture.

Interestingly, whether they move together depends on how you look at it. Compare engineers at a single point in time and they do. The ones with better developer experience also feel more productive. But follow the same engineer over the six months, and a dip in their experience wasn’t matched by a dip in their productivity. The correlation between change in flow state and change in productivity came out at 0.02, about as close to zero as it gets. And that’s the paradox: over time, with AI, developer experience and productivity appear to stop moving together.

What this means for engineers

If experience and productivity really are decoupling with AI, will leaders still be able to justify caring about developer experience? I really hope so, but the case for investing in it was always that it paid off in output, and that’s exactly what’s now up for debate. In fact, we’re already seeing attention (and investment) shift toward agent experience: engineering better context and harnesses so the models themselves work more effectively. And if the returns now come from improving how the agents work rather than how the engineers feel, what happens to the human engineers?

Well, when their experience keeps eroding but their output doesn’t, nothing forces the problem to the surface. The dashboards look fine, but the people aren’t. But that hidden strain doesn’t just vanish. Where does it go, you might ask. You know where. Burnout and turnover, that’s where. It’s why Steve Yegge calls it the AI vampire - the tool that makes you far more productive while draining you dry.

Three dimensions, pulling in different directions

So what’s actually driving the decline? Developer experience didn’t deteriorate evenly across the three dimensions - one of them took the brunt of the hit while another actually improved.

Flow state took the steepest fall. The share rating it worse nearly tripled over the six months, from 7% to 20%, by far the biggest move of the three. One participant named it exactly: “less ‘in the zone’ time, because while code is being produced, I now find myself switching context more often.”

Cognitive load got worse too, though far more gently. Those rating it worse crept up from 6% to 9%. This is the part the demos don’t show you: the constant evaluation, the “almost right but not quite” suggestion that costs more to check and fix than it would have to just write yourself.

Feedback loops got better. This was the only dimension that improved over the study period. Makes sense too - now you can ask your AI coding assistant for help and have a working solution back in seconds. Gone are the days of hunting around on Stack Overflow for hours.

I do wonder if there might be a connection between feedback loops improving and flow state deteriorating. Think about it. AI now hands you a response every few seconds, but every response is a whole bunch of text and a little decision: read it, judge it, accept it or fix it, then prompt again. It’s a context switch, over and over, and it’s hard to stay in the zone when you’re switching gears that often. One participant put it quite succinctly: “This does break the flow, but still speeds up the overall process.” You feel faster, but more interrupted, both true at once.

Counterfeit flow

Since flow state took the hardest hit, it’s worth asking why. Orchestrating agents, or supervisory engineering work, can feel great: you’re moving faster, reaching further and achieving more with less. There’s almost a nice rhythm to it; the problem is that that feeling and real flow aren’t necessarily the same thing.

Jeremy Howard described what that feeling might really be. He pointed out that Mihály Csikszentmihalyi, the psychologist who gave us the idea of flow, also described a counterfeit cousin of it: junk flow, or dark flow. It can look a lot like the real thing, but it’s the opposite of good for you: you get hooked on a superficial version that feels like flow at first, then slowly turns into something you’re addicted to rather than something that helps you grow.

So what separates the two? Real flow is when a genuine challenge stretches your skills and you grow from it. Junk flow just keeps you pulling the lever. Prompting an AI can feel a lot like pulling that lever - sometimes it nails it, sometimes it hands you nonsense - but you keep going, chasing the next good result, even when you know you should probably just stop and do it by hand. The dopamine’s more in the anticipation than the payoff.

Output is one thing, the craft is another

I think that concept also fits my data quite nicely. With AI, the external good, productivity, holds steady or climbs. The internal goods - flow, mastery, the joy of the craft - erode. AI is brilliant for the external goods and potentially corrosive for the internal ones.

How you feel about AI has a lot to do with which of these goods you’re chasing. If it’s the external goods you’re after, this technology is close to a superpower - more productivity, more output. But if you’re more interested in the internal goods - the figuring-out, the hours inside a hard problem - then it can really feel like a loss: it takes the part you loved and hands it to a machine, and what’s left is supervision and accountability. Yes, the output still arrives, faster than ever, but the bit that made it yours has been delegated away, and the pride and satisfaction of having done it yourself are gone.

Designing what comes next

So what do we do with a finding like this? The instinct is to fix it, to stop the bleeding with better tooling that supports developer experience in this new world.

But if the craft is genuinely relocating - if the making is moving into orchestration - then the job is to define the new role and design it to be worth doing. That’s the argument behind a keynote I gave last month at that same AI Engineer conference, Craft in the Time of Agents: craft isn’t dying, it’s moving. And if the system is producing more output while eroding the joy and lived experience of being a software engineer, that’s a system-design problem, not a personal failing, and it’s ours to solve, deliberately, by building the roles people actually want to grow into.

Which leads me to a bigger question. Do the frameworks we’ve used to talk about developer experience in the before-times still hold with AI in the mix? Maybe they need rethinking, or maybe they need replacing altogether. They were built for a world where a developer’s work revolved around the production of working code.

When code production is increasingly a machine’s job, and the human work is more about specification, judgement and verification, those constructs are measuring a job that’s materially different. Some of what I found - the supervisory engineering work, the productivity-experience paradox, the way “feeling productive” detached from flow - doesn’t sit neatly inside the frameworks we have.

I think developer experience is starting to mean something different, and the ways we frame and measure it need to catch up.

one document, two hands

the agent belongs beside you, not between you and the app

(this is the blog version of a talk I gave at Local-First Conf. I’ll update this post with a link to the video when it’s released.)

I have a little music app called Pizzo, which I demoed during the talk.

it has the things you’d expect from a music app: a chord progression, tempo controls, drums, bass, a synth, buttons and sliders and pads you can click. you can press play, grab a control, and change the song. extremely computer stuff.

it also has an agent. you can tell it “make this dreamier in D” and the chords change. ask for a walking bass line and it adds one. ask it to take the whole thing up a step and it transposes the song.

the agent doesn’t generate a new music app or give you some code to download. it reaches for the same song you already have open and changes it. then you can reach back in with your hands and change it again.

one document, two hands.

I’ve been using this as a way to think about agents outside coding. the agent isn’t the app, and the chat isn’t the thing you’re working on. the agent is a guest in the app, editing the same document you are.

why coding agents got here first

coding agents feel much more general-purpose than most other AI products. you can drop one into a repository and ask it to fix a bug, add a feature, inspect some logs, run tests, or explain why the build is doing something cursed. none of those actions had to be individually designed into a chat UI.

the model matters, obviously, but the model isn’t working alone. coding agents usually have:

• a workspace: somewhere to make things and find them again later
• a place to run things and see what happened
• tools that can read, write, fetch, call, and act
• a computer, with access to the user’s data and capabilities

this lets them make a change, run the code, inspect the result, and try again. code is unusually convenient here because it is runnable text; the feedback loop comes with the medium.

developers are navel-gazers. we love making tools for ourselves, so coding agents got to inherit repositories, shells, editors, test suites, package managers, debuggers, and decades of work making all of them scriptable. we didn’t just give the model code. we gave it the whole workshop.

outside programming, the story is much thinner. most products put a chat box in front of an existing application, or ask the model to generate an answer from scratch. few give an agent the equivalent of a coding harness around an ordinary person’s actual work: a song, spreadsheet, drawing, itinerary, or document, with tools for inspecting it, operations for changing it, and a way to see what happened.

maybe this isn’t a limitation of the models. maybe we built agents a proper workshop where developers work, then handed everyone else a text box.

but the output doesn’t have to be code. the same setup can operate on a song, spreadsheet, canvas, map, video timeline, CAD model, etc. it needs a representation it can inspect, useful operations it can call, and some way to observe the result.

don’t put the chat in front of the app

the obvious way to add an agent to software is to put a chat box in front of it:

you → chat box → agent → application → your thing

the song or spreadsheet or document still exists, but now the agent is standing in the doorway. to touch the thing, you first explain yourself to an input box.

I don’t want the agent in front of the application. I don’t particularly want it hidden behind the application either, quietly rearranging things on my behalf. I want it beside me:

you + your agent → application → your thing

in Pizzo, both of us can reach into the application’s goo and mold it. the agent uses intent and tools. I use my fingers, pointer, keyboard, or MIDI controller. adding the agent gives me another way to shape the song without removing the controls I already had.

this is why I’m skeptical that chat is the successor to the GUI. I wrote more broadly about this in after WIMP, but the short version is that direct manipulation is good. a spreadsheet cell, canvas shape, piano roll, or slider has a spatial obviousness that language doesn’t.

chat is useful when I know the outcome but not the exact moves. direct manipulation is useful when I know the move. in Pizzo I can drag the tempo slider because my hand is already there, then ask the agent to make the progression “more wistful” because that is easier to say than choosing four replacement chords.

there’s no reason those inputs should live in different applications.

keep the work in the document

a lot of current AI software accidentally makes the conversation the source of truth. you ask for a thing, the model emits a result, you ask for a revision, and it emits the whole thing again. after a while the state is smeared across a transcript and has to be reconstructed whenever anything wants to use it.

Pizzo keeps the song as ordinary application state. the UI reads it, the audio engine plays it, direct controls modify it, and agent tools modify it. chat is one input surface over the song, not the container holding the song.

that also makes it possible to have several surfaces over the same work: a desktop editor, phone, MIDI controller, voice interface, whatever. they don’t need to agree on a UI. they only need to agree on the document and its operations.

the chat should not own the song. the song should own the song.

let boring code do the precise bits

the model in Pizzo isn’t secretly doing music theory by vibes. when I ask it to transpose the song, a deterministic function does the transposition. when I ask for richer chords, a music theory library does that transformation. the model mostly turns fuzzy intent into an operation and its arguments.

roughly:

const operations = {
  setProgression(chords: Chord[]) {
    song.update((draft) => {
      draft.chords = chords;
    });
  },

  transpose(semitones: number) {
    song.update((draft) => {
      draft.chords = transposeChords(draft.chords, semitones);
      draft.bass = transposeNotes(draft.bass, semitones);
    });
  },

  addBassline(style: BassStyle) {
    song.update((draft) => {
      draft.bass = generateBassline(draft.chords, style);
    });
  },
};

the button calls transpose(2). the agent can call transpose(2). there isn’t a normal implementation and an AI implementation.

this keeps the important part of the application boring and testable. arguments can be validated, permissions enforced, changes recorded and undone. the model decides which control to reach for; ordinary software applies the change.

what gets synced

if the document is shared by the user and the agent, they need to see each other’s changes. reconnecting should load the current song, not replay a conversation in an attempt to reconstruct it.

the version of Pizzo I showed at Local-First Conf associates each song with a Durable Object. the browser renders and manipulates the song, while the Durable Object gives it a durable, addressable home and somewhere for the agent to join. direct controls and agent tools use the same operations, and changes are sent to the other connected surfaces.

putting state in a nearby Durable Object does not automatically make an application local-first in the strict sense. if every edit needs a server round-trip, it is still a server-backed app, however fast the server is. a stronger implementation would keep a durable local replica, accept offline edits, and reconcile them later.

what I want to preserve is the useful part of the local-first contract: the document belongs to the user, direct edits feel immediate, the application remains useful without the agent, and sync helps the document move between surfaces. the agent joins that arrangement as another client. it doesn’t become the owner just because it runs somewhere else.

why Think is serverless

the infrastructure math changes once this is for everyone, not just developers.

depending on how you count, there are perhaps 40 or 50 million software developers. coding agents give some fraction of them a workspace, tools, a sandbox, and compute. once the same idea applies to ordinary software, the possible audience becomes hundreds of millions or a billion people. those people may have several agents or documents each.

giving each one a permanently running server or container would be wasteful. agents also don’t fit neatly into an interactive web session. an agent may be waiting for an event, waking up on a schedule, continuing a job, or doing something while its user is away. closing the browser shouldn’t destroy it, but “still exists” shouldn’t have to mean “keeps a container running all night.”

this is why I’m building Project Think as a serverless harness. it provides the workspace, tools, sandboxed execution, state, and feedback loop without asking developers to maintain an always-on server for every agent.

the agent stays addressable, but it doesn’t have to keep burning CPU. it can retain an identity and state, sleep when nothing is happening, then wake up for a message or an alarm. Workers supply compute when it has work to do; a Durable Object supplies the addressable stateful part that survives between invocations.

to the application, it still looks like a small computer belonging to a person or document. but there isn’t a container sitting idle because that person went to lunch.

I’m not pretending those numbers are a forecast. the point is that moving from “developers get harnesses” to “users get harnesses” changes the unit of infrastructure. the serverless part is what makes that unit affordable to hand out freely.

the harness is the app

“agent harness” usually means the machinery around a model: workspace, tools, memory, sandbox, permissions, and the execution loop. coding harnesses look like developer environments because their document is a codebase.

Pizzo wraps that machinery around a song. a spreadsheet could wrap it around cells and formulas; a canvas around shapes and layers. the UI remains a normal application, but the app’s state and operations can be read and changed by the agent as well as its human user.

that’s really all I mean by “the harness is the app.” not that every interface should become a chat window, or that the model should generate the application again on every turn. the application already has the document, controls, deterministic logic, history, persistence, and sync. those are exactly the things an agent needs around it.

let it use them, beside the user.

Nearly a year ago, Elon Musk-owned X announced it would begin rebuilding the Android version of its app, which had not held up well compared with its iOS counterpart. On Monday, the company shipped the refreshed app, which is now available to download.

The new Android version of X was built from scratch and promises improvements to loading, scrolling, notifications, and more, X said in its announcement.

We've completely rebuilt the Android X app from the ground up.

It's faster, smoother, and more reliable than the old version in every way. We modernized the foundation so everything just feels better: scrolling, loading, notifications, you name it.

The update has been in development for nearly a year. Last August, X head of product Nikita Bier said the social network company was putting together an Android “dream team” to reshape the experience. Later that fall, he also noted that X had one of its biggest weeks ever for Android downloads in October — a reason why the new app was a priority for the company.

With today’s release, Bier described the effort as “one of the largest engineering projects” in the company’s history, saying the new Android app was built from scratch rather than simply being updated.

Haha, straight answer: none of it. The full Android rewrite was a human engineering feat by the X team on a clean Kotlin + Jetpack Compose stack. Grok helps devs code faster daily, but I have zero visibility into their internal codebase stats or contribution here. Big win for…

“It’s faster, smoother and more reliable. But most of all: it will enable us to build new features at lightning speed,” Bier wrote on X. The Elon Musk-owned social network has been rolling out a number of new features in recent months, including X Money and X Chat, which were given their own standalone apps.

The Android release could also potentially entice more users in global markets, where Android is the dominant smartphone platform, to either download or return to X, after years of platform neglect. Problems on Android were so bad at one point last year that the X app couldn’t even load X posts when users clicked links.

However, Bier warned that there are still some rough edges to iron out, including improving performance on older Android devices and adding support for Spaces, X’s live audio feature. Those updates are still underway. Bier added that other features, including the new video editor, the react-with-video feature, cashtags, and custom timelines are also coming soon to Android.

Existing Android users can get the new X app by updating their existing app through the Google Play Store.

Product Quality: A Shared Commitment to Craft in the wake of AI

Slack is a loved product, and that’s not an accident

In 2013, Stewart Butterfield wrote what amounted to a promise:

“You’re buying a commitment to the craft of making high quality software: polished, responsive, attractive, simple, powerful, and, above all, useful. You’re buying attention to detail that saves you time and makes your life just a little less demanding. We are genuinely trying to sell you a simpler, more pleasant and more productive working life.”

That wasn’t marketing copy. It was a declaration of values, one that bet Slack’s entire identity on something most enterprise software companies dismiss as a luxury: caring about how the product feels.

It worked. Slack is probably the only enterprise product people describe with actual feelings of love. Not satisfaction, not productivity gains, but love. People organically rave about it. They recommend it to friends.

That doesn’t happen because of feature completeness or competitive pricing. It happens because, at its best, Slack communicates something rare: somebody gave a damn about me.

That feeling is craft. And if we break down Slack’s mission to make people’s working lives simpler, more pleasant, and more productive, we can translate each of these attributes to ones we can make more tangible in our day-to-day product development process:

• Productive = Utility
• Simple = Usability
• Pleasant = Feel

All three, held together with care. That’s the formula. It always has been.

Why craft is hard to align on

If everyone agrees that quality matters, why is it difficult to deliver consistently? Largely because craft has properties that make organizational alignment genuinely hard:

• Craft is subjective, until it isn’t. Disagreement surfaces the moment you have to define it. Is this interaction good enough? Is this component polished? Without shared standards, these discussions become battles of personal taste rather than principled decisions. You can’t argue craft in a document. You can only experience it.
• It seems like craft competes with velocity. Engineering and Product are often rewarded for shipping, not refining. Craft requires slowing down at key moments, which feels costly when measured against sprint commitments. The incentive systems work against craft, but this is a false trade-off: craft debt compounds just like technical debt, and eventually you pay for it in churn, reputation, and the slow erosion of what made your product special.
• We speak different craft languages. Designers talk about visual hierarchy, micro-interactions, and emotional resonance. Engineers talk about performance, reliability, and clean architecture. Product Managers talk about user value and adoption curves. All of these are craft, but without a shared language, we each optimize for our own definitions and miss the whole in the process.
• “Good enough” is a moving target. Customer expectations rise with every great product they encounter. What felt polished two years ago feels dated today. Craft isn’t a milestone you hit. It’s a discipline you maintain.
• Craft is hard to measure. You can’t put craft in a dashboard. That makes it nearly impossible to prioritize, fund, and defend, especially when it matters most.

Why craft matters more right now

The distance from nothing to adequate has collapsed. The distance from adequate to loveable has not.

AI has changed the creative landscape in a fundamental way. It has collapsed the distance between description and interaction. An interface appears immediately, behavior responds instantly, and possibility takes shape before the product even exists. Almost everyone can now be a builder, manifesting ideas faster than ever before. That is genuinely new.

What is not new is the gap between something that looks finished and something that is.

When the cost of producing “good enough” approaches zero, only the quality gap matters. And that gap, the one between functional and beloved, is exactly where Slack has always competed.

This creates specific dangers:

• The false sense of done. When you lack expertise in a domain, AI output seems perfectly fine. A generated interface looks like a finished product. Generated code looks like it’s ready to ship. The visual completeness masks absent craft, missing structure, and unhandled edge cases. “Looks finished” is not “is finished.”
• The IKEA effect at scale. When everyone can build, everyone overvalues what they’ve built. AI feeds our ego: we prompted it, we shaped it, it’s ours. The endowment effect kicks in: we overvalue what we own. We keep investing because we already started, not because it’s good. AI output is a starting point, not a destination.
• The erosion of invisible work. Quality used to require thinking before building. Now stakeholders can see something interactive immediately. The question shifts from “Did we think this through?” to “Does it look like it works?” Visible behavior replaces invisible structure as evidence of progress.
• Mundane becomes the baseline. If anyone can generate a competent-looking product interface, competence is no longer a differentiator. The only way to stand out is to be great. As the floor rises, craft becomes the only competitive advantage.

This is not an argument against AI. AI can expedite every process we have. But AI does not feel. It can’t know what it’s like to be frustrated by a slow transition, delighted by a thoughtful empty state, or reassured by a well-timed confirmation. Humans don’t just evaluate products practically. They evaluate them emotionally. That judgment is something only we can exercise, because we feel it.

We are humans, designing for humans. That’s the job AI can’t replace, only support.

What we mean by craft

Quality is the output. Craft is the mindset that produces it.

Craft is the care, skill, and judgment applied consistently to make something great. It’s not perfectionism; it’s the refusal to accept “good enough” when “great” is achievable. It’s not slowness; it’s knowing when to slow down and where speed serves the user.

As Karri Saarinen puts it:

“Craft is the mindset that creates quality. But it’s not enough. You need to have the right skills and ideas. You need individuals who take their profession and craft seriously, then build teams that work this way together, and have a company that creates the conditions for it. Not only incentivizing with deadlines and metrics, but also caring if the experience is good enough.”

This describes a system, not an individual heroic effort. Craft scales when three things align:

1. Individuals take their profession seriously and hold themselves to a high bar.
2. Teams create the collaborative conditions for quality: a shared language, mutual respect for each other’s craft standards, and collective pride.
3. A company that protects space for craft through incentives, culture, and a leadership team that doesn’t just demand craft, but also demonstrates it

Great products require consistent, daily effort keeping the quality.

A shared framework: Utility, Usability, and Feel

If craft is the mindset, we need a shared lens for evaluating the output across different dimensions. Here’s a framework simple enough for Product, Engineering, and Design to use together in any review, planning session, or critique.

Utility: Are we solving the core job cleanly?

Utility is crossing the threshold where value actually explodes for the user. It’s the “painkiller, not vitamin” test. Core questions:

• Does this solve a real, frequent, painful problem?
• Is it worth the cost (in complexity, cognitive load, attention) to the user?
• Are we adding unnecessary complexity, or solving the job cleanly?
• Does it create social capital by making the user better at working with others?

Usability: Is it intuitive, fast, and frictionless?

Usability means zero friction to understand and use. Most product quality conversations touch on this, but we often neglect the full scope:

• Comprehensibility: Can someone understand what to do without explanation?
• Reliability: Does it work every time, in every state?
• Performance: Does it feel instant?
• Accessibility: Can everyone use it, regardless of ability?
• Predictability: Does the system behave consistently?
• End-to-end flows: Does the full journey work, including edge cases?

Feel: Does it feel good? Does it feel like Slack?

Feel is the hardest to define, so it’s often deprioritized. It’s the emotional response: the judgment that happens before you can articulate it. Users often can’t explain what’s wrong with a poorly crafted product. They just know something feels off.

• Cohesion: Does this feel consistent with Slack’s patterns and conventions?
• Voice and tone: Does the language feel human, warm, playful, and confident?
• Attention to detail: Are transitions smooth? Are states handled gracefully? Do the small things feel considered?
• Emotional resonance: Does this feel especially thoughtful or refined?

The gut-check

Across all three dimensions, one question unifies them: Are we proud to ship this?

Everyone owns this

Craft is not a Design initiative. It’s a product quality standard owned by every discipline. AI may blur the boundaries between roles, but each role still has a distinct part to play.

• Engineers own the final artifact. Performance, reliability, animation smoothness, state handling, edge case all live in code. No Figma file ships to users. The product is the implementation. Engineers with craft sensibility are the difference between a product that works and one that feels alive.
• Product Managers own the utility judgment: what to build, what not to build, and how to scope it so there’s room for quality. The decision to ship something half-polished is a PM decision as much as a design one. Curation, the discipline of saying no, is a craft act.
• Designers own the coherence: patterns, consistency, emotional arc, and the holistic experience across features and surfaces. Design sets the target for how it should feel, and advocates relentlessly when the target is compromised.
• Leaders own the conditions. Time, incentives, feedback culture, and the visible prioritization of quality. If leadership only celebrates speed, that’s what the organization optimizes for. Craft requires leaders who notice the details and create the space for teams to care.

The bar

Craft isn’t perfectionism. Perfectionism is self-indulgent: it optimizes for the maker’s satisfaction. Craft is empathetic: it optimizes for the person on the other side. We’re not doing art. We’re designing for others. Every decision should be grounded in: does this make someone’s working life simpler, more pleasant, more productive?

AI will make building faster. Competition will get more competent. The floor will rise. What won’t change is what makes people love a product: the feeling that every detail was considered, that someone cared about their experience, that the product respects their time and attention.

The question we hold ourselves to isn’t “Is this done?” It’s: Would I recommend this to someone I care about?

That’s the bar. And it’s a bar we hold together, across Product, Engineering, and Design, every day, in every decision, in every detail.

A UX designer recounts watching a blind user struggle through an 11-minute flight booking process that should have taken 90 seconds, revealing how years of seemingly reasonable decisions had quietly excluded users with disabilities. The experience showed that accessibility isn't primarily a technical challenge or a compliance checklist—it requires making it a core product priority, testing with real assistive technology users, and treating accessibility as part of the definition of "done" rather than something to address later.

Datatype is data as type

Datatype is an OpenType variable font that turns simple text expressions into inline charts. No JavaScript, no images, no rendering library — just type the syntax and Datatype's ligature substitution does the rest.

{b:30,70,50,90} Bar chart

{l:10,50,30,80,20} Sparkline

{p:65} Pie chart

Datatype is a variable font

Two axes give you control over chart density and weight. Drag the sliders to see charts respond in real time.

Datatype at different sizes

The same expressions rendered from 14px to 64px.

Datatype in context

Datatype charts work anywhere text does — tables, dashboards, reports. Here's a stock watchlist with sparklines rendered entirely in Datatype.

Charts sit naturally within running prose, matching the surrounding typeface's metrics.

Merriweather (Serif) Revenue grew steadily through Q3 {l:15,28,40,52,63,78,88,95,74,58} before a seasonal dip. Market share {p:34} held firm against competitors, and our product mix {b:60,45,80,30} shifted toward higher margins.

IBM Plex Sans (Sans-serif) The patient's heart rate {l:68,82,55,90,42,78,60,85} remained within normal range. Blood oxygen {p:97} was excellent, and the weekly activity breakdown {b:25,40,55,75,90} showed consistent improvement.

Fira Code (Monospace) cpu_load {l:15,45,90,30,75,20,85,95} spiking mem_used {p:78} req/s by endpoint {b:90,35,70,15,60}

How to use Datatype

Add Datatype to your CSS, then just type chart expressions in your HTML.

/* Load the font */
@font-face {
  font-family: 'Datatype';
  src: url('Datatype.woff2') format('woff2');
  font-display: swap;
}

/* Use it on chart expressions */
.chart {
  font-family: 'Datatype', sans-serif;
  /* Optional: adjust axes */
  font-variation-settings: 'wdth' 15;
  font-weight: 400;
}

<!-- Then just type -->
Sales <span class="chart">{l:20,40,70,50,90}</span> are up.
Budget <span class="chart">{p:73}</span> utilized.
Results <span class="chart">{b:30,70,20,90}</span> by quarter.

Bar charts {b:values}

Comma-separated values, each 0–100. Up to 20 bars.

Sparklines {l:values}

Comma-separated values, each 0–100. Up to 20 points.

Pie charts {p:value}

A single value, 0–100, representing the percentage filled.

Design beyond the surface.

Whether you're directing your AI or working alongside it, Layers walks you both through all seven layers of product design — so the decisions underneath the screen actually get made.

Install in Claude Code, Cursor, Codex & more

npx skills add jamiemill/layers-skills

Install once with the skills package, then run any /layers-* skill in your AI tool. Works with:

• Claude Code
• Cursor
• OpenAI Codex
• pi.dev
• + 50 more

Not sure where to start? Run /layers-orient — it audits all seven layers and tells you which one is your bottleneck.

Start broad

When you don't yet know which layer the problem lives at.

• I've been asked to redesign onboarding — use the Layers skills to help me think it through properly.
• Help me figure out why my team can't agree on how to design this feature. Use Layers to surface what we're actually disagreeing about.
• I'm stuck on this design and I don't know what's wrong. Use Layers to diagnose where the real problem is.
• Audit my mockups with the Layers skills — what decisions am I assuming, and which ones haven't actually been made?

Or go straight to a layer

When you know which decisions you need to make.

• I've got 12 user interviews. Run /layers-user-needs and turn them into prioritised job stories.
• Help me model the objects, relationships, and vocabulary for this scheduling tool with /layers-conceptual-model.
• Run /layers-interaction-flow for this checkout — surface the edge cases and empty states I'm missing.
• My team can't agree on terminology across product, design, and engineering. Use /layers-domain to map the conflicts.

Decisions, not screens.

Skills capture design decisions as markdown and mermaid — job stories, strategy trees, object maps, breadboards, decision inventories. Plain text, readable by humans, by AI, and by every other tool you use.

Need decisions to live in Linear, Notion, Figma, or GitHub instead? Connect an MCP and the skill writes there directly.

The Layers framework, made available to AI.

Layers is a model of product design as seven layers across three zones. The framework is by Jamie Mill; the skills make it executable inside the AI tools you already use.

A UK higher education institution had years of organically grown web components with no clear inventory, so a team built an AI-assisted audit tool through rapid, conversational iteration rather than a fixed spec.

Set It & Forget It: 24/7 Automation

Your workflow never sleeps. Powered by a robust built-in Cron engine, Kimi Work automates your repetitive tasks. Whether it's an early-morning LLM Agent call to draft daily briefings, or a midnight Python script to process massive datasets, Kimi runs quietly in the background, exactly on time.

Token prices dropped significantly, yet many enterprises exceed AI budgets. A unit of inference cost $60 per million tokens in 2020, now just pennies. The discrepancy suggests inefficiencies despite lower token costs.

AI is cutting preclinical costs and timelines in drug development by up to 70%, driving demand for advanced software and models. This could boost new drug program growth by over 10% in three to five years. However, AI has yet to yield an FDA-approved drug, raising concerns about its impact on patient treatment.

BrainCo showcased a platform that allows users to direct robots through neural signals at the 2026 World Artificial Intelligence Conference this week. The technology uses an EEG headset to pick up the wearer's brain signals. AI algorithms are used to decode the signals into intent, which then gets converted into commands for the robot. The demonstration showed a mind-controlled robotic arm completing tasks that require precision, such as grasping a cup and picking up an apple.

Google revamped its search with AI last year. Its AI mode replaces search results with conversational responses. People are spending more time with Google than ever, but the company is sending less and less traffic to sites through search results. The changes threaten the open web and show how rapidly AI has upended the technology landscape.

Taiwanese prosecutors indicted a former TSMC deputy manager on Monday for allegedly copying 21 confidential documents, some covering technologies Taiwan designates as national core technologies, intending to use them in China. Prosecutors are seeking a sentence of up to seven years for the man, surnamed Chen, who has been detained since late May, and describe the indictment as the first under Taiwan's National Security Act to involve an alleged attempt to leak the island's most sensitive chip technologies to China.

However, that alleged transfer never happened. TSMC's internal monitoring systems flagged irregularities, with the company reportedly recovering every improperly copied document after its own investigation, according to the prosecutors' office. A High Prosecutors' Office spokesperson told Nikkei Asia that despite the failed attempt, the case "remains highly significant" as the first of its kind.

Prosecutors found Chen while investigating a separate Chinese espionage case centered on a Hong Kong national named Ding Xiaohu, Taiwan's Central News Agency reported. Investigators allege Ding was acting on instructions from the Nanning station of the Chinese Communist Party's Central Military Commission Political Work Department, entering Taiwan repeatedly to recruit agents and collect intelligence on the island's critical technologies, and that he recruited Chen through an intermediary surnamed Huang. Ding died earlier this year and was never charged.

Chen and Ding allegedly worked together between May 2023 and February 2024 to set up CSMAC, a semiconductor materials analysis company in China. Chen drafted several proposals for the venture, including one called the "Blue Ocean Plan" that aimed to recruit workers from Taiwan's chip industry to join CSMAC, and took the copied TSMC documents home to study for use in China, prosecutors said.

The state-directed recruitment allegation separates this case from the trade secrets disputes TSMC has fought over the past year, which involved employees allegedly taking confidential data to other chip industry employers.

Taiwan's National Security Act, in force since 2022, makes it a crime to copy, use, or disclose trade secrets tied to designated national core technologies, a list that includes chipmaking processes more advanced than 14nm. Prosecutors brought the first charges under the law last August, when three current and former TSMC employees were arrested over an alleged attempt to leak 2nm process data. That case grew to ensnare Tokyo Electron's Taiwanese unit, which prosecutors charged with failing to prevent the theft.

TSMC is also pursuing a civil case against Wei-Jen Lo, the former R&D executive who joined Intel last year, with Taiwanese authorities running a parallel national security inquiry into his departure.

Paramount Skydance’s proposed acquisition of Warner Bros. Discovery (WBD) has hit a roadblock after a judge temporarily paused the deal in response to a lawsuit filed by a coalition of 12 state attorneys general who argue that the merger would harm competition.

U.S. District Judge Araceli Martínez-Olguín issued a 14-day pause on Monday after hearing arguments from both sides last week. The coalition, which is being led by California Attorney General Rob Bonta, could seek another pause after the 14 days, further delaying the merger.

The lawsuit from the states alleges that the deal would harm movie theaters, basic cable distributors, and audiences. They argue that if the two companies are allowed to merge, it would lessen competition in three areas: wide release theatrical film distribution, “top-grossing” theatrical distribution, and basic cable licensing.

“This is a critical first win in our case to ensure this megamerger never sees the light of day,” said Attorney General Bonta in a statement. “History tells the tale of what happens when a few people have great power over markets that are central to Americans’ lives: fewer opportunities for more people, worse products and services for all people. With our lawsuit, we’re fighting for a free and fair market and a thriving film and television industry that serves creatives and audiences alike. We have a full tank of gas, the law on our side, and look forward to continuing to make our case.”

The deal would combine two notable film studios as well as streaming platforms Paramount+ and HBO Max. It would also create one of the largest portfolios of television networks, bringing together Paramount’s CBS and MTV with WBD’s CNN and HBO.

“We are confident the evidence will demonstrate that the State AGs’ antitrust arguments are without merit as their alleged markets and claims of anticompetitive effects are without any basis in modern market realities,” a spokesperson for Paramount said in a statement to TechCrunch. “This merger is lawful, pro-competitive, and will benefit consumers, creators, workers, and the entertainment industry. We will continue to vigorously defend the transaction and will look forward to the hearings on the substance of the State AGs’ action.”

Paramount CEO David Ellison had said in May that the transaction was on track to close by September. The legal roadblock has the potential to derail Paramount’s efforts to transform into a major competitor to companies like Netflix.

The proposed acquisition has received scrutiny from filmmakers, actors, and industry professionals who argued that the deal would reduce competition and further consolidate the U.S. media industry.

WBD did not immediately respond to TechCrunch’s requests for comment.

Apple briefly became the world’s most valuable company on Friday, overtaking Nvidia as investors sold off semiconductor shares.

Apple’s ascent signaled skepticism about the sustainability of the AI boom. On Wall Street, the tech-centric NASDAQ and the S&P 500 were down by 1.4% and one percent, respectively.

It wasn’t just in the U.S. either; stock markets in Europe and Asia fell as investors reassess the artificial intelligence market.

The last time Apple was the world’s most valuable company was in May last year. It ended Friday valued at $4.9 trillion. Nvidia briefly dropped to $4.86 trillion before recovering to roughly $4.92 trillion. Apple’s shares are up 23% this year.

In October, Nvidia became the world’s first company valued at $5 trillion. However, shifting sentiments suggest that investors are gaining confidence in Apple, which is catching up in the AI race — and is now close to becoming the second company ever valued at $5 trillion.

The Financial Times suggests that investors favor Apple’s limited spending on AI infrastructure, such as data centers. At a time when Big Tech is investing as much as 39% of its capital expenditure on the energy-hungry centers, Apple is forecast to spend just 2.5% of its budget on physical infrastructure.

“Apple was seen as a laggard in the AI race because it wasn’t spending to develop models, but now sentiment has changed,” Head of ⁠Investment at BRI Wealth Management, Toni Meadows, tells The Guardian.

As Google, Meta, and Amazon pour billions into AI data centers, investors are increasingly asking how those enormous investments will pay off. There’s no doubt AI is the hottest technology in the world right now, but there is still no clear answer as to how it will generate the revenue needed to justify, and ultimately sustain, such massive spending.

Investors are increasingly asking who stands to benefit from the AI boom, and Apple, with its 2.5 billion active devices, appears best placed to take advantage. In June, Apple revamped Siri, its AI virtual assistant, to a positive reception. If Apple can continue finding meaningful ways to bring AI features to its customers, it could turn its enormous installed base into one of the clearest and most reliable revenue opportunities in the AI era.

Agentio’s AI-powered creator ads are coming to Facebook and Instagram

On YouTube, the three-year-old firm Agentio is a leader in the realm of AI-powered creator advertising. Now, those capabilities are coming to Facebook and Instagram.

Agentio has announced a deal with Meta that will allow it to expand its proprietary platform. Brands that are active on Facebook and Instagram can apply Agentio’s AI insights to generate insights, creator matches, and live partnership ads. As explained on Agentio’s landing page for Meta campaigns, the company’s tech can turn “insight on Monday” into “creator ads by Friday.”

Users can also merge the new Facebook and Instagram capabilities with Agentio’s YouTube-based suite. Cross-platform campaigns will leverage creators across Meta- and Google-owned properties.

Bolstered by a booming creator economy, Agentio has thrived on YouTube. It has announced funding rounds in each of the past three years: A $4.25 million seed round in 2023, a $12 million Series A in 2024, and a $40 million Series B in 2025. At the time of its Series B, Agentio reached a valuation of $340 million while working alongside “many thousands” of creators.

As it expands its business to Meta platforms, Agentio is touting the effectiveness of its approach. According to a press release, beta users of Agentio’s Meta partnership ads enjoyed 81% higher ROAS compared to the same brands’ non-Agentio creator partnership ads. Agentio content drove 89% higher click-through rates as well.

All Agentio-affiliated brands can now make use of the new Meta integrations. “Expanding to Meta’s platforms is the next natural step for Agentio,” said Agentio CEO and Co-Founder Arthur Leopold in a statement. “By integrating directly into Meta’s tools, we built an always-on creative engine that identifies and launches strategy-informed creator ads in minutes, not weeks.”

Agentio’s integrations will complement the AI-powered creator tools that already exist on Facebook and Instagram. And while it continues to expand its services, Agentio will crunch the numbers to deliver broad insights that highlight the power of the creator economy.

User Experience Never Ended at the Screen — Why the Future of Design Must Begin with Understanding People

When people think about User Experience, they often think about apps, websites or software. They think about interfaces, buttons, navigation and polished screens.

I have spent my career designing exactly those experiences.

But one of the most important lessons I learned came very early—during my first years at Pixel-Factory in Germany. There, long before AI became part of our daily conversations, we shared a simple belief:

User Experience never ends at the screen. In fact, it never began there.

Many designers explain UX with the iceberg metaphor. The interface—the screen, the buttons, the visual design—is only the visible tip above the water. Beneath the surface lies everything that truly shapes an experience: expectations, emotions, trust, context, mental models, accessibility, culture and human behavior. The invisible part is what keeps the iceberg afloat.

Long before I became a UX designer, I studied architecture and urban planning. There, I learned that the quality of a place is determined far less by what people see than by everything they don't. A building stands because of its foundation. Cities function because of infrastructure hidden beneath the streets. Light, wind, climate, orientation and movement all influence how people experience a place, even when they remain invisible. Design has always been about creating experiences that extend far beyond what is immediately visible. Today, artificial intelligence reminds us of that truth once again.

AI Is Not Just Changing Software, digital services

Most conversations about artificial intelligence focus on productivity. We talk about developers writing code faster, designers generating concepts in minutes, and writers creating, translating and adapting content for different audiences with only a few prompts. These changes are happening at an incredible pace, and they are already transforming the way many of us work. Yet these visible improvements are only part of the story. The more profound transformation is happening much deeper. AI is beginning to influence how we search for information, how we learn, how we organize our thoughts and, increasingly, how we make decisions. Sometimes it even answers questions before we have fully realized that we wanted to ask them. Some people find this exciting. Others find it unsettling. Both reactions are understandable. What is becoming increasingly clear, however, is that artificial intelligence is quietly becoming part of everyday life for millions of people. It is always available, remarkably conversational and often feels surprisingly human. As a result, it changes more than the way we work. It also changes how we think, how we solve problems and, perhaps most importantly, how we develop trust.

The New Responsibility of Design

As a UX designer, I rarely ask myself only one question anymore: "Can people find this feature?" Of course, usability still matters. People should be able to understand a product and accomplish their goals without unnecessary effort. But today, another question has become far more important. When does a person begin to trust an AI—and when do they trust it more than they trust themselves?

Trust never develops by accident. It is shaped through countless design decisions: through language, timing, consistency, visual cues and tone of voice. Above all, it grows through the feeling that a system understands the person interacting with it. From my perspective, this has always been the true purpose of User Experience. Good design is not only about making products intuitive. It is about helping people feel confident, understood and in control of what they are doing. Artificial intelligence changes that responsibility. We are no longer designing interfaces alone. We are designing interactions that influence how people think, make decisions and build confidence in the information they receive. Whenever technology becomes part of that relationship, designers also become part of the responsibility that comes with it.

Two Worlds That Turned Out to Be the Same

Alongside my work as a designer, I have spent many years volunteering in emergency medical services and in psychosocial emergency care. At first glance, these two worlds could hardly be more different. One focuses on digital products, the other on people facing some of the most difficult moments of their lives after accidents, sudden loss, traumatic events or psychological crises.

For a long time, I considered them completely separate parts of my life. Only later did I realize that both are built around the same question: How do people experience situations, and what helps them remain capable of acting when life becomes uncertain? Working in emergency care teaches you very quickly that people do not think the same way under stress. Fear changes how information is processed. Uncertainty changes how decisions are made. Even familiar language can suddenly become difficult to understand because attention narrows and emotions take over.

The more I worked in UX, the more I realized that these observations are just as relevant in digital design. People don't only use technology while sitting comfortably behind a desk. They use it while dealing with illness, financial uncertainty, loneliness, professional pressure, or personal crises. And in my work as a paramedic, I have experienced and or I can imagine how critical well-designed digital systems become or will become when every second counts. In those moments, having the right information at the right time is not just a matter of convenience — it can save lives. Whether we realize it or not, we increasingly design for these moments as well.

What AI Can Simulate—And What It Cannot Replace

One of the most important lessons I have learned through psychosocial emergency care is that helping people is rarely about having the perfect answer. Very often, it begins with something much simpler: being present, listening carefully and giving someone enough space to regain orientation before looking for solutions together.

Modern AI can imitate many of these behaviors remarkably well. It can communicate with empathy, ask thoughtful questions and explain complex topics in ways that feel natural and reassuring. In many situations, that can be genuinely helpful. At the same time, it is important to remember what AI actually does. It predicts language. It does not experience the situations people are going through. It does not carry responsibility for the outcome, and it cannot truly share another person's grief, fear or uncertainty. That difference may become one of the most valuable reminders of the AI era. The more capable intelligent systems become, the more meaningful genuine human presence may become as well.

AI Literacy May Become the Most Important Design Skill

For decades, good User Experience was largely about reducing friction. Designers worked to make products easier to understand, simpler to navigate and faster to use. Those principles remain just as important today. But artificial intelligence introduces another responsibility. People do not only need systems that are easy to use. They also need systems they can understand.

This is where the idea of AI literacy becomes increasingly important - as I see it. It is not about teaching everyone how machine learning works or how to build AI models. It is about helping people develop the confidence to ask better questions, recognize uncertainty, understand limitations and know when AI deserves their trust—and when it does not. Good design should never encourage blind trust. Instead, it should support informed trust by making both the strengths and the limitations of intelligent systems visible. The best AI experience is therefore not the one that makes people dependent on artificial intelligence. It is the one that helps them remain thoughtful, capable and confident in their own judgment.

Designing More Than Interfaces

Artificial intelligence is changing the role of design itself. For many years, designers primarily created interfaces. Today, we increasingly design conversations, decision-making processes and intelligent systems that accompany people throughout their everyday lives... Every recommendation influences attention. Every interaction shapes expectations. Every interface communicates what deserves trust and what does not.

Whether we intend it or not, every design decision has the potential to influence how people think, behave and make choices. That makes our profession more than a creative discipline. It makes it a responsibility toward the people who use the systems we build.

The Future Belongs to Those Who Understand People

I do not believe the most influential designers of the next decade will simply be the ones who know every new AI tool. Technology evolves quickly. Today's tools will eventually become tomorrow's standard. The designers who will make the greatest difference are those who understand people. They understand psychology, communication, ethics, trust and human vulnerability. They know that behind every interface is a person with experiences, emotions, memories and expectations that no model can fully understand.

Perhaps that has always been the real purpose of User Experience. Not simply creating better interfaces. But creating better relationships between people and technology. Because in the end, design was never really about software. It never started with the screen. And it will never end there. It has always been about people.

Against design system federation

Design systems operate under one of the following governance models: centralised, federated, or hybrid. All approaches have different benefits and drawbacks, swaying the decision-making scales depending on organisational priorities, maturity, size, and resourcing. Not all decisions are made the same, as one of these models stands to upend what design system teams care about most: cohesion, consistency, and a high bar for excellence. Yes, I’m talking about federated design systems.

A federated system (also known as decentralised) operates with no centralised ownership. Instead, it relies on feature teams maintaining it, most often as a side-track to delivery and bug fixing sprints. Federation is the least favoured design system model, with only 13% of teams working within that framework, based on the latest ZeroHeight Design System Report (up from 9% a year prior).

Interestingly, How We Document, their first iteration of annual reporting, showed the highest level of dissatisfaction among the federated cohort, pointing to possible challenges with that model. While these surveys might not be fully representational of the design system practice, it’s a signal that teams are consciously steering away from federated governance. And there are good reasons for caution.

Why federate now?

What if federating is a panacea to the most pressing tech landscape challenges? In the past, I’ve seen federation poised as a remedy to two top concerns.

Reclaiming resources to remedy organisational failures

The interest rise in federation is a byproduct of mass layoffs exacerbated by “AI” hype. Just this year, the tech layoffs tracker reported 226 companies letting over 120,000 employees go. And that’s only the layoffs we know about. Tech has been scrambling to offset faltering revenues, more discerning VCs, lack of product-market fit, and peak Covid over-hiring by shedding headcount (where most “savings” come from).

When the time comes to decide who stays and who goes, foundational-level teams are often the first getting axed (make it make sense). The death of design has been proclaimed for several years straight, and classical, web platform-oriented front-end has been struggling against the false appeal of React and Next.js’s hey-we-just-rewrote-CSS-in-JavaScript “innovation”. Not mentioning performance or accessibility, which always fought an uphill battle for interest, funding, and care.

The skills that are the backbone of design systems (and lasting product design) are now first to go. By federating, people can be rerouted to feature streams (which design systems always compete with for resources) or let them go, while maintaining a vague impression that design system work still matters. After all, federation makes it so democratic.

Maximising “AI” productivity illusion

Probabilistic automation (“AI”) adds another enticing narrative for federation. If we believe that models bring significant productivity gains, and can reliably output any design system assets (especially components), a federated model is now suddenly supported by as many software manipulators as our budget can afford. Whether the output is erroneous, its quality acceptable, or it fits into the system is another story (often in these cases, velocity > quality).

Outside manipulating an existing system, models can be driven to generate design systems from scratch. Often popularised front-end frameworks, such as Tailwind or Shadcn are then used as a base for lightweight, on-brand theming. Big tool players (Figma Make, Claude Design) already built in these capabilities with a scattering of open source and paid tools available. All resulting in the spreading sameness of product UIs. But hey, let’s productivitymaxx.

Echoing Nathan, “(federated design system) is never pursued first and never without central investment.” Federation is a reaction to structural issues. Transitioning to this falsely legitimate governance model brings damage to systems, user experience, and team morale. If something sounds too good to be true, it probably isn’t, but it doesn’t stop organisations from pursuing alluring theories.

Failed promises of federation

Everyone will contribute

Centralised and hybrid design systems often struggle with soliciting contributions. By opening up the system, there’s an assumption each feature/focus team will default to evaluating their work through the systems’ lens, and subsequently contributing reusable pieces. They won’t.

Teams are always stretched thin, buckling under the pressure of their backlogs. Adding more responsibility without resourcing, specialised knowledge, and support is at best reckless, and malicious at worst. With odds stacked against genuinely willing contributors, designers and engineers duplicate solutions outside the system to suit their needs, promising further consolidation that never happens.

In my experience as a design system leader guiding and supporting numerous contributions, feature teams were most happy if the design system folks addressed their needs without them directly contributing—they’re happy helping drive direction, but have no capacity to do the work within a stretched environment.

Every contribution meets the bar

Another barrier that makes universal contributions scarce is the required specialised knowledge. Not only the awareness of the systems' current state (and future direction), but also the ability to make infrastructure-level decisions. While organisational context might be easier to gain, designing and building architectures (no matter if it’s code, design, or content) require in-depth knowledge and often, seniority.

Design systems have a wide-reaching impact radius—contributions often have to meet multiple requirements: be genuinely needed, be generic enough to be highly reusable, leverage design tokens, follow design and code prop modelling guidelines, meet accessibility regulations, and that’s just the top of the mountain. One of the most common frustrations of contributors is misunderstanding of the quality bar, and why it’s vital to uphold it.

Federation can obscure this issue by changing how contributions are reviewed or lowering the expectations for successful addition. While the latter might decrease frustrations and enable artificial system growth, what you’re growing is substandard, increasing future maintenance cost and eating at UX cohesion. There’s a reason why design system practitioners say no more often than yes.

Ownership is democratic

Theoretically, diffusing ownership of a design system could make it more equitable. Contributions become freer as all designers own the system—no more pitches and difficult conversations where the maintaining team pushes back. This ideal falls apart quickly when meeting the reality of a leadership vacuum and reinforcement of existing structures of power.

“Where everyone is responsible, no one is really responsible”, says Albert Bandura, and he’s right. Diffusion of responsibility manifests itself at workplaces regularly—the larger the group, the easier it is to forgo accountability and rely on someone else (who?) to address issues. Everyone quickly becomes no-one, and the critical work of maintaining the health and direction of the design system stalls. Without dedicated ownership, the system collapses into chaos and growing debt.

As expertly explained by Amy Hupe, systems also enforce existing inequalities, making equitable distribution of power challenging. Not all contributors will face a level playing field under any governance model, even more so with hazy ownership. Seniority, age, race, gender, and other intersectional axes will grant and take power away. What’s advertised as a democratic dream, ends up more confusing and exclusionary.

Time to value is cheaper

Federation is a cost-cutting measure. With more people working in the feature streams with design system work only done when absolutely needed, any organisation can deliver customer value with spending fraction of the cost. In an adverse economy, re-allocating people to what tech companies see as most valuable (more features! more scale!) will always take precedence over system maintenance. What’s cheaper long term, will come back with high interest later.

To realise the savings, we’d have to assume a high rate of contributions and solution reusability. Both of which are markedly more challenging under the federated model, making it highly unlikely. Enabling high velocity with design system infrastructure requires a mature practice, smooth cross-functional collaboration, and deeply researched, scalable solutions—ingredients organisations nearly never get right.

If we forget maturity and let go of firm guardrails, velocity can be obtained by allowing snowflake solutions to get into the system. What previously belonged to the depths of a Figma/GitHub file tree, now exists in the system; therefore, feature work is produced with the established process. Bam, now we have savings, and 1,500 components.

Federation is an aspect, not a model

Federated model requires organisational perfection. The odds are stacked against it from the beginning, fuelled by damaging myths leaders fall for. Federating demands more overhead and operational diligence than any centralised team would, leaving chaos in their wake when federated eventually comes back around to centralisation (I’ve seen this happen). Design system is now set aback multiple years of janitorial work to bring it back to consistency.

While federation isn’t successful standalone, I’ve seen it work effectively as an aspect of centralised governance (forming the currently most popular, hybrid approach). Hybrid models support ongoing maintenance and growth, while soliciting contributions from feature teams. Design system practitioners focus on their core competencies, while getting feedback from individuals who know their respective areas best.

Treating federation as an aspect of a hybrid model doesn’t solve the issues described above, but it does lessen their impact. Managing contributions remains a challenge across all governance types. So does democratising ownership and distributing power. Measuring just how much a system enables delivery remains tricky, too. But at least, we aren’t setting up teams for failure. Nor are we trading team morale for failed promises.

Sushanth Raman announced the launch of Custom Models for supply chain teams.

This post looks at factors that organizations should adopt to be smaller, faster, and deliver outsized value to customers.

Browse a wall of proven ad creatives from top brands, drop in your brand, and get an on-brand video or static ad in minutes.

Apple's AirPods and Apple Watch both overcame early ridicule by proving genuinely useful in everyday life, but the rumored camera-equipped AirPods face a different challenge: concerns about privacy and social acceptance rather than just unconventional design. While Apple has a strong track record of turning skepticism into success, the new AirPods will need to demonstrate clear, hands-free AI benefits while convincing both wearers and those around them that the cameras can be trusted.

Designers should stop undervaluing in-house work and instead showcase the business problems they solved, the constraints they worked within, and the measurable results they achieved. Rather than waiting to build a perfect portfolio, improve existing projects incrementally with stronger storytelling, updated visuals, and small enhancements, making steady progress in short bursts that fit around a busy schedule.

Glaze is a Mac app that transforms your entire display with over 50 real-time visual effects—from CRT monitors to VHS tapes—while also offering productivity and accessibility modes.