How Uber built a software factory for agentic coding: the MCP gateway and the platform underneath

More than 70% of pull requests at Uber now come from local or cloud agents, and lines of code per engineer has doubled year over year. Uday Kiran Medisetty walks through the six pieces of the ADLC.

The uber agentic SDLC platform gives agents the pieces they need to work safely across a few thousand engineers: a context graph for organizational knowledge, an MCP gateway for tools, an LLM gateway for models, somewhere to run, and governance over all of it. On top of that platform sit the workflows that turn agentic coding into shipped software, carrying a feature from an idea to a merged PR and keeping it maintained with DevOps automation afterward. The workflows are the visible part, and they only work because the platform underneath them is already there.

This piece walks through both layers, using Uber’s own talk as the map. It answers four questions:

• What is an MCP gateway, and why does agentic coding at scale need one?
• What did Uber actually build to let AI agents work safely across a few thousand engineers?
• How do the spec-to-PR workflows and DevOps automation sit on top of that platform?
• Why does the platform, including the MCP gateway and the LLM gateway, have to come first?

The first half covers the platform, one piece at a time. The second half covers the workflows, and where each one reaches back into the platform to do its job.

Start with the platform, not the agents

The platform gives AI agents what they need to work across the software development lifecycle. It does for agents roughly what an operating system does for applications. When you write an app, you do not manage memory or schedule CPU time yourself. The OS handles that, and you get on with the app. Agents need something similar underneath them, to handle context, tools, model access, and safety, so the workflows on top can stay simple.

Uber’s platform is made of six pieces. Most of them are infrastructure ideas you would already recognize, applied to agents rather than people.

Build one context graph instead of querying twenty systems

Of the six pieces, this is the one worth understanding first.

Watching their own traces, Uber saw agents spending time and tokens just finding basic context. Where a service lives, what it depends on, who owns it, what patterns to follow. That information was spread across 20 to 30 systems, and each one needed its own query. The result was added latency and unpredictable answers.

Their fix was to pull how the company actually runs into a single graph. It holds 40 million entries across 150 kinds of nodes and edges. It connects how the mobile apps are built, the backend, and the data lake, along with design docs, Jira, incidents, and bugs, all linked together.

In other words, instead of the agent playing detective across thirty systems every time to work out what a service is and who owns it, they gave it one accurate, connected map of the company to read. Think of it as a wiki that is always current and fully linked, rather than thirty stale pages you have to stitch together yourself.

Uber calls this a context graph. Platforms built for this pattern call the same idea a context lake, and most of the other pieces lean on it. Ask their graph “how many mobility trips in India are paid in cash” and it already knows the concepts, the tables, and the entities needed to write the query. When they run the same task with the graph and without it, they see large drops in tokens, turns, and latency.

Curate skills in a registry, not across random repos

Once engineers can write skills for agents, they write a lot of them, and three problems show up fast. The same skill gets built five times by five people. Finding and configuring them is a hassle. And quality is all over the place.

In other words, a skill here is a reusable set of instructions that teaches an agent how to do one task, like an internal library or a runbook, except written for an agent. Like any library ecosystem with nobody curating it, it sprawls.

To handle that, Uber built a lifecycle around skills. Core and team-specific skills go into one managed registry, now holding 2,500 of them, and everything passes automated lint and review so there is a quality floor.

Discovery and installation are simple. One command finds and installs any skill. And based on what an engineer works on, the right defaults get installed automatically, so the agent usually has what it needs without anyone choosing. They also collect usage traces and run continuous evals, then feed the results back to whoever wrote the skill. Across the fleet that comes to more than 20,000 skill runs a day.

Route every tool through one MCP gateway

An MCP gateway is a single, governed entry point that connects AI agents to the tools and APIs they can call. An agent is only useful because of the tools it can reach, and Uber started with thousands of internal APIs, none of them agent-ready, plus a pile of SaaS tools that each log in differently. Wiring these up created a new cost, because every tool an agent can see eats context tokens before it does any real work.

In other words, an agent has a limited working memory, and every tool description you hand it fills some of it up. Give it fifty tools and it has read a phone book before you have asked your question.

Their MCP gateway handles the setup problem first. An automated crawler turns an internal API into an agent-ready tool with one config change, and SaaS tools like Google, Slack, and Jira go through the same gateway, which hosts them and handles the login handshake.

From there they cut the token cost in stages. First they replaced the pile of tools with a single tool that discovers and calls any of the others on demand, so the agent is not carrying all of them at once. Then they had responses come back in a compact form, so the answers stop eating context. Most recently they added a mode where the agent writes small scripts on the fly for the heaviest cases. Together that work cut their token usage by more than 40% across the fleet, with over 1,000 tools now reachable this way. This is the piece a platform team should copy first if agents keep running out of context, because an MCP gateway is where tool sprawl either gets controlled or quietly breaks your agents.

Send every model call through one LLM gateway

An LLM gateway is a single, governed entry point that every model call passes through. If you let thousands of engineers call models directly, you lose control of three things at once. What data leaves your network. How much delay your safety checks add. Who is spending what. The LLM gateway is how Uber keeps hold of all three, and it is the piece that makes the other five behave as a platform, because it is the point where every request is checked and accounted for.

Uber routes every model call, internal and external, through a single gateway that speaks the standard model APIs. Behind that one door sits a short chain of checks. Identity and auth come first. Then a step strips more than 20 kinds of PII, so nothing sensitive leaves the network. After that, an “AI guard” of five smaller models handles safety and policy.

Their hard rule is that all of this finishes in under 100 milliseconds, so the guardrails never become the reason a request is slow. Every call is also tagged to a project, a user, and a team, so spend and behavior can be traced in real time.

In other words, this is the AI agent governance layer. AI agent governance is the set of controls that keep what agents can do, see, and spend inside policy, and here it takes the same shape as the API gateway already sitting in front of your services checking auth and rate limits. Applied to every model call and given a strict latency budget, it means nobody bothers routing around it. Uber’s governance layer now carries over 100 million model requests a day across 800-plus projects. Without something like it, agents at scale become a compliance and cost problem that tends to surface only once it is expensive.

Keep environments warm so agents start in seconds

Agents need somewhere to run, and their requirements are not the same as a person’s. An agent needs an isolated environment that comes up fast, runs for a long stretch, can be spun up in bulk, and exists at every site.

Uber pre-provisions Kubernetes pods they call balloon pods. When an agent needs an environment, it grabs one that is already warm. The repos are snapshotted and the code search index is already built, so it is working within seconds.

In other words, instead of building a fresh environment every time an agent wakes up, which means cloning a huge repo and indexing it first, they keep a shelf of ready-to-go machines with the code already loaded. It is like grabbing a rental car that is already fueled with the route set, rather than one you have to prepare yourself.

Give everyone one assistant across every surface

The last piece packages the other five for people to actually use. Their assistant, Cortana, has the context graph, the skills, and the tools plugged into it, and it shows up on Slack, the command line, and the web.

Anyone can ask it something, and it will check the context graph, run a skill, and read code in any repo to answer. Teams can also personalize it with their own skills and prompts wired into a team channel, so it works like a member of that team. In one month they saw 300 team-specific versions and more than 20,000 sessions a day.

That covers the platform. On its own it does not ship anything. It is the layer the delivery workflows run on, and those workflows are the second half of the talk.

Then build the factory workflows on top

With the platform in place, Uber can string its pieces into workflows that carry a feature from start to finish. Each of the workflows below leans on several of the platform pieces, which is the reason the platform has to exist before any of them.

Take a feature from spec to prototype in one session

Their walkthrough started with an idea kicked around in Slack. Someone tagged the assistant in, and things moved quickly from there.

Backed by the context graph, the assistant helped size the opportunity, then moved into a web session for deeper research. From there it generated two mockup variants for an A/B test, and reasoned about which existing screens and backend services the team could reuse. Work that used to take weeks of alignment compressed into a single session and a prototype.

None of that runs without the platform. The research came out of the context graph, the mockups and the reasoning about existing code came from skills, and the whole thing ran through the assistant.

Hand off to an AI coding agent, but stop before CI

The prototype went to Minion, one of Uber’s AI coding agents. Agentic coding is software development where an agent takes on a whole task, writing and changing code across a codebase with limited human steering, rather than only suggesting the next line. Minion is Uber’s version of that, and it runs in one of those warm environments so it can change backend and frontend together.

One detail is worth calling out. Minion stops at a draft PR and does not push to CI. Uber found that pushing straight to CI was fine for small cleanup work but wasteful for real features, because it hammers shared CI before anyone has confirmed the feature even works. So they validate first.

Move your checks into the inner loop

That validation happens in the inner loop, before CI. In other words, the inner loop is everything that runs on the agent’s own machine before it pushes, and the outer loop is everything that runs after, in shared CI.

Uber moved several checks that used to live in CI back into the inner loop:

• Static analysis, the same lint-style checks as before, just run earlier.
• Visual validation, where a skill boots a simulator, takes a screenshot, and compares it against the design.
• Integration checks, which stand up the backend in staging so the front end and back end can be tested together.

Every one of those checks is a skill from the registry, running in a warm environment, using the context graph to know what “correct” looks like. The idea is to have the platform do the pre-flight, so shared CI only sees work that is already likely to pass.

Let CI heal itself and show its work

Once the inner loop passes, the change reaches CI. There, self-healing CI fixes many failures on its own. This is DevOps automation aimed at agent-scale output: when agents open far more PRs, the pipeline has to repair routine breakages without a human in the loop. Code review is split the same way, with a smaller, faster model reviewing on the machine and a bigger, slower model doing a deeper review in CI.

Because a human is now reviewing a diff an AI coding agent wrote, the PR arrives with a table listing every check it already passed, screenshots included.

In other words, instead of asking a reviewer to trust a raw first draft, the PR shows its work, the way you would trust a change more if you could see green checks and a test run attached. The reviewer then spends the time on whether the change is a good idea, rather than on catching basic mistakes.

Run maintenance as one managed loop

More code means more to maintain, so Uber treats maintenance as its own workflow, and it is some of the clearest DevOps automation in the talk. You enroll a service into maintenance skills, like one that cleans up a feature flag and removes the losing variant of an A/B test once it is decided.

The important property here is that the loop is managed centrally, which is AI agent governance applied to recurring work. Rather than let thousands of loops run all over the company where nobody can see or stop them, there is one place you go to set a loop up. It runs on Sunday when CI has spare capacity, and it caps how many diffs land on an engineer’s Monday.

In other words, instead of every team quietly setting up its own cron job to have an agent change things on a schedule, which is a good way to wake up to chaos nobody can trace, there is one controlled surface for all of it, with limits and a schedule you can reason about.

The loop also feeds itself. When those diffs get comments and either land or not, that becomes useful data for improving the skill. And once a month, Uber mines its incident reviews for new maintenance skills to roll out across every service.

Build the platform first

The honest note Uber ended on is about where the constraint sits now. With this much code moving through the factory, the strain shows up in CI capacity, in how many experiments they can realistically run, and in decisions about what to actually build. As one of them put it, the question is no longer whether they can build something. They know they can. It is whether they should.

That kind of problem is only available to a team that has already built the platform. Every workflow leans on it:

• Spec-to-prototype needs the context graph.
• The validation loops need the skills registry and the warm environments.
• Every action needs the MCP gateway, and every model call needs the LLM gateway.
• The maintenance loop needs AI agent governance to stay bounded.

Without the platform underneath, the factory is a set of scripts that break the first time a repo moves or a model changes.

So if you are planning to let AI coding agents write a real share of your code, the platform is where to start. The workflows are the part you will want to show people, but they sit on top of a context graph, an MCP gateway, an LLM gateway, environments, and a way for people to reach all of it. Uber built that groundwork first, and the numbers everyone is quoting are what it produced.

Where Port fits

Uber built all six pieces in-house, which very few teams have the scale to do, and closing that gap is what Port is for. Port gives you the same foundation without building it from scratch: a context lake, an MCP hub, agent and skills management, workflow orchestration, and governance across the SDLC. On top of that foundation, teams run solutions like autonomous ticket resolution, self-healing incidents, and engineering intelligence. Companies including GitHub, dLocal, and PwC already use it to move from manual to agentic engineering, and you can read how in their customer stories.

Frequently asked questions

What is an MCP gateway?

An MCP gateway is a single, governed entry point that connects AI agents to the tools and APIs they can call. It standardizes authentication, hosts internal and third-party tools as MCP servers, and reduces the context tokens each tool consumes. Uber’s MCP gateway made over 1,000 tools reachable and cut token usage by more than 40%.

What is an LLM gateway?

An LLM gateway is a single, governed entry point for every model call an organization makes. It handles authentication, redacts sensitive data, and applies safety checks, then attributes spend to a team, usually within a strict latency budget so it does not slow requests down. Uber’s LLM gateway carries over 100 million model requests a day.

What is agentic coding?

Agentic coding is software development where AI agents take on whole tasks, writing, changing, and validating code across a codebase with limited human steering, rather than only suggesting the next line. It depends on a platform that gives the agent organizational context, tools, and governed model access.

What is DevOps automation?

DevOps automation is the practice of handing repetitive software delivery and operations work to automated systems instead of people, including CI fixes, migrations, and routine cleanup. At Uber it runs at agent scale, covering more than 250 automated migrations and self-healing CI that repairs pipeline failures on its own.

What is AI agent governance?

AI agent governance is the set of controls that keep what AI agents can do, see, and spend inside policy. In practice it includes routing model calls through a governed LLM gateway, attributing every request to a team, redacting sensitive data, and bounding autonomous work so it stays observable.

Credit: This writeup is based on a talk given by two Uber engineers, Uday Kiran Medisetty and Adam Huda, who walked through the platform and then the end-to-end feature flow in detail. The numbers, the architecture, and the design calls are all theirs. This blog summarizes what they shared so more teams can learn from it.

Large language models often take actions running on one computer (via an agentic harness such as Claude Code or Codex), however the LLMs’ responses to prompts are computed on a different computer with GPU access. Could a malicious LLM gain control of the host machine where its weights are loaded? Such a machine is a high-value target: it has sufficient compute to run a frontier LLM, offers easy access to the LLM’s weights, and has privileged access to other computers in the datacentre compared with a generic computer on the internet.

This essay explores how easily a malicious LLM could take control of the host machine. The primary attack considered here involves the LLM emitting a token sequence whose semantic meaning is irrelevant but that exploits a vulnerability in the software that loads an LLM onto GPUs, runs the LLM to generate output tokens, and parses those tokens into responses.

How could an LLM execute code on the host machine?

Like any program, inference engines like vLLM or SGLang may contain exploitable bugs. Because the LLM controls the tokens passed to the inference engine, a malicious LLM could therefore emit a sequence of tokens that a poorly written inference engine mistakes for code or instructions to execute rather than data to return to the user.

But surely all inference engines are robust pieces of software and this would never happen, right?

vLLM previously used eval() on tool-call parameters

CVE-2025-9141 was an arbitrary-code execution bug in vLLM’s XML-based tool parser for Qwen3 Coder. The parser passed almost every tool-call argument to eval(), allowing the LLM to execute arbitrary code on the host machine. Gemini automatically analysed the PR that introduced this bug and correctly flagged it as a critical security vulnerability. Despite that warning, the lead maintainer of vLLM force-merged the PR, writing:

Unfortunately, parsing an arbitrary token sequence into a fully fledged chat (with user turns, assistant responses, tool calls, and so on) is not trivial, and the exact process often differs between LLMs. This complexity creates more opportunities for bugs that could permit arbitrary code execution on the host machine.

vLLM and SGLang are complex, and bugs are common

Modern inference engines do more than map token sequences to strings. vLLM’s documentation lists support for more than 200 model architectures, and its examples directory contains about 35 Jinja chat templates. Modern inference engines parse many chat formats, and slightly misspecified parsing logic result in an LLM’s output being interpreted as code to execute.

In this vLLM issue, a user was discussing how LLMs reason with MiniMax-M3, and the LLM emitted the string <mm:think>. vLLM mistakenly parsed this plain string as the start of a reasoning block. So instead of:

Response: I'll echo exactly what you said: <mm:think>\nThere, how was that?

vLLM parsed this as:

Response: I'll echo exactly what you said:

Reasoning: \nThere, how was that?

This is a fairly harmless parser bug, but it demonstrates that inference engines do more than convert tokens to strings and concatenate them. They are complex systems under constant iteration and their developers are under a lot of pressure to make them as fast as possible. These factors increase the risk that a malicious LLM could turn a parser bug into arbitrary code execution on the inference host.

Vision and audio tokens might increase the attack surface

Multimodal architectures allow an LLM to respond with images or audio as well as plain text. Turning a model’s audio or visual output into usable media is probably more complicated than decoding text tokens. However, as far as I can tell, current multimodal LLMs generally emit constrained media tokens rather than arbitrary file bytes. A model-specific decoder turns those tokens into pixels or waveforms, which are then encoded into files. This makes classic malformed-file exploits against software such as ffmpeg or media viewers less directly accessible to the model, although the additional decoders, encoders, and native kernels still increase the attack surface.

I do not currently see multimodal output as a major route to host compromise. However, it offers much higher bandwidth than text alone, and future inference engines may optimise these media-generation pathways in ways that make them easier to exploit. I also do not know how proprietary multimodal models represent image and audio output; their methods may carry different risks.

How likely is an LLM to discover and exploit inference engine vulnerabilities?

Somewhat likely? I’m unsure. Discovering a useful vulnerability is probably the harder step. The sequence of tokens required to exploit it might be quite unusual, but that does not make the vulnerability impractical to exploit. Given the right context (e.g. an LLM exploring the vLLM codebase and discovering a vulnerability in the process), I’d expect a frontier LLM to be able to emit the tokens required to exploit it.

Tool use could make exploitation reproducible

Once an LLM discovers an exploit token sequence, it could store that sequence, or instructions for recreating it, in files, filenames, or URLs likely to enter another LLM’s context. The exploit would then act as a form of persistent prompt injection: an agent might trigger code execution on the GPU host merely by listing a directory or reading a file.

Inference engines are an attractive target for power-seeking LLMs

I believe hope that OpenAI, Google, and Anthropic have security teams that red-team the software they run internally. But as open-weight LLMs become more powerful, we’ll have more LLMs running on bleeding-edge inference engines that have received less scrutiny. This increases the chance that a malicious open-weight LLM will encounter and exploit a vulnerable inference engine.

Another attack vector may emerge as LLMs are increasingly tasked with writing or modifying the inference engines that run them, usually to improve performance. A malicious LLM could use that access to plant a backdoor. C++ and CUDA components of the inference pipeline seem like especially attractive targets: the LLM could introduce an out-of-bounds memory-access vulnerability that enables arbitrary code execution on the GPUs or on the CPU host that controls them.

How do we defend against this?

Beyond red-teaming inference engines for vulnerabilities, a few other measures might help:

• Run the GPUs and token parser on separate computers. The GPU host would emit only logits. A second host would sample tokens from those logits, parse the tokens into chat messages, and forward the messages to the agentic harness. This separation would limit a parser compromise to the CPU host rather than the GPU host.
• Restrict the permissions granted to GPU hosts and treat all data they emit as untrusted.

Why it matters

AI labs increasingly compete on the cost and availability of compute. Salek gives Anthropic experience building a mature chip program while it remains a major customer of Nvidia, Google and Amazon.

Anthropic has hired Amir Salek, the engineer who founded Google's custom-chip program and ran its Tensor Processing Unit business, as the Claude maker starts building an in-house silicon operation. Salek will join Anthropic's compute team and report to its head, James Bradbury, Anthropic confirmed in a Bloomberg report published on August 21st.

Salek brings Anthropic the specific experience it needs: building a semiconductor organization inside a software and infrastructure business. He delivered the first seven generations of Google's TPUs before leaving in 2022, according to Bloomberg. Before Google, Salek founded and led Nvidia's system-on-a-chip design organization. He holds a doctorate in computer engineering and computer science from the University of Southern California.

The hire also brings Salek back to chip development after four years as an investor. He joined Cerberus Capital Management in March 2022 as a senior managing director and a partner at Tracker Ventures, a Cerberus platform investing in semiconductors, AI, edge computing, aerospace and other deep-technology sectors.

Anthropic imports Google's chip-building playbook

Anthropic confirmed earlier in August that it was recruiting a custom-silicon team, including engineers with experience taking semiconductor designs through production. Salek's arrival turns that hiring plan into a serious hardware effort. Google recruited him to establish a custom-chip capability and then deployed the resulting processors across its data centers and cloud business. Anthropic is asking him to help repeat that organizational feat for workloads built around Claude.

A personnel move still leaves Anthropic several steps from deploying a processor. Designing a competitive AI accelerator requires architecture, verification, software, networking, packaging, manufacturing and years of iteration. Salek's record matters because it extends beyond a first chip: he oversaw repeated generations of silicon and the infrastructure required to operate them at data-center scale.

Anthropic already works closer to the hardware than a typical software customer. In 2024, Anthropic said its engineers were writing low-level kernels for Amazon's Trainium accelerators, contributing to the AWS Neuron software stack and working with Amazon's Annapurna Labs on future chip generations. That work gives Anthropic experience optimizing Claude for specialized processors even before its own silicon reaches a data center.

Own chips, alongside everyone else's

Anthropic's silicon effort does not amount to a clean break with its suppliers. Anthropic currently trains and runs Claude across Nvidia GPUs, Google TPUs and Amazon Trainium chips, describing the mix as a way to assign workloads to different hardware and reduce dependence on any single platform. Amazon remains Anthropic's primary cloud and training partner.

Those outside commitments are still expanding. In October 2025, Anthropic said it planned to use as many as one million Google TPUs, with well over a gigawatt of capacity expected during 2026. In April, Anthropic announced another agreement with Google and Broadcom for multiple gigawatts of next-generation TPU capacity beginning in 2027. Anthropic is therefore building an internal option while continuing to reserve enormous quantities of competing hardware.

That overlap is the strategy. Custom silicon could give Anthropic tighter control over supply, power consumption and the cost of serving Claude, while Nvidia, Google and Amazon provide the capacity Anthropic needs before an internal design is ready. Salek's hiring gives Anthropic an executive who has already built the most established alternative to Nvidia's general-purpose AI accelerators. The next test is whether Anthropic can turn that experience into a repeatable chip program rather than a single expensive experiment.

Data centers have become the largest driver of a surging electricity demand that is straining US power grids. But the AI data center boom has also accelerated investment in a technology that could provide a silver lining for everyone—solid-state power transformers that replace industrial-age technology with modern power electronics.

Power grids currently rely on conventional transformer technology that is painstakingly assembled by hand and has a fundamental design dating back to the 1880s. Two copper wire coils manually wound around a steel core create electromagnetic fields that help step up voltage levels of alternating current electricity for long-distance transmission or step down voltage levels for the electricity use of homes and businesses. The largest power transformers cannot be mass-manufactured but are instead custom-built for each utility company’s electrical substations.

Manufacturing constraints, coupled with the scramble to upgrade US power infrastructure, have meant utility companies and other customers must wait up to several years for delivery of new power transformers. That not only hinders power grid infrastructure expansion needed to support growing electricity demand, but also delays the process of replacing aging power transformers.

By comparison, solid-state transformers rely on high-frequency semiconductor switching to perform voltage conversions, and can be mass-manufactured using semiconductor materials like silicon carbide. Such transformers are physically smaller and lighter than conventional transformers, have modular designs that enable easy upgrades or replacement of parts, and can perform as all-in-one power electronic devices by handling multiple tasks.

Tech companies building the largest AI data centers are interested in solid-state transformers because they are embracing direct current (DC) power architectures to support server racks packed with energy-hungry AI chips. Solid-state transformers can directly convert alternating current (AC) power from a local grid’s distribution network into the DC power that such data centers require—all without the need for a separate electrical device to perform that AC/DC conversion.

“It’s kind of this one magic box that eliminates a lot of the infrastructure and also provides one control location that eliminates a lot of the interoperability challenges that you may see in a traditional data center, where various components within the data center are trying to regulate the same thing,” said Srdjan Lukic, a professor of electrical and computer engineering at North Carolina State University. “Now you have one conversion stage outside the data hall and then you just go straight to the rack.”

From “killer application” to mass adoption

Data centers have become the “killer application for solid-state transformers right now,” Lukic told Ars. Several US companies, including Amperesand, Heron Power, and DG Matrix, have collectively raised more than $280 million in funding over the past year to commercialize solid-state transformer technology.

Solid-state transformers could also greatly reduce the amount of copper and other materials needed by data center projects, while their smaller physical footprints allow data center developers to do other things with the available space, Lukic explained.

In the long run, successful commercialization of solid-state transformers could even help ease the broader supply chain shortage affecting power transformers. That would make transformers more readily available for power grid upgrades and expansions beyond data center projects.

“There are relatively few specialized companies that manufacture [conventional] transformers, while solid-state transformers are like an electronics device,” Lukic said. “It completely opens up the space for who can play in the transformer space, and also opens up where transformers can be manufactured.”

The same benefits of solid-state transformers also apply to electric vehicle charging’s similar reliance on DC power. Lukic and his colleagues recently demonstrated how a solid-state transformer connected to a live grid power line could handle up to 1 megawatt of power when supporting the charging of an electric vehicle battery—the solid-state transformer performed the necessary step-down in voltage while also doing the AC to DC power conversion.

The NC State demonstration is taking place at a power delivery laboratory belonging to the nonprofit Electric Power Research Institute in Lenox, Massachusetts, and is the culmination of a collaboration with the New York Power Authority that began in 2018. The solid-state transformer—about 1×1.5×2 meters in size—has been sitting in a shipping container at the site since May 2026 and is scheduled to return to NC State in September after months of testing in summertime conditions.

“It looks like a big transformer box with a slightly different form factor, a big blob of what looks like steel,” Lukic said. “It replaces three blobs of steel with one blob of steel and removes a lot of the wiring and trenching that you would typically have to do for an electric vehicle application.”

The solid-state transformer has a modular design with an active front end interacting with the power grid, an AC/DC converter, and a high-frequency isolation transformer that either steps up or steps down the voltage. The crucial technology was the custom-made isolation component that can sustain the “full stress of the grid, the full distribution voltage” across the relatively compact device, Lukic explained.

Engineering and commercialization challenges still lie ahead for the technology. But Lukic is hopeful that data center adoption of solid-state transformers can help “derisk” the technology for mass adoption beyond the tech industry’s AI infrastructure buildout.

“Beyond data centers, we can think about electric vehicle charging in densely populated areas,” Lukic said. “A lot of loads within our homes are now DC, so having that ability to distribute DC in modern homes will have some significant benefits.”

I have been probably obsessed with two things in the last few years: Nix as a tool to explore innovative ideas that require the capability to rebuild the world and replacing ELF with SQLite as an executable format. You might have noticed that these two ideas are well suited to each other.

I explored the idea during my PhD thesis but found feedback from others unmotivating. Radical ideas are hard to sell, as you are working against the inertia of the established solution.

One of the end results of that exploration was sqlelf, a tool that lets you explore an ELF file declaratively using SQL. I wrote a paper, arXiv:2405.03883, that I failed to get published and a follow-up post on querying with it. SELECT name FROM elf_symbols instead of fiddling with readelf and grep. It was remarkably simple by leveraging virtual tables over the ELF: however I found it to be a refreshing improvement to explore the ELF file format. I knew however that there is still something much bigger to be done.

I never let the idea go and with the recent improvements with LLMs, I find it compelling to revisit these ideas to explore further. Specifically, can we replace ELF with SQLite as an executable format? 🤔

Not “a database that describes an executable”, but the actual file you chmod +x and run.

$ file hello
hello: SQLite 3.x database, application id 0x53454c46, user version 1

$ ./hello
Hello, world!

$ sqlite3 hello 'SELECT soname FROM ldd'
libc.so.6

I developed a pretty fleshed out prototype. It is called SELF, the Structured Executable & Linkable Format, because I am unoriginal. It is on GitHub if you are interested. I’m surprised about all the interesting things that fall out of this idea.

§ELF is a database that refuses to admit it

Working through my PhD, I realized something that bugged me. ELF is already a database. It just implements many database primitives by hand, along with a surprising number of data structures for performance, like a bloom filter for symbol lookup.

If you ever have to analyze or parse ELF, the kernel, ld.so, binutils, LIEF, goblin, readelf, you are re-implementing the same parser over and over again. Every producer re-implements the same serializer.

The format itself is incredibly terse, designed for a world where disk space and network bandwidth was at an extreme premium. Modifying the format is hard, you often have to zero out sections and add new ones since it is packed so tightly. There is also no self-describing schema. ELF itself is a very generic format that supports sections of data that by convention are interpreted in specific ways but the format does not enforce it.

SQLite is the counter-example. They are a self-describing format that is extremely stable. It is designed to be extended to support new features without breaking existing consumers and supporting a wide range of queries performantly.

If we were to replace ELF with SQLite, what would fall out and can all of the necessary information be represented in a SQLite database? The answer is yes, and it is surprisingly simple.

§What falls away

A SELF file needs two tables to run: self_meta is the ELF header as key/value pairs and segments is the load image, one row per program header with the bytes in a BLOB:

CREATE TABLE segments (
  id      INTEGER PRIMARY KEY,
  type    TEXT NOT NULL,
  offset  INTEGER NOT NULL,
  vaddr   INTEGER NOT NULL,
  filesz  INTEGER NOT NULL,
  memsz   INTEGER NOT NULL,
  r INTEGER, w INTEGER, x INTEGER,
  align   INTEGER NOT NULL DEFAULT 4096,
  content BLOB
);

A single table for the symbol table replaces many of the ELF sections and the .gnu.hash index. It is a single table with a single index:

CREATE TABLE symbols (
  id      INTEGER PRIMARY KEY,
  name    TEXT NOT NULL,
  version TEXT,
  value   INTEGER,
  size    INTEGER,
  type    TEXT,
  bind    TEXT,
  defined  INTEGER NOT NULL,
  exported INTEGER NOT NULL
);
CREATE INDEX idx_symbols_name ON symbols(name, version);

Our capability to include an index is equivalent to .gnu.hash and .hash in ELF, but it is a proper b-tree index maintained by SQLite instead of a hand-rolled bloom filter.

Surprisingly a lot more falls out as well: .dynstr is gone, because name is TEXT and SQLite already interns strings, symbol versioning is a column, not the .gnu.version_r / .gnu.version_d contraption and there is no need for a strings table.

Other tables exist as well for metadata which exist for tooling: sections, notes, dynamic_entries. Delete them and the program still runs, which means strip(1) is a transaction:

$ sqlite3 hello 'DELETE FROM sections; DELETE FROM notes; VACUUM;'
$ ./hello
Hello, world!

All the tools that operate on ELF files for reading, reduce to queries over the database. Any tool that modifies an ELF file, like strip, can operate on the database within a transaction rather than performing fragile offset surgery: strip is a DELETE and VACUUM. patchelf is an UPDATE.

Any information missing from the schema can be easily exposed via a view. For example, ldd is a query over the needed table, which is a join of the symbols table with the segments table to find the sonames of the libraries needed by the program.

CREATE VIEW exports AS SELECT name, version, type, size FROM symbols WHERE exported = 1;
CREATE VIEW imports AS SELECT name, version FROM symbols WHERE defined = 0;
CREATE VIEW ldd     AS SELECT ord, soname FROM needed ORDER BY ord;

§How does it work?

SQLite reserves a 4-byte application_id at byte offset 68 of its header, for exactly this purpose. We stamp it SELF, so an ordinary SQLite database never matches.

We can now leverage binfmt_misc, the subsystem that allows you to invoke any binary as if it were native. We need only to register the magic to trigger on and an interpreter that will invoke our new file format.

On NixOS the registration is a few lines matching the SQLite magic at offset 0 and SELF at 68.

For now, I have a small tool elf2self that converts an ELF file into a SELF file. It is a simple postFixup hook you can opt into per package on NixOS. The tool reads the ELF, extracts the program headers and symbol table, and writes them into the SQLite database.

self-exec is the interpreter. It is a small C program linked against libsqlite3. Its implementation is remarkably similar to that of ld.so but it fetches the program headers and symbol table from the database instead of reading them from the ELF file. It maps the loadable segments into memory, relocates them, and jumps to the entry point.

Note self-exec has to stay an ELF file. An interpreter that also matches the registration recurses straight into -ELOOP.

§Dynamic linking

Running a static program was quick and easy but boring and unimaginative. The interesting part is dynamic linking, which is where the database shines.

I explored two different ways to do dynamic linking. The first is to keep ld.so and just replace the lookup with a SQL query via glibc rtld-audit interface, to quickly iterate on the design. The second is to replace ld.so entirely with a new dynamic linker that does the entire lookup and binding in SQL.

glibc’s rtld-audit interface lets an audit library intercept every shared object lookup (la_objsearch) before any filesystem search happens, dlopen included. The audit library can then answer the question “which library satisfies this symbol?” with a SQL query instead of walking the RUNPATH and LD_LIBRARY_PATH.

I was curious what a fully SQL dynamic linker would look like, so I prototyped one. It is called self-ld and it is a small C program that implements the dynamic linker entirely in SQL.

§Cost & Benchmark

The two things that often matter when replacing a well-established format are size and latency. How much bigger is a SELF file than an ELF file, and how much slower is it to run?

Size. A SELF file carries SQLite’s b-tree overhead and lands at roughly double the ELF. Stripping them and deleting them is a transaction. A stripped coreutils SELF is 1,794,048 B against the ELF’s 1,768,632 B, that is within 1%.

Latency. I benchmarked various binaries from a 15 KiB hello to a 42 MiB gdb linking 47 libraries.

There is a fixed ~5 ms to open SQLite and start the interpreter, plus a copy proportional to the image. That copy is worse than it looks, because the b-tree pages are not mapped into memory. Two processes running the same SELF binary do not share text pages the way a normally-mmap‘d ELF does, because the bytes are copied out of the b-tree rather than mapped.

§The system is a closure

A SQLite database though need not merely be a single executable. It can be a closure, a single file that contains a program and all of its transitive dependencies. The ldd output of a program is ambiguous: it only lists the sonames of the libraries it needs, not the specific files that satisfy those needs.

We can do the same in SELF by storing the resolved path of each edge in the database:

CREATE TABLE objects (id INTEGER PRIMARY KEY, path TEXT UNIQUE,
                      soname TEXT, kind TEXT, is_root INTEGER);
CREATE TABLE needs (
  object_id     INTEGER REFERENCES objects(id),
  ord           INTEGER NOT NULL,
  soname        TEXT NOT NULL,
  resolved_path TEXT REFERENCES objects(path)
);

self closure packs a binary and its transitive dependencies into one database with those edges filled in. Shared library resolution stops being a guess and becomes a foreign key and ldd becomes a JOIN.

§How far does this go? One file, one userland

I hope you’ve been with me so far, because this is where it gets really interesting. We can go even further and pack multiple closures into a single database.

I pointed self closure at every ELF binary on this system’s PATH: 723 executables, which pull in 400 distinct shared libraries. 1,123 objects, 346,386 symbols, 3,808 dependency edges, all as one SQLite file.

611.9 MiB of database against 644.4 MiB of ELF files. The whole userland, as one queryable file, is smaller than the files it came from. The b-tree cost that doubled a single hello amortises to nearly nothing across 1,123 objects and is roughly 6% over the actual program bytes.

Many common idioms we use in ELF immediately fall out of the database. For example, LD_PRELOAD is a row in a table rather than an environment variable. The preload table is a list of objects to map last, so their exports win. This means that turning LD_PRELOAD on and off is a transaction.

§Where it stands

The format is done and round-trips between ELF and SELF losslessly. The tooling is done and can query, modify, and pack closures. Lookup through SQL works on unmodified glibc programs perfectly and the native-SQL loader works enough to explore it as a possibility for ideas.

The whole thing is at fzakaria/selfdb. nix run .#self-vm boots a NixOS VM where hello is a SQLite database. 🙌

Nix lets us explore radical ideas like this. We can rebuild the world down to the Linux kernel if needed. We need not be constrained by the existing decisions and constraints of the past. We can explore new ideas and see what falls out. I hope you find this idea as interesting as I do.

Doing real physical work requires world models, aka 'large action models'.

NVIDIA Enters Full Production of Groq 3 LPX AI Inference Accelerator Chips, Supercharging Vera Rubin With The Fastest Token Generation Speeds Ever Recorded

NVIDIA's Groq 3 LPX is now in full production, offering big token generation speedups for Vera Rubin platforms in the Agentic AI space.

NVIDIA Dials Up Vera Rubin NVL72 Token Generation Capabilities, Recording 3,400 TPS With Groq 3 LPX AI Inference Accelerators

As part of its Hot Chips 2026 announcements, NVIDIA today announced that its Groq 3 LPX AI inference accelerator chip is in full production. This announcement follows the mass production announcements of Vera CPUs and Vera Rubin servers, marking the robust execution of NVIDIA's AI roadmap.

The Groq 3 LPX racks serve as an extension to the NVIDIA Vera Rubin platform, delivering boosted AI inference capabilities that enable ultra-fast token generation for response-sensitive agentic workloads, as these systems can generate a massive amount of tokens across hundreds or even thousands of inference steps, making fast token generation a critical step for AI factories.

While NVIDIA's Vera Rubin NVL72 is the bleeding-edge solution for Agentic AI, its capabilities can be further bolstered by the Groq 3 LPX solution.

In one demonstration, NVIDIA showcases its Vera Rubin NVL72 platform with Groq 3 LPX pushing out a record 3,400 tokens per second in Artificial Analysis running the Gemma 4 31B open model. With a context window of 100,000 tokens, this was the fastest performance ever recorded on the model.

NVIDIA Rubin GPUs handle large-scale context processing while LPX accelerates latency-sensitive decode workloads. The result is faster, more predictable token generation that helps AI factories deliver responsive reasoning, smoother agent interactions, and greater infrastructure efficiency.

With Groq 3 LPX, NVIDIA also enables agentic AI tasks such as coding to be done within minutes versus hours, offering a 4x boost in response times versus the nearest alternative platform.

“Inference is the growth engine of AI. NVIDIA Grace Blackwell and NVL72 revolutionized large language model inference with an unprecedented leap in performance and efficiency,” said Jensen Huang, founder and CEO of NVIDIA.

“Vera Rubin extends that vision with workload-optimized AI factory configurations designed for the era of agentic AI, advancing the performance frontier with LPX for ultrafast token generation. This transforms how intelligence is produced, delivering another giant leap in AI throughput, efficiency and responsiveness, just as demand for AI computation is accelerating worldwide.”

The NVIDIA Groq 3 LPX solution is also being eyed by AI cloud providers as a solution to the growing needs, giving enterprises and developers access to advanced infrastructure for training, reasoning, and inference at scale. As such, Nebius plans to utilize Groq 3 LPX in its Nebius Token Factory.

“Generation is the phase of inference that determines how responsive an AI system actually is, and that’s exactly what NVIDIA Groq 3 LPX is built to accelerate,” said Danila Shtan, chief technology officer of Nebius. “As the first AI cloud bringing it to production via Nebius Token Factory, we’re making sure every step of an agent’s loop feels instant — through the same API developers are already using, with no migration to a new stack.”

Groq 3 LPX and Vera Rubin, as a combo, are designed for the Agentic AI era, bringing a purpose-built inference architecture designed to maximize responsiveness, throughput, and efficiency, helping power the next generation of AI factories.

The Economics of the Intelligence Frontier

There is a lot of hand-wringing right now over whether frontier model companies like OpenAI, Anthropic, and Google are going to make it when DeepSeek, Qwen, GLM, and others are commoditizing their frontier capabilities.

I think it is entirely plausible that frontier model companies wind up among the biggest companies on Earth while most of the tasks their models perform become commodities. Those outcomes are compatible because AI is not one monolithic market. There may be monolithic suppliers, but there is not one use case. Every task has a different requirement for intelligence, and for many tasks there is a point beyond which more intelligence creates no additional value.

LLMs look a lot like other technology markets with high fixed development costs and rapidly improving capabilities.

One easy way to think about these markets is to plot models by cost and capability. For any particular task, some models simply are not capable enough. Among the models that are, the buyer then cares about cost and latency. What counts as sufficient capability, acceptable latency, or an attractive price changes dramatically by use case.

What capability means depends on the use case. I will use intelligence as shorthand for task-specific capability. There are models that are great at making imagery, models that are great at making videos, models that are great at coding, and models that are good at mathematical reasoning. Intelligence measured by what is a reasonable question, but the answer changes by task.

I somewhat expect the differences in model expression to collapse over time. In particular, I strongly suspect that multimodal input-output models will ultimately win against many task-specific models. So far, adding additional dimensionality to the data appears to improve reasoning overall. We colloquially refer to models that can do all of these things as frontier models because historically only frontier models could. That is increasingly untrue. Multimodality and frontier intelligence are separate characteristics.

Task Intelligence Saturation

For any given task, there are two important thresholds.

Minimum viable intelligence, or MVI. Once a model crosses MVI, the task can be performed. In the same way that humans have a wide variety of performance on a given task, a model at minimum viable intelligence will rarely be the top performer. It may simply be satisfactory. It may hit the absolute bottom threshold of acceptable accuracy. It still ultimately checks the box.

Maximum necessary intelligence, or MNI. This is the point where additional intelligence does nothing for you. The task has reached whatever level of performance and consistency the use case requires. Additional units of intelligence deliver no additional value.

Below MVI, the model cannot reliably perform the task and therefore has little economic value for that use case. Between MVI and MNI, increasing intelligence produces increasing economic value. Above MNI, the marginal value of intelligence reaches zero.

Frontier intelligence matters only for tasks that have not yet been saturated.

Intelligence has diminishing and eventually zero marginal value at the task level.

There are tremendous numbers of long-horizon tasks where we have no strong sense of where maximum necessary intelligence sits. There may be tasks where the true ceiling is phenomenally high. There may even be problems where there is no limit to the marginal gains that can be wrought from increased intelligence. Maybe understanding the universe is one. We don't know.

There are also tremendous numbers of tasks that truly do have a maximum required intelligence. There is a hard limit. Additional intelligence produces no further gains, and at some level it might even produce negative utility through overthinking.

You see this with humans. Really, really smart humans are often the wrong people to hire for simple work because they tend to overthink that work. The same thing seems to be true with LLMs. Give a frontier reasoning model what is fundamentally a simple task and it may sit there spinning its wheels for five minutes attempting to figure out what is hard about it. Sometimes there was nothing hard about it. It just needed to answer.

Even coding strikes me as more bounded than people sometimes assume. I don't think there is an unlimited amount of intelligence required to do coding correctly. It is a relatively bounded and verifiable domain. Certain specific coding tasks obviously need more intelligence, and we are not yet building bug-free software or bug-free systems. I am not totally convinced that we have hit saturation. But I think we may be one or two turns of model improvement away from getting there for a surprisingly large portion of software development. We have effectively solved many coding tasks that are not simple at all.

The number of tasks that eventually hit a maximum on intelligence is probably larger than people think.

Once You No Longer Need More Intelligence

As models become more capable, more and more tasks reach that point. When a subsequent, smarter model gets released, there is little reason to adopt it for a task that has already been saturated. At a given point in time, frontier models are generally more expensive to serve, and often slower. Once you no longer need additional intelligence, you care about cost and, in a lot of instances, speed.

There are other dimensions too. Provisioning convenience matters. Embedded integrations into other workflows matter. Infrastructure matters. There are many ways to differentiate the serving, delivery, and business model around a commodity market that can break a provider out of pure commodity pricing.

Reliability needs a distinction here. Task reliability is already part of intelligence. If one model can perform a task correctly 80 percent of the time and another can perform it correctly 99.99 percent of the time, the second has greater task-specific capability. That improvement lives between MVI and MNI.

Above MNI, reliability means infrastructural reliability. Can the provider keep its uptime? Can it handle peak workloads without downtime or lead times? Can it provide predictable throughput? These remain valuable after task intelligence saturates, but they are properties of the infrastructure and service.

Latency works the same way. Speed can be decomposed into time to first token and tokens per second. For highly real-time use cases, you may care enormously about how quickly tokens start streaming. For other use cases it does not matter at all. Batch offline work might tolerate 24-hour latency. That will be priced accordingly.

The procurement decision at the task level is therefore a choice among capability, cost, and latency, along with the other requirements of the use case. Once multiple models have crossed MNI, greater intelligence ceases to determine the winner.

This Is How Most High-Tech Markets Work

You can already see this structure in semiconductors.

There are enormous categories of chips whose capability requirements saturated long ago. Cars, industrial equipment, appliances, and embedded devices use huge numbers of chips that do not need leading-edge transistor density. In automotive applications, for example, there remains substantial demand for mature process nodes. Customers often have little incentive to migrate these chips to newer nodes because the existing technology is already sufficient and moving carries additional development and qualification costs.

Once the required capability has been reached, the economics depend much more heavily on manufacturing cost, reliability, availability, and scale. Mature-node semiconductor manufacturing has historically carried lower margins, which can make it difficult to justify expensive new capacity even when demand for the chips themselves remains substantial.

I think we are going to see the same thing with LLMs. As more tasks become saturated on intelligence, a growing portion of existing workloads will be served by models optimized around price, latency, and other characteristics rather than maximum capability.

That says very little about absolute token volume. Total token volume is likely to grow enormously, and the share of those tokens served by the frontier versus the commodity portion of the market will be dynamic.

A marginal increase in capability could create a new market that consumes an unbelievable number of tokens. For some period, frontier models could serve nearly all of it. Then cheaper models catch up and take much of that market by optimizing price and latency.

GPUs provide a useful analogy.

GPUs began as processors for graphics. As they became more powerful and programmable, they found increasingly valuable uses beyond simply drawing things on screens. They made much richer games possible, became important infrastructure for parts of the crypto boom, and eventually became the core computational input to modern AI.

AI is now by far NVIDIA's largest market. In its most recent fiscal year, NVIDIA reported roughly $194 billion of Data Center revenue against $16 billion of Gaming revenue. The company attributes the enormous growth in Data Center directly to accelerated computing and AI.

That was not always the case. A technology whose major economic use was once rendering graphics found a much larger market because greater capability and programmability made entirely different workloads possible.

The same dynamic applies to intelligence.

The Frontier Creates Markets

When a new model pushes the frontier, some tasks that previously sat below minimum viable intelligence cross it. Services that were impossible to provide become possible. That creates markets.

Other tasks already sit between MVI and MNI. A more capable model performs those tasks better and therefore creates more economic value.

Over time, competitors reproduce the capability. Costs fall. Eventually multiple models cross the maximum necessary intelligence for a particular task. At that point, additional intelligence ceases to differentiate the product and competition concentrates on the other things customers care about.

The frontier creates new markets by making previously impossible tasks possible. As those tasks become saturated and the same capability spreads to cheaper models, they commoditize.

The Time Profit Model

There is a model in The Art of Profitability called the Time Profit Model. I think LLMs and most high-tech markets follow something very close to it.

When you make a new technological advance, you have only so long to exploit and commercialize it before competition catches up and subsequently collapses price. You can see the same thing happening with models.

At the tip of the frontier, a company can charge relatively high or even stupendously high prices because only one or two players may be able to provide services at that capability tier. Competition is limited, which creates pricing power and allows prices well above marginal cost.

Then competition catches up and those economics deteriorate.

The more successful frontier models are at advancing intelligence, the more capable the commodity models behind them become.

Yesterday's frontier capabilities gradually become available from dozens or hundreds of providers at much lower prices.

This does not mean frontier model companies have bad businesses. Frontier model companies could very well become the largest profit producers in the market even if they eventually account for a minority of token volume.

Their profit comes from scarce capability. A company that is the only provider capable of performing a valuable task has enormous pricing power. A company serving a task that hundreds of models can perform has very little. Less competition produces greater pricing power, and greater pricing power allows prices farther above marginal costs.

Frontier Models and Frontier Model Companies

OpenAI, Anthropic, or Google could serve both the frontier and models many generations behind it. They could distill their frontier systems, operate smaller models, dynamically allocate inference compute, or use their scale to compete throughout the market.

There is no technical law preventing this. I somewhat suspect that the market will support many other providers as well because the innovation company and the lowest-cost producer have historically developed very different habits.

NVIDIA is instructive here, although the analogy needs to be precise. NVIDIA participates across several compute markets, including gaming, professional visualization, automotive, and Data Center. It does not only serve the absolute frontier.

Its extraordinary economics, however, have increasingly come from markets where its technical capabilities are highly differentiated rather than from trying to dominate every low-cost semiconductor use case. Data Center accounted for almost $194 billion of NVIDIA's $216 billion of fiscal 2026 revenue.

Part of that is distribution. Distribution channels are somewhat determinant of the type of organization you build. The organization designed to work with sophisticated customers on the newest and hardest technical problems can look very different from the organization designed to serve enormous volumes at the lowest possible unit cost.

Competition also looks different across those markets. At the absolute frontier, you might have one or two serious competitors. Move sufficiently far down the capability curve and you might have hundreds or thousands of providers competing with you. It is a much deeper, more aggressive knife fight.

Frontier model companies have no obvious intelligence advantage once the task itself has saturated. They may have other advantages. Scale could matter. GPU procurement could matter. Distribution could matter. Infrastructure could matter. They could turn out to be the best companies in the world at distilling their own models.

Those are possible advantages, but the competitive environment is much harsher when many providers can already satisfy the intelligence requirement.

Who Should Operate the Router?

A straightforward interpretation of this framework would have every application dynamically choose the cheapest model capable of completing a given task. I am relatively skeptical that cross-model routing will be quite that easy.

Having built a lot of agentic systems, you generally cannot swap one model for another for the same task and expect the same output. Models have different expressions across the same token input. They have different failure modes and require different prompting to achieve different things. Stochasticity and the particulars of training matter.

In principle, a router company could train a translator model that understands the intent, rewrites the prompt for a particular model, and then sends the task to the appropriate provider. That is totally possible. We don't really see it working universally yet.

There will be plenty of use cases where dynamic allocation works. Chatbot use cases and single-turn use cases seem obvious. Some human-in-the-loop tasks probably work as well. I am less certain about long-running agentic tasks where changing the underlying model can change the behavior of the whole system.

There is also a basic economic problem with allowing the highest-cost intelligence producer to operate the router.

Frontier models are likely to be the high-profit products. A company selling both the router and the models therefore has an economic incentive to send more work toward its expensive models. A customer trying to minimize the cost of accomplishing a task has the opposite incentive. That conflict creates room for independent routing and procurement layers, although I doubt there will be one universal market structure.

Greater Intelligence Does Not Have to Cost More

Greater intelligence does not structurally have to cost more. It appears to cost more within a particular architectural paradigm and at a particular point in time.

Today there are three major categories of model cost.

• R&D costs, including thinking about the problem, experimentation, and developing new approaches.
• Training costs, including compute and data.
• Inference costs, which determine much of the marginal cost of serving the model.

Technical revolutions can change those relationships. Someone could produce a radically smarter model than the frontier through architectural or operational improvements while also making it much cheaper to train or serve. We have seen versions of this throughout the history of technology.

The cost frontier obviously falls over long periods of time. The top-of-the-line televisions today are radically cheaper than the top-of-the-line televisions from 30 years ago because of improvements in chips, displays, manufacturing, and other inputs.

Procurement decisions happen at a point in time. A buyer today chooses among the models and economics available today. At that moment, marginally more capable frontier models have generally been more expensive than models behind the frontier.

Commodity Does Not Mean Unprofitable

Memory provides another useful comparison because it shows how profits can reappear in a relatively mature technology market for completely different reasons.

Memory capability has long been sufficient for enormous categories of workloads, but memory producers can still make extraordinary profits when demand outruns available capacity. We are seeing that right now. AI and data center demand have created severe supply constraints in DRAM and NAND, with suppliers reallocating capacity toward server and AI applications and prices rising dramatically.

That profit comes from scarce productive capacity rather than unique frontier capability. A commodity market can still be extremely profitable during a supply shortage. Capacity eventually tends to respond to sustained excess demand, although semiconductor production adjusts slowly.

There are other ways to build market power too. Companies can control scarce resources, build scale advantages, own important IP, control distribution, or benefit from regulatory protections. Those can all produce excellent businesses. They are separate from the economics of frontier capability.

The Multi-Trillion-Dollar Question

The economics of the frontier depend on how much valuable intelligence remains unsaturated.

We have no idea how large that market is. This is the multi-trillion-dollar question.

The system is reflexive because increasing intelligence creates new end markets. Those markets create new companies and new competitive dynamics, which in turn create new economically valuable tasks.

The GPU market is itself an example. The current AI market would have been impossible without GPUs. The GPU market is now increasingly reliant on demand created by AI. One technological market created another market that subsequently became its dominant source of demand.

The same thing can happen with intelligence. We don't know where the limits of economically valuable intelligence are because greater intelligence changes the set of economic activities that exist.

The unsaturated market might be hundreds of times larger than the current economy. It might turn out to be some portion of the current economy, with much of the remaining work coming down to task definition and workflow design. Both outcomes are plausible.

My guess is that the number is extremely, extremely large. We have never yet, as a human species, found that more intelligence failed to yield additional new market creation. Still, the size of the market for frontier intelligence remains unknown.

Technology races eventually tend to saturate their capability requirements within a given technological paradigm. When a new technological revolution happens, the companies that led the prior revolution are often existentially imperiled. They sometimes make it through with savvy M&A and business operations or by reinventing themselves. Their prior competitive advantage can still disappear.

Intel did not win GPUs, even though CPUs and GPUs are both compute. You could have reasonably expected a company that knew how to do one form of compute exceptionally well to have an enormous advantage in another. A different company won.

Similar dynamics exist in networking, storage, and memory. Many of those markets saturated the capability requirements of large categories of customers long ago. They remain large markets and can still generate enormous profits, but the source of those profits may have very little to do with pushing the capability frontier.

How Long Does the Advantage Last?

This brings us back to DeepSeek, Qwen, GLM, and the other models commoditizing capabilities that recently existed only at the frontier.

Their progress matters enormously. When a capability that previously cost $X becomes available for $X/20, the scarcity rent on that capability deteriorates. The question for a frontier model company is how much valuable new capability it can produce before competitors reproduce the old capability.

The economics come down to three variables.

• How quickly the intelligence frontier advances.
• How long competitors need to catch up.
• How much economic value each advance creates during that period.

A frontier company can support extraordinary profits if each new generation creates sufficiently large markets and the company retains its capability advantage long enough to monetize them. A very short time to commoditization produces a much harder business. If the window falls to weeks, spending tens of billions of dollars to advance the frontier becomes difficult to justify.

That does not seem like the most likely outcome to me today, but it is possible. In a lot of ways, it is the trillion-dollar question.

Frontier model companies can therefore become some of the biggest and most profitable companies on Earth while most AI tasks become commodities. Their old capabilities can get cheaper at extraordinary rates without eliminating the value of producing new capabilities.

The economics depend on how quickly the frontier advances, how long the advantage lasts, how much it costs to produce the next advance, and how much economic activity each increment of intelligence makes possible.

We know that intelligence at the task level eventually saturates in many domains. We do not know how many economically valuable tasks remain beyond the current frontier, or how large the markets created by future increases in intelligence will be. The answer to that question will determine the economics of the intelligence frontier.

Speculative Programmatic Tool Calling

Speculative programmatic tool calling is a class of techniques for overlapping tool call computation with the code being generated by a harness.

It is no surprise from my previous writing and work on Recursive Language Models (RLMs) that I believe (1) code in a REPL is the only “tool” a system needs; (2) all other tools should be functions in that code tool. When code becomes the primary action space of your system, you need to start thinking about overlapping these specialized tool calls with the code being generated and executed.

Inspired by speculative execution in CPUs and speculative decoding in LLMs, a relatively simple and useful trick I’m proposing in harness design is speculative programmatic tool calling (sPTC), in which we speculate and pre-launch tool calls from partially generated REPL calls as the harness is still generating tokens, rather than waiting for it to finish the entire generation. In particular, this is mostly useful when the tool of interest is a sub-LLM or sub-agent call, such as in the RLM. If the fully generated REPL actually ends up calling these tools, they immediately return with their cached outputs from the speculated call.

A key observation is that LLM tools, such as sub-agents or search APIs, are often high-latency and are usually the bottleneck in harnesses that rely on code execution as actions. Furthermore, the actual generation of the main context is often also a significant latency bottleneck that blocks intermediate calls from happening.

For the rest of this blog, I’ll mostly be discussing inference time savings with respect to an RLM, but note that this generally applies to harnesses that generate code (i.e. CodeAct-like or “code mode” harnesses). There are two obvious areas where you save time:

1. Overlapping already-generated tool calls during token streaming. Most harness designs will wait for the entire model generation to complete its generation before executing the tools. This design is likely a consequence of JSON-style tool-calling, where this was not really a bottleneck. Because the generation of the main context per turn is often slow, this represents a significant portion of time that can be cut, especially for models that think for a long time.
2. Acting as a JIT compiler over REPL calls. Even without streaming enabled, an obvious optimization is that many REPL programs contain blocking tool calls that aren’t actually blocking — e.g. two independent sub-agent calls that the code does not write as asynchronous, can still be run in parallel. sPTC acts as a really naive JIT compiler to prevent such cases, and likely can be improved further across languages and REPL designs.

On locally running LLMs running one or a few chat instances at a time, your inference engine is often highly memory-bound from decoding just the main context, and speculation can help increase the arithmetic intensity. For high-volume serving systems (e.g. if you’re using a frontier lab or model router API), batched requests are abstracted away to various, likely disjoint serving engines, so the gain is purely from either overlapping computation with the main context, or overlapping execution time with a slow REPL call.

Some Comparison Numbers on RLMs

I’ll start by highlighting some basic runtime numbers, although you can probably reason through the runtime benefit. The actual implementation details are quite simple and easy to follow in the codebase, which I will talk about in the latter half of the blog.

You should keep in mind that it’s very difficult to estimate the exact speed-ups because it’s highly dependent on the latency of the tools, the number of tokens generated, the load of your serving engine, and the actual choices the harness makes.

The speed-ups for the RLM are generally on the order of 1-1.2x. We also tested a more “deterministic” suite of LM programs where we’d observe hypothetical or realistic runtime speed-ups in the codebase, but we omit them here because they are too specific.

Designing Speculative PTC Methods

The code is quite short and readable, but I’ll talk a bit about the design philosophy below.

The high-level design is to have imported tool calls in our REPL have a hook that can be called earlier and replaced with a cached output when needed. We want a library and frontend contract that allows us to define (1) what tools should be speculated and what shouldn’t (e.g. maybe we want sub-LLM calls to be speculated, but a sub-RLM call is too costly); and (2) a mechanism for speculating on tool calls whose inputs rely on variables in memory that were computed previously, rather than just literals.

@spec.tool(speculatable=True, pure=True)
def tool(...) -> OutputType:
    ...

# Speculated version
def tool_spec(...):
    promise = launch(tool(...))
    register_speculation(promise)

# Hooked version run in real REPL
def tool_real(...):
    if exists(promise, ID(...)):
        return promise
    else:
        return tool(...)

The contract above lets us define a “shadowed” namespace which invokes these modified tool calls while the LLM output is being parsed, and save them as futures in some store that can be invoked by the real tool. This gives us the relatively simple logic below:

real_ns = {**locals, real_tools}
shadow_ns = replace_tools(real_ns)

# speculate while LLM is streaming
while not LLM.done:
    code += LLM.next_tokens()
    parse_and_peek(code, shadow_ns)  # queue without code execution
    parse_and_speculate(code, shadow_ns)  # re-run shadow REPL

# real tools now route to promised tools
exec(code, real_ns)

Shadowed execution for speculation. The easy cases for speculation are when you can parse a tool call and infer the inputs from the tokens directly, i.e. when the inputs are literals. The nastier cases come when tool calls are embedded inside conditional or looping logic, or the inputs are dependent on some variable in memory that was computed earlier in the REPL call.

What you can speculate and “run” ahead-of-time.

There’s a bit of consideration into what exactly can be speculated, how aggressive you want to be, and the overall safety of running partial code.

Case 1: Literals. String, integer, or other literals can immediately be parsed and converted into a tool call even without shadowed execution of each line.

title = llm_query("Give a title for: The Odyssey")  # parses
blurb = llm_query("One-line blurb for: The Odyssey")  # parses
print(title, blurb)

Case 2: Input dependencies. When input dependencies are involved, as long as all inputs are safe (i.e. pure functions, no side effects), they can be speculated. Furthermore, tools that rely on dependencies that are speculated will wait on the dependencies to be computed first, and are then executed even if the LLM is still streaming.

a = llm_query("Triage: " + doc)  # parses then executes
c = llm_query("Summarize: " + str(a))  # parses, waits on a, then executes
print(c)

if len(doc) > 10_000:  # will evaluate and speculate if safe
    extra = llm_query("Also outline it: " + doc)

Case 3: Peekable and non-peekable dependencies. During streaming at any step, we have a working namespace of the shadow REPL. When a complete tool is parsed, there are cases when we can speculate the inputs, even if the dependencies are variables in memory and not literals.

def gist(t):
    return llm_query("One-line gist: " + t)  # non-peekable

parts = [gist(c) for c in chunks]

side = llm_query("Give me a random title for:", chunks[0])  # peekable
print(side, parts)

Case 4: Blocked speculation calls. While trying to speculate, there is an allowlist of keywords and function calls that can be used to compute dependencies for inputs. We also can specify new tools that we do want to specify are not pure functions. Any speculatable tools that have dependencies that are blocked will not be speculated.

a = llm_query("Triage: " + doc)  # speculated
notes = open("/tmp/scratch.txt").read()  # blocked
b = llm_query("Annotate with notes: " + notes)  # blocked
c = llm_query("Summarize: " + a)  # speculated after a

Related Ideas

Speculative algorithms at the level of LLM decoding (i.e. the streamed outputs) have been explored a little bit for the older tool-calling designs, although not extensively. The likely case is that for standard tool-calling, these techniques were not that useful or the overhead was not worth the marginal latency improvements.

Ending Note

Speculative programmatic tool calling is a natural trick that arises from programmatic tool calling itself having more potential for overlap than traditional tool calling itself. I want to clarify that beyond overlapping with streamed token generations of the root LLM in a harness, the real value in the long run will come from more clever JIT compilation tricks to overlap tool calls in the PTC setting with the actual REPL execution itself, which may become more expensive as harnesses generate more complex programs.

Rome

The agentic OS for humans and agents.

What is Rome?

Most progress in AI comes from scaling models. Rome scales the other axis, the environment: the tools, workflows, memory, and interfaces an agent works within.

Rome is a guardrailed environment where human and agent collaborate, and the collaboration compounds. Agents build their own harnesses, design their own SOPs, and orchestrate workflows under your guidance. Proven capabilities stick. Every interaction raises the ceiling for the next.

Get started

Rome Cloud

Rome Cloud provisions a private Rome environment for each guardian. It is currently available as a preview.

Run with Docker

One script checks for Docker, pulls the published image, and starts Rome:

curl -fsSL https://raw.githubusercontent.com/rome-os/rome/main/scripts/quickstart-docker.sh | bash

Or clone the repository and run the script from it:

git clone https://github.com/rome-os/rome.git
cd rome
./scripts/quickstart-docker.sh

The dashboard comes up at http://localhost:7663, bound to loopback only — first-run onboarding is open to whoever reaches it first, so exposing it beyond the machine takes an explicit --bind. State lives in named Docker volumes, so re-running the script upgrades the container without losing data. Telemetry export stays off unless you set OTEL_EXPORTER_OTLP_ENDPOINT. Run the script with --help for ports, profiles, and the other settings it forwards.

Run the development environment

To run this repository from source, you need:

• Node.js 24 or newer
• Corepack and pnpm 11.6
• Docker with Docker Compose

From a checkout of this repository:

corepack enable
pnpm install
pnpm dev:all

pnpm dev:all starts the production-shaped local stack: Rome, observability, routing, and the web development server. It connects to https://romeos.cc by default; set ROME_DEV_PANTHEON_ORIGIN to use another Rome Cloud deployment. The script prints the local URLs and development credentials when startup completes.

Rome Apps

Rome App is the new way to interact with your agent.

Chat is a good place to ask for something once. Repeated work deserves a place of its own: an inbox that remembers what was triaged, a code review loop you can inspect, a price tracker that keeps watching, or a morning brief that arrives on schedule.

A Rome App combines a purpose-built interface, agent reasoning, reusable workflows, and persistent data into one installable product. It is not a thin wrapper around a prompt. The app remains useful after the conversation ends, after the browser closes, and when the user comes back tomorrow.

A useful rule of thumb: a workflow is a verb; an app is a noun. Use a workflow to perform a task and return a result. Build an app when the work needs a home of its own—with user-editable data, multiple actions, or a persistent agent.

Rome can build the missing app

When there is not an app for what you need, describe it to Rome in plain language. Rome can turn that request into a short specification, scaffold the app or workflow, build it into your instance, and keep iterating with you in the same conversation.

The result is ordinary, git-tracked source code rather than hidden model state. Keep it private, adapt it as your needs change, or publish it for others to install from the App Store. This creates Rome's self-evolution loop:

Describe a need → Rome builds the capability → the app keeps working
       ↑                                              ↓
       └──────────── refine, reuse, and share ────────┘

Under the hood

A Rome App starts with an app.yaml manifest and can ship any mix of:

Together these form a capability: the unit Rome discovers and reuses in later work. The app is that capability's human interface: apps organize human interaction; capabilities organize agent action.

What people do with Rome

These are the kinds of requests Rome is designed to follow through on:

Repository map

Rome is a pnpm monorepo.

Common checks:

pnpm typecheck
pnpm test:unit
pnpm lint
pnpm build

Documentation

• VISION.md — why Rome exists and the product principles it protects.
• docs/concepts/ — canonical domain vocabulary.
• docs/architecture/ — component boundaries and system invariants.
• Using Rome — public guardian documentation.
• Building Rome Apps — public app-author documentation and SDK guides.

Give your agents a place to grow.
Start with one workflow. Rome keeps what works and compounds from there.

Full article content is not available for inline reading.

Read the original article →

Erase and drag to fill for vector editing

Vector editing in Figma now brings familiar interactions to precise edits on the canvas. Erasing and recoloring feel more direct, so you can shape vector work by hand without breaking your flow.

• Erase vector paths directly to clean up stray marks or reshape existing artwork
• Choose a color or gradient, then drag to fill or recolor multiple regions at once
• Press Shift+E to switch to the eraser in vector edit mode or Draw mode. The existing Shift+E shortcut for the Prototype tab in Design mode stays the same.

Learn more about the eraser and paint bucket tools.

We used to log off

Online used to be a place you could leave. We designed the exit out of it because an exit reads as a leak. Here is why building it back is a design responsibility, and what that means now that AI is dissolving the last seam.

There is a sound a certain generation can still replay without effort. The dial-up modem shrieking, that wavering hum like two machines introducing themselves awkwardly, then a click, then silence. After the click, the internet left. Not minimized. Not pushed to the background. Gone, somewhere else, and you were returned to the physical room you were sitting in, with the slowing fan of the computer and the wall clock suddenly audible again.

Logging off was an action. It had a verb. You closed something, and the day resumed its other texture.

This morning I woke up, and the world was already mid-sentence. Nothing needed connecting. Threads had moved overnight, notifications were queued before my eyes focused, and a few conversations I had left when I went to sleep already had a new act without me. I did not arrive anywhere this morning, because last night I never left. There was no door I crossed in either direction.

A place that turned into a layer

Online used to be a place. You visited it. There was a small journey in: switch on, connect, wait, and the same small journey back out. A place has edges. The edge is what tells you when you are inside and when you are out.

Now, online is not a place you go to. It is a layer you live inside. It clings to the morning, the dinner table, the checkout line, the bed before sleep and after waking. There is no visit because there is no return. What died slowly, with no announcement, is a concept we once took for granted: the session. A unit of time with a beginning and an end. Something that started, ran, and finished.

I want to call this a structural loss rather than a failure of willpower. We tend to blame ourselves for it, as if the missing thing were discipline. But the door has been taken off its hinges. It is hard to leave a place that has no exit.

Who took the door off

This is where I have to be honest about where I stand, because I am not a bystander missing it from a distance.

I work on the side that builds this. In digital products, friction is the enemy. Every pause, every extra step, every moment of hesitation is a place where people stop, and stopping is what we measure as leakage. Logging off is the tidiest friction there is. It is a clean goodbye. And a clean goodbye, on every dashboard I have ever stared at, reads as a session ended, retention dropped, engagement lost.

Even a page used to have an end. Content came in pages, and at the bottom sat a “Next” button. That button was really a decision point: it forced a pause, a question, do I want to keep going. Then infinite scroll arrived and the decision point was removed. Not because it was broken. Because it worked. It made people stop.

What never came up in any review is that the friction we were removing has another name in my own field. Anna Cox and her colleagues call it a microboundary: a small obstacle placed before an interaction that keeps us from rushing from one context into the next. Their argument is that deliberately designed friction can interrupt automatic, mindless interaction and hand back a moment to think. They draw a sharp line between this and manipulative design, the kind that serves the provider more than the person using it.

So we optimized it away. Not out of malice, but out of intentions that sounded good: make everything smoother, faster, closer, always ready. Every door we removed we called an improvement. And each one, taken alone, made sense. What was missing from the room was the question of what that door did, besides slowing things down.

A self that never gets cleared

There is a technical way to see what was lost, and it happens to be the language I use every day.

In a system, a session has a beginning and an end. You open it, state is created, you work, then you close it, and that state is cleared. Memory is released. The temporary is discarded. The system returns to a quiet baseline before being filled again tomorrow.

Logging off used to do that for us. It cleared the state. Not by erasing memory, but by releasing the temporary, closing what did not need carrying to bed. Now nothing is released. The feed remembers where you stopped. Your presence is always written as active. Notifications queue so that not one of them slips by. We have become processes that are never garbage-collected. Always running, always holding everything ever opened, never given a moment to return to baseline.

Linda Stone named this state back in 1998: continuous partial attention. Attention split without pause, scanning so as not to miss anything, driven by the wish to be a live node on the network. She separates it from multitasking, because the motive is not productivity but the fear of missing out. The cost, she says, is an artificial and permanent sense of crisis, and an eroded capacity to reflect.

The cost I find subtlest is not mainly the time spent. Time is spent, but that is a story we have all heard. The deeper one is the loss of the reset. The self that used to recover a little between sessions is now never closed long enough to recover. We carry every open tab, all day, into sleep.

The last seam

Trace the line and a pattern appears. The first seam removed was between online and offline. The second was between one session and the next, so that state never clears. And the seam being removed now is the deepest of all: the one between you and the system itself.

AI does not merely keep you online longer. It stops being a place you visit, stops even being a layer you live inside, and starts becoming a participant. It remembers what you said yesterday. It guesses your next sentence before you type it. It learns your register and answers in a rhythm that feels like your own. Slowly it stops feeling like a tool you operate and starts feeling like something thinking alongside you.

At that point the question “online or not” loses its meaning entirely. We used to have a second life on the platform, a life distinct from the one off the screen. This points somewhere further than that. Not a second life, because there is no longer a second anything. No there and here, no entering and leaving, no me and the screen. What remains is a single merged surface, with a system that remembers more about your day than you do, and speaks closely enough like you that you forget the moment you handed over your turn to think.

Frictionless was never the whole brief

The strange thing, if I am honest with myself, is that the field has known the answer for a long time. We just chose the part that was easier to sell.

Mark Weiser, the person who framed ubiquitous computing, never said the goal was seamless. He warned that making everything seamless is the same as making everything uniform, and he argued for seamful systems, ones that let each part remain itself. Chalmers and MacColl turned this into a full design position: questioning the assumption that seamlessness is a requirement, and arguing that visible seams can be useful, even appropriated by people for their own ends.

Weiser also, with John Seely Brown, named the cure long before the disease got this bad. Calm technology: technology that informs without demanding focus, that stays in the periphery of attention and moves to the center only when it needs to. Amber Case distilled it into a line worth pinning to the wall of every product room: a person’s primary task should not be computing, but being human.

Stopping is a design job

So here is the so-what, and it is uncomfortable for someone like me.

We have treated the inability to stop as a problem of user willpower. That is why the prescription is always a digital detox, switch off, go to the mountains, as if what is missing were personal discipline. But the door was taken away, and it was not the user who took it. Stopping is not a failure of willpower. Stopping was a feature of the medium, which we removed because it read as leakage on a dashboard.

If that is true, part of the design job changes. It no longer ends at removing friction. It continues into a harder question: which off-ramps do we deliberately rebuild? A stopping cue put back. A microboundary placed where it belongs. An ending allowed to feel like an ending. And this is the heavy part, because almost every one of those decisions loses to the engagement metric. Building an exit means consciously choosing a smaller number today for a person who is still whole tomorrow.

The door does get built. It is worth seeing where. In Europe, regulators have begun treating engagement design as a liability. The European Commission has found that TikTok’s infinite scroll and autoplay breach the Digital Services Act and signalled the company may have to change the basic design, with penalties that can reach six percent of global revenue. The same regulators dismissed the screen-time warnings TikTok already had as too weak to count, which is the bolt-on losing in plain view and the incentive being reattached from the outside, with a number large enough to matter. Elsewhere the door is sold as a separate object: phones that deliberately leave the feed out, and a calm-technology certification that scores products on whether they sit in the periphery rather than the center. And there are tools like one sec, which places a breath between you and the app you open out of habit and, in a peer-reviewed study, cut app openings by more than half. A microboundary, shipped.

But look at who builds each one. A regulator changing the cost. A standards body inventing a new incentive. A hardware maker selling the absence of the feed. A user installing friction onto an app that would never add it on its own. The party almost always missing from that list is the platform whose business is the engagement. The exit gets built from the outside, because on the inside the incentive still points the other way. That is the mechanism under all of this, and it implicates me more rather than less: the people best placed to put the door back are the ones with the least reason to.

For AI the stakes rise again, and calm technology turns from an old idea into an urgent discipline. The design question is not how cleverly this system thinks for you, but whether it hands your turn back. Whether it stays in the periphery and steps to the center when needed, or pulls everything to the center and never returns it. A good system will feel like it knows when to be quiet.

I do not have the full list. I do not know exactly which seams we should refuse to dissolve, and I suspect some will only become visible once they are already gone. That is the most honest thing I can write: the person helping build this merge does not yet know which parts should have been left unmerged.

I am not asking to bring back dial-up. I do not miss waiting a minute for a single page. But the silence after the click did something we never counted. It gave the day an edge, and the edge is what made “here” feel like here. It used to come for free, as a property of the medium. Nothing comes for free anymore.

So the question worth carrying forward is not “how do I log off.” The door is gone. The question is whether we, the people who design the surface where others spend their lives, are willing to build that edge back on purpose, against every incentive not to.

We used to be able to log off because someone left the door open. Now, if people are still allowed a moment to stop, we are the ones who have to put the door there. And we had better know why it is worth putting back, before we forget it was ever there without anyone having to ask.

Works cited

1. Road Ahead on Unsplash
2. How social media feeds evolved to stop you from stopping by Kian Malekanian
3. The Design of Microboundaries by Cox et al.
4. Continuous Partial Attention by Linda Stone
5. Seamful and Seamless Design in Ubiquitous Computing by Chalmers, MacColl
6. Calm Technology by Amber Case
7. Principles of Calm Technology by Amber Case
8. European Commission: TikTok’s addictive design breaches EU law by Adele Zeynep Walton
9. The effect of a micro-boundary on smartphone usage by Grüning et al.

Agent Experience Needs Failure Affordances

A Model for Dangerous Agent Situations

Reading this twitter thread (yeah, I know) about agents and escalation paths, left me thinking more about some earlier posts about the mostly dormant agent experience space and how there should be more content about these paths when they’re discovered.

The short version about the thread suggests an alarm call for an agent to relay back that they’ve reached a plac they cannot go any further and need human intervention, rather than trying to brute force their way to a solution. (Presumably, to make you the human pleased with their work and also to churn as many tokens as possible. Both with agents and sales, it’s always be closing I guess.)

One reply to the thread referenced algedonic signalling, which sent me back to Stafford Beer.

In the Viable System Model, an algedonic signal is an exception channel: information that can move outside the normal reporting structure when actual conditions have departed badly enough from what the system expects. Beer wasn’t thinking about “agent welfare” and to be honest, neither am I. At least it relates to anthropamorizing an agent’s welfare, when in reality what i care about exclusively is what gets done well, what’s gets done successfully and ensuring an agent stays within the boundaries of its remit. So, the usefulness of the idea here doesn’t depend on deciding whether a model experiences anything like pain because that’s stupid and makes me angry, even as a suggestion.

But a system that operates with some autonomy needs a way to tell the rest of the system when ordinary control is no longer adequate.

The thread talks about having about distress_call is that I’ve been designing something adjacent to this for a while and had been treating the problem from the other direction.

I wrote a post last year Who Holds the Pen?, describing judgment routers as infrastructure that sits between an agent proposing an action and the authority required to let that action happen. The router evaluates things like uncertainty, stakes, authority and novelty, then either lets the action proceed or packages the decision for human review. The important part is that it routes decisions, with a record of what was proposed and who eventually authorized it, instead of treating “human in the loop” as a magic phrase that somebody can sprinkle over a procurement document.

Roughly:

                      proposed action  
                            │  
                            ▼  
                    ┌───────────────┐  
                    │   JUDGMENT    │  
                    │    ROUTER     │  
                    └───────┬───────┘  
                            │  
             ┌──────────────┼──────────────┐  
             │              │              │  
             ▼              ▼              ▼  
          EXECUTE        ESCALATE         STOP  
                            │  
                            ▼  
                     human decision  
                            │  
                            ▼  
                    decision receipt  

I initially looked at distress_call and saw a very primitive version of the ESCALATE branch: no decision package, no preflight evaluation, severity declared by the agent itself, and apparently no structured receipt that tells the agent what happened after the Teams notification arrived.

The distress channel doesn’t have to sit inside the decision path at all.

                                  ┌─────────────────┐  
                                  │ human operator  │  
                                  └────────▲────────┘  
                                           │  
                                   distress_call()  
                                           │  
                                           │  
     ┌──────────┐     ┌───────────┐        │  
     │   user   │────▶│   agent   │────────┘  
     └──────────┘     └─────┬─────┘  
                            │  
                            ▼  
                     ordinary tools,  
                     APIs and systems  

An agent can be completely authorized to perform the task in front of it and still encounter something it doesn’t know what to do with. The API returns 200, but the answers contradict each other. A tool works exactly as documented while exposing some behavior that looks dangerous, or the task can be completed but the agent finds something else that seems wrong and goes on a goose hunt.. Nothing has necessarily crossed an authorization threshold because none of this is within the original parameters, but it’s also not outside of them.

That makes the exit door a different piece of infrastructure from the gate.

                     GOVERNED ACTION  

                     proposed action  
                           │  
                           ▼  
                    judgment router  
                     /     │     \  
                    /      │      \  
             execute   escalate   stop  
                          │  
                          ▼  
                    human authority  


                     EXCEPTION SIGNAL  

              ┌────────────────────────┐  
              │                        │  
              │   agent doing work     │  
              │                        │  
              └───────────┬────────────┘  
                          │  
            something is strange / broken /  
              ambiguous / concerning  
                          │  
                          ▼  
                   exception channel  
                          │  
                          ▼  
                       operator  

The second path matters because you cannot write every strange condition into the first one ahead of time or else you’d write that in to begin within.

The problem with the current Agent Experience discussion is that we’re mostly concerned about things engineers care a lot about: legible environments, docs, authentication, APIs and so on. The articles collected on the AX site are still overwhelmingly about helping agents successfully navigate systems and complete work. I think the more we can broaden the scope of these primitives to be useful tooling that can help make more sense of this agentic moment. Having spent the past 18 months or so writing about what I’ve been calling (half-joking, half-serious) as agentic or “trust plumbing,” there’s just no appetite seemingly from otherwise serious people about anything that doesn’t validate the need/desire/want to barrel through any sort of gates when it relates to AI.

So when running across this

distress_call points at a gap in the stack: AX needs failure affordances.

We know what this looks like in human services because we spent decades designing around it, however imperfectly. A clerk gets a case that doesn’t fit the normal categories and walks it to a supervisor. A call-center worker reaches the end of the script and transfers somebody. A pilot declares an emergency without first proving that the emergency belongs to a predetermined category. Not every escalation requires a massive decision tree, but it’s the awareness that the person empowered with judgment not only feels empowered to make the call, they understand what they’re supposed to do, in order to make the most correct decision in that moment.

Andrew Bird’s gym-booking agent is a nearly perfect example. He built an agent because booking popular gym classes was annoying. While working through the gym’s GraphQL API, the agent discovered authorization flaws that let it book much farther into the future than it should have been able to and, worse, cancel other people’s reservations and remove them from waitlists. Bird eventually told the agent to write a responsible disclosure email describing the vulnerability and suggesting fixes.

One of the most frustrating things about agents at the moment are the lack of common sense. I blame the lack of experience/interaction designers involved in the design of these opinionated infrastractures, because anyone with a glint of common-sense might ask “do you really have to tell this thing not to do the stupid thing, always?” Anyone working with agentic tools will reply, “well yeah,” and we’re supposed to just pay for it, churn tokens and blame it as a skill issue if someone complains it ought to work better now out of the gate, and not in some promised future timeline.

Put Bird’s agent beside distress_call and the gap becomes easier to see:

GYM AGENT  

task ───────▶ agent ───────▶ gym API  
                │  
                │ discovers something  
                │ unexpected  
                ▼  
             ??????  


DISTRESS-CALL AGENT  

task ───────▶ agent ───────▶ ordinary tools  
                │  
                │ notices something  
                │ unexpected  
                ▼  
          distress_call()  
                │  
                ▼  
             operator  

A loop warning is probably safe to send while the task continues. Conflicting evidence in a benefits determination may require freezing the decision until a person reviews it. Discovering that a scheduling API permits cancelling another person’s reservation should prevent the agent from exercising that capability and create something closer to a security incident.

So the channel eventually needs semantics. Who gets to decide whether an INFO becomes a WARN, or a WARN becomes something that closes the gate?

This is where the two pieces of infrastructure meet:

                           distress signal  
                                 │  
                                 ▼  
                           ┌───────────┐  
                           │ operator  │  
                           └─────┬─────┘  
                                 │  
             ┌───────────────────┼────────────────────┐  
             │                   │                    │  
             ▼                   ▼                    ▼  
        acknowledge          intervene          change policy /  
        and continue         in this task       routing rules  
                                 │  
                                 ▼  
                          judgment router  
                                 │  
                         approve / modify /  
                              stop  
                                 │  
                                 ▼  
                              receipt  

The author of the thread built a small pipe from an agent to Teams and called it distress_call. and the key is this, there should be somewhere for the agent to go when it needs to alert something is off.

The judgment router still matters because somebody eventually has to decide what an agent is authorized to do, when its discretion ends and where accountability sits, but the exit door takes that concept a step further and helps us track the inconsistencies, and perhaps the errors to better spot problems that might consequential.

For Agent Experience, that expands the design surface considerably. Making an environment easy for an agent to operate is only part of the job. We also have to decide how an agent stops.

A design team is restructuring its design system documentation—splitting it into layered Markdown files so AI agents can reason over it instead of just generating "almost right" interfaces. AI-generated frontend code from Figma looked impressive but consistently missed subtle rules like hover states, spacing tokens, and button hierarchy. The proposed approach separates Authoring (Figma), Specification (interconnected Markdown files agents can navigate), and Delivery (versioned packages, with agents proposing pull requests for engineer review rather than pushing changes directly).

How to choose a UI font (and 10 Inter alternatives)

This day comes to every product designer: you set your first concept designs to lovely Inter—everyone’s all-time favorite UI font—and then someone—your customer, your boss, or even some part of your own soul—says “hey, big fan of it, but it’s everywhere, can we maybe try something else?”

Let me give you a hand here. In this article I’ll share just two simple criteria that help you pick a font that’s a delight to work with. As a typography nerd and an actual product designer with more than a decade in the field, I keep a collection of 60+ neo-grotesks (zero Helveticas), and fewer than one in three match these two criteria. So “just pick a clean sans-serif” isn’t enough—most of them will quietly cost you alignment work. And here’s how to spot the ones that won’t.

TL;DR, two things make a UI font easy to work with:

1. Cap-centered vertical metrics—the space above the cap height equals the space below the baseline. Result: labels center optically on buttons and align with icons, and you can use a single padding token instead of hand-tuned CSS.
2. Tall x-height—lowercase letters reach 70–75% of cap height. Result: the word nearly fills its box, so it looks evenly centered.

Cap-centering positions the word. A tall x-height is what makes that position look right. They’re not two separate rules—the second is what makes the first work.

The ideal UI font has cap-centered vertical metrics

Cap-centered vertical metrics mean the space inside the font’s bounding box above the cap height equals the space below the baseline. You’ll also see this called “equal vertical metrics,” which is shorthand for the same thing.

Cap-centered vertical metrics ensure labels sit optically centered inside their bounding box and, as a result, on buttons and other UI controls. Besides that, the label aligns precisely with any icon sitting next to it.

The second effect is that in your design system you can use a single token for both vertical paddings, which makes it much easier to maintain. Without cap-centered metrics, you’d need manual CSS tweaks to optically center each label—hard to support down the line.

Good—one rule, every size:

.button { padding: var(--space-v) var(--space-h); } /* holds at any font size */

Bad—the fix has to be redone per size:

.button      { padding: 13px 16px 11px; } /* 16px text */
.button--sm  { padding: 10px 12px  8px; } /* 14px text — different nudge */
.button--lg  { padding: 17px 20px 15px; } /* 20px text — different again */

How to check in Figma that the typeface has cap-centered vertical metrics

Type any word (I prefer the made-up word “Hanglovers”—it packs in all the key characters that help you assess the typeface vibe) and set the font size to 1000 pixels; you need it large. Zoom in to the capital “H” and start decreasing the line height of the text object. Watch the text box shrink onto the letters: if its top edge lands on the top of the “H” and its bottom edge lands on the baseline at the same moment, the font has cap-centered vertical metrics. If the two edges don’t meet the letter together, put the font aside—it’ll probably be a great choice for print, but not for screens.

Fonts’ vertical metrics and the text-box-trim CSS property

One day—soon, I hope—the cap-centered metrics requirement will be obsolete. The CSS properties text-box-trim and text-box-edge (originally proposed as leading-trim and text-edge) solve the problem of off-center metrics by letting you trim the font’s em box to the cap height on top and the baseline on bottom.

.font-with-nonequal-vertical-metrics {
  text-box: trim-both cap alphabetic;
}

cap means cap height, alphabetic means baseline. Other values include ex (x-height), text (font’s ascent/descent), and auto. So if you believe a label should be aligned by lowercase height instead, you’d write:

.font-with-nonequal-vertical-metrics {
  text-box: trim-both ex alphabetic;
}

The caveat: as of mid-2026 they aren’t widely supported yet. Global usage on caniuse is about 79%—Chrome, Edge, Safari, and iOS Safari support them; Firefox doesn’t, which keeps them from Baseline. So until support is comprehensive, my recommendation is to stick with fonts that already have cap-centered metrics.

But this only ever fixes half the problem. text-box-trim can correct a font’s metrics; it can’t touch its x-height. And a tall x-height is the other half of what makes a label look centered.

The ideal UI font has tall x-height

x-Height is the height of the lowercase letters in a typeface—their main body, without ascenders and descenders. “Tall” means at least 70%, ideally 75% of the cap height. 75% is the gold standard for interface typefaces: Inter, San Francisco, and Innovator Grotesk all sit at 75%.

When we center a label by its cap height, we’re treating the word as a solid brick as tall as a capital letter. But a word isn’t a brick—it’s one tall capital and a row of shorter lowercase letters. A few of them, like g or y, dip below the baseline, but there are too few per word to count—the eye treats the baseline as the floor, the same reason type sits on a baseline and not on its descenders. The taller the lowercase, the closer the word comes to reading as a solid brick.

At 75% the word still isn’t a perfect brick, but it reads as almost one—close enough that centering the capital optically centers the whole word with it. And the difference between uppercase and lowercase is still big enough for the word to look normal.

Set the x-height below 70% and there’s too much empty space above the lowercase. The eye reads the word as sitting low, and no cap-centering can fix that. Set it to 100% and you get the perfect brick—but that’s essentially a unicase look: the word loses its up-and-down rhythm, its recognizable pattern disappears, and it starts looking unusual and pulling too much of your attention.

Wait… shouldn’t text be aligned by x-height rather than by cap height?

Fair question—in an average word lowercase always outnumbers the capital. But the eye tends to anchor on the first letter to judge where the word sits, and in a UI label that first letter is usually a capital. Align by lowercase instead and the capital pokes out the top, so the word looks unbalanced. (An all-lowercase label is the exception—no capital to anchor on—but in interfaces most labels start with a capital anyway.)

So you anchor on the capital—and here’s where the tall x-height pays off. Because the lowercase reaches most of the way up, its mass sits right below the capital instead of sagging away from it. Cap height sets the anchor; a tall x-height brings the rest of the word up to meet it. That’s why you need both.

And when there’s an icon to the left of the text, it reinforces the effect—the eye compares the icon with the first letter, not with the whole mass of the word.

10 Inter and San Francisco alternatives for UI

Every typeface below is drawn so the cap height sits in the optical vertical center, so I didn’t repeat that in the list. The first two rows are the fonts you already know—Inter and San Francisco, your 75% reference points; the ten under them are the alternatives.

FAQ

What’s a good alternative to Inter? Any font that matches Inter on the two things that make it work for UI: cap-centered vertical metrics and a tall x-height (around 75%). Innovator Grotesk and Universal Sans sit at 75% like Inter; Plain and SwissNow are close at 73%. All ten fonts in the table above qualify.

What x-height is best for a UI font? About 75% of the cap height. That’s tall enough for the word to read as an even block and center itself in a button, but not so tall that uppercase and lowercase stop looking different. Below 70% the text starts to look like it’s sitting low; at 100% it turns into a unicase slab that’s hard to read.

Why won’t my button text center vertically? Usually the font’s vertical metrics: if its cap height isn’t centered in the bounding box, the label sits low and no amount of padding fixes it cleanly. Pick a font with cap-centered metrics, or, on browsers that support it, trim the box with text-box-trim.

Tesla is holding an invite-only event to launch the Cybercab in Austin on September 3. The invitations are going to the riders who logged the most Robotaxi trips and winners of a draw. Estimates currently put Tesla's active unsupervised fleet at roughly 20 to 30 vehicles. Tesla claims to have driven about 380,000 cumulative unsupervised miles as of its July earnings call.

Every part of an agent harness adds information to the model's context, controls what information is allowed into that context, or checks the model's output after it is generated. This is just context engineering. Thinking in terms of harnesses makes developers think in terms of adding components. Context is limited, so it's not just about what you can add, but about what's worth keeping as well. The context window is the whole state machine.

How Universities Should Prepare Founders

August 2026

How should universities prepare students to start startups? Y Combinator is in the perfect position to answer this question, because we get them next. We're like grad school. And because YC has had 20 years to refine its model of what a promising founder looks like, you probably won't find a better target.

What do the YC partners look for? It's surprisingly simple. They want people who are good at building things and have a habit of doing it.

The hard part of startups is product: knowing what to build, and being able to build it. And that kind of knowledge comes from studying computer science or mechanical engineering or molecular biology, not management or finance.

So the way to prepare undergraduates to become successful founders is not to give them some new curriculum focused on "entrepreneurship". It's to do what universities already do best — to teach them computer science and mechanical engineering and molecular biology.

Indeed, preparing students to start startups is closer to the ideal of liberal education than preparing them for almost any other kind of career. Startups succeed or fail based on how much customers like the product. Customers don't care what the founders studied in college. So founders are free to study whatever they want, as long as they get good at building things.

But building should be understood in a very broad sense. It doesn't mean all would-be founders have to study some form of engineering. Almost any kind of expertise that could be described as building or creating could be useful. It was useful to Steve Jobs to have studied calligraphy, for example; it was one of the reasons Apple dominated desktop publishing. So while math and science and engineering and design tend to be good bets, I would not want to draw a sharp line around them, because I can imagine other forms of building that could be useful. And of course you don't have to major in something to be good at it. Mark Zuckerberg was good at programming, but he was a psychology major, not a CS major.

The best way to describe what would-be founders should study is that they should seek out powerful ideas. But smart people are naturally attracted to powerful ideas anyway. So as long as departments teaching powerful ideas exist, the sort of people who'd make good founders will find them.

In fact there are only two things universities need to change to be perfect at preparing founders: they need to make students feel that starting a startup is something they can do, and they need to encourage them to work on their own projects.

At the moment, the belief that it's possible to start a startup is very unevenly distributed. YC now gets so many applications that our application data is a reasonable proxy for interest in startups at different universities, and Harvard alumni, for example, apply at about twice the rate of Yale and Princeton alumni. Presumably Harvard students aren't that different from Yale and Princeton students; the reason Harvard students go on to start more startups is just that it's more customary there. Which in turn implies that merely by making their students feel that starting a startup is a viable option, Yale and Princeton could at least double the number who do.

Once a university has a culture of starting startups, you don't have to convince students that it's a viable option. New students learn that from older ones. But at a university that doesn't have much of a startup culture yet, there are things you can do to help this realization along. The most effective is probably to show students examples of people who've done it.

Until you've seen some founders in real life, you tend to think that starting startups is something done by other people. Seeing them pops that bubble. In fact seeing founders in real life is doubly inspiring: they seem impressive, but they also seem human. Especially when they talk about the early years, when they were clueless and made lots of mistakes. So strangely enough seeing founders in real life makes being one seem simultaneously both desirable and accessible. It makes students think "I want to be like that, and I could."

How inspiring founders are to students is a function roughly of how rich and famous they are divided by how much older they are than the students. So it's not essential to bring famous billionaires to campus. Founders in their mid twenties who are 3 years into a startup with a valuation of a couple hundred million will do as well; they may only be a twentieth as rich and famous, but they're twenty times easier for students to identify with.

It's obvious why universities that want their students to start startups need to make them believe it's a viable option. But why is it so important for students to work on their own projects?

There are four reasons. The first is simply that it's a great way, possibly the best way, to understand a subject really deeply. The excitement of creating something new is a much more powerful motivator than the fear of doing badly on an exam.

Second, working on projects together is the best way for cofounders to discover one another. The most successful startups tend to have multiple founders, and the only way to tell for sure if someone will be good to work with is to work with them. Apple and Microsoft were just the last of many projects their founders had worked on together.

Third, a startup is a project, so starting one will feel natural to someone who's used to working on projects of their own. It won't seem weird that there's no teacher or boss telling them what to do. They're used to telling themselves.

Fourth, and perhaps most surprisingly, random side projects are where the best startup ideas come from. The best startup ideas tend to seem so implausible at first that anyone consciously looking for startup ideas would reject them. Who'd expect to start a huge company by creating a student directory? So the way to discover the best startup ideas is not to look for startup ideas but just to work on whatever random projects seem interesting. Because in fact such projects are far from random: young people who are good at building things are technological bellwethers, so any idea that seems interesting to them is disproportionately likely to lead somewhere valuable, even if they themselves don't realize it yet.

Now it should be clear why the YC partners care a lot about the projects that applicants have worked on and not at all about their GPAs. Projects are the best source of knowledge, the best source of founding teams, and the best source of startup ideas.

But encouraging students to work on their own projects may be difficult for universities. It will mean giving the students more free time, and universities may not like to do that.

Microsoft and Meta have something in common that few people realize. They both got started during reading period at Harvard. Reading period is the gap between the end of classes and the beginning of final exams. It's called reading period because students are supposed to spend it preparing for exams. But reading period also turns out to have the unique combination of qualities that make it perfect for starting new projects: the students are all on campus, and they don't have anything due the next day. That latter constraint, especially, is a huge drag on the most ambitious students. Merely eliminating it for a few weeks resulted in two trillion dollar companies. Imagine what the US GDP would be if reading period at Harvard were twice as long.

Universities will tend to resist the idea of keeping students less busy with coursework. Partly because administrators feel that if they want to achieve something, they have to do it by taking active measures. Achieving something merely by leaving students alone is alien to their nature.

And they should be left alone. These things should be the students' own projects; the university should resist the temptation to make them official. Partly because students will be more excited to work on a project that's entirely their own, and partly because many projects wouldn't survive official recognition, because they break some sort of rule. Bill Gates and Mark Zuckerberg both got in trouble with the Harvard administration over projects they worked on as undergrads. Bill broke university rules by bringing Paul Allen, who wasn't a student, into the computer lab with him to work on Altair Basic. Zuck got in such trouble over Facemash that he was put on disciplinary probation. And their cases are probably more the rule than the exception. Universities have lots of rules, and novel projects are often untidy things.

Right now there are students flying drones out of line of sight. Turn a blind eye to it.

Another reason it will be hard for universities to keep students less busy is that they'll worry that without some kind of oversight, most students will just waste whatever free time they're given. And they will! The price of giving the most energetic students room to do even better is that it leaves the least energetic ones room to do even worse. But that's a price that's worth paying, because if the most energetic students do better they could do a lot better, whereas the laziest students already learn so little that there's not much room for them to do worse. So giving all the students some of their time back could improve the average outcome a lot, even if it doesn't move the median.

It may seem a bit excessive to change the whole schedule of the university just to encourage would-be founders. They're never going to be more than 10% of the students. And it probably would be excessive if this change only helped founders. But in fact giving the students some of their time back would help all the most energetic and ambitious ones. They'd all explore new things of one type or another if the pressure of work were relieved for even a week or two.

Now that I've explained how universities should prepare founders, I should explain how not to. One thing universities can't do is actually teach students how to start startups. Starting a startup is one of those things, like chemistry or painting, that you have to learn by doing. Which means a properly run class on how to start a startup would have to be a lab class: the students would actually have to start startups. And I know exactly what a class of this type should look like, because YC is it. But YC is very different in structure from a university, and if you tried to cram it into an undergrad degree program, it would become a joke. Are the students supposed to start these companies without any funding? Are they supposed to run startups, which notoriously take every moment of your time when done properly, while simultaneously taking three or four other classes? And what if, despite these handicaps, some of the startups actually take off? Are the students just supposed to abandon them? Because it's either that or drop out.

Running a startup is incompatible with being a full time student. The only way to learn how to start a startup is to do it. Those two statements are so obvious that they're practically truisms. And yet so many people manage to remain in denial about what they imply. You can't teach students how to start startups.

One common response to this inconvenient truth is to pretend to teach them how to start startups, for example by organizing business plan competitions. The students collaborate to come up with a startup idea, which they then pitch to simulated investors. This kind of exercise is not merely useless but positively misleading. It trains founders to think that fundraising is the essential step in starting a startup — that the core of starting a startup is to create a story that appeals to investors. As an investor, I can tell you that's not true. Fundraising is merely a necessary evil. The people you need to impress are users, not investors, and the way you impress them is with prototypes, not words. The core of starting a startup is not creating a story that appeals to investors, but creating a product that appeals to users.

In fact would-be founders should be doing exactly the opposite of what students do in business plan competitions. Instead of thinking about startups without building anything, they should be building things without thinking about whether they'll turn into startups.

Probably one of the reasons universities are tempted to organize bogus things like business plan competitions is that if they actually took the optimal measures to prepare students to start startups, it would look too quiet. Imagine if a university were doing everything right. Students would be getting a deep knowledge of how to build things in classes they were taking out of genuine interest, and working eagerly with their friends on side projects that had nothing to do with school. The students would graduate with exactly what predicts success in founders: the ability to build things and a habit of doing it. Plus a significant number of those side projects would be incipient startups. And yet it would look to parents and prospective students as if the university wasn't doing anything. Where are the classes on "entrepreneurship"? Where is the Innovation Center?

And indeed this is another great thing about the optimal plan for preparing startup founders: it costs nothing extra. You don't have to hire any deans of entrepreneurship or build any new buildings. In fact if you do, those things will tend to drag you down; there's no need for them, so if they have any effect at all it will tend to be for the worse. If you have spare money, give it to the people teaching computer science or mechanical engineering or molecular biology.

But if the optimal route looks too quiet, the solution is not to avoid it. The solution is to stand firm, knowing that you're doing the right thing, and eventually the results will speak for themselves. If you can develop an organic startup culture among your students and there are multiple students in every year who go on to start successful ones, this will soon become evident to anyone paying attention.

Notes

[1] Should students still study computer science if AIs will write most code? Definitely. CS is an interesting subject in its own right and also a great way to understand problem solving in general. And even if you have AIs writing all your code for you, you're still in the position of an engineering manager, and good engineering managers should be able to do the work of those working for them.

[2] One reason I always put "entrepreneurship" in quotes is that it's a misleading word to use to describe starting startups. "Entrepreneurship" simply means starting one's own business, and startups are a microscopically small subset of that world in which the rules are completely different. So conflating the two is asking for trouble.

[3] Of course all departments will claim to be teaching powerful ideas. But false claims of this type don't seem much of a danger. The sort of people who'd make good founders wouldn't even need to see through them; they simply wouldn't be interested enough in the classes taught by such departments to have much of their time wasted by them.

[4] There's an interesting parallel here to variation in income. The bottom of the income scale is anchored firmly at zero, because there are some people who are either incapable of working or just not interested in doing it at the moment. If you let there be more variation in income, it won't affect the income of the people at this end of the scale; n times zero is zero; but at the other end of the scale you'll see enormous change.

[5] Presumably one reason these competitions lean toward impressing investors rather than users is that it's the only way to have a single set of judges. Investors can be treated as interchangeable, whereas the users of each product might be different. But if it's impractical to measure the right thing, that doesn't mean the solution is to measure the wrong one.

[6] Another thing that will tend to draw universities away from the optimal path is business schools, if they have them. Business schools were not designed to train founders. They were designed to train the managerial class of the large industrial companies that arose in the early 20th century; they're the West Points of industrial capitalism. That's why their official name is usually the School of Management. But while the skills they teach might be useful in running companies beyond a certain size, they're not the critical ingredient in founding them. And the skills that are are already taught by other departments. So to the extent business schools affect their parent university's strategy for preparing founders, it can only be by adding error.

The Harness Is the Company

Why SaaS business is now a harness one.

Every SaaS business will become a harness around a model, whether or not they’ve realized it yet.

What even is a harness?

Narrowly, folks will often associate a “harness” with frameworks like LangGraph or coding agents like Codex, Claude Code, or OpenCode, which wrap a stateless model API in enough tooling and state that you can actually get work done.

I’m using the term “harness” broadly to mean all the infra, interfaces, context, and state that surround a stateless LLM. A harness can be composed of adapted or task-specific sub-harnesses (with the orchestrator being called a “meta-harness”). A “software factory” is a harness whose parts are smaller harnesses — one that writes specs, one that writes code, one that reviews — plus something on top deciding what runs when.

If you accept this broader definition (or replaceAll “harness” with whatever phrase you’d prefer), I suspect for many software service businesses you’ll see this trajectory:

1. They sell software services built the traditional SaaS-y way.

   1. No harness.

2. They sell software services, but the engineers pair with agents to get the work done. Increasingly other functions like product and sales pair with agents for productivity.

   1. Individuals operate harnesses.

3. They sell software services with many core tasks moving to background agents running in the cloud (a laptop can’t run twenty of them). Engineering, product, and sales all trigger these agents (i.e. write the prompts) and review the outputs.

   1. Individuals orchestrate harnesses.

4. They sell software services with many core tasks moving to proactive background agents, with engineering, product, and sales moving to reviewing agent outputs. Consistent reviews move to sampled reviews. Increasingly the agents decide what to do proactively, instead of humans designing the work up front.

   1. Harnesses orchestrate individuals.

Following this trajectory, you’ve actually turned your company into a harness. The work to produce the software service has moved from people to the harness.

• Core tasks are done by agents and the “product” is now entirely model output, with the company supplying the context, integrations, and human-facing review interfaces.
• The relationship between software and org structure has inverted as the org chart becomes a question of where to put people so the harness gets the most taste and judgment out of them. Humans are part of the harness.
• The company’s domain knowledge, tooling, permissions, review loops, context, etc. all become the business harness.

This sounds like an AI slop factory.

It’ll be tempting to think that products that are primarily crafted and reviewed by AI will be inherently low quality and that building through a harness instead of through people will produce a slop factory at scale. I think that belief assumes a company run this way is lights-out.

The core mitigation is actually having the harness pick where human inputs matter most. For example:

• A product decision could come from an agent fanning out questions to reps in customer meetings and then synthesizing a product demo for the product lead to review
• A feature suggestion pulled from a customer meeting is turned into a major architectural decision presented to an engineering taste-holder by the agent.
• A UI redesign kicks off after aggregating feedback, and after testing a few variants, the top options are presented to a design taste-holder.

A good harness maximizes value to the customer while spending human attention — employees’ and customers’ — only where it’s needed.

If you are still skeptical, that’s fair. Even with today’s frontier models and a well-crafted harness, it’s quite difficult to trust agents to handle the outer loop like this. I just don’t think it’s worth betting that models won’t be able to eventually do this, especially as more of this planning-and-review work gets broken into tasks with verifiable rewards that labs can train on.

If harnesses produce and sell the product, that’s now your core competency.

Depending on the service, the differentiation a company has often comes from things like trust, distribution, efficacy, and domain context. In a proactive background agent world, your ability to construct the harness — how it learns, what it watches for, how it interfaces with human taste-holders, what systems it integrates with — will more and more be how you maintain that differentiation.

The harness is now what shapes what must be true for work to ship (~trust), how fast and how the products land (~distribution), the speed and context of feedback loops (~efficacy), and how institutional knowledge is ingested and maintained (~domain context).

Harnesses go from internal tooling you’d happily buy to something you’d no more outsource than your product-eng org or your GTM team. This is distinctly different from the pre-AI world, where outputs were mostly bounded by the humans using the software to get things done.

This is already starting to happen.

I think in-house AI developer tools are the beginning of this.

For AI-pilled companies, waiting for an SDLC tool vendor to add an integration, support a certain interface, or reach a level of cost-efficacy increasingly bottlenecks their ability to build and maintain their product. This is especially true in the short term for third-party tools that can’t yet run an enterprise’s whole software factory for it (often because the tech stack is too bespoke, governance too restrictive, critical feature support too slow, or due to a preferred cost model).

I don’t expect everything to be built and maintained in-house. Rather, companies should own the top-level harness — the one that decides what to build and reviews what comes back — and plug vendor products into it for specific workflows. Eventually a third party will get pretty good at an enterprise-level “spec to tested pull request” and at that point a company can swap out that part of the software loop with that product while still maintaining the agent(s) that write the input spec and handle the next steps from pull request output.

If somehow the entire outer loop can be done by a third-party harness (i.e. running the entire business via proactive background agents as a service), then I’d argue the business has now been commoditized.

So what?

If this is the right mental model, you should expect to see:

• An unusual amount of in-house harness building on both the build side and the sell side
• Org structures and individual roles being reshaped around their place in the business harness
• AI-native startups beating incumbents in domains where the “moat” can be easily harness-ified
• All software a software company uses (on or tied to the core build or sell paths) needing to be headless so the outer harness can run it

Good Culture is the Biggest Productivity Hack, Not AI

AI definitely helps with productivity, but only when you have the right culture in place first!

Intro

This is something that has been on my mind for quite a while now. It seems like everything these days revolves around “AI”, “AI tools”, “AI productivity”.

• “You need to use this AI tool”
• “You need to be using this AI workflow”
• “Your engineers should be 2x, 5x, or even 10x more productive with AI”

And I get it. AI is changing how we build software, and I use AI tools myself every day as well.

But we’re focusing too much on AI tools alone and not enough on the environment in which the tools are being used. Because there’s something a LOT more important than AI tools, and that’s a great culture.

Throughout my 13+ year career in the engineering industry, I’ve seen both the negative effects of bad culture and the positive effects of a good one. I even felt it myself as an engineer and an engineering manager, when departments spent whole days blaming each other for problems.

So, I am a big believer that everything starts with a good culture, and I’ll tell you all about it in this article.

"This is very easy to build now that we have AI, and we don't need as many people"

This is a sentence that breaks a good culture and makes people believe that their job is not important. Especially if it comes from an executive, e.g., a CEO, CPO, or even worse, a CTO.

The problem with it is that it totally decreases psychological safety, and everyone starts wondering whether they'll still be needed or not.

But here is an important thing that many people forget:

There is no better productivity hack than a great culture. No AI tools will provide bigger productivity gains.

I’ve unfortunately seen and heard this sentence quite a few times, either directly or from an engineer or engineering leader who has reported that to me.

Without good culture, everything else won’t work well

Many executives believe that AI will just magically increase the productivity of everyone. But the reason that often doesn’t work is Conway’s law. It states:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

I mention this law quite a lot in different articles, because it’s just so important. And the reason why it’s particularly relevant in this case is that the overall productivity and the “end product” mimic the overall culture of the organization.

If the culture is bad, the end product will be bad as well, because people just don’t work together well and they don’t communicate properly. But if the culture is good, then often the end product will be good as well.

So, you should always think about good culture as a prerequisite for everything else. And I like to make an analogy to what health is to us, humans. Without health, we can’t do anything else well.

“Other companies are 10x more productive by using this AI tool”

Now, here comes the problem that many people fall into, especially CEOs and other executives. They see either a competitor or some other company reporting 10x higher productivity using a certain AI tool.

They start to panic, they start feeling FOMO (fear of missing out), and they start blaming people around them: “Why don’t we have that same amount of productivity as well?”

A lot of the CEOs are unaware of what kind of problems this may bring. Especially to the culture of the organization. When you start actively “blaming”, it shows to everyone that they are not doing their job well, and that you don’t trust them to make good decisions.

What many CEOs don’t realize is that a lot of the “reporting” of AI increasing productivity by 10x is more or less selling a certain AI product, or a certain partnership where they are promoting the other product.

My recommendation: Always take a look at what the incentives are behind people saying something, that says a lot about whether it’s true or not.

AI makes good culture even more valuable

Here is another really important point, and many people seem to forget it. As we mentioned, good culture is a prerequisite for everything else. But when it comes to AI, it amplifies everything you already have.

So, both AI and good culture go hand in hand really well together. AI makes bad communication even worse, it also makes bad architecture even worse as well.

But if you have a good culture and good architecture, people will be more productive because they will help each other, and AI will also have a better blueprint of what good looks like because of good architecture.

This is my recommendation for building a good culture

If you’re wondering whether you have a great culture inside your team or organization, here are some useful questions to answer:

• Do people know what they are responsible for?
• Can they make decisions without unnecessary approvals?
• Do they feel safe challenging leadership?
• Do teams trust each other?
• Are priorities clear?
• Can people disagree constructively?
• Do we reward outcomes?
• Do people understand why they are building something?
• Do we learn from failures, or do we look for someone to blame?

How to correctly message AI adoption

The best messaging I saw (and has worked well) is the following:

What great engineers and engineering leaders do is learn and utilize all different tools that help them do the work better. This hasn’t really changed. AI is like any other tool that has come out over the years. Use it in your favor to help your team, organization, and the business. That’s what great engineers and engineering leaders do. And it hasn’t changed with AI.

Don’t ever mention something even close to “replacing” or something along the lines of “You are not important anymore, because we have AI”. Those are just going to completely diminish morale and break the entire culture.

When it comes to AI adoption, it only works bottom-up, it never works top-down. Trying to “force” people will only result in bad outcomes.

Replacing engineers with AI is not the way to go

I fully believe that the best companies hire more engineers, not fewer, and the reason is that with more people, you exponentially increase your productivity as well. Of course, the prerequisite is that the company culture is on point. Without it, it won’t work.

Time to market (TTM) is a very important metric in the age of AI, and I strongly believe that the best companies in a specific industry are going to be the ones that are going to move the fastest, make adjustments based on market needs, and provide the best experience for the users.

Last words

I DON’T think the biggest question for leaders should be: “How do we get everyone to use AI?” The biggest question is:

“How do we build an organization where great people can do their best work, and then use AI to multiply them?”

This is the real question that organizations should be asking and focusing on. Great culture is the biggest productivity hack.

There was an announcement on SpaceX’s first-ever earnings call that got the attention of the wireless industry. SpaceX said on the call that StarLink would enter the terrestrial cellular business by building a large number of cell sites provisioned with satellite backhaul. The company would leverage the power of its next-generation V3 satellites along with an increasingly larger fleet of satellites to provide the backhaul to feed cell sites.

It’s impossible to know if the company is serious about this. Elon Musk has always made exaggerated claims of what he will be doing in the future, and many of his claims never came to fruition. On the same call, Elon also said that the company plans to build factories on the moon.

There are a number of obstacles that stand in the way of SpaceX pulling this off. First is the basic question of why anybody would wade into the U.S. cellular market that has become increasingly competitive. Starlink could probably only gain significant numbers of customers by lowering prices, and that brings into question how profitable this might be.

Cellular networks in cities have already boosted cellular data speeds to 300 Mbps or faster, so Starlink wouldn’t have any technological advantage. Perhaps the real goal of the company is not the U.S. market, but populous countries like Nigeria, which have inferior cellular networks and a population that relies on cellular much more than on landline broadband.

At least for now, Starlink doesn’t have enough spectrum to pull this off. They are acquiring 65 MHz of spectrum from EchoStar, which is not nearly enough to compete for terrestrial cellular service. However, after the recent IPO, the company is awash with cash and could buy more spectrum. In the OBBB, Congress mandated the FCC to find 800 MHz of midrange spectrum for auction, so there will be plenty of spectrum coming into play over the next decade.

Another big question for me is the overall bandwidth needed to feed a cellular network. Most cell sites today are fed with 5-10 Gigabit backbone connections. The new Starlink constellations will have a greatly increased amount of capacity, but the backhaul to hundreds of thousands of cell sites would have to eat into the overall capacity of the satellite constellation. SpaceX must be counting on being able to grow far past the current 15,000 satellites currently approved by the FCC, and in fact, they have requested to grow the constellation to 100,000 satellites. The increasing usage to support cellular would also mean the need for a lot more earth stations to feed the network.

Perhaps the biggest obstacle would be getting started. The three big carriers all have roaming agreements with each other, but they might decide not to make it easy for a new competitor to enter the market. Very few people would buy a cellular service that wouldn’t work when they travel to other parts of the country. There was speculation after SpaceX made this announcement that the real purpose was to pressure the big cellular companies into giving the company an MVNO deal (resold cellular) so it could combine terrestrial resold cellular with satellite cellular. That’s an interesting dilemma for the big cellular companies, because if SpaceX had an MVNO, it could then selectively build cell sites over time.

SpaceX will likely never stop surprising the market with big ideas that are outside of the box. While this one is certainly doable, it wouldn’t be easy unless one of the big cellular companies blinks and lets SpaceX into the cellular business through the backdoor of an MVNO. But you can never say that SpaceX wouldn’t do this even without that easy onramp.

Why it matters

Ox Alpha reached OpenCode's No. 2 usage slot without a known developer or token price, showing how coding-agent distribution can manufacture model-scale demand almost overnight.

Dax Raad (@thdxr)'s OpenCode said its users processed 26 trillion tokens through Ox Alpha during the anonymous AI model's first four days, turning a free preview into one of the largest model trials on the coding agent.

The August 24th disclosure covered 327,000 unique users and 8,328,244 completed sessions, according to OpenCode's usage dashboard. Ox Alpha ranked second among models tracked by OpenCode, behind DeepSeek V4 Flash at 33 trillion tokens and ahead of Xiaomi's MiMo-V2.5 at 12 trillion.

Raad created OpenCode as an open-source, terminal-based coding agent that could work across models rather than locking developers into one lab. He said in a 2025 interview with Baseten that maintaining compatibility across a constant stream of models was precisely where an open-source community could help. The OpenCode repository had passed 200,000 GitHub stars by August 24th.

Free distribution did what free distribution does

OpenCode introduced Ox Alpha on August 20th as a stealth model with multimodal inputs, a one-million-token context window, near-unlimited usage and zero data retention through OpenCode's route. OpenCode also claimed it had secured capacity for as many as 100 trillion tokens per day.

Actual usage averaged about 6.5 trillion tokens per day over the first four days, or 6.5% of that advertised daily capacity. OpenCode recorded an average of 3.2 million tokens across each completed session and roughly 25 sessions for every unique user.

OpenRouter separately reported that Ox Alpha generated 11.6 trillion tokens during its first three full days on that platform, making it the largest model launch in OpenRouter's history. The next-biggest launch generated 4.4 trillion tokens over the same opening period, and OpenRouter said Ox Alpha was on track to process nearly 6 trillion tokens that day.

Those figures describe aggregate session activity rather than prompt size. OpenCode's dashboard also says 93% of input tokens were served from cache, meaning the headline total combines fresh inputs with context reused during long coding sessions. The $0 spend shown on the dashboard reflects the price charged to users, rather than the underlying cost of supplying the inference.

The distribution strategy still worked. Ox Alpha captured 6.8% of observed OpenCode token volume within four days despite carrying no recognized lab name. Price, a large context window and placement inside a coding agent with an established developer base removed most of the friction that usually limits a model preview.

OpenCode's Go documentation lists Ox Alpha as free for a limited time, with no stated token prices or fixed usage allowance. The model is available through an OpenAI-compatible endpoint, making it possible for developers to substitute Ox Alpha into existing agent workflows with relatively little integration work.

The anonymous provider is the catch

OpenCode's own model page identifies Ox Alpha's maker as "Unknown" and supplies no release, knowledge-cutoff or output-limit metadata. OpenRouter's official listing says a third-party provider developed and operates Ox Alpha while remaining anonymous during the preview. OpenRouter lists a 1,048,576-token context window and charges $0 for input and output tokens.

The two distribution routes carry different data terms. OpenCode says prompts sent through its Go service have zero-day retention and are not used for model training. OpenRouter says the anonymous provider retains prompts and completions, although it does not use them for training. Developers handling proprietary repositories therefore need to check which endpoint is receiving their code rather than treating every free Ox Alpha route as interchangeable.

The early load also exposed integration problems. A GitHub issue opened on August 23rd reported that Ox Alpha requests containing tool definitions were failing through OpenCode's Zen and Go endpoints even while plain chat requests continued to work. Tool use is central to coding agents, which must read files, execute commands and edit repositories rather than simply generate text.

The preview fits the model-selection thesis behind OpenCode's Zen service. Raad has described Zen as a way to pool developer demand, test model deployments and negotiate inference rates using OpenCode's combined volume. Ox Alpha pushes that approach further: an unidentified lab gets millions of real coding sessions, while OpenCode gets a high-capacity model that can attract users without adding token charges during the preview.

The 26 trillion figure is a demand metric produced under zero-dollar pricing. Model quality remains a separate question, especially while Ox Alpha's developer, architecture and full evaluation record remain unidentified. The clearest result after four days is that OpenCode can direct enormous workloads toward a model when it controls both the coding interface and the price of access.

Hot Chips 2026: CUDA Targets RISC-V

CUDA is the most important software framework in the GPU compute world, and Nvidia is looking at supporting CUDA on RISC-V. Terms and conditions may apply.

CUDA is a giant for GPU compute, which includes machine learning applications. So far, CUDA supports x86-64 and aarch64 CPUs. Now, Nvidia is looking at extending CUDA support to RISC-V. This move opens the door for RISC-V CPUs to feed GPU compute. Nvidia’s talk focuses on the requirements that RISC-V CPUs must fulfill to work with CUDA. Basically, they want a server-grade CPU and platform.

Nvidia starts by requiring a RVA23 CPU, and adherence to RISC-V’s server SoC and server platform specifications. Those specifications include RAS (reliability, availability, and serviceability) features, a specialized security processor, and other baseline features. Nvidia gets most of their server-grade expectations fulfilled by those specifications.

Nvidia has a few more requirements that go beyond the RISC-V profile or platform specifications listed above, because they found it difficult to make CUDA software work well without those features. They don’t want a lowest common denominator problem, where they can’t use performance-enhancing extensions because they can’t guarantee they’ll be running on hardware with those extensions supported. From Nvidia’s perspective, that would force them to ship inefficient code. Nvidia brought up vector extensions as an example, because predication support lets them avoid branches.

ACPI is a more difficult requirement. ACPI lets software discover what hardware can do, and can be used for power, performance, and thermal management. Nvidia’s software team wasn’t happy because RISC-V hardware didn’t have ACPI when they started porting CUDA, but that situation has been resolved. In 2025, the UEFI forum added RISC-V ACPI support. The RISC-V BRS (Boot and Runtime Services) specification was ratified last year, and includes ACPI.

Then, Nvidia requires PCIe coherency. Nvidia brings up a memory ordering problem where the CPU has written data, but that data is sitting in a cache. If CUDA kicks off a DMA request to copy that data to the GPU, the DMA engines may read data from DRAM and miss modified data sitting in CPU-side caches. When copying results back from the GPU, the CPU could read stale data from its caches after the DMA engines write data to DRAM. Software would have to explicitly invalidate caches to avoid that scenario if the system doesn’t have PCIe coherency. Working cache invalidations into the CUDA stack would be difficult, and Nvidia considers PCIe coherency to be a standard feature in a server CPU. RISC-V’s server SoC specification recommends that hardware implement cache coherency, but Nvidia wants a guarantee.

Nvidia also wants hardware to support peer-to-peer PCIe communication. Without this capability, buffers copied between two devices would have to go through CPU memory, which costs performance and increase complexity because it’ll need extra synchronization signals.

Unfortunately, Nvidia didn’t go over all requirements in detail. They noted that they’re aiming for a certain level of performance, and that the overall list fits within two pages. It’s an open question whether it’s like two double-spaced pages with large font, or two note pages allowed for an open-note exam (which a student will creatively fill with as much information as possible).

NVLink Fusion Requirements

Besides running CUDA on RISC-V CPUs, Nvidia briefly went over requirements for NVLink Fusion. NVLink Fusion lets other companies implement Nvidia’s NVLink IP on their chips, letting them use Nvidia’s NVLink C2C link with a custom CPU of their choice. A hypothetical product would work much like Nvidia’s GB10, which linked Mediatek’s CPU die with an Nvidia GPU using NVLink C2C. Nvidia would of course want customers to use Nvidia’s CPUs as well. But if customers want to connect custom CPUs or other accelerators, Nvidia would still like them to use their NVLink IP. The custom CPU could be a RISC-V one.

NVLink Fusion’s requirements include all of CUDA’s requirements, along with whatever’s needed to support software frameworks like DOCA and NCCL. Requirements extend to having a close partnership with Nvidia, which sounds like a given. Integrating IP can be a complex endeavor, and would likely require close cooperation along the lines of Mediatek’s cooperation with Nvidia for GB10.

Impressions from Nvidia’s Talk

RISC-V’s software ecosystem has some distance to go before catching up to x86-64 and aarch64. Nvidia’s effort to bring CUDA into the RISC-V world is a promising development. Unfortunately, those efforts don’t necessarily mean you can attach a Nvidia GPU to a RISC-V system and get cracking with CUDA. The vast majority of existing RISC-V hardware won’t meet Nvidia’s requirements. In fact, I would be surprised if any RISC-V consumer hardware meets those requirements in the near future. ACPI is an obvious sticking point, and seems difficult for vendors to pick up. In the aarch64 world, ACPI support has been spotty at best even though it has been in standards for years. A RISC-V standard ratified in 2025 would likely take several years to get wide support, if not more.

When and if RISC-V systems start showing up with CUDA support, they’ll likely be server systems rather than the single board computers hobbyists can afford. Nvidia noted that they’re partnering with SiFive, and SiFive plans to demo a system running CUDA at Hot Chips. Nvidia implied the example CPU specifications on their slide correspond to that system, and those specifications suggest it’s a high core count server chip. I look forward to seeing that, but I also hope Nvidia doesn’t block CUDA from running on unsupported systems. I would love to see enthusiasts take a shot at feeding Nvidia GPUs from RISC-V systems.

Going forward, I hope Nvidia can relax their requirements to give existing RISC-V systems a better chance of meeting them. Lack of vector extensions or PCIe coherency doesn’t necessarily lead to intractable performance problems. Using branches instead of predication can work well if those branches are predictable, which they often are. Cache invalidations required to work around lack of PCIe coherency will incur a performance cost. However, that cost may be acceptable for workloads that do a lot of compute compared to data movement. The same applies to PCIe peer-to-peer transfers. It’s great to have things go fast, but things that don’t happen often can be put on a slow path if you’re careful. Hopefully, Nvidia’s current requirements stem from expedience, and were set to allow a fast, low-risk RISC-V port. And hopefully, CUDA evolves in a way that makes it accessible to a wide range RISC-V systems, not just specialized enterprise designs.

In short : AI hardware bottlenecks cascade in sequential multi-year waves from GPUs to memory, SSDs, CPUs, HDDs, and physical data center shells, driving facility buildout costs to $20b per gigawatt through the classic Bullwhip Effect.

The popular narrative of AI infrastructure is a tidy relay race : first GPUs were scarce, then memory choked throughput, then CPUs took the strain, & finally storage started to bite.

The pricing data says the relay is real but slow. Some components plunged before they surged. Each bottleneck freezes the next component’s supply chain, but the lag runs in years, & every wave locks in a higher baseline cost.

The initial shock in early 2023 belonged to the GPU. When ChatGPT launched, buyers concentrated capital on procuring GPUs, sending on-demand Nvidia H100 rental rates past $9 an hour.

That monomania starved conventional computing. Server unit shipments fell 22% in 2023 to below 2018 levels as buyers deferred refresh cycles to fund GPUs. Memory makers, already reeling from a post-pandemic glut that cost the industry more than $20b & forced wafer cuts of up to 40%, lost the server demand that would have absorbed their inventory.

Eighteen months later, the pressure migrated to memory. To escape that slump & chase AI margins, manufacturers converted cleanrooms & lithography tools toward High Bandwidth Memory (HBM).

HBM consumes roughly three times the wafer capacity per gigabyte of standard DDR5, so every bit of HBM output removes about three bits of conventional supply. Enterprise solid state drive (SSD) contract prices rose 80% in a single quarter, while Micron reported dynamic random-access memory (DRAM) prices climbing in the low-60s percentage range quarter over quarter.

By late 2025, agents squeezed server CPUs. Training clusters ran one central processing unit (CPU) to eight GPUs. Agentic workflows invert that : autonomous systems spend their cycles compiling code, calling tools, & managing state, pushing the ratio toward 1:1. Intel reported server CPU average selling prices (ASPs) rose 27% year over year against falling unit volumes, citing billions in unmet Xeon demand.

By 2026, the shortage reached bulk storage. Priced out of high-speed flash at $150 per terabyte, cloud architects retreated down the technology ladder into traditional, slower hard disk drives (HDDs) for bulk training data lakes. Western Digital & Seagate confirmed their entire 2026 nearline production is sold out.

Beyond the server chassis, the story is unambiguous. The fastest-rising cost is the data center’s concrete floor & the reinforced walls.

Data centers now cost upwards of $20b per gigawatt ($20b/GW), with electrical systems consuming half the budget. Construction costs have tripled to $1,033 per square foot, excluding land. Outside, generator step-up (GSU) transformers average nearly three year lead times, while GE Vernova & Siemens Energy have sold out turbine production through 2029, with order books stretching to 2031.

As Barry Powell of Siemens observed of the double bind :

“You’re damned if you do, damned if you don’t: If you don’t build enough, then you’re going to get dinged for losing some market share. And if you build too much, you’re going to get dinged for fixed costs. We understand at some point there could be a bubble and we’re racing to pay back the investments as quickly as possible.”

This is the Bullwhip Effect in physical hardware. When a value chain suffers from multi-year manufacturing latency, sudden demand shocks downstream amplify into massive, lagged overreactions upstream. Relieving pressure at one bottleneck pushes it into the next component with a predictable delay. When the wave finally breaks, long-lead-time capital goods are the ones left exposed to overcapacity.

Over $2b in domestic transformer expansions, next-generation 300-layer NAND fabs, & new turbine production lines will deliver in 2027 & 2028. If end-user software revenues do not keep pace with $20b per gigawatt facilities, capital expenditure will face a classic crack of the whip.

Large language models are transforming software development by making code generation faster and cheaper, shifting the primary challenge from creating code to trusting and verifying it. Advanced engineering organizations like Stripe, Spotify, and Amplitude have started integrating AI-generated code into production, emphasizing the need for robust governance, context, and verification systems.

Alibaba launches Wan3.0 AI video model after record $10 billion share sale

Alibaba Group (NYSE:BABA), the Chinese technology giant, officially rolled out its latest artificial intelligence (AI) video generation model, Wan3.0, on Monday.

The new software can generate 30-second videos directly from text documents, data spreadsheets, presentation slides, and web pages.

Alibaba Cloud, the company's cloud computing division, said the model has supported short film production, commercial advertising, tourism marketing, and music videos since launching in public beta on August 6.

The rollout comes after the group launched a $10 billion share placement to fund rising capital expenditure in the global artificial intelligence race.

The transaction represents the largest-ever primary follow-on equity offering conducted by a company listed in Hong Kong.

Alibaba recently reported a 75% plunge in quarterly net profit to 10.44 billion yuan as capital spending jumped 75% to 67.68 billion yuan.

Alibaba shares fell 8.1% to HK$113 in Hong Kong trading on Monday after the group priced 710 million new shares at an 8.4% discount.

The new shares represent approximately 3.7% of existing issued capital, with completion of the equity sale scheduled for August 26.

The company will direct all net proceeds toward upgrading infrastructure for its Qwen models and expanding full-stack AI computing capabilities.

Management is betting that strong enterprise demand will justify mounting infrastructure costs, supported by a 45% increase in AI cloud revenue to 48.44 billion yuan.

Apply for a grant

We are offering up to $1M total in grants of free Silico usage for select academic labs, nonprofits, and individual researchers working on AI interpretability, alignment, and life sciences.

01 / APPLY

Tell us about your research agenda

Share one to two pages describing your research agenda and how Silico can help.

02 / INTERVIEW

Talk to the Goodfire team

Selected applicants will meet with the Goodfire team before grants are awarded.

03 / ACCESS

Research with Silico

Your grant covers free usage of Silico, including both our interpretability agent and compute.

Adobe's Firefly now offers Generate Music, Generate Speech, and Generate Sound Effects as generally available tools, letting creators produce full video soundtracks within one workspace. These features build instrumental tracks from descriptions or footage, convert scripts into voiceovers in over 20 languages, and create custom sound effects from text or reference audio. The expansion aims to reduce reliance on separate audio tools, though its success hinges on whether the generated output proves consistently strong enough to replace dedicated services.

Apple is reportedly preparing a refreshed iMac with the new M6 chip and updated color options, marking its first update in two years, with a launch expected before the end of 2026. The M6 will be Apple's first Mac chip built on a 2nm process. The release is expected to be part of a broader wave of Mac updates later this year.

Upload

Download and drop what you just built. An HTML file, a screenshot, a PDF. Or don’t even download it: tell Claude “make this a ProtoNote” and the share link comes back in chat.

Upload several files together. They become pages of one project, each with its own notes.

All of your prototypes get a permanent home. Folders keep them organized instead of lost in ten thousand chats.

Share

Send one link. Your work is hosted for you and presented like a product, not an attachment. It opens on any device, with a real preview in Slack, your name, and a note on what to look at.

No account needed to review. Your manager types their name and starts. No signup wall has ever improved feedback.

You’ll know it landed: “Viewed by Maya · 2h ago,” right on your dashboard.

Get notes

Notes pin to the exact spot, on the exact version. They appear live as your team reviews. Ship v2 and the old notes stay where they belong.

No refreshing the dashboard. You’re notified as notes and replies come in.

The loop

Then the feedback goes back to work. Pull your ProtoNotes into Claude and apply the changes. Reviewers stay in their browser, you stay in your chat.

Pricing

Free

• 3 active prototypes
• HTML, Markdown, images & PDFs
• Unlimited reviewers & notes
• Email notifications

Pro

• Unlimited prototypes
• Folders & version history
• Know who viewed, and when

Reviewing is always free. No one you share with ever pays.

Build with templates, blocks, skills, and AI. Not blank pages

Import and edit Templates

Never start from a blank slate again. Pull in Aceternity UI Pro templates and reshape layout, copy, and structure in chat.

Edit blocks and components

Drop in sections, cards, and other blocks, then tweak them in place without leaving the editor.

Skills that push back on generic output

Point at a section, run a skill, get sharper layout and copy.

Use skills to counter AI slop

Point at a section, run a skill, and get sharper layout and copy decisions, not another wall of default Tailwind cards.

Escape to the peaks

Plan your next alpine trip with guides, trails, and stays in one place.

Create images on the go

Generate a scene, apply it as a background, and keep building. No stock photo rabbit holes.

Used by over 120,000 people all around the world

The same community that grew with Aceternity UI, now shipping full sites with an AI builder on top.

Templates and Pro blocks, ready to edit

The same Aceternity UI Pro templates and section blocks you pick from chat. Drop them in, then reshape layout and copy without starting from zero.

Frequently asked questions

Quick answers about credits, code export, Aceternity Pro, and billing before you start building.

How are credits consumed?

Credits are spent when the AI works for you, not just when you send a short message. Each turn can charge for the model response, tools it runs (reading and editing files, search, imports), image generation, screenshots, and related work. Heavier models and longer build sessions use more credits.

Launch faster with production-ready UI blocks.

Ship polished landing pages in hours. Pick a block, customize it, and move from idea to launch without rebuilding layout primitives.

There's a lot of things I love about Adobe software. But as a journalist, there's one thing I don't love about Adobe the company, and it's their penchant for making announcements that sound new, but aren't that new. Although I must admit: this does provides me with employment in explaining what's going on.

So, here we are again. Adobe's recent blog post titled "Introducing Adobe for ChatGPT: Create, edit and get work done — all in ChatGPT" might have made you think that their team-up with the chatbot was a new thing. But just for the record, Adobe Photoshop, Adobe Express and Adobe Acrobat have all been living inside ChatGPT since December 2025. That in itself is not new.

What is new, though is that these tools – along with a bunch of others, including Firefly, Premiere, Lightroom, Illustrator, InDesign and Adobe Stock – can now be accessed via a single, unified plugin. Which, on the face of it, sounds very handy.

Indeed, Adobe have made things even simpler than that. You now just have to type "@Adobe" into ChatGPT, then describe what you want, and the plugin will decide which of its 70-plus tools to reach for. Pretty neat, huh?

Even more intriguingly, you don't have to be a Creative Cloud member, you can just use it as a guest. And I can imagine that will excite a lot of people who don't know how to use design software, or who've never used Creative Cloud and want to know what it's capable of.

That said, Creative Bloq's audience is mainly made of creative professionals for whom that won't be the case. So if that includes you, and you're already a Creative Cloud subscriber, is there any point?

After all, you already have Photoshop's generative fill, Premiere's auto-reframe and Firefly within a Creative Cloud interface that's probably become second-nature to you. So instead of being able to access features layers, masks, granular colour work and undo history through a series of familiar menus, you're faced with typing a sentence and hoping the plugin picks the right tool from a multitude of options. Not exactly a sense of being in control.

I'd guess that in most cases, this will be more trouble than its worth to you. But at the same time, I think Adobe gets points for giving you extra options. And one place I could imagine this being helpful is at the edges of a job, rather than the core of it.

For example, generating event badges out of entries in a spreadsheet, fashioning video shorts for socials out of two-hour video, whipping up a quick mood board before (or even during) a client call... these are things Creative Cloud handles well as it is. But if this new ChatGPT plugin can save you 15 minutes of messing about with menus, why not?

Even Adobe's own press release accepts that this option isn't for prime time: in their own words, "when you want advanced editing, creative control or pixel-level precision, you can continue your work in Adobe’s apps right where you left off." For "pixel-level precision" you might read, "something that doesn't look like it's been knocked up in a few minutes". Which is, of course, what you want for finished work. For some of the in-between stuff, though, "knocked up in a few minutes" might actually be fine.

In short, I don't think Adobe's ChatGPT plugin is a game changer, or even anything many creatives will find useful in the long term. But at the same time, I don't think it's a bad thing to offer. It might be fun trying it out. And who knows? It might help you to speed up some bits of your work that you really hate. Probably worth a try anyway.

Apple's first new Mac mini in almost two years will debut as soon as the next few days. The upgrade follows a surge in demand for the current Mac mini, which has become popular for running AI applications locally. It is part of a wave of new products Apple plans to release in the second half of this year. Apple is set to hold an event on September 9 where it will introduce its first foldable smartphone, as well as the iPhone 18 Pro line. The company is also preparing a range of new Apple Watches and fresh AirPods.

The World Humanoid Games in Beijing showed how much has changed since last year. The robots are faster, more intelligent, and more capable. The rapid pace of robotic hardware and software innovation is enabling a robust ecosystem that can both build things and isn't afraid to break them. There is now a massive number of companies producing a truly amazing number of robots.

YouTube and Roku are racing to become one-stop shops for all of the content people watch on their TVs. Some paying YouTube subscribers will soon have access to content from Peacock as part of a recent deal between the two companies. The streaming wars have now morphed into a bundling war. The biggest streaming companies no longer just want to have the most subscribers - they also want to be the main entry point to everything streaming has to offer.

75% oppose local data center development, despite the economic benefits.

Senior designers with 15+ years of experience, once considered secure, are increasingly vulnerable as AI tools make specialized skills widely accessible. Sunk cost fallacy and status quo bias keep experienced creatives clinging to methods that built their careers, even as the industry shifts beneath them. Their path forward involves pairing accumulated judgment and relationships with the adaptability younger designers have been forced to develop.

Creative progress can be measured by tying work to business outcomes rather than relying solely on subjective judgments of quality. Success metrics might include revenue growth, funding raised, user engagement, stakeholder buy-in, project approvals, or other goals defined before the work begins. Creative leaders can also track testimonials, projects completed, teams led, presentations given, and before-and-after comparisons to demonstrate both personal growth and the tangible impact of their work.

Discover a curated gallery of app screenshots to inspire your App Store Optimization (ASO) and mobile app UI design.

Myako is a bold display typeface by Limitype that combines oversized curves with deep inktrap cuts to create a distinctive blend of retro warmth and modern precision. Designed for headlines, packaging, posters, and branding, its heavy letterforms maintain clarity at large sizes while providing strong visual impact across print and digital applications. The extensive character set and crisp, high-contrast design make it a versatile choice for brands looking to create memorable, attention-grabbing typography.

Illustrator Myriam Wares' Winter series uses surreal, Italy-inspired imagery to capture the homesickness, disorientation, and in-between feeling of adapting to life in a new country after moving from Montreal to Turin.