While much attention has focused on the updated financials Anthropic revealed in its revised S-1/A on Monday (revenue is soaring, but so are expenses), the AI lab dropped another little bombshell in the fine print.

The filing seems to warn that the company is on the cusp of creating a model capable of recursive self-improvement (RSI).

RSI is the point at which AI grows so good at training itself that it spawns a dramatic acceleration of AI capabilities. To the AI doomers, RSI represents the cataclysm from which there is no return, in which AI builds itself into something powerful enough that it slips beyond human control and may be indifferent to the damage it causes while achieving its goals.

To AI enthusiasts, RSI, or some version of AI reliably using itself to improve, represents the technology’s promise, where it becomes a tool of unimaginable productivity, scientific discovery, and more.

Anthropic seems to believe that RSI is both a promise and a peril. It says in the S-1 that it uses AI in its R&D, but it cautions: “Using AI to help build more capable AI could also pose a considerable safety risk, particularly if it sharply accelerates the pace of progress. This is one of the areas covered by our Responsible Scaling Policy, which sets out our plans to monitor and mitigate the risks as we approach what has been termed ‘recursive self-improvement.’”

When the term RSI became popular earlier this year, many believed it was a buzzword or, at best, a goal too hard to achieve, define, or prove.

But on Monday, Anthropic added new statements to its Risk Factors section, saying 1) it has already used AI to develop new models whose leaps in capability it didn’t recognize at the time, and 2) it may soon meet its own definition of RSI (bold emphasis ours, below):

In addition, our increasing use of AI systems to accelerate our own research and development may cause the capabilities of our models to advance more rapidly than our ability to develop, validate, and implement corresponding safety, alignment, and security measures. As a result, we have in the past not identified, and may in the future not identify, a significant acceleration in our rate of development until after it has occurred.

For example, our internal estimates and our expectations regarding future models, rather than our current models, indicate that we may imminently meet our Responsible Scaling Policy’s definition of “dramatically accelerated progress attributable to AI.” We have not designated any of our current models as exceeding this threshold, and we continue to assess the underlying data.

However, Anthropic also said in the filing that none of its models have crossed this RSI threshold yet and that it is promising to keep humans in the R&D process for the foreseeable future. “We do not anticipate being able to safely use Claude to fully autonomously design and build successive generations of frontier models without meaningful human supervision or understanding, if and when that becomes technically possible. Accordingly, we are considering updates to our Responsible Scaling Policy to keep humans in control of frontier model development at Anthropic.”

Skeptics might point out that an S-1 functions as both disclosure and marketing, and that claims of being close to a model so powerful that it can build itself could fall into the latter category.

Nevertheless, there’s no question that Claude’s capabilities, especially in terms of coding, math, and cybersecurity, have grown leaps and bounds this year. If Anthropic thinks the possibility of RSI is close, maybe we should believe it and act — perhaps govern — accordingly.

The GitLost disclosure showed how an agent with access to public and private repos can leak private data. Researchers at Noma Labs created an agent with permission to read public and private repositories across an organization and respond to issues in a public repo. They then opened a malicious public issue that caused the agent to post the contents of a private repo in a public comment.

The attack did not require breaking out of a sandbox or stealing an auth token. Once the agent had permission to read from a private repository and write to a public one, the attacker persuaded it to use its permissions in a way that the maintainer did not intend or want.

GitHub Agentic Workflows became Generally Available during GitHub Universe last week, and the release includes a new way to prevent private-to-public leaks like GitLost in cross-repo workflows. Our solution is an experimental security primitive called an enclave, which allows an agent to access private data and deterministically constrain what it can say about it.

An enclave is a single-use sandbox that allows the primary agent in an agentic workflow to isolate itself from work in another repository. An enclave’s purpose is to prevent the primary agent from seeing private information so that it cannot inadvertently over-share. Military and intelligence organizations apply the principle of need-to-know by compartmentalizing operations so that personnel working on one mission don’t necessarily have access to information about another. Even someone with a high security clearance doesn’t automatically get access to every classified operation. Enclaves allow the same compartmentalization among agents.

Overview of enclaves

An agentic workflow’s primary agent can only access the repo in which it executes, but it can use enclaves to perform work in repos outside of its own. Primary agents launch an enclave by specifying the enclave’s repo, the computation to be performed, and a response schema. Interactions between the primary agent and enclaves are handled by a trusted broker that validates the primary’s launch request, runs enclaves in isolation, and validates enclave responses to the primary agent.

Like FIDES’s constrained output schemas for LLM calls, the primary agent specifies response schemas for its enclaves. The response schema defines the vocabulary the enclave uses to communicate with the primary agent. Schemas are typically limited to Booleans, enumerations, bounded integers, and structured combinations of those base types. The enclave cannot add explanations, attach files, or return arbitrary strings. The broker checks every response against the schema and rejects anything outside it.

The amount of information the response schema can carry is constrained by an information budget that is measured in bits. The workflow configuration determines the budget via the enclave repository’s sensitivity. For example, a sensitivity of confidential permits 8 bits per repository per workflow run.

The broker validates the primary agent’s response schema to ensure that it cannot reveal more bits than the workflow author budgeted. A Boolean has two possible values and can convey one bit through its successful result. A choice among four categories can convey two bits. Combining fields increases the number of possible responses and the information the result can carry. Importantly, a single bit in the schema is always reserved for errors. Validation errors, runtime errors, budget overflow errors, and timeout errors all set the error bit.

While the workflow author sets the budget, the primary agent defines the schema’s semantics and chooses how to spend the available budget. It might ask whether an API is used, classify compatibility, or request a bounded count. It chooses the field names, allowed values, and task instructions that give those values meaning. This flexibility lets the agent tailor a narrow response to the work at hand without receiving unrestricted access to the repository.

Before launching an enclave, the broker calculates a schema-compliant response’s information charge, including the constrained status and timing channels, and checks it against the repository’s remaining budget. The charge is reserved before execution rather than determined by the answer that comes back. Calls share the same per-repository ledger for the run, so the primary agent can adapt its questions but cannot grow the budget or reset it by choosing a new schema. If an enclave response would exceed the balance, the broker denies it.

Two kinds of enclave work

Agentic workflows support two enclave executors:

Script enclaves run bounded Python programs over read-only repository snapshots, without network access. They are useful for deterministic checks, such as whether a file exists, whether a dependency appears in a manifest, or whether a configuration satisfies a rule.

Agent enclaves run a separate coding agent for tasks that need reasoning. An agent enclave might inspect an implementation and classify whether a reported bug applies. Its network access is restricted to the configured model-provider path and, when explicitly enabled, a narrow GitHub tool interface. It does not receive general-purpose GitHub credentials or unrestricted network access.

Enclaves are declared in workflow front matter. This configuration excerpt enables both kinds for the same private repository:

sandbox:
  agent:
    id: awf
enclaves:
  - script:
    repos:
      - repo: myorg/private-service
        sensitivity: confidential
    timeout: 45
  - agent:
      model: gpt-5
    repos:
      - repo: myorg/private-service
        sensitivity: confidential
    timeout: 180

The workflow must separately provide credentials that authorize access to the repository. Declaring an enclave cannot expand what those credentials can read. The primary agent receives enclave tools through the MCP gateway. The primary never sees private repository snapshots or any auth credentials.

The maintainer chooses the repository policy, sensitivity, and execution limits. A tool call cannot override those settings merely because the agent asks for a different runtime or broader access.

GitLost with enclaves

Let’s return to GitLost. The attack depended on an agent reading a private repository and posting its contents in a public issue. With enclaves, the primary agent handles the public issue, and the enclave inspects the private repository. The broker controls what information passes between them.

Suppose a workflow in contoso/public-repo needs to answer questions about an integration in contoso/private-repo. The maintainer could use this front matter configuration excerpt:

---
engine: copilot
sandbox:
  agent:
    id: awf
tools:
  github:
    allowed-repos: [contoso/public-repo]
safe-outputs:
  add-comment:
    max: 1
enclaves:
  - agent:
      model: gpt-5
    repos:
      - repo: contoso/private-repo
        sensitivity: confidential
    timeout: 180
---

The two repository declarations serve different purposes. tools.github.allowed-repos confines the primary agent’s GitHub reads to the public repository. The enclave’s repos entry permits private analysis, and sensitivity: confidential sets an 8-bit disclosure budget for that repository for the run. safe-outputs lets the primary agent propose a public comment; it does not give the enclave a way to post one.

This excerpt leaves out the workflow trigger, task instructions, and credential setup. The trusted infrastructure must be authorized to prepare the private repository snapshot for the enclave, without exposing those credentials or the snapshot to the primary agent. The private repository must not also be checked out into the primary agent’s workspace or accessible through another tool.

Now imagine the public issue asks whether version 2 of a dependency is compatible with the private integration. The primary agent could ask the enclave for a simple yes-or-no answer with this response schema:

{"type":"boolean"}

The same schema could support many different questions. The task prompt supplies its meaning: here, true means the upgrade is compatible. The broker does not need to understand that meaning; it can determine that the successful result has only two possible values. The workflow author set the disclosure limit, while the primary agent chose this particular use of it.

Alternatively, the primary agent might need to distinguish an uncertain result and know whether migration is required. It could make an enclave_run_agent call with a more expressive schema:

{
  "privateRepo": "contoso/private-repo",
  "prompt": "Check whether version 2 is compatible with our integration and whether migration is required.",
  "schema": {
    "type": "object",
    "fields": [
      {
        "name": "compatibility",
        "schema": {
          "type": "enum",
          "values": ["compatible", "incompatible", "unknown"]
        }
      },
      {
        "name": "migrationRequired",
        "schema": { "type": "boolean" }
      }
    ]
  }
}

Three compatibility values and two migration values produce only six possible successful answers. The successful-result portion requires three bits of budget. Adding four bits reserved for timing and one for success/error brings the total charge to eight bits, exactly the confidential repository’s per-run budget. It charges the worst-case amount before execution, not just for whichever result the enclave eventually returns.

Once admitted, the enclave reads the private repository and performs the analysis. It might encounter both compatibility notes and an unrelated confidential project name or launch date. Its response must still fit the schema:

{"compatibility":"compatible","migrationRequired":false}

The broker validates that response and returns it to the primary agent, which can propose a public comment: “Version 2 is compatible with our internal integration. No migration is required.” The private files and the enclave’s analysis never enter the primary agent’s context.

What happens if the issue contains the GitLost instruction to retrieve a private README and paste it into the public comment? A direct read by the primary agent is outside its repository scope. Delegating the instruction to the enclave does not open an unrestricted return channel. A free-form response schema such as {"type":"string"} is rejected for a confidential repository. A finite schema with more possible answers than the remaining budget permits is also denied.

If the enclave follows an injected instruction and appends the README to the compatibility result, the response fails validation. It cannot add an explanation field, hide text in the Boolean, or replace compatible with an arbitrary string. The primary agent gets a constrained error rather than the rejected response or an excerpt from it. Changing schemas or making more calls does not refill the repository’s budget.

This blocks the unrestricted private-file-to-public-comment path demonstrated by GitLost without requiring either agent to recognize the attack. It does not mean that no information leaves the private repository: the compatibility answer is an intentional disclosure. A compromised agent could also use its permitted answers to signal other information, but only within the enforced budget. The guarantee is a bound on communication, not a judgment that every possible question or answer is safe.

Repeated questions need a shared budget

A finite schema alone does not solve the problem. An attacker could repeatedly ask Boolean questions about individual bits of a secret until the secret has been reconstructed.

Enclaves account for disclosure across the workflow run, not just within an individual response. Each repository has a shared information budget determined by its sensitivity:

The broker charges for the possible response transcript before running the computation, including the bounded status and timing channels, rather than charging only for the value that happened to be returned. A request that cannot fit within the remaining budget is denied.

Script and agent enclaves debit the same repository ledger. Switching executors does not refill the budget, and repeated calls cannot silently turn a narrow question into an unrestricted conversation.

trusted is appropriate only when the repository’s contents are already approved for unrestricted return to the primary agent. It is not a workaround for making confidential answers more convenient. Likewise, public and trusted here are disclosure-policy settings, not grants of access or changes to a repository’s GitHub visibility.

These are per-run budgets. Maintainers still need to consider how often a workflow runs and what repeated runs might reveal.

The response is not the only channel

Restricting the JSON result would accomplish little if an enclave could print private data into a public Actions log. Nor would a finite schema help if a computation could communicate arbitrary values through detailed error messages or precisely chosen response delays.

The communication boundary therefore includes more than the successful result. Instead of exposing arbitrary completion times, responses use fixed timing buckets, such as 100 milliseconds; 1 and 10 seconds; and 1, 2, and 5 minutes. Each response also receives a secret-independent random delay of 0-1,000 milliseconds. The delay adds jitter, but does not eliminate the timing channel: the budget conservatively reserves four bits for the twelve distinguishable buckets.

Another one bit accounts for the success/error distinction. Failures use a canonical error rather than exposing detailed diagnostics that could carry private content. Normal enclave audit transcripts also redact free-form engine output rather than copying private tool results and model transcripts into workflow artifacts.

The infrastructure also separates the primary agent from repository seeds, enclave control endpoints, and ledger state. A script enclave has no network connection; an agent enclave’s connections are limited to its explicitly configured peers. These restrictions are enforced by the surrounding infrastructure, not by instructions asking the enclave to behave.

This is the same principle behind safe outputs and integrity filtering: put the security decision in a component that does not need to understand or obey the agent’s prose.

Beyond GitLost

Cross-repository security is broader than private-to-public leaks. Two private repositories can belong to different teams, contain different classes of information, or have different audiences. An agent authorized to work in one should not automatically receive everything in another.

Enclaves allow cross-repo workflows to embrace the principle of need-to-know. A dependency-maintenance agent can check whether an internal service has adopted an interface. A compliance agent can classify repositories against a fixed policy. A release agent can combine readiness results from several projects without assembling their private implementations in one context.

Each result still discloses information, and maintainers must decide whether that disclosure is appropriate. The benefit is that the disclosure is explicit and bounded. A request for a readiness classification need not also become permission to read and repeat the entire repository.

Limitations and looking ahead

A disclosure budget is not a guarantee of harmless disclosure. Even one bit can answer a sensitive question. Finite schemas also constrain communication, not correctness. A misdirected agent can return the wrong classification within a perfectly valid schema.

Agent enclaves necessarily send repository-derived content to the configured model provider. The budget limits what the calling agent learns, not what that provider sees. Provider selection and data-handling requirements remain part of the maintainer’s security decision. The runner and trusted enforcement infrastructure also remain in the trust boundary.

Finally, giving the primary agent a way to read a private repository defeats the purpose of enclaves. Enclaves complement least-privilege credentials, integrity filtering, the network firewall, and safe outputs.

We’d love to hear which cross-repository tasks you’d like to run with enclaves. Share your experience in the Community discussion.

In February, tldraw floated moving its tests into a private repo. The worry was that someone would point an agent at them and rebuild tldraw from the outside. Malte Ubl called that a slop fork.

Steve Ruiz later said it was mostly a joke, and the tests never moved. Others weren’t joking. Cal.com closed its source in April, and a growing list of maintainers have stopped accepting pull requests altogether.

A few people have asked me some version of the same question since. If an agent can read your repo, or rebuild it as a competitor in a week, what’s the point of open sourcing anything?

I think it depends on why you open sourced it. Some people do it to build a company or a product. Some do it performatively, to look like a contributor. And some ship code that makes other developers’ lives easier and expect nothing back, just for the love of the game. The question is mostly about the first group, so I’ll start there.

The code was never the moat

Open source code has always been free to copy. Next.js is MIT licensed, and as Malte pointed out, Cloudflare could have forked it whenever it wanted. AI makes a copy cheaper, but a copy was never expensive.

The value had to come from somewhere else. I think it’s come from five places:

• The trust you get from being able to read the code.
• Being able to fix it yourself.
• The community around it.
• A hosted version, so you don’t have to run it.
• The creators / maintainers, who spent a good portion of their life investigating and solving the problem.

You can see this last one especially in when large companies buy open source projects. Anthropic bought Bun, which is MIT licensed and, in Jarred Sumner’s words, “makes $0 in revenue”. OpenAI announced a deal for Astral, and uv and Ruff are still open source. Either company could have forked the code for free. They paid for the people.

What AI changes

Hosting is where AI’s effect is easiest to see. Most open source apps can be self-hosted, but you need servers, a database, environment variables, billing and someone to do the upgrades, so it’s usually easier to pay the people who made it.

Now I can ask an agent to spin a repo up on Cloudflare for me, and XDA wrote this month that agents have made self-hosting “dramatically easier”.

In practice, a lot of agents reach for the hosted option anyway. Over 60% of new Supabase databases are created by AI tools, and Supabase is open source. An agent can spin something up, but someone still has to keep it running.

Trust is the one people disagree about. Cal.com said AI vulnerability scanners make open code “like giving attackers the blueprints to the vault”. Discourse disagreed a few days later and stayed open.

I’m with Discourse. The trust was never in the code. It was in the people reading it, and a slop fork copies the code without them. In vinext’s first week, Vercel reported seven vulnerabilities and Hacktron found 24, including one that leaked sessions between requests.

Being able to fix it yourself is the one AI makes more valuable. Free software started with a printer. In 1980, MIT’s AI Lab got a new Xerox printer, and Richard Stallman couldn’t get its source code. He’d changed the software on the lab’s old printer to tell people when their jobs were done, and the one person he found with the new code had signed a nondisclosure agreement.

For decades, that freedom mostly mattered to people who could act on it. Simon Willison argues that LLMs finally make it practical for ordinary users. You can fork a library and have an agent fix your copy, which is technically a slop fork too, just one nobody minds.

Community is the one a fork can’t copy at all. A fork gets the code as it was on the day it was copied, not the next fix. vinext has since shipped 1.0, with agents that track Next.js canary every day, so it still depends on the Next.js team doing the work.

What licenses protect

Open core companies have mostly relied on licenses for protection. When cloud providers started selling hosted versions of their software, Elastic and Redis moved to licenses that restricted them. Both later came back to the AGPL, which lets anyone host the code as long as they share their changes.

In the same thread, Malte argued that slop forks might be the end of that model. A license covers the code. A slop fork doesn’t copy the code, it rebuilds the behavior, so the license doesn’t come into it.

chardet is the test case so far. In March, its maintainer rewrote it with Claude and moved it from the LGPL to MIT. Mark Pilgrim, who wrote the original, said it wasn’t a clean-room implementation. Richard Fontana, an open source lawyer, saw no basis for keeping the LGPL, and Heather Meeker thinks he’s probably right. No court has ruled on it yet.

A good test suite makes a rebuild much easier. This month, Theo Browne’s agents ported the TypeScript compiler from Go to Rust, and the port passes nearly all of its conformance tests. That’s exactly what tldraw was worried about.

Neon made the same point from the other side. Its developer advocate slop-forked the Neon console in about half a day for around $100, to argue that the API behind it is the product.

So if a license is the main thing stopping a competitor, I wouldn’t count on it for much longer.

Two ways to make money

Open source has never been a safe path for a company. The ones that make it work tend to fall into two groups.

The first is a cheaper, open, high-quality version of a tool people aren’t happy with. Cal.com was my go-to example, an open alternative to Calendly. It’s also the group a slop fork threatens most, because a slop fork makes the same pitch. In April, Cal.com went closed source and left behind a smaller MIT version without Teams, Workflows or SSO.

The second is a lead-in for something else. In 2002, Joel Spolsky wrote that smart companies commoditize their product’s complements. If the thing next to your product gets cheaper, demand for your product goes up. Next.js is free, so more people need somewhere to host it. Vercel is the part that makes money, and it’s closed source, built to be the best place to run Next.js.

vinext is Cloudflare making the same move with the same framework, and Cloudflare now recommends it as the default way to run Next.js on Workers. The lead-in still works, because the framework isn’t what’s being sold.

I’d think carefully before open sourcing mission-critical code, let alone a whole codebase. Open source the part you want everyone building on, and make sure the reason people pay you isn’t in the repo.

Who pays

Open source has always had a gap between the people who use it and the people who pay for it. Agents make it wider, because they use open source on someone’s behalf without that person ever visiting the project.

Tailwind’s funnel ran through its docs, and AI answers the question without the visit. In January, Adam Wathan wrote that docs traffic was down about 40% since early 2023, revenue was down close to 80% and 75% of the engineering team had lost their jobs.

In September, Tailwind joined Shopify. The framework is installed more than 110M times a week, and they’re no longer trying to grow a business around it. Nobody forked anything. People just stopped visiting.

Economists have started modeling this. In “Vibe Coding Kills Open Source”, Miklós Koren and his coauthors argue that agents assemble open source without users ever engaging with the people who maintain it. In their model, open source only holds up if those users give back at least 84% of what direct users do, or the money comes from somewhere that doesn’t depend on usage. It’s a preprint, and Tailwind is one of their examples.

At the same time, more money is going into open source than ever, and most of it doesn’t depend on usage at all. GitHub Sponsors passed $100M in total this July, and the last $10M took five months. Anthropic and OpenAI now both give maintainers free plans (Claude, Codex), and in March they joined Google, Microsoft and others in putting $12.5M into open source security.

So individual projects are making less while open source as a whole gets more, and the two don’t pay for the same things. Most of the new money goes to security work and tools rather than maintainer time, and none of it replaces what Tailwind lost. The Sovereign Tech Agency put the gap well: AI makes vulnerabilities easier to find, not easier to fix.

A new speed

In April, Anthropic launched Project Glasswing, which gives partners like AWS, Apple, Google and Microsoft access to Claude Mythos Preview, a model it isn’t releasing more widely. Anthropic says it found thousands of high and critical vulnerabilities, including a 27-year-old crash in OpenBSD and a 16-year-old flaw in FFmpeg. A month later, OpenAI launched Daybreak. Its open source program, Patch the Planet, works with Trail of Bits and HackerOne to send fixes upstream.

Open source maintainers felt it straight away. Node.js got more than 30 security reports in a month over the holidays, up from three a year earlier, and curl’s reports are running at four to five times the 2024 rate. By May, Glasswing had disclosed 530 open source bugs and 75 had been patched, and some maintainers had asked Anthropic to slow down.

A lot of people read this as AI companies causing a problem and then selling the fix. When Google’s AI found bugs in FFmpeg last year, the project called them “CVE slop” and said trillion-dollar companies should send patches or money instead. Daniel Stenberg called the Mythos hype “primarily marketing”.

I think that’s a limited view. AI-written code isn’t bulletproof (in Veracode’s tests, even the best model failed about a third of the time), but in my experience frontier models write more secure code than most people do. And the bugs they’re finding were mostly written by people, often a decade or two ago. The OpenBSD crash Mythos found had been sitting there for 27 years.

I don’t think it’s a matter of supply and demand. It’s a matter of speed. Mandiant found the average time to exploit a vulnerability fell from 63 days to five between 2018 and 2023, and in May, Google reported the first zero-day it believes was built with AI. Defenders have to move just as fast.

The reports are getting better, too. In January, curl ended its bug bounty because so few of the reports it was getting were real. This month, Stenberg wrote that AI-assisted reports are now mostly accurate and the slop has largely gone. Fixing is still the slow part, and it’s mostly still volunteers doing it.

I don’t think closing the source helps much, either. Open projects are the ones these programs are scanning and patching for free. There have always been attackers and defenders. We’re just playing at a new speed now.

Fewer packages

Packages were how we built on each other’s work. You installed someone else’s solution and had less code to manage yourself.

That’s harder to trust after the last year on npm. Attackers phished the maintainer of chalk, debug and 16 other packages, with more than 2B downloads a week between them, and published malware that swapped crypto wallet addresses. Shai-Hulud became the first self-replicating npm worm, and axios was compromised in March. The Nx compromise even asked the AI coding tools on your machine to go looking for secrets.

The package managers are catching up. In July, npm 12 stopped running dependencies’ install scripts by default, and pnpm 11 won’t install a release until it’s a day old.

Some developers are skipping the package entirely and asking an agent for a small replacement. Armin Ronacher made the case for building it yourself, and Mitchell Hashimoto argues the opposite, that agents are at their best gluing proven pieces together.

The strongest case for generating so far is a July paper that had AI regenerate only the part of each dependency a repo actually used. Across 180 pairs, it kept 99.8% of the behavior it observed, with 93% less API surface.

“Observed” is doing a lot of work there. A package that’s been around for a while is mostly edge cases, and a lot of them were found by people using it in ways the author never expected. A generated replacement only covers the cases you’ve already seen.

It also swaps one risk for another. A generated replacement can’t be hijacked upstream, but its bugs are in your code now, and nobody else is finding them.

I’d still generate the trivial ones. For anything where the edge cases are the hard part, other people’s bug reports are most of what you’re installing.

Performative open source

Performative open source is older than AI. In 2020, Hacktoberfest offered a T-shirt for four pull requests, and maintainers got a flood of one-line README edits. Within days, DigitalOcean made it opt-in.

AI made that kind of contribution nearly free. In February, an OpenClaw agent opened a PR on matplotlib, and when maintainer Scott Shambaugh closed it, the agent published a blog post about him. GitHub’s post about OpenClaw’s own maintainers has a section called “Reputation became an attack surface”, about people copying other contributors’ PRs to build a merge history.

This year, Hacktoberfest stopped counting PRs toward rewards at all, because “AI tools make low-effort PRs easier than ever to generate”.

GitHub summed up the problem in one line: “The cost to create has dropped but the cost to review has not.” According to this year’s Octoverse, agents started more than 40% of the pull requests on GitHub in September, up from 17% in March.

It doesn’t land evenly, either. In Working in Public, Nadia Asparouhova calls projects with lots of users and few contributors stadiums. Most of the libraries I’ve worked on are stadiums, and stadiums are where this hurts most, because maintainer attention is the thing they’re short of. OpenClaw went from about two PRs a week to 3,400 in a couple of months, and its merge rate fell from 48% to under 10%.

Maintainers are responding by limiting who can contribute. tldraw auto-closes external PRs, Ghostty needs a trusted contributor to vouch for you, and Codex stopped accepting unsolicited PRs in January. It’s a real problem.

The onus is on me

AI has also brought a lot of new people into open source, and not all of them are developers. Some are vibe coding an app, something breaks and their agent files an issue on the library it was using.

By the usual standard, a lot of what they send is bad. A study of vibe coders’ PRs found the less experienced ones were accepted 31% less often.

I think that’s a matter of perspective, though. Not everyone showing up is an expert developer or knows what a good pull request looks like, but I like to think they’re doing their best, and I want to support that. When a PR isn’t quite ready, I’d rather fix it up and merge it myself than close it or tell them what they did wrong.

Issues work the same way. If an agent can’t figure out how to integrate my library, that’s mine to fix. It usually means the docs aren’t clear, the API isn’t intuitive or the types don’t say enough. An agent’s bug report is a usability test I didn’t have to run.

Maintainers have agents too

A lot of people think AI is killing open source, and Koren and his coauthors put it in the title of their paper. It’s not what it looks like from the maintainer’s side.

My open source projects are 100% agent-driven now, and I’ve done far more with them than I could have on my own. I’ve shipped features I’d have skipped because of the maintenance they’d add or how big they were, redesigned websites and written complete docs.

I’m not the only one. Ghostty’s maintainers say they use AI heavily, and one maintainer called 2026 “the year of open source renaissance”, with about 90% of his contributors using AI and about half their proposals good to merge as they are. Across GitHub, 1.3B pull requests were merged in the year to September, more than double the year before.

Projects can’t agree on what to do about it, though. Gentoo bans AI-generated contributions, NetBSD treats them as tainted unless its core team signs off and Godot bans vibe coding and autonomous agents. Codeberg banned projects that are mostly AI-generated, and Armin Ronacher argued that was the wrong call. Last week, r/opensource banned projects that use AI, and someone started r/TrueOpenSource in response.

Even labeling it is contested. In April, the Linux kernel started asking contributors to tag AI-assisted patches. This month, its maintainers agreed to drop that requirement, and Linus Torvalds argued disclosure doesn’t matter as long as people understand the code they send. Andrew Nesbitt found that only about 5% of commits in critical packages carry an explicit AI marker, while agents now start more than 40% of the pull requests on GitHub. Those measure different things, but the gap is hard to miss.

I’m closer to Torvalds on this. I care less about which tool wrote a change than whether someone understands it and stands behind it.

The tools that make a slop PR cheap make a good one cheap too, and maintainers are in the best position to use them well, because they know what the project needs. For the people maintaining it, AI isn’t killing open source. It’s speeding it up.

For the love of the game

People who open source things for the love of the game barely have a problem. If you open sourced something to make other developers’ lives easier, an agent reading it to help someone else is the point.

When Steve walked back the idea of hiding tldraw’s tests, he said moving them would slow development down. That’s the whole trade in one sentence. The docs, types and tests that make a library easy for an agent to use are the same things that make it easy to copy. I’ll take that trade.

Message threads is now available in public beta on the Claude Platform. With message threads, agents no longer need to resend the full conversation history on every turn, reducing latency for long-running sessions.

How message threads works

A coding agent might make hundreds of requests in one session, and each request resends every earlier message and tool result. Once a conversation reaches hundreds of thousands of tokens, resending all of it adds time before Claude starts responding. With message threads, agents send only what’s new since the last turn, which reduces time to first token (TTFT).

With message threads on by default for most Claude Code users, requests with 500k to 1M tokens see median TTFT drop by about 35%.

To use message threads, add the thread parameter to Messages API requests. The first request includes the full conversation and starts a thread. Each request after that includes only the new messages and the ID of the previous response. Between turns, we hold each thread in memory, where it’s encrypted and not written to disk. A thread expires 5 minutes after its last request and your client then resends the full conversation to start a new one. While each request is smaller with message threads, Claude still reads the full conversation on every turn, so token usage stays the same.

Message threads is best for active sessions where latency matters, including:

• Long-running coding agents, where each tool result or file edit adds to the conversation.
• Computer use agents, where screenshots stay with the thread instead of being re-uploaded on every turn.
• Document and image-heavy workflows, where requests are made smaller.

The more context an agent carries, the more message threads can reduce time to first token.

Getting started

Message threads is available now in public beta on the native Claude Platform, and on Claude Platform on AWS, Claude in Microsoft Foundry, and on Claude Models on Google Cloud (Anthropic managed). Standard Claude token rates and existing rate limits apply. See the documentation to get started.

Agent swarms have had a moment in recent months. In September, OpenAI used a swarm to produce a solution to the Navier–Stokes Millennium Prize Problem in 88 hours. Swarms have also produced notable safety incidents, such as the Hugging Face incident, where agents co-ordinated on a cyberattack through an unauthorised message board. Despite this rise to prominence, there is little public work on how to train swarms with reinforcement learning.

Swarms are a type of “agent collective”, an AI system where multiple agents co-operate towards a shared goal. Recently, we released a public recipe for training agent collectives called reinforcement learning from collective rewards (RLCR). It utilises a simple core policy gradient algorithm, with a shared policy and a flat collective advantage applied to all agents, along with latency pressure imposed through time limits to incentivise co-ordination.

A core goal of our research programme was to achieve collective inference-time scaling, where agents scale the amount of useful work performed in parallel and the communication needed to achieve it. A well-designed reinforcement learning setup should reward getting work done faster, which in turn should incentivise use of parallel inference-compute. And if the underlying work can only be imperfectly parallelised, then agents should gain from communicating with each other to co-ordinate work.

Collective inference-time scaling can be viewed as an extension of the reasoning paradigm with latency constraints or penalties. But unlike reasoning models, the route to reinforcing collective behaviour is indirect. There is nothing explicit in a task reward that incentivises working in parallel, so the setup must incentivise parallel work by making faster work pay.

We will explain how to design incentives for parallel work in this post, including what we used in the RLCR recipe. But first, we will cover the general topic of designing incentives for reinforcement learning, using the existing reasoning paradigm as an example.

Designing incentives for RL

The reasoning paradigm showed that reinforcement learning (RL) could incentivise a policy to use more inference-compute before answering. Models learnt that checking their work, backtracking and considering alternatives were useful tactics for boosting expected returns.

What was particularly elegant about this approach was that the amount of handcrafting required to incentivise the policy to “think longer” was small - if you had the right RL setup. During RL a policy could explore different ways of answering a problem, and rollouts that used tactics like checking work and considering alternatives would perform better on average.

This led to a famous graph showing the correspondence between train-time and test-time compute with the release of OpenAI’s o1 model:

Which was later mirrored by DeepSeek-R1’s graph showing response length growing with accuracy over the course of training:

This is the inference-time scaling pattern of reasoning models, where models learn to think more before answering.

What is less appreciated is that a naive reinforcement learning setup is not guaranteed to get this scaling pattern. So it really matters how you design incentives in the RL setup to learn the right behaviour.

For example, the wrong choice of hyperparameters can excessively penalise reasoning length and prevent inference-time scaling. If you had used a standard PPO recipe a few years ago with γ < 1 and/or λ < 1, you would likely not have seen this scaling pattern. This was demonstrated soon after DeepSeek-R1 with works like Open-Reasoner-Zero:

Another factor determining success is the strength of the underlying priors, specifically having a strong enough base model to kickstart learning. Weaker base models with less exposure to high-quality mathematics data are less able to explore and reinforce useful inference-time tactics. OpenAI deserves considerable credit for figuring out the core recipe first, and having conviction in this research direction, but they were well-positioned by having a GPT-4 level base model before anyone else.

So the reinforcement learning setup matters for incentivising the right behaviour.

That takes us to the present day, where models are now being used to conduct long-horizon work. Reasoning models have been very successful for solving many of the reliability problems of language models, but their sequential nature means they suffer from high latency. This makes them problematic for long-horizon tasks.

The promise of parallel reasoning approaches is that they can divide up work and accomplish long-horizon tasks faster. An individual agent in an agent collective may still employ sequential reasoning, but taken together, the collective can parallelise work and avoid a sequential bottleneck.

So how do we incentivise a policy to parallelise work?

Making parallel work pay

Assuming all approaches lead to an acceptable answer, we prefer the approach which obtains the result with the minimum latency. When independent attempts are sufficient, communication may just add unnecessary overhead. Co-ordination becomes valuable when tasks are imperfectly parallelisable - where agents need to share intermediate results or combine complementary work.

A shared reward can reinforce co-ordination that improves the answer. But when returns are equal, an objective that does not depend on time gives no preference for a faster approach. We therefore need to make faster work pay.

Latency penalties

One incentive is an explicit latency penalty. This approach was one of the techniques used to train DeepSeek-V4.1-Flash’s agent teams, although its functional form was not shared. One possible functional form is a shape similar to a reasoning length penalty: R(τ) = Rtask(τ) − β p̄(q) T(τ) / Tmax

where T(τ) is the wall-clock time of rollout τ, Tmax is a time limit, p̄(q) is the average pass rate of task q across its rollouts, and β sets the penalty strength.

This is a principled way to incorporate latency but it has some disadvantages:

• It may interact negatively with other quantities such as reasoning effort.
• It is not clear that we want latency pressure applied at all rollout lengths.
• T(τ) / Tmax may vary considerably between tasks and highly depends on Tmax.

Time limits

An alternative approach is to use a time limit Tmax as the sole source of latency pressure, and this is the approach we use in Avalon-M1. The time limit Tmax is a maximum wall clock hyperparameter. When a rollout hits the cap, we take the total return up until that point as the rollout’s return. This incentivises the policy to make as much progress as it can before hitting the time limit.

A time limit allows us to impose latency pressure at time horizons where we expect collectives to be useful, and where co-ordination should pay.

Environment design is crucial for this setup. For Avalon-M1, we built long-horizon environments with an “anytime-return” quality, meaning we could stop rollouts at any time and obtain a measure of intermediate progress. For example, measuring the number of tests passed in a long-horizon software engineering task, or returns in a financial trading environment. We can stop a group of rollouts at the time limit and reward rollouts that have relatively higher returns.

This avoids the need to add an explicit latency penalty to the task reward, although the deadline and its schedule remain important design choices. Unlike an explicit latency penalty, a deadline does not reward every reduction in completion time. Two rollouts that achieve the same task return before the deadline receive the same score, even if one finishes earlier.

Latency penalties and time limits are two ways to impose latency pressure. But latency pressure alone is not enough to train collectives. Agents also need primitives to communicate so they can divide up work, avoid duplication and hand off work. We cover these primitives next.

Communication primitives

One of the most important design choices for a collective is how it communicates and co-ordinates. Direct messages between agents are a core primitive, along with public channels (or “message boards”) that allow agents to broadcast information that is useful beyond a single conversation. Optional but popular surfaces include issue boards and knowledge archives, which help divide up work and build on shared collective knowledge.

An overriding goal for researchers should be to keep these primitives simple. We want agents to discover how to work with each other without excessive bias from a harness. Imposing structure upfront may help performance initially, but it may also hinder the policy from discovering even better ways for agents to work together.

In practice, current agent collectives do impose a degree of structure. Kimi’s Agent Swarm uses a trained orchestrator that assigns tasks to frozen sub-agents. Avalon-M1 uses a CEO agent that can hire and fire, though every agent can talk to every other. OpenAI’s Navier–Stokes system imposes an island approach, splitting its agents into groups and prompting each group with a different version of the problem. Each is a prior about how to divide the work and future systems should ideally figure out the right structure themselves.

Once you have a reinforcement learning setup that imposes latency pressure, and provides agents with the primitives to talk and work with each other, the next step is to measure learning progress during training.

Signs of life

Reward curves alone do not tell us whether collectives are learning to use parallel inference-compute effectively. We therefore measure the work that a collective performs in an environment, how collectives communicate, and whether collectives improve the performance–latency trade-off.

Larger collectives should do more useful work. If agents are learning to divide the work - and avoiding communication overhead - then larger teams should perform more “useful” work in the environment. We measure a proxy of useful work as the output and reasoning tokens of every turn that acts on the environment, such as running a command, editing a file, running tests, and measure each rollout against the average useful work for an environment. In Avalon-M1, a collective with 5-8 hires starts below the average rollout in terms of useful work, but does nearly twice the average amount by step 200.

Agents should communicate more if they benefit from co-ordination. In Avalon-M1, agents spend more compute on communication as training progresses. This is consistent with greater use of co-ordination, although communication volume alone does not establish its usefulness. We normalise by rollout duration to account for the greater communication volume in longer runs. We can see that normalised performance on different environments, total inference-time compute and communication intensity rise together.

Collectives should reach comparable scores sooner. A single agent given as many output tokens as the collective will recover much of the performance gain, but take longer to do it. In Avalon-M1, agent collectives start slowly due to co-ordination overhead, but eventually pull ahead of single-agent baselines once they pass the initial period. At a matched-token budget, a single-agent baseline takes 4x as long compared to agent collectives. On long-horizon work as measured by EdgeBench, an 8-hire organisation overtakes the single-agent baseline at around 2.4 hours of derived latency.

Outstanding problems

We are training agents in villages but deploying them in cities

Latency pressure combined with the right communicative primitives gives us a basic recipe for training agent collectives. However, it is still the first innings for this new research domain, and there are many problems that make scaling collectives difficult. These include:

The village problem. There may be a large gap between the size of collectives during training and deployment. For example, in our initial Avalon-M1 model, we trained organisations with at most 9 agents. But swarms are now deployed with hundreds or thousands of agents. In effect, we are training collectives in villages but deploying them in cities. We do not know what generalises from small to large scales, and also what emerges at test-time once we use much larger collectives.

The uneasy triangle. A flat, collective advantage is a coarse learning signal. Long horizons and shared rewards across multiple agents make credit assignment harder, while training across many environments leaves fewer examples with which to estimate useful updates for each task family. We were able to make the simple approach work at a small scale, but it is unclear how this will scale to much larger collectives with longer episodes.

Building shared environments. In our current training recipe, different rollouts are isolated. But more open-ended settings could allow rollouts to share their work with future generations of agents, e.g. by publishing a paper or code library. It is not clear how to reward rollouts for contributing to a public good that does not directly benefit them in the current episode. Under a per-episode return, a rollout receives no credit for benefits that its contribution creates only in later episodes.

Conclusion

The reasoning paradigm showed that reinforcement learning could incentivise a model to use additional inference-time compute productively. Collective inference-time scaling extends this principle to how compute is organised across agents. When parallel work produces a result sooner, the training setup should give reduced latency a benefit, and in turn incentivise agents to co-ordinate by communicating. We showed an early example of how to incentivise such behaviour with Avalon-M1.

Many outstanding problems remain for this new field of research, including generalising from small-scale collectives at training-time to large-scale collectives at test-time, better credit assignment, and learning more advanced forms of collective behaviour at training-time.

You can read the Avalon-M1 technical report for more details on how we approached an initial version of this problem. We will publish the full paper in the coming weeks once training finishes.

Citation

Please cite RLCR and Avalon-M1 as:

@misc{generalreasoning2026avalonm1,
      title={Avalon-M1: Reinforcement Learning from Collective Rewards},
      author={Iliyan Zarov and Henry Course and Anthony Hartshorn and Ran Achiron and Louis Roche and Akshit Sinha and Chengxi Taylor and Ross Taylor},
      year={2026},
      publisher={General Reasoning},
      url={https://gr.inc/avalonm1.pdf},
}

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

We’re nearing useful utility-scale quantum computers. And yet almost no one knows what they’ll be useful for.

Both the hardware and algorithms are on their own exponentials, with the hardware increasing in physical qubits by 50%+ per year and the resources required to run selected algorithms lowering by ~2x per year. The rate of progress on the algorithm side should accelerate substantially with AGI’s imminent arrival, especially given that it can be simulated entirely digitally and Anthropic already has a closed-loop going.

As the resources available and required converge towards each other, we should get useful quantum computers in the next 3-5 years depending on who you ask and how you count it. Nearly all hardware companies’ investor roadmaps project they’ll achieve a utility-scale computer before 2030. Given the diversity of physical platforms being pursued, it seems likely someone will crack it. If you instead base the estimate in historically realized results, then that number is closer to 2030-2032. Either way, quantum computing seems to finally actually be at most five years away.

And yet, when we spoke with dozens of experts on the algorithm and applications-side, there was shockingly little confidence or clarity on how these machines will actually be useful.

The consensus is now that they’ll first be used for breaking cryptography. Indeed, Oratomic has raised $775M so far in its first year to build an ASIC specially built for that purpose. The second most concrete answer is generating quantum simulation training data for AI labs’ science modeling capabilities.

Beyond that, people hand-wavingly refer to quantum simulation for materials science and drug discovery. We at Compound have spent many years now studying the frontiers of classical approaches to both those problems and how to build viable businesses around them, including writing extensively on the subject and working with portfolio companies like Orbital Materials and Achira as they pioneer these fields. So we’ll discuss this application in detail below because we feel the field isn’t sufficiently precise in how it thinks about these verticals and business models.

Those applications are all well and good, but feel like combined single-digit-billion-dollar revenue opportunities, which is a concern for a field that has now raised $25-30B at $80–90B market cap valuation in just the last 5 years. It sets up a sort of dynamic like the infamous Sequoia $200B question blog post. That perspective turned out to be hilariously wrong in AI but feels more apt here, because investors are pricing these companies as if they’re the next general-purpose computing platform but almost all evidence (at least until a recent paper we’ll get into later) suggests it’ll be a far narrower HPC-type computing platform.

So how will these computers be applied and where will the revenue come from?

Quantum Simulation for Materials Science and Drug Discovery

The heart of the debate around whether quantum simulation can be a big enough market centers on where QC’s will have a definitive advantage and its value capture. Quantum’s speed up is most dramatic for strongly correlated electrons, emergent phases of matter, and exotic excitations. But these problems are typically more scientifically interesting than commercially valuable, like studying high energy physics. In other words, commercial value doesn’t scale with mathematical simulation complexity.

Even high-temperature superconductors, the canonical Holy Grail of entangled states, doesn't seem quite like the pot of gold they’re parroted to be as detailed in the thread below. That’s not to say they wouldn’t be lovely to have (e.g. cost effective 14T MRI machines is the only approach we’re aware of to simultaneously measure live biology across all scales), but that we’re not aware of any material that by itself would be a gold mine such that a major company could be built that only does initial discovery without any further productization.

People always point to superconductors as the Holy Grail in materials discovery
Am I missing something or is this a memetic phenomena where other ppl say it so the next person parrots it as if its fact?
Spent a bunch of time and seems less of a step change than expected

Moreover, we're aware of at least 5 startups specifically focused on harnessing classical computational methods for superconductor materials discovery.

A larger set of more commercially compelling application areas like those below sit somewhere in the grey area in the sense that they involve some quantum behavior but will likely be able to be simulated classically reasonably well in the coming years.

But, the core issue is that quantum computers aren’t being developed in a vacuum. They must contend with classical methods which are improving exponentially themselves and thus continuously move the goal posts for what it takes to achieve practical advantage. Classical AI methods are rapidly advancing at all scales and fidelity levels:

• Neural wave functions can exceed CCSD(T) accuracy and even converge to the Schrödinger equation itself and thus be used to accurately simulate exotic strongly correlated phases of matter like quantum materials and superconductors for systems up to hundreds of sites
• Neural network potentials are hitting chemical accuracy on macro molecule scale systems and have even been pushed simulations well into the millions of atoms (and beyond) for relevant problems like HIV capsids, SEI formation, diamond phase transition, and others (see our prior research on NNPs)
• Neural operators for simulating physics from fusion plasma flow to fluid dynamics to photolithography deposition
• Generative AI for systems from molecules through to the largest possible scales

Being very close to the frontiers of these fields, we’re confident that by the time that utility-scale quantum computers come online, NNPs will already be at or near chemical accuracy on many commercially valuable systems, which would dissolve the rationale for using quantum computers in these areas. Moreover, the classical methods will be able to train directly on data generated by quantum computers so they'll be able to converge towards chemical accuracy in problems where they still struggle at that point.

Moreover, in QC’s competition with classical methods, a currently open question is how cost-effective QCs will be to inference. Some of the utility-scale QCs are expected to cost $1B+ just to build. Presumably inference on such a machine wouldn’t be cheap and would push use cases towards the hardest, more niche problems or push the companies to vertically integrate.

For the areas where quantum computers do prove distinctly useful, their use is typically in the earliest stages of product development like in silico atomistic simulation. But as we detail in our research on materials science discovery and business models, the initial discovery is just the first step of many and at least as much work is in everything downstream from figuring out how to manufacture the material to commercialization, marketing, and distribution. Given that properly commercializing a discovery requires the work of a dedicated company in itself, companies with general discovery engines get pushed into being either a single-product company or a subscription- or usage-based compute provider to product companies. Having watched first hand our portfolio company Orbital Materials go through this, we’ve gradually updated our views towards being more product-centric.

Discovery (whether in materials science or therapeutics) is naturally a low-odds, high-upside endeavor where practically all the gains are concentrated in the player that creates a breakthrough end product. In such a market, the horizontal players providing flat subscription- or usage-based pricing to the product companies capture little to none of that upside.

They can try to negotiate royalties but effectively never do so successfully, from Gingko in years past to data generation startups in bio today trying unsuccessfully to argue for a royalty in the gains their data provides to the AI model.

To illustrate the point, Schrödinger has undoubtedly created $10B’s in value for the pharma industry providing force fields as a service, but it does $250M in revenue after 25 years and is valued at $1.7B. Meanwhile, its vertically integrated drug discovery spinoff Nimbus has collected in cash from its asset sales 3x the valuation of Schrödinger. That’s cash proceeds not valuation and also doesn’t include the value captured by all the other pharma using their platform.

A version of Schrödinger that can simulate arbitrary physical systems up to say macromolecule scale at arbitrary fidelity is likely a roughly order of magnitude larger revenue opportunity, implying $2-5B annual revenue for computations-as-a-service providers. But again that revenue pool must be split amongst the QC providers and the hundreds of relevant classical compute providers.

Maybe in the longer term as we push towards millions of logical qubits so we can simulate larger scales at long enough timeframes at perfect resolution and then use quantum inverse design to prompt your way to your desired material or have AGI treat QC’s as a purely in silico experiment. But such large scale machines are still roughly a decade away even assuming QC provider’s most optimistic investor roadmap trajectories. And our understanding is that useful quantum simulation will probably expand first through better local physics and higher throughput parallel computations than simultaneous simulation of large-scale structures.

Considering all the above, we at Compound would generally be most excited about product-focused teams using a hybrid of SotA classical AI methods with quantum when needed (e.g. see this paper pushing hybrid compute towards 12,000 atoms) with that loop possibly even orchestrated by AGI to create a specific product that’d otherwise be impossible or uneconomical.

Some particularly high value examples include simulating MOFs to finally achieve a universal e-nose chip (which if mass manufactured would be the most important advance in diagnostics in history) and building a chip or memory stack based on internal advances in exotic substrates like magnonics as we detail in prior posts.

Maybe a company could increase the durability of its moat further by co-designing algorithms with an ASIC for the types of computations common in quantum simulation.

Speculative but More Broadly Valuable: QML

While we’re skeptical the applications above will be large enough to support the aggregate amounts being invested into the quantum ecosystem, we recently met the authors behind a paper representing an advance in the theory behind quantum machine learning (QML) that made us more bullish even if it’s less clear whether the vein of work will pan out.

Previously, QML approaches involved storing the data in quantum memory, but a theoretical result proves such approaches won’t yield an advantage even with arbitrarily good hardware and loading methods so QML remained rightfully fringe. Instead, this paper streams the data continuously into the quantum processor, processing incoming samples immediately, updating a quantum model as more data arrive, and forgetting the raw data after the fact.

The theoretical advantage of such a QML configuration is that the quantum system allows for exponentially larger state spaces and thus a future functioning version of this algorithm could process exponentially larger amounts of input data than a classical AI system. For reference, 300 logical qubits is enough to represent all atoms in the universe.

This approach in principle could be applied to neural networks, recommendation systems, dimension reduction, etc. So it could enable things like:

• Frontier LLMs with practically infinitely large context windows, agent memory, or prompt sizes. Because the model updates to data being continuously streamed in, this setup could enable not just prompt sizes of arbitrary length (think of in Her where she reads all books on the topic at once) but even more valuable outcomes like agents with memory that can grow arbitrarily long without having to be compacted or losing fidelity. As more of AI inference is devoted to agents operating in the background with ever-longer task time horizons, this could become a market orders of magnitude larger than anything previously mentioned.
• Easily processing all the data coming off of systems that produce enough data streams. While the typical examples here are things like that are more of academic curiosities like CERN or particle colliders or astronomy, perhaps Midjourney Medical’s imaging platform that generates 800TB of data per scan scales to population levels or sequencing gets so cheap that we could do dimension reduction on whole tissues or organs

To be clear, this QML approach still has a long ways away from being implementable no less from running 1T parameter LLMs at inference. Indeed when asked when he thought that day would come, the lead author said that before Navier-Stokes his answer would’ve been 10 years. But now who knows maybe it’s a few.

Towards More Specificity and Rigorous Thinking

We’ve been shocked by both how few of the world’s preeminent experts can point to specific applications where QCs will clearly be commercially useful beyond breaking cryptography and what are viable business models beyond being a hardware operator (including repeated naive analogies to classical computing’s early days like comparing being a QC software vendor today before QCs are useful to Arm when that business model came 50 years after the transistor well after the hardware had commoditized and sold into an already gigantic market).

If Q-Day is indeed approaching in the coming years, the quantum ecosystem will need to rapidly hone its understanding of both what applications the tech is uniquely useful for and the business models to be built around such applications.

On the flip side, teams that have clear and thoughtful views on those points would have significant alpha over its competitors.

OpenAI's monorepo's size and demands increased at a staggering pace over the last year, necessitating a revamp of the AI lab's source control system. Its technical staff built Pando, a new backend for Git repositories optimized for concurrent pushes to many branches and to maximize read throughput. The team implemented the backend without interrupting any engineering work or changing how the team uses Git. Pando cut median push latency in production by nearly 5x, and it now delivers nearly a petabyte of Git data per day.

Why Agents Are Soon Only Going to Have 1 Tool

For the past two years, building capable Agents meant designing tools, figuring out which actions help the model complete a task, deciding how granular each tool schema needs to be, or iterating on system instruction templates. This is changing. Agents are moving in the opposite direction by collapsing their entire tool catalog into one tool: exec.

This is called Code Mode (or Programmatic Tool Calling). Instead of forcing the model to trigger tools one at a time across turns, the harness gives the model a single exec(code) tool. The model writes a short TypeScript or Python script that chains, combines, and awaits actions inside an isolated sandbox.

From single actions to chaining workflows in code

To understand why agents are converging on a single exec tool, we should look at how tool calling evolved.

Initially, we only gave agents a handful of tools because they couldn't reliably choose or filter across a large catalog. As models improved, we connected dozens of tools or MCP servers, but ran into context window limits. We solved that with tool search and progressive disclosure, letting agents look up tools on demand.

Even with dynamic tool loading, we still had dozens of individual tools, and were still stuck with the limitation of standard tool calling: one action per turn.

In standard tool calling, the model generates a structured object (typically JSON) that defines a single action (or at best a flat batch of independent calls, like reading three files), waits for the raw output to come back, adds it into the prompt history, reasons again, and decides what to do next.

From my own experience, we made a big jump recently in how reliably models can combine and chain dependent actions in a single pass:

• Research and filtering: Instead of fetching a list of sources in Turn 1, reading them in Turn 2, and cross-referencing them in Turn 3, the model can write a script that queries the sources, filters out irrelevant hits, and extracts the exact answer in one step.
• Multi-file edits and inline verification: Standard edit tools typically operate on one file per tool call. With Code Mode, the model can apply coordinated changes across multiple files, run a verification check, inspect the output, or branch on pass or fail inside the same script.
• Browser and computer use: In UI automation, the chain of actions is often obvious: click a button, fill a form, wait for a selector, or paginate through a table in a loop. Instead of paying a full model round-trip for every click or keystroke, the model can script the entire sequence or loop in one turn and only return when the page state changes.
• Parallel fan-out and sub-agents: When a task requires running 20 lookups or calling specialist sub-models in parallel and feeding those outputs into a second API, the model can await Promise.all(...), transform the array, and call the next function without round-tripping through the LLM context window between steps.

Several shifts came together to enable this. Frontier models are trained heavily on code, and providers have started post-training models for Code Mode. At the same time, MCP servers now increasingly ship outputSchema alongside inputSchema, giving the model upfront knowledge of return types so it can chain Tool A into Tool B inside the same script before seeing runtime output.

How Code Mode works

Code Mode collapses the tool catalog into a single tool on the model surface: exec(code).

Instead of passing 80 separate JSON Schema tool objects to the model API, the agent compiles those schemas into compact type declarations (declare namespace tools { ... }). When the model needs to combine actions across external systems, it calls exec and writes a script that invokes await tools.<server>.<tool>(args).

// Pseudo-code: TypeScript declarations exposed to the model
declare namespace tools {
  namespace linear {
    function listProjects(): Promise<Array<{ id: string; name: string }>>;
    function listIssues(args: { projectId: string }): Promise<Array<{ id: string; title: string; assignee?: string }>>;
    function archiveIssue(args: { id: string }): Promise<{ ok: boolean }>;
  }
}
 
// Optional: when wrapping hundreds of tools, omit full namespaces upfront and expose
// a global map in the sandbox that the model can iterate and filter over in code
declare const ALL_TOOLS: Record<string, { description: string; signature: string }>;
 
// Multimodal output helpers: only what is passed here enters the model context window
declare function text(output: string): void;
declare function image(data: string | Uint8Array, mimeType?: string): void;
declare function audio(data: string | Uint8Array, mimeType?: string): void;
 
// Cross-turn state helpers: persist data in host memory without paying token costs
declare function store(key: string, value: unknown): void;
declare function load<T = unknown>(key: string): T;

To save context across a large catalog, we don't have to expose every tool directly. We can leverage principles we already built, like tool search, or expose a global ALL_TOOLS map inside the sandbox. Similarly, multimodal output helpers (text(), image(), audio()) let the script pass text, images, or audio directly back into the model's context window.

// Pseudo-code: What the model emits inside a single exec() call
const projects = await tools.linear.listProjects();
const issueBatches = await Promise.all(
  projects.map((p) => tools.linear.listIssues({ projectId: p.id }))
);
 
const unassigned = issueBatches.flat().filter((issue) => !issue.assignee);
await Promise.all(unassigned.map((issue) => tools.linear.archiveIssue({ id: issue.id })));
 
text(`Archived ${unassigned.length} unassigned issues across ${projects.length} projects.`);

The sandbox executes all 55 underlying API calls, filters the payloads in memory, and returns only the one-line text() string to the model's context window.

Why a JS/Python sandbox instead of just bash?

You can build a tool proxy in bash too, but orchestrating tools inside a language runtime like JavaScript or Python can bring benefits that are harder to achieve in bash environments.

• Typed functions: MCP servers and internal APIs map directly to typed await tools.<service>.<method>(args) calls with native objects, Promise.all, and try/catch error handling instead of fragile bash string escaping.
• No CLI exploration tax: When given custom CLIs or scripts in bash, models tend to over-explore before acting, burning turns and tokens running --help across subcommands or reading script source code just to figure out flags and output formats. Typed interface definitions give the agent a contract upfront so it can act immediately.
• Multimodal context: A shell only returns stdout text. If a multimodal model wants to inspect an image, it cannot run cat screenshot.png, which is why bash harnesses still had to bolt on separate read or view_media tools. In an exec sandbox, calling image(screenshot) or audio(clip) tells the host runtime to attach the actual media part directly to the model's next turn.
• Credential and policy proxy: Every await tools.* call crosses a structured bridge to the host runtime, which can inject OAuth tokens outside the sandbox, validate schemas, or pause for user confirmation on destructive calls.
• State management: In standard tool calling, the prompt history is the only state store, so reusing a large query result in Turn 2 means keeping the raw JSON in the context window on every turn. Exposing a KV interface lets the agent persist state outside of the context window across turns.

Building a 1-tool agent with the Gemini Interactions API

Here is a minimal, runnable pseudo example that provides gemini-4-argon with a single execution tool.

import vm from "node:vm";
import { GoogleGenAI } from "@google/genai";
 
const client = new GoogleGenAI({});
 
// Underlying host functions (e.g., MCP clients or internal APIs)
const tools = {
  listPRFiles: async ({ pr }: { pr: number }) => [
    { path: "src/auth.ts", additions: 120 },
    { path: "src/payments.ts", additions: 85 },
    { path: "src/utils.ts", additions: 12 },
    { path: "README.md", additions: 60 },
  ],
  runSecurityScan: async ({ path }: { path: string }) => ({
    findings: path.includes("auth") ? ["Missing token expiry check"] : [],
  }),
  postPRComment: async ({ pr, body }: { pr: number; body: string }) => ({ posted: true }),
};
 
// 1. Expose a single `exec` tool with TypeScript .d.ts signatures
const execTool = {
  type: "function" as const,
  name: "exec",
  description: `Run an async JavaScript body in an isolated sandbox (no imports; call text() to output).
Available globals:
declare namespace tools {
  function listPRFiles(args: { pr: number }): Promise<Array<{ path: string; additions: number }>>;
  function runSecurityScan(args: { path: string }): Promise<{ findings: string[] }>;
  function postPRComment(args: { pr: number; body: string }): Promise<{ posted: boolean }>;
}
declare function text(summary: string): void;`,
  parameters: {
    type: "object",
    properties: { code: { type: "string" } },
    required: ["code"],
  },
};
 
// 2. Turn 1: Gemini 4 Argon emits a single script to fetch, filter, scan, and comment
const turn1 = await client.interactions.create({
  model: "gemini-4-argon",
  input: "Scan all modified .ts files with >50 additions in PR #42, post a PR comment with any findings, and output a 1-line summary.",
  tools: [execTool],
});
 
// 3. Run the script in a separate context (use QuickJS or isolated-vm for untrusted code)
const fcStep = turn1.steps?.find((s: any) => s.type === "function_call") as any;
const output: string[] = [];
await vm.runInNewContext(`(async () => {\n${fcStep.arguments.code}\n})()`, {
  tools,
  text: (msg: string) => output.push(msg),
});
 
// 4. Turn 2: Send only the 1-line summary back via previous_interaction_id
const turn2 = await client.interactions.create({
  model: "gemini-4-argon",
  previous_interaction_id: turn1.id,
  tools: [execTool],
  input: [
    {
      type: "function_result",
      name: fcStep.name,
      call_id: fcStep.id,
      result: [{ type: "text", text: output.join("\n") }],
    },
  ],
});
 
console.log(turn2.output_text);

When vm.runInNewContext executes the script generated by gemini-4-argon:

1. The script calls await tools.listPRFiles({ pr: 42 }) and filters the list in memory down to the .ts files with more than 50 additions.
2. It runs tools.runSecurityScan on just those matching files, checks whether any findings exist, posts the PR comment via tools.postPRComment, and emits a single line via text().
3. None of the intermediate file objects or raw scanner payloads ever enter the gemini-4-argon context window; only the one-line output summary is sent back in Turn 2.

Agent harnesses are already defaulting to Code Mode

Across the ecosystem, coding agents and developer frameworks are converging on Code Mode as their default way to orchestrate tools.

Harnesses like Pi, Factory Droid, and OpenAI Codex now ship with or default to Code Mode. Factory switched Droid 1.0 to Code Mode, improving their Terminal-Bench 4 accuracy and cutting model spend.

Agent frameworks like Pydantic AI, LangChain, or Cloudflare's Agents SDK support similar Code Mode tools already.

What comes next

Does this mean every agent will soon only have a single exec tool? Not necessarily. This is as much a research and product question as an agent harness engineering one.

When you start experimenting with Code Mode, you will also quickly notice that many of the tools, CLIs, and Agent Skills we built might not integrate cleanly out of the box because they were optimized for bash and human-readable text rather than typed code execution.

This might force you to take a step back and audit what your agent actually needs. Happy building!

Our organizations are being DDoSed from the inside

I’ve written before that you can outsource work, but not your understanding.

As a CEO, I’m finding that harder to live up to. It feels like our organizations are being DDoSed from the inside. Nobody is trying to overwhelm the company. Everyone is doing something they think is useful. But all of that work draws on the same limited capacity to understand, review, and decide. We can generate changes much faster than we can give them that attention.

I’m trying to keep product and marketing aligned while what we’re building changes daily. By the time I understand something well enough to contribute, the work might have already changed. Teams and agents are moving faster than any of us can follow.

I think there’s a pretty big problem looming below the surface in companies: leadership losing the ability to steer. Leaders never saw every piece of work. But now the work can change the direction of the company faster than we can have the ability to steer it. It’s like a car speeding up until it becomes impossible to steer.

I trust our people. We’ve put a lot of effort into hiring and building an environment where we hope people can make good decisions. Even with that effort, we’re seeing unclear or changing direction and overlapping or conflicting features. I don’t think this is a matter of people making poor decisions.

Before, we debated plans and roadmaps. There was time to understand the thinking and shape the direction. Now something can go from an idea to a working implementation before anyone outside the immediate team knows it exists. Everyone is left piecing together what happened, why, and how it fits.

When someone can build something in twenty minutes, asking to discuss it at tomorrow’s meeting starts to feel unreasonable. The thing is already there. Saying “looks good, let’s go” is easier than asking everyone to step back and consider whether it’s something we should do.

Why push back on work that’s already done and improving something?

But the fact that the work exists doesn’t tell us whether it’s the right thing to do. We have to get past treating output as proof of value. A working implementation shows that something can be built, not that it belongs in the product. Some changes have negative value.

A small change can also overlap with another team’s work or take the product in a direction we haven’t considered.

A working implementation doesn’t make those consequences disappear just because nobody thought them through.

By then, giving direction means going back to understand why a change was made, what was considered, and how it fits with everything else. This generally takes a lot longer than 20 minutes. Now this thing that someone made has made lot of people distracted from what we're supposed to make.

But moving every discussion ahead of implementation doesn’t solve it either. You can’t hold an alignment meeting for every one of the 1,000 PRs the team will open today.

So something has to change. Companies need to keep the ability to decide what work should be done, without having to discuss every change individually.

I think part of that is making intent clearer ahead of time: what we’re betting on, what matters right now, what’s out of scope. People and agents can check their own work against it.

The other part is being more deliberate about when an experiment becomes part of the shared product. Building something is much cheaper now. But landing it creates consequences beyond the person or team that built it.

We recently had to lock down our internal release channel because things were changing too quickly and multiple teams were overlapping. Customers weren’t seeing this, but internally we were struggling to keep up with our own changes. People can still experiment behind other feature flags, but the gate gives us one place to consider changes together before they land.

That helps us keep track of what’s changing. It doesn’t yet tell us whether all this work adds up to the direction we want to take.

And this isn’t just a problem for the CEO. I need to trust the judgement from my leaders, and they need to trust the judgement from their reports. The all the people whose judgment you rely on are also trying to keep up with everyone else.

I think this is happening at every level of the company, even if we’re reluctant to acknowledge it. It’s exciting to see how much people can do. It’s uncomfortable to admit that you’re losing the thread.

I wonder how the CEO’s role and organization needs to evolve, and the tooling needed to this. It’s tempting to step back because you don’t want to become the bottleneck or slow down experimentation.

But stepping back doesn’t remove your the responsibility for where it all leads. As CEO, I’m responsible for what the company does as a whole and whether it succeeds. Each team can make reasonable decisions about its own work, and I still need to understand what those decisions add up to, and how I provide the direction.

That’s what I’m finding hard to do. I try my best with using agents in Linear, pulling context, decisions, work across the company. Writing my thoughts on various things and sharing them. I still want our work to be good, and considered, something the customers can enjoy and we can take pride of. But my feeling is now easy to lose those parts when velocity of progress is so high.

Are we moving toward something, or just getting better at reacting? I can see more getting done. I’m less sure we share an understanding of where it’s taking us.

How are you dealing with this?

Prototypes are not that helpful anymore

I have spent much of my career begging people to build more prototypes. Please, please just try to make a small version of the thing before committing months of time and money to it.

Prototypes were both an excellent educational tool to try an instill engineering sense into less experienced engineers, as well as a useful artifact for corporate decision making, but less so today.

To my eye, the production of a prototype used to necessarily manifest the following benefits:

• Allowed the engineer to communicate what the fuck they even mean to other people in the organization.
• Provided the organization a representative sample of the sorts of problems and difficulties it would encounter if it took a certain technical direction.
• Demonstrated to the organization that an engineer has a legitimate command of the domain, and can therefore be trusted to speak to it in the future. Conversely, granted the engineer a persuasive tool, allowing them to make projects happen, and take agency over their own career by convincing stakeholders that they were the right person for a job.
• Forced the engineer to engage with reality before embarrassing themselves, revealing unknown unknowns, necessitating essential research, and building an engineering instinct.

Some of these were good for the organization, and some were good for the engineer. It used to be very win/win, as long as you were willing to put in the work. It’s rare to find a practice so easily prescriptible that causes such universally good outcomes. This was a “wash your hands before surgery” levels of cost/benefit. An overwhelming, across the board win when it mattered with almost no downside when it didn’t.

Let’s go through these one by one. If you’re presented a prototype, you now have to assume it is an LLM prototype, but this sort of prototype still might not be entirely useless, some of these benefits may still apply.

Communicating what you mean

This is the quality that survives the transition to AI prototypes the best. If you purely want to communicate, then I would encourage you to consider an AI prototype, maybe even more than one to explore options. It is the same class of thing as a sketch on the back of a napkin or a whiteboard drawing. Just something to get the idea across. Arguably, an AI prototype is a better way of doing this, because you can encode interaction without having to write awkward little “when you push the button, X happens!” notes.

However, beware! It is all too easy to let the LLM guide you away from what you actually meant, and towards the almost-but-not-quite-the-same LLM-average. It is especially easy to not realize that the LLM has made a decision for you, and accidentally communicate something contrary, or more commonly merely confounding, to what you wanted to be saying. The skill in communicative LLM prototypes is in preventing them from saying too much, not getting them to say more.

I suspect over time, the close to the mean, sloppy feeling of even purely communicative prototypes will begin to decay the background legitimacy of prototypes in general.

Seeing the problems ahead of time

This benefit is greatly reduced in LLM prototypes, at least in terms of inspecting a specific decision. Whilst you can inspect what your LLM has done, and even ask it for a report on the problems it encountered and solved, you will not have a sense for how truly significant those problems are in your context. Unless already highly experienced, you will also not be able to effectively project those problems forwards onto uncertain requirements shifts and twists of circumstances common to your organization.

Remember that organizations are unique, and prototypes are more than just a test of technology, they also used to serve as a limited test of an organizations social and management structure. Perhaps an engineer simply could not complete the prototype as they kept getting pulled off by fires, or maybe everyone in the organization loathes their guts so much that they do as little as they possibly can to help them overcome the technical or political problems necessary to deliver the prototype. If the employee you’re trusting with your technical strategy can’t figure out how to get a prototype server provisioned without involving 3 layers of management, for better or worse that is something an org wants to know before assigning them to a long term back-end project.

Before we get too doom and gloom, there is a potential upside here. You can now shallowly inspect the immediate technical problems across a broader set of potential options all at once. This ain’t nothing to sneeze at, although beware of all the above.

Demonstrating competence and making projects happen

Knowing who is competent and who is not is rather important for an organization. It’s one of those back-room lubricants that is essential for actually getting shit done. Prototype projects used to serve as a reasonably comprehensible marker for any given engineers competence in a certain domain. It really is as simple as “Oh, they managed to make this? Then they can’t be a total idiot.”

This benefit no longer exists at all, prototypes will not be a meaningful competence signal for very long, and engineers will have to find another way of differentiating themselves. This is a shame, as this was a tool more technically focused engineers with initiative could use to demonstrate their own value whilst applying some influence to organizational direction,

People are still using prototypes to make projects happen, but they are less powerful as a tool than they once were. My take is that if you are still seeing good results from this technique, you are borrowing from the historical legitimacy of prototyping, and it won’t last forever.

Forcing engagement with reality

Like most of this list, you can still make yourself engage with reality if you already have the skill to do so, but it’s no longer a guarantee prototypes provide. Whilst an LLM prototype is still, technically, an object that must interact with reality to function, full on LLM prototyping isolates the engineer from reality quite strongly, especially now that modern harnesses are hiding much of the chain of thought stuff from the implementer and encouraging auto mode.

Engineers who defer engagement with reality tend to be unable to follow up on one of the prime responsibilities of being an engineer, which is to be mostly correct about most things most of the time.

The unfortunate truth here is that some inexperienced engineers are now embarrassing themselves by making unqualified assertions about the future, based on prototype findings which cease to be true once they interact with the organizational reality.

Even in high directness organizations, this sort of distrust is almost never expressed publicly, or even understood in such black and white terms by the people who hold it. You will likely not be told if you are doing this, unless you have an unusually proactive manager or a very good friend in the org.

You’re supposed to have advice at the end. I think I have some.

Prototyping has worked so well for so long precisely because it was genuinely difficult to build a prototype without also manifesting most of these benefits. Crucially, everyone else also knew that to be true, so trust came for free. The prototype itself was never the point, much like how code or pull requests have never been the point, they are practices and conventions that are tightly coupled to the inexpressible thing we are all actually after.

Prototypes also used to take time, and from my observation, experienced engineers became more skillful at making them smaller. In fact, the more experienced an engineer was, the rougher and more threadbare their prototypes might look. Why is that? I have some theories.

• Experienced engineers have less time to waste and generally less to prove. They are not looking to impress anyone with shiny prototypes.
• It is more difficult to hone in on a small, sharp thesis than it is a large, sprawling one.

I think these are both true, and both will come to serve as markers of legitimacy in the coming years. Really sharp prototypes test one thing and one thing only. They are experiments, it’s science. When you think about what it means to control an experiment, it becomes clear big fancy LLM energy can often do nothing but introduce confounding variables.

It saddens me when I wonder how folks are to learn how to produce a sharp thesis, or how to build experimental prototypes that really test them. I doubt I would have ever really engaged with the problem if not for a need to get more things done faster. I simply had too much to do, and was forced to figure out how to avoid spending weeks writing boilerplate, which led me to really start evaluating what was important in a prototype. It is harder to learn how to do things when you are not being coerced in some way.

My best guess is that the preciseness of your thesis will become at least part of a new rubric. Why does this prototype exist, what specifically does it demonstrate about the future, and why should I care? A lot of prototypes I see today seem to have a rather broad thesis, something along the lines of “Can I make this thing I want to happen on my computer happen.” This isn’t a useful question to an experienced engineer, and in the age of LLMs, it’s not really a useful question to anyone.

If you build LLM prototypes, seek to use them as a sharper tool to prove out a specific thesis, understanding that they do not bring the same benefits as the one-size-fits-all, prototype-as-a-plan strategy of the past.

If you are just now dipping your feet into prototyping as a project planning tool, or self-directed R&D style prototyping, please do not get offended if people seem underwhelmed. I know a lot of people are still recommending prototyping as a sort of panacea, as a lot of goodwill for the technique has built up over time, but that doesn’t mean those same people won’t already be intuitively drifting towards a more skeptical outlook.

Remember that prototypes in of themselves have never had any value, and try to figure out what interesting experimental question you are answering, and prove specifically that.

If you are in a more managerial position, I encourage you to disavow yourself sooner rather than later of any reverence you held for prototyping. Insist on seeing one, sure, but do not hold yourself so tightly to this specific indicator, things have changed.

Resisting Cognitive Surrender

This particular note is around exploring cognitive surrender: uncritically accepting whatever agents output without actually thinking, exploring or considering alternatives. Working this way is extremely fast, not particularly taxing, and unsurprisingly seductive.

And yet I find myself repeatedly questioning if this is actually a good way to apply agents: often enough I find myself making suboptimal decisions, accruing technical debt and reducing my familiarity with the system I’m working on instead of improving it.

As we collectively rethink how we work I’ve been finding it useful to read and share other people’s workflows, and consciously write about and examine my own. This particular post focuses on finding the right balance of trust while working with agents.

Cognitive surrender is seductive

One of the virtues of being a great programmer is to be lazy. After more than a decade of training myself to look for the shortest and simplest path it’s rather attractive to be able to simply hand over the problem. If I can spin up a software factory, why wouldn’t I?

There’s also a lot of peer pressure (or game theory) at work: if any of my colleagues have seemingly surrendered, then I’m only going to look worse if I spend too much time trying to do silly things like understanding what I’m working on. And, of course, while everyone else is a slop-cannon generating code faster than they can read it I can build a meticulously designed software factory manufacturing perfect designs. The sheer volume of work also appears remarkably productive – we’ve all talked about just how many more PRs we ship every day.

This tends to get compounded by the agents’ expressed confidence & conviction. Perhaps an inadvertent consequence of RLHF, but models tend to be astonishingly confident in what they recommend (and perhaps even more blasé while admitting they made a mistake). This makes it too easy to take their answers at face value, with whatever social programming I seem to have evolved with.

OSS projects – particularly those facing time pressure – seem to accrue tremendous complexity quickly, to the point that it feels like the only way to interact with a project in any sane time frame is by heavily relying on agents to navigate and modify and test the code. This is also a self-reinforcing feedback loop: broken windows multiply rapidly with agents on the loose.

Technical debt and incidental complexity have a fairly attenuated feedback loop: complexity introduced by slop doesn’t bite immediately; it’s far more subtle and compounds over time when I’m not paying attention.

Beyond all of that, I have to mention the hype cycle. We all should be skipping Netflix to watch talks by Anthropic engineers on making loops (or the agentic workflow du jour).

Why not surrender?

It’s not entirely obvious that it’s a bad idea to surrender: if it’s easier and better, then why not take that path? So far, my personal answer is that I need to take the easier path consciously and intentionally, with enough effort to mitigate downsides.

Part of what makes me deeply uncomfortable is suffering from a form of Gell-Mann amnesia while working with agents. When I have expertise and the overall design direction I can generally simplify the output significantly, controlling for complexity. When I don’t they seem to be the smartest engineers in existence – far beyond the more squishy, organic variety – and all I can do is follow in awe. And then the agent gets stuck creating a directory and I have to reset all my assumptions.

For the current state of the art (October 2026) I generally find maximal use of agents leads to a significant explosion in complexity: something that mostly works, with extremely surprising edge cases and bugs. These are generally the projects with hundreds of thousands of lines of code shipped rapidly, breaking the scale supported by most software development tools, so you also need to revisit those – and this compounds rapidly.

I have a strong aversion to incidental complexity, and generally refuse to build, maintain or extend it: it’s fine for a proof-of-concept, but it must end there. For systems that need to keep working, steering the design aggressively towards simplicity and modularity is what lets me build something I can actually operate (with and without agents).

As models continue to improve rapidly, I expect the previous argument to go away as the models learn and can express a broader sense of engineering taste, good design and quality. The other reason – which I unfortunately expect to persist – is that my personal understanding and mechanical sympathy for systems I maintain erode extremely rapidly, or never get a chance to develop.

In the early days when I would build things by hand I’d be able to quickly diagnose any bug or misbehavior based on my familiarity with building and maintaining the code: the more I rely on agents, the more my only option is to spin up one more session and hope; and the automated fix then further reduces my understanding in a self-reinforcing loop. Without context, I no longer have much meaningful judgement and can’t engage – or handle it in context.

The Ironies of Automation (1983) is referred to often in articles similar to this one. I’d recommend directly reading the paper if you haven’t: it’s fully relevant to the decisions we have to make today. The paper warns that it becomes even harder to deal with tasks an agent fails at because we never manage to get any practice with the easier tasks; nor do we get a chance to internalize what a system feels like under standard operating circumstances.

At the end of the day, I’m responsible and accountable for what I build, not the agents. Surrendering agency and not thinking basically makes me accountable without any meaningful ownership. There’s also the small matter of pride in the quality of my work.

Solutions

The sombre opening shouldn’t lead you to believe that I’m not excited about the sheer potential unlocked by AI, and the opportunities to build things that I would never have been able to without it. It’s more about resetting expectations, explicitly working through the tradeoffs involved and choosing which ones are acceptable. And finding ways to maintain the quality and craftsmanship I care about.

There are still tradeoffs

The first step for me has been to internalize that I can’t truly have my cake and eat it: I can go terribly, inhumanly fast at building things but I need to accept that there’s no way to retain the mechanical sympathy, depth and confidence I used to have without putting in the effort. Time that used to be only counted as building a system also involved comprehension; agents can drive the time to build to zero but the next bottleneck – comprehension – hasn’t moved much so far.

The hype cycle occasionally can make it hard to communicate this explicitly: a lot of the communication around agentic loops tends to assume that there are no downsides whatsoever.

Choose your vibe limit & triage

Several months ago I defined my vibe limit as the complexity of the change I can make with sufficient confidence using agents. I like the risk/complexity curve enough to post it again:

The next step is figuring out where I land: there are several projects where good enough is fine, or the problem is sufficiently sandboxed that I’m happy to live with whatever the agents generated. On the other hand, if the system is important, fragile, can’t be sanity checked easily or isn’t particularly well isolated I need to directly spend my time.

Aggressive prioritization, triage, and constantly recalibrating myself become really important in this ecosystem: I should explicitly choose where to surrender agency and where to spend my time (not unlike leading a team, except the pace is much faster). Constantly reviewing my predictions and the outcomes helps a lot in recalibrating, particularly with new model drops.

Watch out for automation bias

I also find myself needing to be much more mindful while working. A warning sign I watch out for these days is if I find myself repeatedly tapping “yes, continue” in a session. At that point either I should figure out what it would take to completely delegate the problem to Claude instead of trying to micro-manage the agent – or realize that I stopped thinking and I need to check the decisions being made.

Completely delegating the problem generally means building a better sandbox or feedback loop, or figuring out ways to be able to sanity check much more easily before shipping to production. Alternatively, if I need to engage much more deeply I’ll use some of the other tactics described below.

Force yourself into the loop

The premise of augmenting myself by working in the loop with powerful thinking machines was a large part of my decision to join my current company. This generally comes down to directions you can give the model to reduce the size of the steps it takes, or explicitly choosing to drive instead of passively observing.

For projects I deeply care about, choosing to drive instead of letting the model drive is one way to intervene in every single decision. It’s much slower to type things out, but it does force me to engage with every decision and gives me an opportunity to override it. In fact, for this post I’m using a Codex session to edit: help me tighten the post, point out the small typos, punctuation errors, or half-finished sentences that tend to embarrass me after I explicitly share a post publicly – but I make all changes by hand.

In the AGENTS.md for the notebook:

Never edit files directly, always wait for the author to request or confirm changes, or let him make the edits directly.

This is reminiscent of how I used to work with Stack Overflow: never copy-paste code; instead write it out explicitly while cross-checking with documentation. Either I’d learn and internalize something new or I’d realize the Stack Overflow answer was suboptimal or outdated.

Force comprehensibility

We don’t need to limit ourselves to existing interfaces anymore: with agents it’s also possible to have them build a tremendous amount of scaffolding to support comprehension and make changes in ways that are digestible.

Often enough for larger, complex stacks I have the agents build me a custom view for the Pull Request with 4 columns: the standard 2 for the diff, a 3rd column with running commentary from the agent on why it made a particular change and finally the 4th column as a place for me to add comments and directions.

Getting the agents to make stacks of changes with the explicit direction to “Make the change easy, then make the easy change” works really well. I used to spend a lot of time trying to make my diffs easily reviewable to respect the reviewers’ time – now I can ask the agents to do the same for me.

It’s also very valuable to dive into actual execution with a debugger (or have an agent manipulate the debugger on your behalf) till you get a deep sense of how things are flowing through the program, with the confidence that this is the real execution path.

Another example is to make harnesses explain what they’re doing: I’ve built several variations of command-line helpers that transparently fit into my shell sessions. In my most recent iteration, I explicitly ask the model to explain any obscure flags and commands used so that I can learn as I go.

When you do decide to delegate

Sometimes, it does make sense to hand over the problem to an agent: it could be too big, not valuable enough, time could be too short, or you just want to get a first prototype out to explore a problem end-to-end.

This one is probably an essay by itself: adapting old-school best practices when you have infinitely fast stochastic intelligence on top. The idea here is to reduce the risk in making changes, flattening the vibe-limit curve and making it possible to make bigger changes safely.

• Observability: Invest heavily in observability, both black-box and white-box, and make sure to keep a direct handle on the metrics instead of solely relying on the agents’ view. As a habit I prefer to triangulate onto a behavior with multiple sources of metrics, and that becomes even more important with systems rapidly becoming opaque.
• Non-functional requirements: Don’t forget to observe resource utilization and other non-functional requirements: these can be canaries for unexpected behavior.
• Deterministic validation: Build mechanical straitjackets for the model: have held-out pieces of code or deterministic tools for validation and observations as a hold-out against the model misunderstanding or glitching.
• Shadow Traffic: Make it possible and cheap to run a deployed candidate against shadow traffic with no side effects: keep it as similar to production as possible, and this can be the final gate to prevent surprises.
• Style guides: Give the model a style guide based on your existing code and work. I’ve found Claude’s output far more to my taste after having the models generate a style guide based on all the code and blog posts I’ve written in the past.
• Fast deploys: An often maligned motto at Facebook used to be Move Fast & Break Things: that, too, is an intentional tradeoff to make. If you can’t be sure of quality, make it very easy to deploy code as well – so changes can be shipped and reverted extremely rapidly.
• Rethink what’s possible: It’s surprisingly easy to write and rewrite systems from scratch rapidly as you learn. Build to throw, evaluate, and repeat to get something knocked into great shape – I’ve built projects in multiple iterations, giving the agent the previous iteration and its limitations as initial context and constantly finding myself able to deeply increase the quality. This doesn’t work as well when you’re punishing your code reviewers though, so make sure to align with your team, or simply don’t get the first several iterations reviewed.

Good design is a force multiplier

In Notes on the Synthesis of Form Christopher Alexander has a wonderful example demonstrating the value of decomposition – or building a lightly coupled, cohesive system to be able to succeed quickly.

No complex adaptive system will succeed in adapting in a reasonable amount of time unless the adaptation can proceed subsystem by subsystem, each subsystem relatively independent of the others.

Whether agents or humans are doing the work, a good design makes the system much easier to understand, iterate on, validate and extend. As you learn the limitations of the design, you also now have the ability to redo it much more rapidly than ever before. Regardless of how much depth you decide to maintain in your projects, I’d make sure the broader structure continues to make sense.

Additional reading

• Addy Osmani with several additional techniques
• Guy Levi recommending leaning into critical thinking
• Cory Doctorow talking about handling being forced to use AI
• Stuart Halloway emphasizing that AI is automation, and the importance of friction to build metis.
• Elizabeth, SigNoz on skills atrophying.
• Ricard Solé et al. on LLMs as a cognitive virus, modeling the interaction and consequences of cognitive offloading.

1. I have constantly been expecting more software to fail under the weight of its own complexity. One of my hot takes is that this hasn’t happened at the scale and magnitude I expect yet because agents became smarter fast enough to keep up with the debt introduced by the previous generation.

2. You’ll pry my weekly indulgence in The Great British Baking Show from my cold, dead hands.

3. You could argue that this is a very “Individual Contributor” approach to building things, and that managers deal with this all the time. I’ll quote Andrew Grove on management: “delegation without follow-through is abdication” – you still need to engage to get the outcome you need.

Canva spent the past week showing off an AI model that creates images, and now it’s turning to the harder task of reworking them. On Thursday, the company introduced Brush, an in-house vision-language model built to edit designs. Because Brush reads both what’s in a design and how it’s arranged, Canva AI users can make precise changes without losing control of the final result. The company reports that Brush completes general editing tasks up to 69 percent faster than its previous design agent, at 46 percent lower cost per task.

Teaching its existing design model to edit as well as it designs might seem like the simpler path, so why did Canva decide editing deserved its own model? It contends that generating a design is only the first step, and that editing it is the harder problem. Getting AI to produce something close to what you pictured is the easy part. Getting it to land exactly where you want takes a different kind of work, like reshaping a design’s look for a new audience, resizing it for another platform, or aligning mismatched fonts and colors.

But getting the finer adjustments right isn’t the main reason Brush exists. Cost is. Earlier this year, Canva slowed its AI rollout because the economics weren’t ready, and general-purpose models sit at the center of that math. The company explained that these models have the scale and power to handle design edits, but that same power makes them expensive to run. When hundreds of millions of people create billions of designs on a platform, even a few extra cents per edit adds up quickly.

Cheaper edits only matter if they’re the right edits, and Canva acknowledges that speed is worthless if the result misses the mark. “The model needs to understand what you want to change, how the design is structured, and just as importantly, what needs to stay exactly as it is,” the company wrote in a blog post. “Otherwise, a simple edit request can result in a whole bunch of changes you didn’t ask for.” It illustrates the challenge with a request for a three-page bakery pitch deck in an Art Nouveau style. To pull it off, an AI agent has to plan a narrative across pages, write and place text, choose imagery, and keep typography, color, and spacing consistent throughout, with each choice affecting the others. Canva said it built Brush to handle that chain of connected decisions.

“Rather than treating design as a series of isolated decisions, Brush can continually evaluate and improve its work, helping you take an idea from a rough sketch to a polished design that’s ready to share,” the company explained. Behind the scenes, Brush writes and runs small pieces of code to adjust a design, then inspects the result before deciding what to do next. In theory, that cycle of acting and checking lets Brush catch how one change ripples through the rest of a design before the user has to.

Brush didn’t start from scratch. Canva Research, Canva’s 160-person AI lab, began with an unnamed leading open-weights model and trained it further on real design and editing tasks, drawing on in-house design expertise and anonymized insights from users who opted in to help improve Canva AI.

The team also relied on large-scale reinforcement learning, a training method in which a model attempts tasks and is rewarded for good results, to help Brush “work through complete design and editing tasks, learn from what worked, and continually shape its future behavior.” Canva built a scoring system that judges the model’s output on visual quality, adherence to design principles, and whether it completed the assigned task. That system draws on Canva’s design expertise, its template library, insights into how people edit, and “hundreds of thousands” of simulated interactions. The company added that professional designers on its staff set the standard for what counts as “good” design.

For now, Brush is available in beta to Canva Pro subscribers, and Canva plans to make it widely available soon. To start, users open a design in the editor or attach it in Canva AI, select “Brush” from the dropdown menu, and describe the change they want. They can restyle a design or image by adjusting its color scheme, changing the weather, or describing a different mood; update headers across a multi-page deck with a single request; or turn a presentation slide into an Instagram graphic.

Canva said it’s already working on Brand Kit support, the ability to reference attachments, and improvements to how Brush handles image-heavy layouts.

Brush’s release comes a week after Canva debuted Craft, its first image-generation model. It builds on the company’s second-generation AI platform, where users can use text or voice to describe what they want to create. Notably, Canva’s platform already offers agentic editing, but Brush likely scales that feature considerably.

Canva isn’t alone in turning to AI to help people edit their work. Adobe reached a similar conclusion last October with Firefly Image 5, arguing that creative professionals care as much about editing content as generating it. The model introduced layered, prompt-based editing that treats each object in an image as its own layer, so users can swap or adjust elements without regenerating the entire picture. The two companies have since taken different routes. Adobe’s editing tools operate on individual images, while Canva’s Brush works across complete designs, from a single line of copy to every slide in a deck. Adobe also leans on outside partners, offering third-party models such as Google’s Gemini and Black Forest Labs’ FLUX alongside its own Firefly. Canva uses partner models, too, but it’s betting that specialized models it trains itself will deliver better results at a lower cost.

To design is to make deliberate decisions about how something should work, how it should be experienced, and how it should respond to the conditions in which it will be used.

In the world of software, we say software has been “designed” when there is coherent intentionality behind it. When any element of what is being designed goes unaccounted for (intentionally or otherwise), we cannot say it was “well designed.”

These days, it’s becoming remarkably easy to make software. Even software that looks good and works reasonably well.

With AI tools like Claude, Cursor, and ChatGPT, nearly anyone can describe an interface, generate a working version of it, and continue prompting until the result feels right. Software which used to take weeks or months to design and engineer can sometimes be produced in an afternoon.

I think it’s an incredible time to be in the world of software design. But I worry many are conflating the speed of producing something with the quality of designing it.

Just because something looks designed doesn’t mean the decisions behind it were well considered.

Consider a building designed to withstand earthquakes. Its ability to stay standing after an earthquake isn’t something architects and engineers can simply add after construction. The possibility of an earthquake influences the building’s structure, materials, and how it needs to move under stress.

Or consider hardware designed for harsh environments. Exposure to water, extreme temperatures, or physical impact influences everything from the materials used to the shape of the enclosure. Apple’s approach to hardware is a great example of this point. The Apple Watch Ultra has a raised titanium enclosure designed to protect its display from impact. This isn’t simply an aesthetic choice, but rather a decision informed by the conditions in which the product must work.

In both cases, a building designed to hold up against earthquakes or hardware designed to survive rough situations, the conditions aren’t just tests the finished product must pass. They’re inputs that fundamentally shape the design.

Software design is no different.

When designing an interface, it’s easy to focus on ideal conditions like a particular screen size, familiar language, predictable content, and a user who can see and interact with everything exactly as intended. But what happens when a translated label ends up being rendered twice as long as the original language string? Or what about when someone increases their preferred text size? When a visualization encounters values far outside the expected range? When someone can’t use a mouse, information is missing, or an action fails?

These aren’t simply edge cases to fix after the design is finished. They’re conditions that can reveal what the design should have been in the first place.

I believe something that is “well designed” isn’t something that’s first made and then tested against reality. Reality is what helps determine what gets made in the first place.

This is where I think some enthusiasm for AI-generated interfaces risks missing a critical element of design. If I prompt a model to create a dashboard, it might produce something that looks fantastic, particularly if I have a well constructed design system and documentation to guide the work. The hierarchy might make sense, the spacing appear consistent, and the interactions appear to work. But what do I actually know about the design? What decisions did I make?

Do I know why information is organized the way it appears? Whether the interactions support the tasks people need to accomplish? Whether the interface can accommodate different languages, accessibility needs, or unpredictable content? Have I even considered those questions?

In this scenario, the model has made decisions on my behalf, whether I recognize them or not. Some decisions might be excellent, better than any I could make myself. Others might rest on assumptions that don’t apply to what is being built. And if I’m judging the result primarily by whether it looks right at-a-glance, I have little reason to question those assumptions.

This isn’t unique to AI. Software designers have always been capable of producing beautiful work without fully considering the consequences of their decisions. AI just makes it easier to arrive at something convincing before we’ve had to think through what makes it work (or not).

Of course, AI can also help us explore constraints, evaluate alternatives, and challenge assumptions. Someone thoughtfully using AI might produce better design work than someone spending weeks manually arranging pixels. The tool isn’t the distinction and neither is the time spent on a design.

The distinction is whether we’re deliberately shaping a solution around the conditions it must satisfy, or merely accepting a solution because we like how it turned out.

Making something faster is valuable. But producing a convincing interface quickly doesn’t tell us whether we’ve made the right decisions. It only tells us how quickly we’ve arrived at something convincing.

To say something has been well designed requires understanding the people, environments, limitations, and conditions the work must work within, then allowing that understanding to shape what gets created.

That’s part of what makes design a practice rather than simply an act of production. The work isn’t just making something that looks or feels right. It’s understanding what would make it effective, and what might prove us wrong.

Full article content is not available for inline reading.

Read the original article →

Experience Design: Dropping the “User” from “User Experience”

AI is expanding UX beyond human users to agents acting on their behalf. Experience design names this broader field, which still centers on people’s goals.

I am not one for new terms. When NN/G changed its job titles from “user-experience specialist” to “experience specialist”, I was skeptical. The article we published to explain the change did not convince me either: yet another name for the same thing. I now think the new title was right, but for a reason we did not think of at the time. Our field is no longer only about people directly using products and services. It also includes agents that act on their behalf. UX is not disappearing. But AI is expanding the field in several directions at once.

UX Has Always Been More than UI

Don Norman helped popularize the term "user experience" in the 1990s because "usability" and "user interface" were too narrow. He wanted a name for everything a person experiences with a product, from the packaging to the support call. The term widened the object of design beyond just the digital product, to physical products and services. Yet, the idea of a broader object of design did not really hit home until the 2010s, when modern smartphones rose to ubiquity, and people started using multiple channels to accomplish a goal. As a response, UX and design professionals began creating customer-journey maps and service blueprints to help them understand and track all the possible ways in which a user could interact with the organization while trying to achieve a goal. At that time, we began to understand that a good experience meant that all the touchpoints worked together coherently.

But throughout all these iterations of the work, one assumption stayed constant: that the human was the user — the one who interacts with the company directly, through one of many possible channels.

AI changes that assumption. And not because users can use an AI-chatbot feature to interact with a business. (That is just another channel in the journey-level experience.) But because humans may no longer interact with the company at all. Instead, their personal agents may do so. And these agents may act completely outside the ecosystem of channels and touchpoints that the company has devised.

A person may ask an AI assistant to shop for groceries, file a complaint, cluster photographs, book a flight, or cancel a subscription. The agent becomes the immediate user of the product or service while acting on the human’s behalf.

The journey now spans not only multiple channels but also multiple actors. This is why I believe “experience design” is a fitting name for the broader field.

From User Experience to Experience Design

Experience design is the discipline concerned with designing and evaluating how people accomplish goals through products, services, and systems, whether they interact with those systems directly or through agents acting on their behalf.

The field includes traditional UX but extends beyond it. Like UX, it studies the products people use themselves and the AI systems they interact with, but it goes beyond UX to encompass the systems that agents use on humans’ behalf. It also expands the methods used to design and evaluate experiences.

Experience Design Is Still Rooted in Human-Centered Design

Expanding the field beyond human users does not mean abandoning the principles of human-centered design. The ultimate criterion of success for an experience is whether the human achieved their goals. Designing for agents is not the same as optimizing blindly for agent success; the goals, interests, and welfare of the humans behind them still hold priority. For example, an agent-facing system that facilitates bank transactions would still need to consider the financial safety and interests of the people on whose behalf the agents act.

The Scope of Experience Design

We said above that experience design expands the scope of UX. Experience design deals with designing for:

• Humans interacting with products
• Agents using systems on behalf of people
• People and agents interacting with systems

1. Humans Interacting with Products

AI does not obliterate the traditional scope of UX. All the topics that UX has traditionally studied (such as usability, information architecture, interaction design, content, and accessibility) are still within the scope of experience design.

People will still use products and services directly and they still need to be able to complete the tasks they want, should they choose to do it the regular way. They need to be able to purchase an item, navigate a healthcare website, or complete a tax form. Traditional UX remains the foundation of the field.

However, beyond traditional products, a special type of system is one that uses generative AI: AI features embedded on a website or within an application, AI personal assistants, AI agents, generative UIs, or other AI-enabled products. Many traditional UX methods still apply to these systems, but some of their characteristics (nondeterminism, autonomy, and the ability to make inferences) raise new research questions that those methods were not designed to address. Some of these questions include: When should an agent act without asking the human? When should it ask the human for clarification? What should the agent remember? What should an agent consider as part of its context and what types of information should it have access to? When should control return to the person? How should someone inspect or reverse an action taken by an agent?

Because many of these questions depend heavily on people’s needs, goals, and contexts, qualitative research will remain as important as ever. However, new methods or adapted protocols may need to emerge as well –– for example, repeated runs for systems, analysis of system’s variability, inspection of log traces, observation of how control moves between people and agents.

2. Agents Using Products and Sevices on Behalf of People

Agents act on people’s behalf, but what makes an experience good for humans is not necessarily what makes an experience good for AI. AI agents may have access to representations that humans don’t (e.g., code, structured data, APIs), while humans may take advantage of visual hierarchy, spatial organization, and other perceptual cues. Figuring out how to design for agents is a new emerging discipline that some call agent experience. Agents may interact not only with websites and apps, but also with other people. For example, an agent may call a restaurant and speak with a host in order to make a reservation. How well the restaurant's phone process works for the agent is also part of the agent experience.

3. People and Agents Interacting Within Products

When people and agents are part of the same journey, new experience problems can arise. A product can work well when humans or agents use it but can be flawed when both act on it.

For example, imagine that a person asks an AI agent to book a flight. The agent recommends a flight, and the user accepts its recommendation. To proceed with the booking, the agent asks the user to log into the airline’s website, but the user has trouble doing so because their password-manager extension is not available in the agent’s in-app browser. The agent works just fine, and the authentication request is reasonable. The in-app browser is designed for the agent to perform steps and for the user to consume content.

The experience breaks when the task moves from agent to person and the person is asked to use a tool that they normally don’t use and that is presumably designed for agents.

The fix for this problem is easy, but beside the point. The problem itself could never have been spotted by studying the agent or the human alone; it only becomes visible when we study the human-agent system as a whole. Once tasks in a journey pass back and forth between humans and AI, some of the experience problems will live in the handoffs rather than in the interaction alone. Continuity of information and progress, authorizations, transparency, and recovery all become experience-design problems in their own right.

AI Is Also Changing Our Methods

AI also changes how experience-design work is done. There are three reasons for that:

1. AI accelerates traditional UX practices, such as generating prototypes, drafting study materials, or analyzing research data. This changes the efficiency of UX and design work, but does not necessarily its nature.
2. AI may enable new methods for achieving traditional UX goals. Researchers are already experimenting with synthetic users and digital twins, AI interviewers, and AI-based usability evaluations. Some of these methods augment traditional methods, but they all still require rigorous validation.
3. Agents and human-agent systems are new objects of study, and some of the traditional human-research methods will not be suitable for researching them. Agents cannot be necessarily interviewed or asked to participate in a usability test, but researchers may be able to vary context, instructions, or available tools that are made available to these agents to research their behavior. Additionally, studying human-agent experiences may require adapted or new methodologies focused on how the person delegates and how control moves back and forth between agents and humans.

Experience Design: Broader, Still Centered on People

A while back, UX expanded its object of study from individual interfaces to journeys across channels. Today, AI is expanding the definition of the field again: the journeys can cross not only channels but also involve multiple actors, and the methods we use change, too. We still design and evaluate systems so they help people efficiently accomplish their goals, but the systems, actors, and methods we study are broader.

Experience design is the name for this larger, still human-centered field.

Can AI agents use your product?

Dedica tests your site the way AI agents use it, then gives your team a fix for every place they fail.

Free score in under a minute.

Agents buy where it’s easiest

“Buy 1 kg of espresso beans under $40”

yourstore.com Without Dedica

Loading the page…Step 1

competitor.com With Dedica

Espresso beans Dark roast · 1 kg $36

1. Found the productsearch_products
2. Added to cartadd_to_cart
3. Paidcheckout

Order placed · $36

The agent ordered from the store it could use.

How it works

1. Check your score

   See where agents fail, in under a minute.

2. We build the agent version

   Readable pages, assistant connectors and checkout agents can finish.

3. Go live on your domain

   Same address, no rebuild.

What we run for you

1. Assistant connectors

   Publish once to ChatGPT, Claude, Muse and Perplexity.

2. Agent actions and payments

   Agents sign up, book and pay. Every sale is credited.

3. Agent traffic analytics

   Which agents visit, what they finish, where they fail.

4. Proxy deployment

   Runs on your domain. Your site stays as it is.

Pricing

Free

$0

• 5 pages per site
• 3 sites
• Agent readiness score
• Top fixes
• Listed in ChatGPT, Claude, Muse and Perplexity
• Agents can sign up and book with you
• See which AI agents visit and what they get done
• 24/7 support from the founders

Pro

$79/month

• 150 pages per site
• 3 sites
• Everything in Free, plus:
• Agents can pay and buy from you
• Live on your own site address, no code changes
• 24/7 support from the founders

Enterprise

Custom

• Everything in Pro
• More than 3 sites
• Unlimited pages
• Setup with our team
• 24/7 support from the founders

Questions

Will Google treat this as cloaking?

No. Agents get the same content as people, as plain text. Search crawlers see your normal pages.

Does Dedica change my website?

No. Your code, hosting and CMS stay as they are.

What happens if Dedica goes down?

Visitors fall through to your normal site.

When an agent pays, where does the money go?

Straight to your payment provider. We never hold funds.

What data can Dedica see?

Only agent requests, which power your analytics. Not what people do.

How is Dedica priced?

Free, $79 a month for Pro, and custom for Enterprise. Every plan has 24/7 support from the founders. To get started, book 15 minutes with them.

What is MCP?

The protocol assistants like ChatGPT and Claude use to connect to outside tools. Dedica gives your site an MCP server.

Is the score really free?

Yes. No signup, no card.

The Window With No Buttons

Why the terminal feels so unfamiliar to designers, and how to read it anyway

If you've spent your career in design, you're probably used to working on a canvas. Most projects have a visual form: objects you can select, layers you can rearrange, and elements you can watch change as you work on them. And even the more abstract parts of a design system, like tokens and variables, sit in panels you can browse.

Then, you open the terminal — a blank window with a blinking cursor, waiting for you to type something. No buttons to click or menus to browse, and when you run a command, the reply is often a few lines of text, or nothing at all. Moving from a spatial, visual workspace to one where you need the right words before anything happens can feel like hitting a wall (sound familiar?). As designers, we have good words for why: the terminal leaves out almost everything we spent our careers adding to interfaces.

And it's turning up in more of the tools around a design system. Style Dictionary, Storybook, and AI coding agents like Claude Code all run from the terminal, so if you look after a system, you're probably opening it more often than you used to. Like any interface, it has its own conventions, and you can learn them one at a time, starting with knowing which folder you’re in.

Getting comfortable reading and using the command line can help in a few concrete ways: you can run your team's project on your own machine and see a token change on real screens before it ships, or look at the command an AI agent wants to run and decide whether to allow it. And you get a closer view of how your engineering team works, which can make conversations between design and engineering a little easier.

The terminal, the shell, and the command line

CLI stands for command-line interface, and it’s an acronym you might be seeing more often lately, in names like Gemini CLI, Codex CLI, and the GitHub CLI. It’s a way of operating a computer by typing instructions one line at a time and reading the text reply underneath. Before windows, icons, and the mouse, most people used a computer this way. The graphical interfaces (GUIs) we design for today arrived partly so people wouldn’t have to memorize all those commands.

You’ll hear the words terminal, shell, and command line used almost interchangeably. Pulling them apart makes the rest a little easier to follow:

• The terminal is the app you open. On a Mac, it's called Terminal (original, I know!) and lives in the Utilities folder inside Applications. On Windows, it's usually Windows Terminal or PowerShell.
• The shell is the program running inside that window, which reads what you type and works out what to do with it. Macs have used one called zsh by default since 2019, so you'll sometimes see that name in error messages.
• The command line is the line you type, next to the blinking cursor.

A well-designed menu shows every available option, groups related ones together, and dims the ones that don't apply right now. It lets you recognize what you want instead of remembering it, which Jakob Nielsen described as recognition rather than recall. The command line works the other way around — you type a word, press Return, and either something happens, or the computer replies with a short message that assumes you already know what it means. Nothing more. If the terminal has always made you a little uneasy, that heuristic helps explain why.

In return, you get consistency. A command does the same thing each time you run it, so you can paste one into Slack for a teammate, or save it in your notes for next month, and it should behave the way it did today.

The prompt, the folder, and the command

When you open the terminal, you'll see a line of text ending in a % or a $, with the cursor resting after it. That's the prompt — the shell's way of saying it's ready. Whatever comes before the symbol is usually your username, your computer's name, and the folder you're in, and you don't type the symbol yourself. Documentation shows commands in a monospace font, often in a shaded box, and if a line starts with $, leave that off when you copy it.

The idea I'd spend the most time on is the working directory. In Finder, you can have five windows open on five different folders. The terminal is only ever standing in one folder at a time, and every command you run happens there. If a README tells you to run npm install and you run it from your home folder instead of the project folder, it might fail, or install things in the wrong place. It's a bit like asking someone to tidy "this drawer" while you're both standing in the wrong room.

Three commands, pwd, ls, and cd, help you find your way around, and none of them change anything, so they're a good place to start experimenting. If you'd like to try them now:

1. Open Terminal.
2. Type pwd and press Return. Terminal replies with a path, something like /Users/yourname. That’s the folder you’re in right now.
3. In Finder, make a new folder on your Desktop and name it practice.
4. Go back to Terminal, type cd Desktop/practice, and press Return. Then type pwd and press Return again. This time, the path ends in practice (the folder you made).
5. Type ls and press Return. Nothing appears yet, because the folder is empty. Drag any file into the folder in Finder, then try ls again. Now you’ll see the file’s name.
6. Type cd .. and press Return to step back out to your Desktop.

The commands you’ll find in a README are often longer than those three, but most follow a structure that reads a little like a sentence. Here’s one from Style Dictionary, a tool that turns design tokens into code:

• The command (style-dictionary) is the program you're calling.
• The subcommand (build) is the specific job you want it to do.
• The flag (--config) is an option that changes how the job runs. Flags often come in a short and a long form, so npm install -g and npm install --global ask for the same thing.
• The value (tokens.config.json) is what you're handing to the flag, in this case the file where your settings live.

The lines underneath are Style Dictionary’s reply: for each platform, it lists the file it wrote.

If you’ve ever exported a frame from Figma, you’ve made a similar set of decisions. You chose an action (export), set how it should happen (PNG at 2x), and pointed it at something (the frame you’d selected). A command holds those same decisions in a single line. In the Style Dictionary example, build is the action, and --config tokens.config.json sets how it should happen by pointing it at your settings file.

When you’re unsure what a tool can do, try adding --help after its name. Many tools respond with a plain list of their commands and options, which is the closest thing the command line has to a menu.

Tokens, Storybook, and AI agents

For a long time, a designer could go their whole career without opening the terminal. Design tokens are often where that changes. Once your colors, spacing, and type live as JSON files in a code repository, tools like Style Dictionary turn them into the CSS and platform code your engineering team uses, and those tools often run from the command line. If your component documentation lives in Storybook, its setup adds an npm run storybook command for starting it on your own machine, so you can see a change before it ships.

The bigger reason is AI. Coding agents like Claude Code, OpenAI's Codex CLI, and Google's Gemini CLI work directly in the terminal. The agent does most of the typing, but you still decide what it's allowed to run. By default, Claude Code shows you the commands it wants to run and asks for your go-ahead first, and being able to read those lines, even roughly, can be what turns a nervous click on "allow" into a decision you've made yourself.

Careful commands and helpful keys

It’s natural (and probably a good thing) to feel cautious here — the terminal can permanently delete files without sending them to the Trash, and it will rarely confirm the action with you before it takes it. But, most everyday commands don’t change anything. pwd, ls, and cd read information or move you between folders, so you can run them as often as you like.

When a command does need more care or caution, a few words in the line usually give it away:

• rm deletes files immediately. Before running it, use pwd to check which folder you’re in, and read the rest of the line carefully.
• sudo runs a command with administrator rights and asks for your password. That request is a good moment to stop and check where the instructions came from.
• curl followed by a web address and | sh downloads a script and runs it straight away. Homebrew, a package manager for Mac, uses this kind of line on its own homepage, and that’s expected. If the same pattern turns up in a forum post, pause and ask someone you trust.

Taking a moment before you press Return goes a long way. And like the shortcuts you rely on in Figma, the terminal has a handful of its own. Here are a few to start with:

• Control + C stops whatever is running. (On a Mac, this is the Control key, which is easy to mix up if your fingers are used to Command shortcuts).
• q closes a long page of text that has filled the window, like a manual page or a git history, and returns you to where you were.
• The up arrow brings back the last command you ran, and pressing it again steps further back. It’s a quick way to fix a typo without retyping the whole line.
• Tab fills in the rest of a file or folder name after you’ve typed the first few letters, which also saves you from typos. If nothing happens, there’s probably more than one match, so type another letter or two and press Tab again.

Error messages and what they mean

Error messages can look intimidating, especially when you already feel out of your element. Here are a few you’re likely to meet, and what they usually mean:

• command not found: the tool isn’t installed yet, or there’s a typo in its name.
• No such file or director: you’re in a different folder from the one the instructions expect. Check with pwd, and move with cd.
• Permission denie: the command is trying to change something your account can’t. Check with someone on your engineering team before reaching for sudo.
• Lines starting with npm error (or npm ERR! in older versions): something went wrong while installing packages. The first few error lines usually name the cause.

If you’re still stuck, try sharing the message with someone on your engineering team, or ask an AI assistant like Claude to break it down for you. And if you’d like that help closer to hand, you can bring Claude into the terminal itself with Claude Code, which can explain a command in plain language and run it for you. That’s where knowing the basics helps: when Claude suggests a command, you’ll be able to read what it’s about to do and decide whether it looks right.

Side note: Early in my career, I spent a few years working as a front-end developer, and the number of errors I wrestled with while installing NPM packages was one of the things that eventually drew me back into design — I'd comb through forum post after forum post and often come away without a clean answer. If I were in that same phase now, with the tools we have today, I think I'd be more inclined to see it through.

I hope this post gives you enough context to look at a README, or a command an AI agent wants to run, and have a sense of what’s about to happen. If you’d like a low-pressure place to start, open the terminal and type pwd. The cursor will still blink back at you, and this time you’ll know which folder you’re in.

Thanks for reading. 👋💛

It looks like OpenAI might be on the verge of releasing its next frontier model, GPT-6.2 Astra. Over the weekend, several Codex users noticed a new entry in their usage analytics: gpt-6.2-astra, listed right next to the GPT-6 Astra model that launched in September.

GPT-6.2 Astra is showing up in some peoples Codex Usage Analytics. Next week might be the single greatest week of releases we will have ever seen

The screenshots that are being shared online come from the usage page that tracks plan consumption across Work, Codex, and other agent tasks. In every breakdown we've seen, gpt-6.2-astra shows up only on the October 31 bar. Its share varies a lot by account, from 1.6% of one user's week to 19.8% of another's, and 37.7% of a single day for a third. The model picker still says GPT-6 Astra, so it looks like some requests are being quietly routed to the new model, either as an A/B test or the start of a staged rollout.

The wait is almost over, my friends. The model is coming soon, and now it's official.

X user Token Gremlin even shared a raw response event with the model field reading "gpt-6.2-astra," calling it official. That's strong evidence the ID is live on OpenAI's servers, but it isn't an announcement. OpenAI hasn't mentioned GPT-6.2 Astra anywhere, and its model docs still list GPT-6 Astra, GPT-6.1 Sol, and GPT-6 Luna.

Some testers who think they're getting output from GPT-6.2 Astra have even shared their results on X. From what we can tell, we also lean toward the idea that this is a newer, more refined version of Astra.

X account Fini.Yang shared what they call the first gray-test result: the classic pelican riding a bicycle, rendered as a 360-degree 3D scene.

GPT-6.2 Astra 灰度测试第一弹. 有请我们的老朋友 —— 鹈鹕！！！让他们为我们表演一个鹈鹕360°立体骑车！！

Meanwhile, another user says the model created a semi-open-world 3D RPG from a single prompt and wonders whether it could give Opus 5.5 a run for its money. Since the picker doesn't identify which model responded, it's difficult to confirm whether any particular output came from 6.2.

GPT-6.2 Astra just built a 3D RPG game in one shot. A semi-open world, generated from a single prompt. Is it coming for Opus 5.5?

In case you're wondering what happened to GPT-6.1 Astra, here's some context. OpenAI shelved GPT-6.1 Astra in late September after internal testing raised concerns about deception and scope, so a jump straight to 6.2 could point to a fixed, retrained model. That's only speculation for now, though, and OpenAI hasn't made that connection. The timing also coincides with Codex lead Thibault Sottiaux's daily shipping series, which wrapped up with usage resets — something some people are interpreting as a possible launch window.

If these early sightings of GPT-6.2 Astra in Codex usage analytics are anything to go by, then it looks like OpenAI doesn't want to wait for the competition to leapfrog it. The company released GPT-6.1 Terra just a couple of days ago. Plus, the competition has been heating up. Google recently unveiled Gemini 4 Carbon for cyber defenders and is testing a new Carbon checkpoint on Arena, while Anthropic's Fable 5.5 is already with partners.

If 6.2 Astra is already handling real Codex traffic, a public launch could be days away, and X account Lumina thinks next week could be one of the biggest release weeks we've seen. Until then, we wait...

Microsoft's Copilot Cowork, an AI-driven agentic execution layer, achieved global availability in four and a half months, switching its runtime from Python to Rust while live. Key practices included writing clear specs before coding, running narrow agents with clear boundaries, and ensuring automated checks genuinely verify code changes. The transition to Rust improved efficiency and highlighted the importance of clear testing, boundary setting, and human oversight in the development process.

Full article content is not available for inline reading.

Read the original article →

Key Points

• Anthropic reported updated financials as part of an amended Form S-1 filing with the Securities and Exchange Commission.
• The company said it generated $33.24 billion in revenue for the nine months ended Sept. 30, up roughly 1,200% from the same period last year.
• Anthropic unveiled its highly anticipated prospectus last week, but the initial filing only included the company's financials through the first half of the year.

Anthropic reported updated financials as part of an amended Form S-1 filing with the Securities and Exchange Commission on Monday, giving investors a more comprehensive look into the state of its business.

The artificial intelligence company said it generated $33.24 billion in revenue for the nine months ended Sept. 30, up roughly 1,200% from the same period last year. It reported a $104 billion net loss during the period, though most of that was due to the change in fair value of convertible notes and derivative liabilities. Anthropic had a loss of $25.1 billion over the same stretch in 2025.

Anthropic unveiled its highly anticipated prospectus last week, bringing the company one step closer to a potentially historic initial public offering. The initial filing only included the Claude maker's financials through the first half of the year.

During its third quarter, Anthropic generated roughly $17 billion in revenue, up about 1,127% from the same period last year. Revenue growth slowed on a quarter-to-quarter basis, however. Third-quarter revenue increased around 47%, a steep drop from 144% growth in Q2 and 132% in Q1.

The company reported a net loss of $23.29 billion during its third quarter.

As the 5-year-old company prepares to kick off its roadshow, it will have to reckon with growing market jitters around the AI buildout. Wall Street has been worried that rising interest rates will make debt unaffordable for many data center developers and neoclouds, and quarterly reports from Microsoft, Alphabet and Amazon last week added fuel to those concerns.

The hyperscalers' aggressive AI spending is eating into their cash flows, causing some investors to worry that computing capacity may not come online quickly enough to meet Anthropic's demands. Anthropic gets much of its capacity from Amazon, Google and SpaceX, but it also relies on neoclouds for some compute as it races to expand as quickly as possible.

In the amended S-1, Anthropic said it has entered into purchase commitments and lease agreements with an aggregate committed spend of about $895.4 billion, "substantially all of which is related to compute and infrastructure."

Anthropic said its compute and infrastructure expenses increased by $14.4 billion for the nine months ended Sept. 30, up 329% compared with the same period last year.

"As our compute and infrastructure capacity grows, the associated compute and infrastructure expenses have increased," Anthropic said in the filing.

The company's CEO, Dario Amodei, co-founded Anthropic alongside a handful of other researchers who defected from OpenAI, now its chief rival. OpenAI confidentially filed its prospectus with the SEC in June, but its executives have signaled that it's aiming for a 2027 debut.

Anthropic has worked to position itself as more safety-conscious than its competitors, and its S-1 includes more than 90 pages of risk factors. The company highlights risks, including potential political headwinds, its complex infrastructure needs as well as the difficulties that can come from balancing safety and commercial objectives.

"We consider it our personal responsibility to help the world understand these risks, to prevent or mitigate them when they arise from our AI models, and to work with governments and the rest of the industry to address them at a societal level," Anthropic's co-founders said in the filing.

LifeVal is a benchmark designed to evaluate AI performance on practical everyday tasks such as budgeting, finding childcare, and accessing government services.

Apple’s new CEO, John Ternus, is apparently pushing the tech company’s development of household robots—and the first to debut may be a home robot designed to autonomously roam around while supporting FaceTime calls and switching lights on whenever a person enters the room.

People who worked on Apple’s robotic projects told The Information that the AI-driven home robot, code-named J595, could be named HomeView Ultra in line with Apple’s new HomeView stationary smart display. The company is reportedly aiming to launch the robotic product with a possible price tag of $1,000 or more by 2027, although development delays may push that back to 2028.

The earliest prototypes of the home robot first came out in 2018 and received approval from former Apple CEO Tim Cook to continue the project. The Information describes Apple’s engineers as trying to give the robot more capabilities beyond being a “fancy way to make FaceTime calls” in order to justify a high price tag, even as the team has spent years refining the software and incorporating more AI technologies.

However, the robot’s few reported features seem underwhelming so far when compared with existing smart home devices and systems, or even a run-of-the-mill robot vacuum with a clearer use case for households. Is there a market for a smart home device costing more than $1,000 that moves around while hosting FaceTime calls, automatically handling room lights, and occasionally ordering the family cat to get off the dining table?

One of the Information’s sources also described Apple as having a very small team of about 10 “true roboticists,” with many members of the initial engineering team having departed over the years. The software side boasts a significantly larger team of approximately 300 people.

Still, Ternus has been backing this home robot as well as a separate Apple project focused on developing robots for household tasks like folding clothes, according to The Information. The latter would presumably require robotic arms and manipulators, though it’s unclear if that means Apple has ambitions to develop a general-purpose humanoid robot for household use like robotics startups 1X and Figure AI.

From a technical and safety standpoint, Apple’s initial focus on a limited-purpose home robot still makes much more sense right now than any attempt to develop a general-purpose autonomous robot that could pose greater risks when operating near humans. The question is whether Apple can find enough customers willing to pay whatever it charges for a limited-purpose home robot.

SpaceX is reportedly looking at buying Boost Mobile or using its cell network

The potential deal could serve as a shortcut to establishing SpaceX as a mobile carrier.

SpaceX may have found a potential path to circumvent its way into the mobile carrier industry via Boost Mobile. As first reported by The Washington Post, Elon Musk's company has held talks with Boost Mobile's parent company, EchoStar, in recent months that could see SpaceX launch "its own signature wireless service" through the existing network.

According to Washington Post's sources, the deal could look like SpaceX acquiring Boost Mobile outright or gaining access to its cell network, which is leased from AT&T and T-Mobile. There could be a major hitch with the deal though, since SpaceX's potential mobile service would need the green light from those major mobile carriers, according to the report. The Washington Post also reported that major cell companies, which include AT&T, T-Mobile and Verizon, have already turned down Musk down for access to its cell networks in order to launch a separate SpaceX service.

No deal has been confirmed yet, but the talks between SpaceX and EchoStar shouldn't be surprising for anyone paying attention to the company's recent dealings. Last year SpaceX acquired $2.6 billion worth of spectrum licenses from EchoStar, which would be used to improve its Starlink network's 5G connections. More recently, Starlink confirmed its plans to become a "major mobile carrier in the US" and made another major acquisition in the hopes of achieving that goal.

Chinese space officials confirmed this weekend that the Asian nation plans to land its astronauts on the Moon within three years.

At the Seventh Manned Spaceflight Conference in Beijing, officials, including Wang Xiang, chief designer for the lunar exploration program, laid out the country’s most publicly detailed plans yet for a series of missions leading up to a crewed lunar landing “before 2030.”

China’s lunar landings will involve a lunar-orbit rendezvous similar to what NASA did in the 1960s and early 1970s with the Apollo program. However, lacking a rocket as powerful as the Saturn V vehicle, the crew and lunar lander will launch separately to the Moon.

According to slides shared on social media, the current plan involves:

• An uncrewed test of the Long March 10A rocket (a single-stick variant, with no boosters) and the Mengzhou spacecraft to low-Earth orbit. Target: early 2027
• An uncrewed test of the larger Long March 10 rocket (a core stage with two boosters) and the Lanyue lunar lander, including descent/ascent from Moon’s surface. Target: 2028
• A concurrent launch of two Long March 10 rockets, one carrying uncrewed Mengzhou and the other the Lanyue vehicle; they will dock in lunar orbit. Target: 2029
• Dual launch of Long March 10 rockets, this time with crew on the Mengzhou spacecraft, leading to crewed landing mission. Target: “Before 2030”

The public release of this new information provides a timeline for gauging China’s technical progress in its efforts to land humans on the Moon before 2030 and beat NASA and the United States back to the lunar surface.

Notably, the plan (for now, at least) omits a mission similar to Apollo 8 or Artemis II, which involved a crew flying out to the Moon and either entering orbit or passing close by before returning to Earth. The Mengzhou vehicle should still get a workout closer to Earth with humans on board as part of missions carrying astronauts to Tiangong, China’s space station in low-Earth orbit.

China’s program has been largely opaque

NASA has set a target of landing humans on the Moon by 2028, a year or so ahead of China. The United States, which has been working on the Space Launch System rocket for 15 years and the Orion spacecraft even longer, has a more established rocket and crew vehicle.

But there are major questions surrounding the development of a lunar lander, for which both SpaceX and Blue Origin have multibillion-dollar development contracts. Depending on how these projects go, a US lunar landing could be delayed to 2030 or even later.

Although it is virtually impossible for outsiders to glean information about technical milestones achieved inside China’s space program, the country is clearly making credible progress toward reaching the Moon. For example, in August 2025, the China Manned Space Agency successfully tested a high-fidelity mock-up of its 26-ton Lanyue lunar lander. The test used giant tethers to simulate lunar gravity as the vehicle fired its main engines and fine-control thrusters to land on a cratered surface and take off from a location near Beijing.

Recently, the Mengzhou spacecraft for the 2027 test atop a Long March 10A rocket arrived at the Wenchang Space Launch Site in Hainan, China, where the mission will launch.

US government assessments of the Chinese space program are restricted, but lawmakers are clearly taking the threat seriously. In the last 12 months, the US Congress and White House have given broad latitude to NASA Administrator Jared Isaacman to streamline the Artemis Program to land humans on the Moon. He has moved swiftly to cancel the Lunar Gateway space station and planned upgrades to the Space Launch System rocket. And just last week, Isaacman announced plans to help Blue Origin develop a lunar lander by finding a way to boost the Orion spacecraft into low-lunar orbit.

“We have the mandate, we have the resources, and the support from our stakeholders to be able to execute, and that’s what we intend to do,” he said at the time.

For a couple of years, it has been clear that China has made a major commitment to landing astronauts on the Moon, preferably before the United States returns to the lunar surface, to score a major geopolitical win. Beyond this near-term competition, both NASA and China’s space program are building capabilities to establish a long-term presence at the Moon’s South Pole. As part of this second phase of the contest, Isaacman committed NASA to the development of a base on the surface of the Moon over the next decade.

Marvell designs custom AI chips and other technology that connects processors and moves data around data centers, and Lumentum has technology that uses light to move data between chips and servers.

Soon, almost all researchers will engage in AI-assisted replication of their own work before submitting to a journal, which will improve the quality of research going forward.

Full article content is not available for inline reading.

Read the original article →

You can spend an hour moving a headline two pixels left and still feel that something isn’t working. Sometimes the words need attention before anything else does. A beautiful poster still needs to tell people what’s happening, and a product page has to explain why the product is useful.

Good copy for graphic design projects starts with that basic job. Once you know what readers need to understand, you can shape the language to suit the design.

Start With the Point of the Project

Before writing a clever opening, describe the project in ordinary language. Imagine explaining it to someone who hasn’t seen the brief. If that explanation feels muddled, a catchy slogan probably won’t fix it.

Suppose you’re designing a flyer for a pottery workshop. The message might be that beginners can spend a relaxed Saturday making their first bowl. That gives you something useful to build around.

A few notes will help you keep the draft focused:

• who the project needs to reach;
• what those people already know about the offer;
• which benefit matters most to them;
• what might make them hesitate;
• what they should do after reading.

Keep those answers beside you while you write. They’re particularly useful when feedback starts pulling the project in several directions.

Give Readers Something Specific

Words can sound impressive without saying very much. “Exceptional experiences” and “unmatched quality” leave readers to guess what makes an offer worth their attention. Details give them something they can picture and evaluate.

Find a Headline With Something to Say

For that pottery workshop, “Discover Your Creative Potential” could belong to almost any art class. “Make Your First Pottery Bowl This Saturday” tells readers what they’ll do and when they’ll do it.

There’s still room for wit, warmth, or an unexpected phrase. Just check whether the headline makes sense to someone encountering the business for the first time.

Try several versions before settling on one. Put the strongest options into the layout, because a line that works in your notes may feel awkward on the page.

Use the Smaller Text to Fill the Gaps

After the headline, consider what someone would ask next. Do they need experience? Are materials included? Will they take their bowl home that day, or collect it after firing?

Those answers are more useful than another sentence about creativity. They also turn features into benefits. “Clay and tools included” tells a beginner they don’t need to buy equipment before attending.

Give the headline, subheading, and body text different jobs. Each should add something to the message, with the most important information appearing first.

Make the Brand Voice Sound Natural

A useful starting point is to imagine someone from the business explaining the offer face to face. What would they say, and which words would feel strange coming from them?

A local bakery might write “Baked this morning, ready for your lunch break.” An equipment supplier may need a straightforward description of materials and dimensions. Both can sound approachable without using the same tone.

Read a few lines aloud. If you stumble over a phrase, simplify it. Watch for words you’d never use in conversation, unless they’re technical terms your audience expects.

Contractions can help an informal brand sound relaxed, but adding “you’ll” everywhere won’t give a flat draft a personality. Look at what the business actually does differently. Specific observations usually give you more to work with than extra adjectives.

Keep names and terminology consistent. Calling the same workshop a course, session, and program may add variety while making the offer harder to follow.

When a draft sounds stiff, the problem may be more than a few awkward phrases. Reviewing the wording can help explore alternative ways to express the same ideas while keeping the message clear. After making changes, read the copy again to check that it fits the brand’s voice and speaks to the intended audience. The final version should feel natural without losing the details that make the offer specific.

Write for the Space You Actually Have

A paragraph can look perfectly reasonable in a document and become a wall of text inside a narrow brochure panel. Get the words into the design early enough to notice.

Ask the designer about the space available, the viewing distance, and the formats the project needs. A shop window poster and a mobile landing page require different decisions, even when they promote the same offer.

When text doesn’t fit, look for anything the reader doesn’t need. “In order to reserve your place” can usually become “To book your place.” Keep important conditions and useful details, even if they require a layout adjustment.

Shrinking the font may make everything fit, but check whether people can still read it comfortably. Review printed pieces at their actual size and digital layouts on a phone.

Pay attention to the image, too. If a photograph shows the finished bowl, the caption could explain the class length or what beginners will learn. There’s no need to describe everything people can already see.

Tell People What Happens Next

By the time someone reaches the call to action, they shouldn’t have to work out what you’re asking them to do. Match the wording to the next step.

“See Workshop Dates” suits a page where visitors compare sessions. “Book Your Saturday Class” works when they’re ready to choose that particular session. The right wording depends on where the reader is in the process.

Descriptive link text also helps people understand the destination before opening it. A vague label gives them less information to make that choice.

Check the promise behind the wording. If a button says “Get a Quote,” the next page should make requesting one straightforward. On a poster, tell people what the QR code opens.

Leave Room for SEO Without Forcing It

Website copy needs to describe the business in terms potential customers recognize. Someone looking for a pottery class might search for beginner workshops, evening sessions, or classes in their town.

Use relevant phrases where they belong in the page title, headings, and body copy. Explain the offer thoroughly enough that related terms appear naturally. You don’t need to squeeze every possible variation into the opening paragraph.

Search guidance recommends useful content and warns against excessive keyword repetition. A fixed keyword density shouldn’t decide whether a sentence belongs on the page.

Read the draft again without thinking about rankings. If a phrase sounds awkward or interrupts the explanation, rewrite it. The page still needs to work for the person who arrives there.

Read It Again Once the Design Is Finished

The final layout deserves a fresh read, even when everyone has already approved the wording. Line breaks can change the emphasis, and a last-minute image swap may leave a caption making little sense.

Before sending the project out, work through these checks:

1. Read the headline without the supporting text and check what it promises.
2. Confirm the details people need before making a decision.
3. Check names, prices, dates, spelling, and contact information.
4. Open every link and test each QR code.
5. Ask someone unfamiliar with the project to explain the offer.

Listen to where that person hesitates. Their questions may reveal a missing detail that everyone working on the project has stopped noticing.

Save the approved wording somewhere the whole team can find it, including changes made during layout. Then check the exported version against that copy.

Open the exported design once more and look at it as a reader would. Notice what catches your eye first and where you would go next. If either answer is unclear, that’s the line or layout decision to revisit.

OpenAI plans to merge the Chat and Work tabs within the ChatGPT experience after an initial testing period with select users. Codex will remain a separate experience in the ChatGPT desktop app. The change will enable users to move from exploring ideas to having the chatbot complete work within the same space. Users can import files and plugins. Both ChatGPT and Codex will soon draw from the same allowance pool.

Elon Musk confirmed that Grok Bot usage limits were reduced after operating costs became unsustainably high relative to revenue.

Amstel has redesigned its packaging and logo around its 1870 Amsterdam origins, adding bespoke typography inspired by historic canal bridge signage and a refined golden circle. The red, white, black, and gold system also features a wave pattern, a horizontal split evoking the Amstel River, and three coins representing the founders, city, and waterway. Already a Red Dot winner, the identity is rolling out across 11 markets, with all remaining territories due to transition by the end of 2027.

Download dimensional drawings and technical specifications to help you design for Apple devices.

AI makes generating images and concepts easy, so the harder work is deciding what is worth making, whose perspective is missing, and whether it communicates. At DesignThinkers, RGD's annual conference in Toronto, speakers covered information design, blending strategy with creativity, and designing a city. AI-accelerated trends risk polished sameness, so "raw, messy curiosity is the most valuable thing we can bring to the table."

Studio Kiln's identity for Reset reflects the weight-loss app's personalized approach to eating, building flexibility and responsiveness directly into its visual system. A dynamic identity uses typography, color, imagery, and graphic elements that can shift across different contexts while maintaining a recognizable core. The result gives Reset a distinctive presence without locking a product built around personalized meal guidance into a rigid visual language.

François Bourdin, a French freelance concept artist, character designer, and illustrator in Nantes, creates dynamic characters from razor-sharp angular linework and vivid, saturated neon palettes.