Full article content is not available for inline reading.

Read the original article →

How the Claude Code team does code review

How do you review code at the volume agents produce it? On the Claude Code team, once we had high coverage and deep reviews, we started optimizing for the minimum amount of human review time that doesn't raise reverts or incidents.

We've said before that Claude writes about 90 percent of Claude Code's own code. So how do we review code at the volume we produce it? Does anyone read code anymore? And if something breaks, who catches it?

This post covers the code review flow on the Claude Code team and how it has evolved. From June to September, merged pull requests to Claude Code's codebase more than doubled while the share that had to be reverted fell by more than 40 percent.

We didn't remove review. But we did move most of the reading to machines, optimized for human time and attention, and invested heavily in making it fast and easy to undo mistakes.

RETHINKING THE PURPOSE OF CODE REVIEW

When agents write code, the number of changes goes up, fast. In Anthropic's monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September this year.

Claude Code lives in its own repository, separate from the monorepo, but it's seeing a lot of pressure too. When you are shipping this fast, manual, line-by-line code review is incredibly difficult if not impossible.

Code review does two jobs:

1. Find and fix issues before they ship
2. Build shared context and codebase understanding across the team

This article mainly focuses on finding and fixing issues, but we will come back to the second job near the end.

We think "did a human read the code?" is an imprecise proxy for "what could go wrong with this change, and which check—automated or human—is the right one to catch it?"

Asking that question also changed when review happens. Before, review was a gate at the end of the road: write the code, open a PR, wait for your colleague.

Now, review runs continuously, more like spellcheck while you write. Most changes have been reviewed and fixed by Claude at least once before a human is asked to look. This catches most routine mistakes, and saves team attention for higher-level questions and scrutiny.

THE SCARCE RESOURCE: HUMAN TIME AND ATTENTION

We want to preserve human time and attention for issues only humans can solve and make sure automated checks catch the rest. At our current rate of change, there is still an incredible amount of work for humans to do, and our team encounters new and novel challenges almost daily.

Human time covers both sides of review's cost: the time people spend reviewing, and the time they spend fixing what bad code breaks. Cutting the first doesn't help if the time just shows up in the second.

So the goal is that most pull requests in the Claude Code repos (the CLI, the desktop and web apps, and the mobile apps) merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. To measure human time, we track human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail: if they rise, we haven't saved human time, we've only moved it.

THE LIFE OF A CHANGE

A typical change, from an engineer's laptop (or a Claude session in Slack), goes through multiple layers of code review.

LAYER BY LAYER

1. The work is verified before anyone else looks

Most review now happens before a PR exists. We give Claude something it can run—like tests, a build or a screenshot to compare against the design—and ask it to show the output instead of saying it's done. Then a subagent reviews the diff with fresh context. Both habits come from our best-practices guide.

Before opening a PR, many of us also run a few internal skills: one hunts for bugs, one simplifies the diff, and one checks the behavior end to end. UI changes also get checked against our design guidelines.

Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for getting good results. He estimates it makes the final result two to three times better, and writes, "Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator."

When the automated reviewer keeps flagging the same thing, we fix it at the source: in the skill, with a lint rule, or with updates to instructional files such as:

• CLAUDE.md tells Claude what the project is: the stack, the conventions, the goals and the non-goals. Every review loads it, so in a large codebase we keep it short and point to other docs from there. The reviewer also flags code that breaks a convention in it, and changes that make a line in it out of date.
• REVIEW.md, written by code owners, tells the reviewer what matters in their part of the code. We check separately whether the reviewer actually follows it. The good ones are short. They say what failure looks like in that repo (for docs it's "it lies," for config it's "it misroutes"), cap the nits, list paths to skip, and ask for a file and line as evidence instead of a guess from a name. They also ask for a summary that starts with a count and says plainly when there's nothing to fix.

2. AI review on every pull request

Every pull request gets a Claude review before a person looks. It reads the diff against the whole repo and the PR's stated intent, and asks: does the change solve its problem, fit the system, or break something else?

On a bug fix, it looks for the root cause. The public version, Code Review for Claude Code, is now generally available on Team and Enterprise plans, and /code-review runs a lighter version locally.

When we launched the research preview, the share of internal PRs getting substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings, and most small ones come back clean. Admins set each repo to Quick, Standard, or Deep. Deep is worth it where one missed bug costs more than the extra review time.

Findings get verified by other agents before humans review them. Several agents look for bugs at the same time. Then a separate group votes on each finding, and it only gets posted if enough of them agree it's real. Findings that are only about style, diagnostics, or cleanup get dropped. We A/B tested those filters on our own PRs before keeping them. What's left shows up as inline comments sorted by severity. Each is tagged Important, Nit, or Pre-existing, so a bug the PR didn't introduce doesn't look like the author's fault.

Every finding has to be answered. You either fix it or resolve the thread with a reason. Often an agent picks up the fix overnight, so the author comes back to a PR that's already been through another round.

3. Security review that can block

Security gets its own automated review too. A PR can't merge while any finding from the bug review or the security review is still open. You either fix it or close the thread with a short reason, which is how you clear a false positive.

If a later commit fixes the issue, the finding clears on its own. You can set up the same thing with the open-source security review GitHub Action or the /security-review command.

4. Automated checks that block

The usual: lint, type checks, tests on every platform, and a build. A typical CLI pull request may run dozens of checks before anyone looks at it. The PR template asks how the change was tested and how to undo it. Claude can fill that in, but the person who asked for the change signs off on it.

5. Human approval, scaled by risk

The change sets the tier, not the author. A classifier reads the change and picks its risk tier. A second classifier asks whether this particular change needs another person even when its tier says it doesn't. Some paths always need a person, anything owners have listed as sensitive and any CI workflow file.

Only trusted authors get the lighter paths. Only authors on the repo's trusted list get the lighter paths, mostly the team that owns it. Everyone else needs a second person to approve. An agent's approval never counts as a person's, either. Automated review can clear a low-risk change, but it can't fill a slot that calls for a human.

Whoever prompted the change is on the hook for it. On an agent-written PR, the person directing the agent counts as one of the required reviewers, the same as if they'd typed the code themselves.

An approval covers one specific commit. If new commits land that the system can't vouch for, like an agent's push or a merge someone resolved by hand, the approval has to be given again.

6. Merge queue, flags and a gradual release

The merge queue re-runs every check against main with the change applied, so two PRs that pass separately can't combine into a broken main. New behavior usually ships behind a flag to Anthropic employees first, and our heavy use often surfaces regressions before users do. Public releases go to the latest channel first. The stable channel trails it.

7. Fast detection, fast rollback

Some mistakes will still get through, so the last layer is about catching them fast. Flags turn off without a deploy. Claude Code has a weekly on-call rotation, and incident reviews ask which layer should have caught the issue.

Noticing a bad merge still depends on the author and on-call as well as the revert and incident dashboards. We don't yet have circuit breakers that tighten approval when those numbers move; engineers here want them before more code moves to zero-human merges.

HOW WE MAKE THE REVIEWER BETTER

Our code review process is constantly improving in a loop.

Any incidents are now an eval. The team collected past PRs that caused incidents, with their fix-forwards and reverts, and had engineers who know that code confirm each bug and where it lived. The reviewer runs against that set daily.

We measure noise by watching what people do with the comments. It's easy to catch more bugs if you don't mind flagging a lot of non-bugs, so we need a check on that. We sort every comment the reviewer leaves by how the person on the PR responded: they fixed it, said it was wrong, said the behavior was intentional, or decided it didn't matter. We also run the reviewer on PRs we know are clean and count how often it reports something that would have led someone to make a harmful change.

Noise costs more when the author is an agent. A person can wave off a nit in seconds. An agent fixes it, which means another commit and another round of review.

Review has to converge. An agent author and an agent reviewer can keep each other busy indefinitely. One CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it.

When we ran git blame on what the reviewer kept flagging, about 59% of it was code that had been there since the reviewer's first pass. The reviewer was rarely finding new bugs, it was finding a few more old ones each round.

We made it worse ourselves. We'd gotten used to running several rounds by default, since each pass catches something new. This can be worthwhile on a risky change, but not on every PR. The team now tracks rounds-to-pass alongside recall, and changed re-review:

• A round cap. After three rounds, the reviewer asks the author to step back and reconsider the approach.
• Diff-only re-review after the first few passes.
• Flag the class of bug, so the author fixes every instance, not one line.
• No repeats of findings already posted.

Review agents also run nightly over existing code, helping us catch old bugs before they show up somewhere else.

WHERE HUMANS STAY IN THE LOOP

Pulling a senior engineer out of deep work to catch a routine mistake costs far more than an automated review. People on the team are still responsible for:

• Deciding whether to build it. Direction, taste and scope.
• Reviewing risky code such as billing, the auto-updater and CI workflows.
• Reviewing architecture that sets a pattern others will copy.
• Reading the evidence. Test output, the command that ran and what it returned, a screenshot, the reviewer's findings. If you can't say what the checks would miss, ask for a real review rather than a quick approval.
• Owning the outcome. A person is accountable for every change that ships, whoever typed it.

SHARING CONTEXT ACROSS THE TEAM

Code review's second job has always been to spread codebase understanding. Reading a teammate's diff is how you learn what changed and how the pieces fit. If machines do most of the reading, how does anyone learn the code?

We don't have a formal process for this. Nobody on the team keeps a complete mental model of Claude Code in their head, and we don't think anyone needs to. When someone wants to understand a part of the codebase, they ask Claude to write an explainer for exactly that slice. It takes minutes and reflects the code as it is today.

"YOU LAND IT, YOU OWN IT"

If you land a small or medium change and something still goes wrong, it's a team norm that you usually fix it. A few things keep this from going badly:

• Changes are small, so they're easy to review, debug and revert.
• Everything is reversible. Flags, reverts and staged releases undo most mistakes in minutes.
• Blast radius sets the bar. Expensive code gets more people and more checks.
• Regressions surface fast through telemetry and internal use.
• It isn't blame. Owning a fix means you have the most context; incident reviews look at the system.

WHEN WE CHANGE DIRECTION

Agents make it cheap to start things, so some work shouldn't land. Usually someone in the channel asks why, points at an earlier decision, or suggests a simpler route, and the author closes or reshapes the PR.

HOW YOU CAN ADOPT THIS PROCESS

Most of the pieces to do this with your team exist today.

Before the pull request

• Give your agent checks it can run, listed in a short CLAUDE.md, plus hooks that run formatters and linters.
• Run /code-review and /security-review locally, or a fresh-context subagent review.
• Add a REVIEW.md, and move repeated review comments into it.

On every pull request

• Require CI, and add "Testing", "Risk" and "How to revert" to your PR template.
• Add an AI reviewer on one repo, tune REVIEW.md for a few weeks, then widen.
• Add automated security review, and require every review thread resolved before merge.
• Match review effort to risk.
• Cap review rounds; after the first few, re-review only the new diff.

Approval

• Write down risk tiers, set from the change rather than the author; start strict and loosen with evidence.
• Keep the lighter approval paths for authors you trust.
• Use CODEOWNERS and branch protection so auth, billing, CI and release workflows, and installers always need a person.
• Never let a bot's approval replace a required human's; dismiss approvals on new commits.

Merge and after

• Use a merge queue, feature flags, internal use first, staged releases and one-step rollback.
• Turn incidents and reverts into an eval set, and rescore the reviewer whenever its prompts, tools or model change.
• Measure human time, with revert and incident rates as the guardrail.

WHERE THIS IS GOING

When a review misses something, we ask what the model didn't have in front of it and put the fix into a CLAUDE.md, a skill or a new check. The goal hasn't changed: less human time per change, and no more reverts than before.

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 →

Introducing Timestral

Timestral, Mistral’s first family of time-series foundation models, delivers state-of-the-art probabilistic, multivariate forecasts with just 209M parameters, outperforming larger models on key benchmarks while supporting past and future covariates. Available in four sizes (5M to 209M parameters), it balances accuracy and efficiency, running efficiently on CPUs and excelling in zero-shot forecasting for diverse domains. The model combines synthetic pre-training, covariate-aware attention, and long-context learning, with fine-tuning options for domain adaptation via Mistral Forge.

Today, we’re releasing Timestral, our first family of time-series foundation models. Our largest model, at just 209M parameters, ranks first on all three of the field's main public benchmarks, GIFT-Eval, TIME, and fev-bench, outperforming the previous state of the art with only two-thirds of the model parameters.

Timestral delivers probabilistic, multivariate forecasts and supports past-only and known-future covariates. Our family of models sits on the Pareto front of forecasting accuracy versus model size, delivering leading performance at each size. Results have been submitted to the GIFT-Eval and TIME leaderboards.

Time Series Foundation Models (TSFM)

Time series is one of the most common data types in enterprise, from sensor telemetry to observability metrics. Forecasts built on it drive decisions in capacity planning, energy, supply chains, risk and maintenance.

Industrial plants forecast process sensors against the production schedule, catch equipment drift before it fails, and plan capacity and spare parts across thousands of assets. Finance teams forecast flows, volumes, and volatility to inform positions, hedging, and treasury across thousands of accounts.

Classical models such as ARIMA and linear regression remain well-established tools for forecasting time series. These models are usually fitted to a single series and learn only from that series' history.

Deep learning models such as PatchTST add the capacity to learn nonlinear patterns across many related series, but they are still typically trained from scratch on each dataset, so what they learn doesn't carry over to new domains.

Time series foundation models bring the pre-training approach to time series. Trained on a large and diverse corpus, our model learns patterns that transfer across series, forecasting zero-shot on data it has never seen, even in domains where data is scarce.

Benchmark Results

We evaluated Timestral on the three main public forecasting benchmarks: GIFT-Eval, TIME and fev-bench. Among pre-trained, zero-shot models, it ranks first across all five metrics. These results come from a single checkpoint, without ensembling.

• GIFT-Eval - GMean MASE
• GIFT-Eval - GMean WQL

GIFT-Eval, top ten of 83 comparable pretrained and zero-shot entries. Lower is better.

• TIME - GMean MASE
• TIME - GMean CRPS

TIME, top ten of the 35 leaderboard entries. Lower is better on both metrics.

fev-bench, top ten of the 37 leaderboard entries, by SQL skill score. Higher is better.

Family of models optimised for every specification

Timestral has been optimised as a family of four models: 5M, 28M, 123M and 209M parameters. The larger models improve forecast performance, while the smaller ones are faster and cheaper. All four share the same architecture and training recipe. Every size sits on the Pareto front of accuracy versus model size: for each model size, no public model forecasts better.

Score vs model size on GIFT-Eval, TIME and fev-bench (shown as 1 − skill score). Lower is better. Our 28M model beats Chronos-2, about four times larger, on GIFT-Eval and TIME. Our 209M model beats TimesFM-3 and Falcon-2.0 with fewer parameters.

Timestral does not need a GPU at inference. On a standard server CPU with 8 threads, forecasting one day ahead from three weeks of 15-minute history takes 10 ms with the 5M model and 140 ms with the 209M model. Smaller models trade some accuracy for speed: the 28M model is five times faster than the 209M model, and the 123M model comes within 0.2% of the 209M score at three quarters of its latency.

An industrial example

Consider an industrial plant with thousands of sensors across its equipment. Timestral can improve the forecasts on that data in several ways.

Multivariate forecasting. A pump's vibration, temperature and pressure don't move independently. A rise in one often explains or causes a change in another. Timestral models related series jointly, so it can use those dependencies instead of forecasting each sensor in isolation.

Probabilistic forecasting. A single predicted value may not show the full picture. Timestral predicts a full set of quantiles, so teams can see how wide the uncertainty is, set alert thresholds that reflect it, and plan maintenance around risk rather than a single number.

Categorical covariates. Some covariates take values from a set of categories rather than continuous numbers, such as the day of the week, or a machine's state (running, idle, under maintenance). Encoding these as numbers would impose an order or scale they don't have. Timestral takes them as categorical inputs directly to improve forecasts.

Known-future covariates. Some drivers of sensor behaviour are known in advance, such as production schedules, planned shutdowns, weather forecasts. Timestral can condition on them to improve forecast quality, so a scheduled load increase is expected rather than flagged as a surprise.

From Model to System

Timestral is a numerical model that can run inside existing monitoring pipelines, or be paired with our language models in multi-modal agentic workflows.

In the plant, that could look like this:

1. Timestral running continuously on the plant's sensor streams, detecting anomalies as they occur.
2. When it flags an anomaly on a pump, an agent embeds the signals and compares against embeddings of past sensor data to find similar historical failures.
3. The agent then starts sub-agents to run a root cause analysis, drawing on context from that plant, such as maintenance records, shift logs and operator notes, equipment manuals, past work orders, and readings from related equipment.
4. The agent drafts a suggested diagnosis based on the findings, with supporting evidence and possible next steps.

The plant manager gets a diagnosis and a plan backed by the sensor data, rather than just an alert.

Key technical contributions

Several ideas have been combined to produce these results. Each will be described in detail in the technical report.

1. Decoupled Horizon Forecasting. Causal decoders trained with contiguous patch masking, as in Toto 2.0 and TimesFM-3, mask out the values to be forecast, so they look like missing values and are also lost as context for later forecasts. Our approach, DHF, separates the two: the full history stays in the sequence, and learned forecast tokens read the history before them. Every observed value thus serves as both target and context, true gaps stay flagged as missing, and training horizon lengths and missing-data augmentation can be tuned independently of each other.
2. Covariate-aware attention. Each input series is assigned a role: target variate, past-only covariate or known-future covariate. Known-future covariates are visible across the whole window while targets stay causal, and information flows only from covariates to targets. Timestral can therefore use a holiday calendar or a weather forecast without leaking a target's own future into its forecast.
3. Synthetic-first data. The majority of the training data was synthetic. We first generated univariate processes with coherent temporal dynamics, including trends, seasonality and diverse noise patterns. We then used a multivariate synthesizer to construct multivariate series by introducing nonlinear dependencies between these processes.
4. Two-stage training. Timestral is first pre-trained at scale on purely synthetic data with context size 8192, then post-trained on a mix of real and synthetic data with a 4x longer context. The objective is a pinball loss over 21 quantiles, a discrete approximation of CRPS.

A model that can be adapted

Public benchmarks measure general performance, but production data can be significantly different in behavior and structure. It may also shift over time as markets change regime, equipment degrades and demand patterns move. The lasting value lies in being able to adapt a model to in-domain data and keep retraining it as the distribution moves.

For organisations that want to go further, Timestral is available through Mistral Forge, the same training pipeline we use for our language models. It supports:

• Zero-shot inference out of the box.
• Architectural extensions, such as domain-specific covariates.
• Fine-tuning on proprietary data, specialising to a domain while preserving general performance.
• Control over the training data, including adjusting the training mix, replaying pre-training data, and generating synthetic data samples to reflect the target domain. Full control over the data ensures that nothing we backtest was seen during pre-training.

The full pipeline can be deployed on our clients’ hardware, including air-gapped environments.

What’s next

We have published a GitHub repository so you can run Timestral on your own data. A technical report with the full results will follow. For more specialised forecasting problems, or to collaborate on research, please reach out to us.

Neon now has realtime

Neon Realtime is live in public beta. Any SQL query can now be a live query. Subscribe to it and the result stays up to date as your data changes. That makes your whole app reactive, with no polling or refetch logic.

It all runs directly from Lakebase Postgres, so there's no second realtime system to bolt on and it works natively with scale to zero and branching. And it comes out-of-the-box with type-safe, end-to-end reactivity, SSR support and instant local writes for the best possible reactive AX and DX.

It's free during the beta, there's no waitlist, you can use it right now and your coding agent can set it up in one command. Try to break it and tell us what you find on Discord so we can get it to GA fast.

Realtime has always had a reputation for demoing well but falling over in production. Especially with the "holy grail" of realtime: live SQL. The idea is so simple. No limitations, just subscribe to any SQL query. But making it real has always been too complex and too hard to scale.

Well, not any more. Our team has spent decades working on this. Building the Electric sync engine and before that in academic research. But before joining Neon we had never been working with a database with Neon's unique storage architecture. Now, working inside Neon, we've been able to build fully expressive live SQL queries with no limitations that can scale to the largest enterprise workload.

It's everything we learned building Electric, reimagined and rebuilt to Lakebase engineering standards. The result is realtime that just works. Full reactivity on standard Postgres. With a batteries-included stack for building reactive apps and agents. That works with your existing schema, queries, api, auth and frontend code.

Realtime as the default for coding agents

Realtime should be a primitive that agents reach for by default and get right the first time. When a developer asks an agent to build an app, a lot of what the agent builds would be better live:

• The chat panel should show new messages as they arrive
• The notification badge should update its count
• A shared board should show a teammate's edits
• A task list should show an agent's progress as it works

Ideally the agent wires all of this up as realtime from the start, the same way it adds auth or a database table without being asked. In practice it rarely does. Ask a coding agent to build a CRUD app and it usually gets it right. Ask it to build realtime sync and the failure rate goes way up.

A big part of the reason is that realtime usually lives outside the backend. It runs as a separate service that has to mirror what's in the database, and that's where things break:

• It has to stay in sync with the database. Every change has to reach every connected client, in order, and survive dropped connections and reconnects. That's hard to get right, and when it slips, screens quietly show stale data.
• It doesn't share the backend's context. It has its own permissions model, its own connections, and no idea which branch it's pointed at. A preview branch can end up wired to production's realtime.
• It's one more system to operate. The agent has to set it up, configure it, and keep it consistent with everything else, which is exactly where agent-written code tends to go wrong.

Neon Realtime moves realtime inside Postgres. Live queries run in your database, not in a separate service bolted on next to it, so there's no mirror to keep in sync and no second system to drift. It also sits alongside the other Neon backend primitives: Managed Better Auth, Object Storage, Functions, and AI Gateway. It speaks the language agents already use: SQL, the ORM already in the codebase, and the auth the app already has.

And it follows the same principles as the rest of Neon: it's enabled per branch, and it scales to zero.

Neon Realtime: live queries for Neon apps

Neon Realtime adds live queries to Lakebase Postgres. Here's what you get:

• Any SQL query can be live. Enable Realtime on a branch and any deterministic query against that database can be live, joins and aggregates included. Subscribe from the terminal with neon realtime subscribe, from your code with the SDK's subscribe(), or from a React component with useLiveQuery.
• Reactive building blocks for your UI. Bind a React component to a live query with useLiveQuery, and it re-renders on its own whenever the result changes. Writes show on screen immediately and are confirmed when the database commits them. SSR and TanStack DB are supported.
• All inside Postgres. There's no second realtime system and no separate database to run. Your schema, queries, ORM, and client state library stay the same.
• A TypeScript SDK for your backend and frontend. Define queries on your backend with raw SQL, Drizzle, or Kysely, and subscribe to them from a browser, a server, or an agent. It works with Next.js, TanStack Start and TanStack DB, and Mastra.
• Built for coding agents. Your agent can enable Realtime in one command, test a live query from the terminal, and use the Realtime skill (neon skills -s neon-realtime) or the Neon MCP server to build the app. The Neon API and Console work too.

The fastest way to see it is from the terminal. Enable Realtime on a linked branch with neon realtime enable, or declare it while setting up an app with neon bootstrap my-app --template realtime-react or neon init --services realtime, then run neon deploy from that app's directory. Once Realtime is enabled, subscribe to a query.

With a schema like this:

neon psql -- -c "CREATE TABLE items (id UUID PRIMARY KEY DEFAULT gen_random_uuid(), value TEXT)"
neon psql -- -c "INSERT INTO items (value) VALUES ('foo')"

You can subscribe to it like this:

neon realtime subscribe "SELECT * FROM items"

You'll see the current rows. Insert a row from another terminal and the result updates in place:

neon psql -- -c "INSERT INTO items (value) VALUES ('bar')"

Add --changes to see the raw delta stream underneath.

Any query can be a live query

Most realtime systems tell you that a row changed in a table. Then your app has to work out what that means for the screen: what do you need to display, what do you need to refetch? With Neon Realtime, you subscribe to the exact query your screen shows, and that result is what stays live.

For example, say your app needs to show the channel name and unread message count for all of the channels you're a member of. You can just express that in SQL and subscribe to the results:

SELECT c.id, c.name, count(m.id) AS unread
  FROM memberships mb
  JOIN channels c
    ON c.id = mb.channel_id
  LEFT JOIN messages m
    ON m.channel_id = c.id
   AND m.created_at > mb.last_read_at
  WHERE mb.user_id = $1
  GROUP BY c.id, c.name
  ORDER BY c.name

This works for any read-only, deterministic SQL query. You can use joins, aggregates, group by, distinct, window functions, subqueries, built-in and user-defined functions, extensions, etc.

Reactive UIs, with instant writes

In a reactive UI, what's on screen follows the data: when the result of a query changes, the component re-renders on its own. You don't write refresh buttons, polling intervals, or refetch-after-save logic.

In React, that's useLiveQuery:

// frontend/Sidebar.tsx
import { useLiveQuery } from "@neon/realtime-react"

export function Sidebar({ sealedQuery }) {
  const { data } = useLiveQuery(sealedQuery)

  return (
    <ul>
      {data.map((channel) => (
        <li key={channel.id}>{channel.name} ({channel.unread})</li>
      ))}
    </ul>
  )
}

You can have instant local writes too. Apply the change on screen with React's useOptimistic, send it to your API, and wait for the matching Postgres transaction to come back on the live stream with awaitTxId. Until then, the screen shows the optimistic state. Once the transaction arrives, it shows the confirmed state.

If you use TanStack DB, sync the live query into a collection and TanStack DB manages the optimistic state for you. SSR works as well: the page arrives with data from the server, and live updates take over from there.

All inside Postgres

Realtime runs in your database, not in a separate service bolted on next to it. That means you get realtime, reactive apps and agents:

• Without a second or bespoke realtime system
• Without changing your schema, queries, ORM, or client state library
• Without bending your app around the limits of a sync engine

A TypeScript SDK for your backend and frontend

The SDK splits the work between your backend and whatever is subscribing. You define queries on the backend, where your auth already runs, using raw SQL or your ORM. Drizzle and Kysely adapters ship today. Then you seal them:

// backend/queries.ts
import { createRealtime, rawSql } from "@neon/realtime/server"
import { drizzleAdapter } from "@neon/realtime-drizzle"

const realtime = createRealtime({
  adapter: drizzleAdapter(),
  db: "app",
  secret: process.env.NEON_REALTIME_SECRET!,
})

export async function sealUnreadCounts(userId: string) {
  const query = rawSql<UnreadCount>(UNREAD_COUNTS_SQL, [userId])

  return realtime.seal(query)
}

A sealed query can't be forged or modified, so it's safe to hand to a browser or an agent. Expose it from an endpoint, where parameters like the user ID come from the request rather than from the client:

// backend/server.ts
app.post("/api/v1/unread", async (c) => {
  const user = await requireUser(c)

  return c.json(await sealUnreadCounts(user.id))
})

Anything that receives the sealed query can subscribe to it, whether that's a browser tab, another server, or an agent:

const subscription = client.subscribe(sealedQuery)
subscription.onChange(console.log)

The SDK fits into the frameworks you already use:

• Next.js: a realtime, reactive app with SSR support
• TanStack Start and TanStack DB: live queries synced into TanStack DB collections, with optimistic mutations
• Mastra: agent workflows that react to changes in Postgres directly

Built for coding agents

Agents are a first-class interface of the Neon backend, and Realtime is no exception. Your agent can set all of this up.

To enable Realtime on an existing project:

neon realtime enable

Or set up the current directory and declare Realtime in neon.ts, then apply that config:

neon init --services realtime
neon deploy

Or to bootstrap a Neon project with a realtime template:

neon bootstrap my-app --template realtime-react
cd my-app
neon deploy

Then give your agent context by installing the Realtime skill:

neon skills -s neon-realtime

Or connect the Neon MCP server.

Built as a Neon primitive

Realtime is built into Neon as a backend primitive, so it keeps the properties agents and developers rely on:

• It scales to zero. Clients connect to Neon's ingress layer, not to Postgres, so open subscriptions don't keep your database awake.
• It branches. Realtime is enabled per branch, and child branches inherit it. A preview branch or an agent's branch gets live queries against its own data.
• It's cost-efficient. When a write commits, only the live queries it affects are updated. You stop paying to re-run queries on reads and polls, and pay a small incremental cost on writes instead.
• It leaves your primary alone. The incremental work runs on a replica, so your primary's write latency, write throughput, and compute aren't affected. Live queries don't use database connections either.

Realtime you don't have to work around. Try it

We want Neon Realtime to be one more primitive you and your agent reach for when building an app. It lives in your Neon backend, works with the rest of it, and gets it right the first time.

Help us take it to GA. Enable Realtime, build something, push it hard, and tell us what breaks and what's missing on Discord.

Beta is gonna beta

We're shipping this early on purpose: the core works and we want you building on it, but we're still building it. Here's what to expect:

• Performance will keep improving: we have a long list of optimizations to work through, which is why we're not publishing benchmarks yet.
• Expect papercuts: the protocol underneath is still changing, so use the SDK rather than the raw API.
• The console experience is minimal for now.
• No row-level security yet.
• Available in us-east-1, us-east-2, eu-central-1, and ap-southeast-1, more regions to come.

The good part: Realtime is free during the beta. Just remember that database compute (starting a live query can wake your database) and egress will be billed as usual.

TabPFN

Quick Start

Interactive Notebook Tutorial

Dive right in with our interactive Colab notebook! It's the best way to get a hands-on feel for TabPFN, walking you through installation, classification, and regression examples.

Installation

pip install tabpfn

TabPFN supports Python 3.10+.

⚡ GPU Recommended: For optimal performance, use a GPU (even older ones with ~8GB VRAM work well; 16GB needed for some large datasets). On CPU, only moderate datasets are feasible (TabPFN-3, TabPFN-3.5 and TabPFN-3.5-Fast allow up to 5000 samples; older versions up to 1000). No GPU? Use our free hosted inference via TabPFN Client.

On macOS: GPU support is automatically included for Apple Silicon Macs. For best performance, ensure you are using PyTorch 2.13 or newer.

On Linux: Nvidia GPU support is automatically included. For AMD GPUs, first install PyTorch with ROCm, then install TabPFN. For example,

pip install torch --index-url https://download.pytorch.org/whl/rocm7.2
pip install tabpfn

For a CPU-only install, first install CPU-only PyTorch, then install TabPFN. This saves disk space if you do not have a GPU.

On Windows: For Nvidia GPUs, install PyTorch with CUDA, then install TabPFN. For AMD GPUs, install PyTorch with ROCm, then install TabPFN.

Basic Usage

To use our default TabPFN-3.5 model:

from tabpfn import TabPFNClassifier, TabPFNRegressor

clf = TabPFNClassifier()
clf.fit(X_train, y_train)  # downloads checkpoint on first use
predictions = clf.predict(X_test)

reg = TabPFNRegressor()
reg.fit(X_train, y_train)  # downloads checkpoint on first use
predictions = reg.predict(X_test)

To use the smaller, faster TabPFN-3.5-Fast you can use ModelVersion.V3_5_FAST or "v3.5-fast".

from tabpfn.constants import ModelVersion

classifier = TabPFNClassifier.create_default_for_version(ModelVersion.V3_5_FAST)
regressor = TabPFNRegressor.create_default_for_version(ModelVersion.V3_5_FAST)

To use other model versions (e.g. the previous default, TabPFN-3):

classifier = TabPFNClassifier.create_default_for_version(ModelVersion.V3)
regressor = TabPFNRegressor.create_default_for_version(ModelVersion.V3)

TabPFN Ecosystem

Choose the right TabPFN implementation for your needs:

• TabPFN Client: Simple API client for using TabPFN via cloud-based inference.
• TabPFN Extensions: Community extensions and integrations, including:
  • interpretability: Gain insights with SHAP-based explanations, feature importance, and selection tools.
  • unsupervised: Tools for outlier detection and synthetic tabular data generation.
  • embeddings: Extract and use TabPFN's internal learned embeddings for downstream tasks or analysis.
  • many_class: Handle multi-class classification problems that exceed TabPFN's built-in class limit.

  To install:

  pip install tabpfn-extensions

• TabPFN (this repo): Core implementation for fast and local inference with PyTorch and CUDA support.
• TabPFN UX: No-code graphical interface to explore TabPFN capabilities—ideal for business users and prototyping.

License

The code in this repository is licensed under the Apache License 2.0. Third-party code is subject to its own licenses and attribution requirements.

Model weights are licensed separately.

The TabPFN-2.5, TabPFN-2.6, TabPFN-3 and TabPFN-3.5 model weights are released under non-commercial licenses. TabPFN-3.5 is used by default.

The TabPFN-2 model weights are licensed under the Prior Labs License (Apache 2.0 with an additional attribution requirement). To use the v2 model weights, instantiate your model as follows:

from tabpfn import TabPFNRegressor
from tabpfn.constants import ModelVersion

tabpfn_v2 = TabPFNRegressor.create_default_for_version(ModelVersion.V2)

Enterprise & Production

For high-throughput or massive-scale production environments, we offer an Enterprise Edition with the following capabilities:

• Fast Inference Mode: A proprietary distillation engine that converts TabPFN into a compact MLP or tree ensemble, delivering orders-of-magnitude lower latency for real-time applications.
• Commercial Support: Includes a Commercial Enterprise License for production use-cases, dedicated integration support, and access to private high-speed inference engines.

Join Our Community

1. Connect & Learn:
   • Join our Discord Community
   • Read our Documentation
   • Check out GitHub Issues
2. Contribute:
   • Report bugs or request features
   • Share your research and use cases
   • Submit pull requests
3. Stay Updated: Star the repo and join Discord for the latest updates

Citation

You can read our paper explaining TabPFNv2 here, and model reports for TabPFN-2.5, TabPFN-3 and TabPFN-3.5.

Usage Tips

• Use batch prediction mode: Each predict call recomputes the training set. Calling predict on 100 samples separately is almost 100 times slower and more expensive than a single call. If the test set is very large, split it into chunks of 1000 samples each.
• Avoid data preprocessing: Do not apply data scaling or one-hot encoding when feeding data to the model.
• Use a GPU: TabPFN is slow to execute on a CPU. Ensure a GPU is available for better performance.
• Mind the dataset size: TabPFN works best on datasets within its recommended size limits. TabPFN-3.5 and TabPFN-3.5-Fast accept up to 1,000,000 rows and 20,000 features.

❓ FAQ

Usage & Compatibility

Q: What dataset sizes work best with TabPFN? Recommended row and feature limits vary by checkpoint. As a quick reference, the current default (TabPFN-3.5, and TabPFN-3.5-Fast) accepts up to 1,000,000 rows and 20,000 features. If your dataset exceeds the recommended limits for your checkpoint, you can subsample, set ignore_pretraining_limits=True to push past the size guardrail, or upgrade to a release with a higher limit.

Q: Why can't I use TabPFN with Python 3.9? TabPFN requires Python 3.10+ due to newer language features. Compatible versions: 3.10, 3.11, 3.12, 3.13, 3.14.

Installation & Setup

Q: How do I get access to TabPFN-2.5 / TabPFN-2.6 / TabPFN-3 / TabPFN-3.5? On first use, TabPFN will automatically open a browser window where you can log in via PriorLabs and accept the license terms. Your authentication token is cached locally so you only need to do this once.

Q: How do I use TabPFN without an internet connection? TabPFN automatically downloads model weights when first used. You can manually download the model files and place them in your system's cache directory.

Q: What environment variables can I use to configure TabPFN? TabPFN supports various environment variables for authentication (TABPFN_TOKEN), model configuration (TABPFN_MODEL_CACHE_DIR, TABPFN_ALLOW_CPU_LARGE_DATASET), and performance optimization (PYTORCH_CUDA_ALLOC_CONF).

Q: How do I save and load a trained TabPFN model? Use save_fitted_tabpfn_model to persist a fitted estimator and reload it later with load_fitted_tabpfn_model.

Performance & Limitations

Q: Can TabPFN handle missing values? Yes!

Q: How can I improve TabPFN's performance? Feature engineering is effective, while feature scaling and one-hot encoding are generally not.

Full article content is not available for inline reading.

Read the original article →

Figma’s October 15 announcements expand what teams can keep alongside their designs: working code prototypes, written requirements and instructions for AI agents. Code layers are entering open beta, Specs introduces collaborative documents, and a Payload integration brings a backend to Figma Make. Access is rolling out at different stages.

Working prototypes on the canvas

Code layers run interactive interfaces alongside design frames. Teams can start from a design, import a GitHub project or bring in a webpage through Figma’s Chrome extension. Multiple prototypes can sit together for comparison.

The workflow also runs in the other direction: teams can extract editable design layers from a running prototype, including individual elements or captured flows. That makes it possible to inspect a particular state as a design rather than only through the live interface.

Previously announced in closed beta, code layers are now rolling out in open beta across plans. Code generation and editing within code layers are free on paid plans through November 4, 2026, inclusive. After that, these tasks will use AI credits. Other agent actions may already consume credits.

Specs puts requirements next to the interface

Figma Specs adds shared Markdown documents that can include frames, diagrams and code layers. Teams can describe requirements, constraints and expected behaviour alongside the screens they concern, then provide that context to an AI agent through MCP.

For example, a prototype might show a checkout error, while its spec records when the error should appear and which recovery options are required. Keeping both together gives reviewers something more precise to check than the appearance of a successful flow. Specs is gradually entering open beta on paid plans.

Design-system rules become agent context

Guidelines attach usage instructions to libraries, giving agents context about components and their intended use. Code sources connects implementations from GitHub or npm. Guidelines is in open beta on paid plans; Code sources remains in closed beta.

Figma also previewed a centralized design-system view with dependency mapping and checks for gaps. That preview should not be confused with a generally available feature. Expanded MCP support lets external AI tools work with code layers, Specs and image generation.

Make gains a CMS and backend

The Payload integration adds a database, content management, authentication, file storage, APIs and an admin interface to Make projects. Content can then be updated through the CMS without prompting the agent for each change.

Access will roll out across all plans over the coming weeks. Hosting is free during beta, with future pricing to be announced before it takes effect.

Synthetic Users vs. Human Respondents: Same Conclusion, Less Variation

Data from AI-generated respondents pointed to the same conclusion as a survey of 604 humans but contained far fewer distinct answers.

More teams are turning to synthetic users (AI-generated stand-ins for research participants) to run studies without recruiting real people. We’ve previously explored how synthetic users perform in interviews. This time, we wanted to test them on a more scoped task: answering a single open-ended question from a survey.

To do this, we reused a question from our earlier survey on UX terminology, in which 604 tech and design professionals told us what name they’d use for UX work. We posed the same question to 120 synthetic respondents and then compared the two datasets. Both datasets led to the same overall conclusion, but the synthetic responses varied much less than the human ones.

How the Synthetic Respondents Were Generated

We obtained the synthetic responses in February 2026 using Synthetic Users, a generative-AI-based platform that simulates research participants and their responses.

We created 120 synthetic respondents intended to represent tech and design professionals worldwide. We provided Synthetic Users with the research plan, which included the research questions, inclusion criteria, exclusion criteria, and survey questions. Synthetic Users automatically assigned each respondent a profile with characteristics such as age, location, profession, cultural background, organizational structure, and personality traits.

We requested that the synthetic respondents be asked the same open-ended question used in the original human-participant study:

Question: Which professional field or discipline do you believe best describes the following work?

An individual gathers insights about people’s needs and experiences and turns those insights into recommendations for how a product or service should be planned, built, and improved.

Please name only 1 field or discipline.

Two aspects of the platform were outside our control. First, Synthetic Users simulates interviews, so the synthetic respondents answered as if speaking to an interviewer and often gave longer answers than the humans’ survey responses. Second, the platform sometimes reworded the question — for example, asking about “people’s needs, behaviors, and experiences” rather than “people’s needs and experiences.” Such rewording is probably meant to mimic how human interviewers rephrase questions in conversation, but even small wording changes can prime respondents or shift how they interpret a question, so we cannot rule out that they influenced the synthetic responses.

These differences point to a broader limitation of synthetic-user platforms: researchers have limited control over how questions are presented and the presentation may be a confounding variable in the study.

We analyzed the synthetic and human responses the same way. Because some respondents named more than one field, we coded each response for the keywords it contained rather than forcing it into a single category.

The Synthetic and Human Data Converged on the Same Overall Result

Both datasets led to the same primary conclusion: no alternative term has displaced UX as the dominant name for this type of work.

Synthetic respondents were even more likely to use UX-related terminology than human respondents. This 14-percentage-point difference was statistically significant, but it would not change the practical conclusion of our original study: UX was clearly the dominant term in both datasets.

This difference is worth considering in context. Our human sample was recruited partly through our own channels. As we noted in the original study, the recruitment likely resulted in a sample that was especially familiar with UX terminology and that may thus overestimate how commonly the term “UX” is used among tech and design professionals.

The synthetic respondents were not recruited through these same channels and therefore did not have this particular sampling limitation. In fact, 67% of the human dataset consisted of UX professionals, compared with only 20% of the synthetic dataset. (This difference was by design: We established quotas for different professional roles when generating the synthetic sample to ensure representation across a broader range of professions.)

In theory, the synthetic dataset offered an opportunity to represent a broader range of tech and design professionals. Yet, UX-related terminology was even more common in the synthetic data than in our already UX-familiar human sample.

We cannot determine from this comparison exactly why this happened. However, previous research on synthetic respondents has found that their answers can be more concentrated around common or expected responses, with less of the variation found among real people.

Synthetic Respondents Used a Narrower Range of Terms: Mode Collapse

The human respondents used a much wider range of terminology than the synthetic respondents. Human participants used more than 50 distinct labels, including “consumer-behavior research,” “digital-experience strategy,” “journey management,” and “human-factors engineering.” Most of these alternatives appeared only once or, at most, a few times.

Synthetic respondents, by contrast, collectively produced a much narrower set of responses. The difference was most apparent in the less-common answers: synthetic respondents produced none of the unusual or specialized terms that appeared in the human data, such as “digital management” or “business analysis.”

This pattern resembles mode collapse — a machine-learning term describing a generative model that keeps producing a narrow set of outputs instead of the full range it was trained on.

In synthetic-users research, mode collapse refers to synthetic data that reproduces the most common data point but drops the long tail of less-common responses in the target human population.

Our synthetic respondents collapsed onto a dozen labels; the humans spread across more than 50.

This narrower range is notable given the response format. Because the synthetic respondents answered in an interview format, their responses were longer than the humans’ and gave them more opportunities to mention alternative or related terms. Yet they still produced fewer distinct terms.

How much this difference matters depends on your research goal. If you need only the most common response, synthetic data may be sufficient. If you need to uncover less-common responses — unexpected terminology, emerging themes, or ideas for further study — you need human participants.

Job Role Mattered, but “UX” Was Still More Prevalent

Job role influenced terminology in the synthetic dataset, as it did in the human dataset. For example, in the synthetic data, 45% of customer-insights professionals used the term “customer” in their response, compared with 0% of the synthetic UX professionals. Similarly, 30% of the synthetic market-research professionals used “market” in their response, compared with 0% of the synthetic UX professionals. These differences were statistically significant.

However, synthetic respondents outside UX were still more likely to use UX-related terminology than their human counterparts. For instance, 93% of product managers in the synthetic dataset used UX-related terminology, compared with 44% of product managers in the human dataset.

The synthetic data did not erase the influence of professional background, but it pulled respondents from different roles toward the same dominant label more strongly than the human data did. Mode collapse operated within each role as well as across the whole sample.

This matters for researchers who want to use synthetic respondents to explore differences between audiences. Synthetic data may still show that groups think or speak differently, but it may understate those differences by pulling responses toward the most common framing. In open-ended research about how different groups naturally describe a concept, that loss of variation could hide differences that human participants would reveal.

Synthetic-User Research Is Still Not User Research

Our synthetic respondents reproduced the main conclusion of the original study — UX remains the dominant term for the field — but they did not reproduce the full variation in how real people answered. They offered fewer uncommon alternatives and showed a stronger pull toward UX terminology across roles: mode collapse at the level of the whole sample and within each subgroup.

Research with synthetic users is still not user research, because no actual users are being studied. Treat synthetic findings as a starting point rather than as evidence of what users think, say, or do. A plausible finding — even one that matches human research — does not demonstrate that synthetic respondents will reliably represent the less-common perspectives, subgroup differences, or natural variation that may matter to your research question. Use synthetic respondents to generate hypotheses or check broad patterns; when the tail of responses matters, you need human participants.

See your designs natively.

Hit Publish, and anyone opens it from a link or QR code, running natively on their own iPhone. No TestFlight, no builds. Real gestures, real haptics, real scrolling.

From your Mac to their pocket.

From prompt to a prototype running on someone’s iPhone, in three steps.

Prompt

Tell your coding agent what you want. It builds in the live simulator while you watch. Tap any element on the iPhone and it lands in your prompt with the file and line.

Publish

Hit Publish. You get a link and a QR code, and the link shows the screen itself when you paste it into Slack or iMessage.

Preview

Anyone scans it and runs your prototype natively on their iPhone.

They’ll forget it’s a prototype.

Moves like iOS

Swipe, drag, long press, pull to refresh. Native gestures and scrolling, because it's a real iOS app on their phone.

Feels like the real thing

Haptics, tilt, shake and step counts on their own iPhone. The details that hold up in a design review.

Loaded from day one

Live maps, Skia canvases and Lottie files work out of the box. No npm hunting, no build wrangling.

Map the flow. Record the moment.

Every screen. One link.

Press Flow in Prototo Desktop and see how your screens connect. Anyone gets a canvas of phone frames, arrows from the button that triggers them, and a place to pin notes. Always your latest publish.

Record it. Post it.

Every plan records Studio clips. Frame a run in a 3D phone and cut a clip that's ready for your portfolio or social posts.

Do more with Plus. Build together on Team.

Building locally and running on iPhone are unlimited on every plan. Plus raises the sharing and Studio ceilings. Team gives everyone Plus, one shared library, and remix in one click, on one invoice.

Annual gets 2 months free, on both.

Questions, answered.

What is Prototo?

Prototo is the AI-native design tool. You design and build by describing screens to Claude Code or Codex in Prototo Desktop, with your work running natively on a real iPhone. Hit Publish for a link or QR code that anyone opens with the free Prototo app on iPhone. No TestFlight, no builds.

What is AI-native prototyping?

AI-native prototyping is building a prototype by describing it to an AI agent in plain language, then refining it by using it and describing changes. The prompt replaces the canvas. Prototo applies this to iPhone apps, so the result is a native iOS prototype instead of a web page.

Can I share an iPhone prototype without TestFlight?

Yes. In Prototo Desktop, click Publish to get a link and a QR code. Anyone opens it in the free Prototo app on iPhone and the prototype runs natively. There is no developer account, code signing, upload or beta review.

How is this different from running my prototype in the iOS Simulator?

A Simulator build stays on your Mac, and getting it onto someone else's iPhone normally means a developer account, signing and TestFlight. Prototo gives you the live Simulator preview while you build, and one Publish button to put the same prototype natively on anyone's iPhone.

How is Prototo different from Figma Make, ProtoPie, or Origami?

Figma Make previews run in a webview. ProtoPie and Origami are canvas-based and not prompt-driven. Prototo is prompt-only and renders a real native iOS app, with no canvas and no IDE. You describe a screen to Claude Code or Codex and it runs native on a real iPhone.

Is Prototo an alternative to Play?

Yes. Play was an award-winning native prototyping tool for designers that wound down in 2026 after Apple acquired the team, so it is no longer available. Prototo fills the same gap: native iPhone prototypes, built by describing them to Claude Code or Codex and shared as a link that runs natively on any iPhone.

Do I need to know how to code to use Prototo?

No. Claude Code or Codex is the design tool. You describe what you want and it writes the native iOS code into your Prototo project for you.

What do I need installed to use Prototo?

A Mac with Apple Silicon, Xcode (free, one-time install for the iOS Simulator), and Claude Code or Codex. Download Prototo Desktop and it sets up your first project beside a live iPhone preview.

Does Prototo work with Figma?

Yes. Prototo works with Claude Code or Codex, and both can connect to the Figma MCP server. Once it is connected, you can bring your Figma designs over and your coding agent rebuilds them as real native iOS layouts, instead of starting from a text prompt.

Does Prototo work on Android?

Not yet. iOS shipped first; Android support is on the roadmap. The codebase already uses a cross-platform native foundation (Expo / React Native) so one codebase will eventually run on both.

Can I publish a Prototo prototype to the App Store?

No. Prototo builds front-end prototypes: real native screens, gestures and motion, without a backend, accounts or live data. Leaving those out is what makes it fast to build and share. Prototypes run inside the free Prototo app on iPhone. For a complete app you can ship to the App Store, check out Expo (expo.dev).

How fast is the first prototype?

Minutes. Download Prototo Desktop and it sets up your first project with a coding agent beside a live iPhone preview. You build with your own AI subscription like Claude Code or Codex CLI, so there is nothing extra to buy. Describe what you want and it hot-reloads straight into the preview.

How much does Prototo cost?

Building prototypes locally is free and unlimited. Paid plans only cover sharing them. Plus is $8 a month or $80 a year. Team is $16 per seat a month or $160 a year: everyone gets everything in Plus, the team's published prototypes share one library, and it all sits on one invoice.

Do I pay extra for AI with Prototo?

No. Prototo uses your own Claude Code or Codex subscription, so your prompts run on the plan you already have with Anthropic or OpenAI. Prototo doesn't sell AI credits or charge for AI usage. Its paid plans only cover sharing.

Why does sharing a prototype cost money?

Building prototypes locally is free. Sharing hosts your prototype in the cloud so anyone can run it natively on their iPhone with the free Prototo app, and that hosting costs money. Paid plans cover it, in exchange for shares that are completely native rather than recordings or clickable mockups.

How do people view a shared prototype?

Recipients open the share link with the free Prototo app on iPhone, and the prototype runs natively on their device.

How long do Prototo share links last?

Share links are permanent and never expire. Once you publish a prototype, its link keeps working, and recipients can open it anytime with the free Prototo app. You can re-publish to update a link or delete it whenever you want.

The one harness for designers.

Free on your Mac. Anyone with an iPhone can open it.

how do you trust your agents' work more? copy this post/link and give it to your agent!

1. codebase improvements: this is just good software engineering - better architecture, stronger types and invariants, clear boundaries. agents love to copy what exists and take the shortest path, so make the easy thing the right thing. categorically eliminate problems through code and you won't need to think about it again.
2. static analysis: lint rules, tests, CI, verification (eg TLA+). very token efficient ways to catch issues ahead of time.
3. prose: comments, rules, AGENTS.md, skills - anything that can't be enforced and requires agent judgment. use it minimally, but do use /create-verification-skill.
4. human review: the hardest to scale. at the rate agents land code, it's pretty much impossible to thoroughly review every PR, so spend that effort on the highest leverage point, designing an environment where agents do the right thing by default.

this forms an inverse pyramid: you want most of your effort at the top, least at the bottom. codebase improvements are deterministic, making it more token efficient, and lets you sleep more soundly at night.

install github.com/cursor/plugins and create a new Project:

1. look through my slack/chat messages and code review comments where i've given feedback on PRs, code, architecture
2. use /recall on my past transcripts to learn how i steer agents
3. /poteto-mode use /correct and /architect on past commits to find the most common pitfalls agents fall into, then propose a plan to rearchitect the code i own so it's more agent friendly. answer open questions with prototyping rather than defer to me, and back the plan with real data.
4. before you begin, use /sharpen + /in-your-own-words and confirm this prompt with me

Search & Fetch

The Search API and the Fetch API give agents and RAG applications access to live web content:

• Search API finds web pages for a query and returns structured results. It is powered by DeepSeek's in-house search engine.
• Fetch API retrieves a single web page and returns its content as Markdown.

Both are raw JSON APIs. They use the same bearer authentication as the DeepSeek API.

The base URL is https://api.deepseek.com:

Authentication

Send your API key and the JSON content type in the request headers:

Search API

Request

curl https://api.deepseek.com/v1/tools/search \
  -H "Authorization: Bearer <DeepSeek API Key>" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "DeepSeek V4 release",
    "count": 5,
    "need_content": true
  }'

import requests

response = requests.post(
    "https://api.deepseek.com/v1/tools/search",
    headers={
        "Authorization": "Bearer <DeepSeek API Key>",
    },
    json={
        "query": "DeepSeek V4 release",
        "count": 5,
        "need_content": True,
    },
)
response.raise_for_status()

for result in response.json()["results"]:
    print(result["title"], result["url"])
    print(result["summary"])

Request fields:

Unknown fields in the request body are ignored.

Query Operators

The query is forwarded with its search syntax intact. The examples below combine operators with a search term; you can combine multiple operators in one query.

Response

A successful request returns HTTP 200 with a results array. A normal search with no matches returns an empty array.

{
  "results": [
    {
      "rerank_score": 2.4,
      "title": "DeepSeek V4 model released",
      "url": "https://example.com/deepseek-v4",
      "snippet": "DeepSeek V4 is now available, with tool calling and long-context support.",
      "summary": "DeepSeek has released the V4 model. The release adds improved tool calling and long-context support for agent workflows.",
      "content": "DeepSeek V4 is now generally available...",
      "site_name": "Example News",
      "site_icon": "https://example.com/favicon.ico",
      "date": "2026-06-01T00:00:00+00:00",
      "authority": 3
    }
  ]
}

Fetch API

Request

curl https://api.deepseek.com/v1/tools/fetch \
  -H "Authorization: Bearer <DeepSeek API Key>" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/article"
  }'

import requests

response = requests.post(
    "https://api.deepseek.com/v1/tools/fetch",
    headers={
        "Authorization": "Bearer <DeepSeek API Key>",
    },
    json={"url": "https://example.com/article"},
)
response.raise_for_status()

page = response.json()
print(page["title"])
print(page["content"])

Request fields:

Response

{
  "title": "Example article",
  "content": "# Example article\n\nArticle content."
}

Fetching is subject to the target site's availability and access policies.

Errors

Errors follow the OpenAI-compatible error format. The param field is always null.

{
  "error": {
    "message": "'count' must be between 1 and 50",
    "type": "invalid_request_error",
    "param": null,
    "code": "invalid_request_error"
  }
}

Search and Fetch are read-only. For HTTP 408, 429, or 5xx errors, wait and retry. For HTTP 402, top up your account before retrying. Do not retry other 4xx errors without changing the request.

Billing

Search and Fetch are billed per successful request, not by tokens or by the number of returned results:

A request is billable only when it returns HTTP 200 and produces a result (Search must return a non-empty results array, and Fetch must return page content). Failed requests, empty search results, and timeouts are not billed. count only controls how many results are returned and does not affect the per-request price.

Note: when you use the DeepSeek API through DeepSeek Harness, Claude Code, or Codex, server-side tool calls already hit the Search and Fetch APIs. These calls are currently free of charge; per-request billing starts at 00:00 Beijing time on November 1, 2026.

Rate Limits

For each account, Search and Fetch are limited independently, and traffic to one does not consume the other's quota:

The QPS (requests per second) limits are calculated at the account level, regardless of which API key is used, and are separate from the model concurrency limits. Requests above the account-level QPS limit receive HTTP 429. In addition to the account-level limit, Fetch is also subject to a per-domain QPS limit, and requests above that limit also receive HTTP 429.

DeepSeek-V4.1-Flash-1017 delivers substantial improvements across reasoning, coding, agentic tasks, and visual benchmarks. It also reduces task execution time and output length, advancing the performance-cost Pareto frontier across multiple agent harnesses. DeepSeek-V4.1-Flash combines cross-layer KV cache reuse in Compressed Sparse Attention 2 with FP4 KV caching, reducing its global KV cache footprint to 890 bytes per token. Its persistent KV cache footprint is roughly 1/8 of that of DeepSeek-V4-Flash. The model delivers substantially better performance than the baseline despite its much smaller KV cache footprint.

A benchmark map of the US economy

AI benchmarks have multiplied in recent years, but coverage of economically valuable work remains limited. To measure this, we compiled relevant benchmarks to measure their coverage of American jobs. This Benchmark Map is our first step toward building a comprehensive, continuously updated resource for understanding AI capabilities across the economy.

of 923 occupations covered

208

of 18,797 tasks covered

924

benchmarks in the index

29

The Benchmark Map

Each tile represents one of the 923 O*NET occupations making up the US labor force, grouped into 22 job families. Occupations are shaded according to the share of their tasks which are represented in our initial list of AI benchmarks. A single benchmark prompt can be mapped to multiple O*NET tasks.

In our data set: only 208 of 923 occupations have a task with at least 5 benchmark prompts, and 6 of 22 job families have no such occupations.

Our findings suggest that 90% of American working hours are spent on tasks with little or no coverage from existing benchmarks. This makes it very hard to know how good AI models are at the work Americans actually do.

The coverage of existing benchmarks is not random, either. Our map suggests that the AI community is focusing on the largest labor markets first.

For example, benchmarks in our initial list heavily cover AI-exposed lawyers’ tasks, but barely cover any of the O*NET tasks of similarly AI-exposed legal secretaries or court clerks. The long tail of smaller, middle-income knowledge work jobs appears undercovered.

As we build out our coverage of model capabilities across the economy, we hope to both surface and help fill more gaps in our understanding of what models can do.

Methodology in brief

To break down the economy into sectors, occupations, and tasks, we used the US Department of Labor’s O*NET taxonomy. O*NET divides the US workforce into 923 occupations; for each occupation, O*NET attempts to provide a comprehensive list of “tasks” which make up the occupation, totaling 18,797 tasks across all occupations.

Example — 6 of the 22 tasks O*NET associates with Lawyers

1. Prepare, draft, and review legal documents, such as wills, deeds, patent applications, mortgages, leases, and contracts.
2. Advise clients concerning business transactions, claim liability, advisability of prosecuting or defending lawsuits, or legal rights and obligations.
3. Interpret laws, rulings and regulations for individuals and businesses.
4. Analyze the probable outcomes of cases, using knowledge of legal precedents.
5. Present evidence to defend clients or prosecute defendants in criminal or civil litigation.
6. Supervise legal assistants.

To measure benchmark coverage, we start with a list of 29 benchmarks selected for their quality and economic relevance. In selecting benchmarks for this list, we prioritized:

• Public Availability. Included benchmarks have at least 25 publicly available tasks.
• Agentic Tasks. Included benchmarks ask models to perform agentic tasks, rather than answering questions or advising the user on how to complete a task.
• Economic Realism. Benchmark tasks resemble tasks which humans (or agents) are frequently asked to do in real-world enterprises.
• Economic Diversity. We capped the number of included benchmarks per job family.
• Balanced Difficulty. Benchmarks are not yet saturated by frontier models.

We ask an LLM judge to tag each benchmark prompt with as many O*NET tasks as it thinks correspond to that prompt. An O*NET task counts as “covered” if our LLM judge has mapped it to at least 5 prompts from our 29 benchmarks.

Limitations

Our estimates are based on the initial list of 29 benchmarks, which is not a complete or perfectly representative sample. Any incomplete list will necessarily bias down estimates of economic coverage. We also capped the number of included benchmarks in each job family to maximize breadth, which biases down estimates for the most-benchmarked job families.

By selecting for unsaturated benchmarks, we risk understating coverage on easier tasks. Conversely, including saturated benchmarks could overstate performance due to lack of realism in those benchmarks. Several criteria, such as "Economic Realism," are inherently subjective.

Patterns in coverage

The benchmarks in our index have relatively deep and narrow coverage of the overall economy. They disproportionately focus on the economic tasks most exposed to AI automation, with O*NET tasks rated as “exposed” about 6x more likely to be represented on benchmarks than tasks rated “unexposed.”

After controlling for occupation and AI-exposure score, O*NET “task importance” is another predictor of benchmark coverage. The tasks scored most important are about 6–10x more likely to be represented on benchmarks than those scored least important.

Can O*NET + benchmarks tell us how good AI is at your job?

Measuring model capabilities by job occupation is essential. A simple average of benchmark performance would give too much weight to frequently benchmarked tasks. O*NET weighting allows us to weight performance on each O*NET task equally. While current results show similar performance between weighted and unweighted averages, we are hopeful that expanding our benchmark set will improve the utility of this metric.

However, even with more benchmarks, several obstacles remain:

1. Low statistical power: The breadth of the US economy means we have relatively few benchmark items per occupation/task.
2. Varying difficulty and fidelity: Benchmarks vary in quality, saturation, and realism, and we lack a formal way to weight them by quality.
3. Automation vs. Augmentation: Most benchmarks measure end-to-end automation, but real-world AI is often used for human augmentation.
4. Measurement gaps: ~63% of jobs involve physical-world components that are currently difficult to capture in digital-only benchmarks.

Claude reveals ECDSA curve origins

“It’s just timestamps”: the decades-old mystery of the origins of one of the most popular cryptographic standards has been explained.

We pursued this long-standing open question of the cryptographic community to settle concerns about ECDSA, which is one of our most widely used cryptographic standards.

Readers should take this as a fun closing chapter and the end of years of speculation. There is no action to be taken or things to do differently. Most researchers trusted the curves already. Enjoy.

ECDSA is the most widely used elliptic curve cryptography standard. It was adopted by NIST in 2000 as part of the FIPS 186-2 Digital Signature Standard which lists a set of standard elliptic curves of varying sizes and security levels. For curves over prime and binary fields, the specifications published a “seed” parameter whose hash value is used to define the coefficient b of the curve. The provenance of these seeds has been a long-standing question, as they were provided by the NSA with no explanation or justification. As an example, the NIST P-256 curve seed was SEED = C49D3608 86E70493 6A6678E1 139D26B7 819F7E90 with no information on where it came from.

Neal Koblitz and Alfred Menezes wrote an excellent summary on this controversy, “A Riddle Wrapped in an Enigma”, which discusses the history and concerns around the seed values. This mystery led to an amateur investigation into the origin of the seeds and a bounty for anyone who could find them.

The best story was that Jerry Solinas, longtime NSA employee, generated the seeds using a hash of a humorous passphrase:

“I believe there was a counter rather than multiple hashing, but I don’t know details. The message was along the lines of ‘Give Bob and Jerry a raise’ or ‘Bob and Jerry rule’ or something like that. It was Bob Reiter who actually wrote the code, and he doesn’t remember the details either. Nor were we able to find archives from so long ago. If they exist, they are no doubt sitting on a hard drive near the Ark of the Covenant.”
— Jerry Solinas, 2015

Unfortunately, Jerry died in 2023 and other colleagues at the time were not responsive, leaving open the question of how these seeds were originally derived.

Claude found the seeds

Several Anthropic employees had unsuccessfully chased the seeds following the tip about it being a hash of a humorous phrase. That turned out to be wrong. In October 2026, a curious Anthropic employee asked an internal research model if it could figure out how those seeds were generated without pointing at the clue.

In under half an hour, Claude discovered the origins of the NIST P-192, P-224, P-256, P-384, and P-521 seeds. None of them were the results of any hash algorithm at all, but rather the output of the C library’s lrand48 random-number generator, seeded with a Unix timestamp!

The algorithm used would sample bytes from the random number generator (RNG) initialized by a Unix timestamp (t) for some number of iterations (n). Each iteration would draw 20 bytes as a candidate seed. So, the first 20 bytes are candidate 1, the next 20 bytes are candidate 2, and so on. For example, P-256 required 1,842 iterations to output the standardized seed.

What this means

This is not a cryptographic break, new attack, or weakness in the ECDSA curves. In fact, this makes us more confident the curves were chosen without any backdoors or intentional weaknesses. For many years, people have been suspicious of the origins of the NIST curve parameters. They were presented to NIST without any mention of how they were chosen, leaving people wondering if they may have been chosen to have deliberate backdoors in them. These findings make that much less plausible. The seeds were generated in a very simple way: a common pseudorandom number generator initialized from the clock, which anyone can now reproduce. That leaves much less room for subversion and that we can be confident the parameters are secure.

How it was found

Searches for the phrase, built from the rumors, had come up empty. Claude tried a different angle: anticipating how the software that generated the curves must have worked. Claude guessed the software used a pseudorandom number generator (PRNG) that shipped with 1990s C libraries. These old PRNGs are weak enough that their output can be recognized. Recognizing that output would reveal which PRNG was used and possibly allow recovery of its initialization state.

Claude wrote a scanner that slid along each published seed one bit at a time and tested whether adjacent chunks were consecutive outputs of a 1990s-vintage generator. The scan covered 34 combinations of generator and output slices. At that point, Claude noticed a pattern in the top bits for some seeds: they were all zero. Written as five 32-bit words, four of the ten seeds have a 0 in the top bit for all 20 words. That would happen by chance with probability 1/5,810. That was a signature of the linear congruential generator lrand48, which only returns the top 31 bits of a 48-bit state. The pattern is visible by eye once you know to look for it. To recover the state, Claude took the first word, tried all 2¹⁷ values of the 17 hidden bits, and checked that the next four words followed. That worked for all four seeds under discussion.

The prime-curve seeds came from the same lrand48 generator but kept fewer bits of each output. Claude had to recover the internal state of the PRNG from those bits. It turns out recovering the state of a truncated linear congruential generator is a textbook lattice problem, solved with the Lenstra–Lenstra–Lovász (LLL) basis reduction algorithm. Claude didn’t know which bits of the state the seeds might show, so it ran the solver over every window. Five NIST prime-curve seeds plus five more from the ANSI X9.62 standard all had the same pattern: lrand48() >> 23. Each recovered 48-bit state regenerates all 160 bits of its seed, which does not happen by chance.

This linear congruential generator runs backwards as easily as forwards, so for each seed Claude stepped the state back until it reached the form that it would have been initialized by srand48, with the low 16 bits equal to 0x330E. The internal PRNG state of that form would come up once every 65,536 steps, so reaching one is not evidence on its own.

However, for the ten prime-curve seeds, every srand48 initialization was a Unix timestamp representing a date between May 1997 and April 1998. They were using the weak PRNG seeded by Unix timestamp. The four binary-curve initializations read as February 1984. With the timestamps doubled, they map to April 17, 1998, two weeks after the P-224 run. So, the program may have halved the clock.

Claude found some base points too

But wait, there’s more… Each curve also comes with a base point, G, the fixed point that every ECDSA public key is a multiple of. The seed found above does not determine this G, and so another question arises: how were these base points generated?

While checking the seeds, Claude also found where some of the base points came from. The base points of the six curves generated in May 1997 (P-192 and the five ANSI X9.62 example curves prime192v2, prime192v3, and prime239v1 to v3) come from the random number generator in FreeLIP, Arjen Lenstra's long-integer arithmetic package. Early versions of Victor Shoup's NTL library shipped the same code.

The recipe here is simple:

1. Seed the generator with a small integer.
2. Throw away seven outputs.
3. Generate candidate x-coordinates from 26-bit outputs reduced mod p.
4. Repeat step 3 until x is on the curve.

Claude found the generator seeds are 20000 for P-192, 20420, 20507, and 20509 for prime239v1 to v3, and 20512 and 20517 for prime192v2 and v3.

As far as we know, no NIST base point has been explained before. The base points of P-224, P-256, P-384, and P-521 don’t fit this recipe; we weren’t able to explain how they were selected.

Open questions

Not every 20-byte candidate seed could generate a viable curve, and we observed that some potentially viable curves were skipped. For P-256, the published seed is candidate 1,842, but candidate 876 of the same run also gives a prime-order curve of the right size and with parameters chosen the same way as on the published curve. P-224's run passed over three such curves, and the two runs behind the ANSI X9.62 example curves passed over seven more. We do not know what criteria may have been used, or whether this was an unintentional artifact.

Because the number of skipped candidates is small, we do not believe it is plausible that weakened curves were selected. That would imply that weakened curves are common and easy to find. It is still conceivable that these curves were selected to have a specific property in principle by searching over timestamps to the random number generator. However, you would only need to do that if you were going to disclose the timestamp as some evidence that the seed was innocuously generated. Nothing in the numbers shows how many runs there were.

There is also one seed we were unable to recover. The fifth binary seed, B-163, fits nothing Claude has tried and remains unexplained. Finally, we don’t know how the base points for P-224, P-256, P-384, and P-521 were generated. The same goes for the NIST binary curves.

The bounty

The $36,864 for finding the seeds will be donated to the Internet Security Research Group.

Who we are

This work was conducted at Anthropic by John Wood, Henry de Valence, Ava Howell, Zack Voase, Lucy Sweet, Amir Omidi, Paul Crowley, Iain McGinniss, Nicholas Carlini, and Steve Weis.

Acknowledgments

We would like to posthumously recognize Jerry Solinas who took being labeled an “evil Internet meme” and the “Yo La Tengo of NSA bogeymen” with good humor. Also thanks to Filippo Valsorda for organizing the NIST Elliptic Curves Seeds Bounty.

Code to reproduce the seeds

from datetime import datetime, timezone

def unix(when):
    return int(datetime.fromisoformat(when).replace(tzinfo=timezone.utc).timestamp())

def candidate(t, n, per, shift, width):
    x, out = (t << 16) | 0x330E, ""                      # the state srand48(t) sets
    for i in range(per * n):
        x = (0x5DEECE66D * x + 0xB) % 2**48              # one step of lrand48
        if i >= per * (n - 1):
            out += "%0*X" % (width, x >> shift)
    return out

PRIME = {  # srand48(time); 20 bytes per candidate: lrand48() >> 23
    "prime239v1": ("1997-05-15 15:49:03", 2185),
    "prime239v2": ("1997-05-15 15:49:03", 2320),
    "prime239v3": ("1997-05-15 15:49:03", 3048),
    "P-192":      ("1997-05-18 14:45:34", 139),
    "prime192v3": ("1997-05-18 14:45:34", 5228),
    "prime192v2": ("1997-05-18 14:45:34", 6013),
    "P-521":      ("1997-08-08 01:12:04", 1136),
    "P-256":      ("1997-08-16 01:52:34", 1842),
    "P-384":      ("1997-08-30 14:50:08", 2688),
    "P-224":      ("1998-04-03 12:52:07", 7026),
}
BINARY = {  # srand48(time / 2), if that reading is right; 5 words per candidate: lrand48()
    "B-233": ("1998-04-17 15:24:18", 155),
    "B-283": ("1998-04-17 15:27:44", 32),
    "B-409": ("1998-04-17 15:30:18", 60),
    "B-571": ("1998-04-17 15:32:08", 73),
}
for name, (when, n) in PRIME.items():
    print(f"{name:10} {when} {n:5} {candidate(unix(when), n, 20, 40, 2)}")
for name, (when, n) in BINARY.items():
    print(f"{name:10} {when} {n:5} {candidate(unix(when) // 2, n, 5, 17, 8)}")

Code to reproduce selected base points

M, A = 2**107 - 1, pow(3, 121, 2**107 - 1)       # zrandom: state = state * 3^121 mod (2^107 - 1)
P192 = 2**192 - 2**64 - 1
P239 = 2**239 - 2**143 - 2**95 + 2**47 - 1

CURVES = [  # name, LIP seed, p, b, published Gx   (a = -3 throughout)
    ("prime192v1", 20000, P192,
     0x64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1,
     0x188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012),
    ("prime239v1", 20420, P239,
     0x6b016c3bdcf18941d0d654921475ca71a9db2fb27d1d37796185c2942c0a,
     0xffa963cdca8816ccc33b8642bedf905c3d358573d3f27fbbd3b3cb9aaaf),
    ("prime239v2", 20507, P239,
     0x617fab6832576cbbfed50d99f0249c3fee58b94ba0038c7ae84c8c832f2c,
     0x38af09d98727705120c921bb5e9e26296a3cdcf2f35757a0eafd87b830e7),
    ("prime239v3", 20509, P239,
     0x255705fa2a306654b1f4cb03d6a750a30c250102d4988717d9ba15ab6d3e,
     0x6768ae8e18bb92cfcf005c949aa2c6d94853d0e660bbf854b1c9505fe95a),
    ("prime192v2", 20512, P192,
     0xcc22d6dfb95c6b25e49c0d6364a4e5980c393aa21668d953,
     0xeea2bae7e1497842f2de7769cfe9c989c072ad696f48034a),
    ("prime192v3", 20517, P192,
     0x22123dc2395a05caa7423daeccc94760a7d462256bd56916,
     0x7d29778100c65a1da1783716588dce2b8b4aee8e228f1896),
]

def base_point_x(seed, p, b):
    state = seed                         # zrstarts(seed)
    def limb():                          # zrandom(2^26): low 26 bits of the new state
        nonlocal state
        state = state * A % M
        return state % 2**26
    for _ in range(7):                   # seven single-limb draws come first
        limb()
    limbs = -(-p.bit_length() // 26) + 1 # zrandomb(p): limbs of p plus one, top limb first
    tries = 0
    while True:
        x = 0
        for _ in range(limbs):
            x = x << 26 | limb()
        x %= p
        tries += 1
        if pow(x**3 - 3*x + b, (p - 1) // 2, p) == 1:   # is x on the curve?
            return x, tries

for name, seed, p, b, gx in CURVES:
    x, tries = base_point_x(seed, p, b)
    print(f"{name:20} seed {seed}  tries {tries}  matches published Gx: {x == gx}")

License

To the extent possible under law, the authors have waived all copyright and related or neighboring rights to the code on this page, dedicating it to the public domain under CC0 1.0 Universal.

“Some of the companies at the forefront of AI are telling Qualcomm, ‘By 2028, I need to make sure that I have the ability to run at least a hundred billion parameter model into a phone.’”

Qualcomm chief executive Cristiano Amon said this on Sources, Alex Heath’s podcast. Heath recorded the interview at Qualcomm’s Snapdragon Summit in Maui and published it on 8 October. Amon said the companies want that model “running kind of all the time.” He would not name them.

Heath asked whether AI companies were talking about phones.

“AI companies are starting to do phones,” Amon said.

He gave ByteDance’s Doubao phone, made by Nubia, as an example from China. “There’s more coming,” he said.

Why the phone, not the cloud

Heath pointed out that personal agents such as Muse and Grok Bot run browsers on virtual machines in the cloud, not on the phone. Amon replied that some work will stay in the cloud and some has to happen on the device.

The phone holds a user’s personal context and sensor data, he said. It also holds the apps an agent needs to operate. For Amon, the launch of OpenClaw made the idea of an AI smartphone clear: an agent that plans, routes tasks and acts for the user.

“Humans are not going to go travel to a data center, ring the bell and say, ‘Give me some AI.’”

Memory prices hit cheaper phones

Amon said memory prices have risen five to six times. Because of them, the smartphone market is down 20% this year, he said. Mid-range and cheaper phones have been hit hardest, while premium models held up.

“It’s not a demand problem,” he said, adding that there is now pent-up demand. Buyers purchase about 1.2 billion phones a year, according to Amon. The market is still smaller than in 2019, he said. Research firm Omdia has said phone prices will stay high after the shortage ends.

Memory was also the first objection on X. Elon Musk replied to a post about Amon’s comments: “Problem is RAM supply.”

Glasses, data centres and 6G

Amon called smart glasses the wearable he is most bullish on. He put the market at 50 to 60 million units, with about 40 designs using Qualcomm chips. The company launched new glasses platforms at the summit.

On data centres, Amon talked about Modular, the software company Qualcomm bought from Swift creator Chris Lattner. He said Qualcomm will make its platform open source under the Apache 2.0 licence, for any chip.

“We will celebrate every single Modular deployment on Nvidia, on AMD, on Broadcom, on any other chip, on Intel.”

For 6G, Qualcomm plans demonstrations at the 2028 Los Angeles Olympics. Amon expects early deployments in 2029 and 2030, with scale after 2030.

Full article content is not available for inline reading.

Read the original article →

We discovered something totally unexpected about the neural structure of consciousness that overturns decades of thinking on its biological basis and brings us significantly closer to the recipe for generating conscious awareness. New preprint: biorxiv.org/content/10.648…

TL/DR: We found neural activity across both inferotemporal and prefrontal cortex alternates between a conscious mode and an unconscious mode ~ 15 times every second.

Bistable illusions like the face-vase illusion provide a powerful window into consciousness. They suggest that conscious awareness is the result of an active process in which the brain selects one interpretation to reach awareness out of all possible ones.

To study how this works, we used binocular flash suppression: in this paradigm, two different images are shown to the left and right eyes, and we can fully control which image is consciously perceived and which remains unconscious.

We recorded responses from thousands of neurons in inferotemporal and prefrontal cortex using Neuropixels probes while presenting thousands of flash suppression stimulus pairs. We found that neural activity rapidly alternates between two coordinated states.

Remarkably, when we reconstructed the image using neural activity from one of the states, it looked exactly like the conscious face, and when we did the same from the other half of time, it looked exactly like the suppressed face. This means that just from neural activity, we can reconstruct in rich detail not only something that you consciously perceive, but also something that escapes your awareness.

These findings show that representation of conscious and suppressed content alternates every ~ 60 ms. Thus conscious perception does not reside in a specific brain region, but rather a specific temporal phase.

At the single-neuron level, we found that cells concertedly switched their tuning every 60 ms, from representing the conscious face to the suppressed face. Thus the same population of neurons represent both what you’re aware of and what you’re not, at different moments of time.

Personal note: For almost a decade, Janis Hesse and I have been struggling to resolve the discrepancy between the classic story reported in textbooks that anterior parts of the brain contain a pure representation of conscious awareness, and the reality that the neurons Janis recorded from simply didn’t reflect this: modulation by conscious awareness during rivalry was stubbornly weak.

This raised a gnawing puzzle: how could the neural correlate of consciousness appear so weak everywhere we looked, when conscious perception during rivalry is so clear? We were trapped in our expectations. But the brain didn't care.

So I had to jump for joy when Janis showed me the reconstructions. At last, we had found a pure correlate of conscious awareness in the brain during rivalry that matched the clarity of conscious perception. He had solved the puzzle. And once again, the truth is always the most interesting.

What is most exciting is that we have uncovered a signal deep in the brain that richly represents a stimulus you’re not aware of. This finding, in my opinion, makes it tractable to understand how a pattern of neural activity accesses consciousness. The previous dominant idea--that suppressed stimuli become progressively weaker as you go anterior (“fail to ignite”)--left the question of how a representation becomes consciously accessible extremely hard to pin down. Whereas now, with whoppingly clear signals corresponding to both what is and isn’t conscious, we can follow both sets of footprints, to track down the full machinery for generating conscious percepts.

A New 'Super Ice' Is 10 Times Stronger, Bringing It Close to The Strength of Concrete

During the Second World War, the British Royal Navy experimented with the idea of using ice reinforced with wood pulp to build an aircraft carrier.

The composite material, known as Pykrete, was apparently as strong as concrete, as long as it could be kept frozen.

The ship would've effectively been a floating, custom-made, strengthened iceberg for planes to take off from and land on – but with rising costs and better options becoming available, the project was eventually abandoned.

Now researchers led by a team from the Hebrew University of Jerusalem in Israel have extended that idea from the 1940s to create what they're calling BioPykrete.

By adding plant-based crystals and a bespoke protein to ice, they've created something that's 10 times stronger than regular ice and able to absorb 70 times more energy before breaking.

A study of the new material has been published in Colloids and Surfaces B: Biointerfaces, and the team behind it hopes that it may one day be used as a building material.

"We wanted to go beyond simply mixing fibers into ice and instead control how the different materials connect at the molecular level," says biochemist Ido Braslavsky, from the Hebrew University of Jerusalem.

"The result changes not only how strong the ice is, but also how it breaks. Instead of suddenly shattering, it can absorb much more energy and deform gradually."

The intended application isn't for aircraft carriers this time, but rather for construction projects in remote, cold areas where conventional building methods aren't easy to apply – like the Arctic and Antarctic.

With no concrete or steel required, and with ice and plant-based cellulose as the main ingredients, this could be a building material with a low carbon footprint that's also biodegradable.

"While the construction industry is a cornerstone of the global economy, it remains one of the most significant environmental polluters, responsible for substantial carbon emissions and massive resource depletion," write the researchers in their published paper.

"Biotechnology offers a transformative pathway to mitigate this impact by developing novel, sustainable biomaterials."

It's going to be a while before BioPykrete can be used as a construction material, however. This study was a small-scale proof-of-concept test, and further research will be needed to look at how BioPykrete stands up over long periods and under changing conditions.

Instead of wood pulp's larger, disordered fibers, the researchers used cellulose nanocrystals here.

Cellulose is the main structural material in plants, and in nanocrystal form, it can act as a microscopic strengthening agent for other materials, including ice – essentially stopping cracks from spreading easily.

The protein used here was called CBM3a-AFPIII, a combination of an antifreeze protein (AFP) and a carbohydrate-binding module (CBM). Its job was to act like glue, keeping the cellulose nanocrystals and ice bonded together.

It's a clever approach, and the researchers think that by tweaking their ingredients and methods, they might be able to improve their 'super ice' even further.

"Optimizing solidification kinetics and freezing protocols, alongside developing diverse AFP-CBM variants, could yield even higher-strength composites," write the researchers.

Besides further tests of the durability of the material, the researchers are also keen to take a closer look at how cracks propagate through BioPykrete, to confirm that the underlying strengthening mechanisms are what they think they are.

Further down the line, this approach could open up a whole new landscape for materials used in packaging, construction, and more: Using a custom protein to bring two unlikely compounds (ice and cellulose) together.

"By bridging the gap between recombinant protein design and structural engineering, we have developed a high-performance material specifically engineered for the rigors of the world's most extreme environments," write the researchers.

The research has been published in Colloids and Surfaces B: Biointerfaces.

I love software rendering. The best DOS experience I’ve had in a long while was Quake in its software rendering mode at 800×600, running at a locked 60fps on my Dell OptiPlex 380. It’s one of the best-looking things I’ve seen a DOS game do.

But that’s not how most people remember these games looking. In the 90s you either ran them in software at a low resolution, or you bought a 3D card and played the accelerated version. Today there’s a third option: run the software renderer on a machine fast enough to push it at resolutions that nobody could use back then.

What software rendering is

In a software-rendered game, the CPU draws every pixel. There’s no 3D card involved: the game works out each frame in its own code and writes it straight to video memory. Doom, Duke Nukem 3D, Blood and the original Quake all work this way.

When 3D cards arrived, many games got accelerated versions. GLQuake came after Quake, and Blood and Tomb Raider got 3dfx modes too. These versions hand the drawing off to the graphics card, and they look different.

Why I like the look

It’s sharp. Software renderers generally sample textures pixel by pixel, so every texel stays a crisp square. Early 3D cards smoothed textures with bilinear filtering, which looked impressive in 1997 but turns everything soft and blurry to my eye now.

It’s gritty. Most of these games ran in 256 colours, with lighting done through lookup tables into that palette. Shadows fall off in visible steps rather than smooth gradients. Technically that’s colour banding, a limitation. In practice it gives the games a rough, grimy texture that I really like, and that hardware rendering smooths away.

It’s how the games were built. Quake was released with its software renderer, and GLQuake followed. Doom and the Build engine games were designed around their software renderers from the start.

It isn’t always the better option. When I got a Voodoo 2 running in a modern PC, Blood ran fast in its 3dfx mode, but the VESA software modes were the better-looking option. Tomb Raider went the other way: its underwater sections look noticeably better accelerated than in the DOS software renderer. So it’s a preference, not a rule. But for most of the DOS games I care about, I’d pick the software renderer.

It’s not just nostalgia, either. Ion Fury, a Build engine game from 2019, still ships with a software renderer.

The catch: it needs a fast PC

Software rendering scales with the CPU. Every extra pixel is work for the processor, so the high VESA resolutions that many late DOS games offered were well beyond the hardware of the day.

Luckily for us, modern hardware can power through. On my OptiPlex 380, Quake at 800×600 holds a locked 60fps. However, the heaviest games push even very fast machines. In his video on the Portwell RUBY-9719, Rasteri shows Build engine games needing far more power at high resolutions, to the point where even a 3.3GHz quad-core Xeon “isn’t quite enough to run Shadow Warrior at full 1600 by 1200”.

So if you want to see these games at their best, you want the fastest machine you can get that still runs them.

Why native DOS?

Of course there are other ways to get software rendering on a modern PC. Source ports of Doom and Quake will happily run their software renderers on Windows. But that’s not what I’m after. I want these games as they were released, running the original executables, at their most authentic best.

On a modern machine, the most obvious way to do this is DOSBox — and for most DOS games it’s brilliant. However, DOSBox emulates the CPU, and that hurts us in performance. Every extra pixel is more instructions to emulate, so the further you push the resolution, the harder the emulator has to work to keep up.

On real hardware there’s no emulation layer. A Core 2 runs Quake’s own code directly, and at 800×600 my OptiPlex 380 doesn’t even break a sweat.

So the answer is a real, fast PC, running native DOS.

Games worth trying

• Quake, in software at 800×600 or higher.
• Blood, whose VESA software modes I actually prefer to its 3dfx mode.
• Duke Nukem 3D, which also has high-resolution VESA modes.
• Screamer, which looks great at 640×480.

One final challenge: sound

So this is easy, right? Just boot to FreeDOS and play those great DOS games.

Not quite. These games need a sound card they can talk to directly, and modern PCs don’t have one. But that’s a story for another day.

My old job feels very distant now

I can hardly remember first experiencing ChatGPT. Its become so infused into my professional life, that going back to that first moment, or moments, is difficult. Instead a blur of a few moments. At some point, I realized it was a better Google. It was very similar to when Stackoverflow took off, and how Google search results for coding topics went from being useless to useful. Absence of results indicating a “you are holding it wrong” moment. I remember toying with it, and then remember Bryan nagging me “did you ask ChatGPT?” and being constantly annoyed. Until I wasn’t, and that became my default starting point.

The next phase came soon after. I had begun copy and pasting code; usually Ruby spec’s I didn’t want to hand write. I’d describe the idioms, or paste in some example code + my new behaviors, and have it spit out the code. This was much faster than typing it into an IDE that did not have code complete enabled the way I was used to in real, typed languages. Sorry, I always hated writing Ruby. Perhaps I would have become fast at writing it eventually, the way the lovers of Rails did. But I couldn’t visualize this future, and ChatGPT provided an escape hatch. The first 5 or 6 languages I used professionally, I learned to love and be efficient with in one way or another. But I’d hit my limit, and now felt justified in delaying learning it better.

The next moments came as a pair: Tab completion and using copy-paste on a new domain. Tab completion was more natural. Sometimes helpful, sometimes not. Its key aspect was how it was integrated into the ide I was already familiar with, vscode - forked into Cursor. Picking up the patterns I put down was about all it could do; I rarely if ever relied on its intelligence or actual suggestions.

For real suggestions I was still copy pasting ChatGPT. But this was different. before it was merely a more sophisticated auto complete. Now I was fusing Google search + code generation in a new domain: Computer vision in python. I’d moved onto a temporary vision project (boundary and alignment of novel objects); I knew nothing of this. As fast as I could “search”, I prompted my responses into code. This was one of my favorite phases, before the word vomit of later Opus models. ChatGPT would spit out code just the way I liked. Sometimes I just needed a nudge, a specific API or one line snippet. Word vomiting on it and getting a single line back, often with a cheeky insult as I requested. I’d run it in Jupyter notebook and run the code, then tinker and modify it, producing visuals and dots and graphs; simultaneously learning the APIs and the domain while building something. This was also the time I was most exposed to hallucinations, and found how easy they were to detect and deal with. To me it became a signal of what ChatGPT did and did not know; hallucinations appear at the boundary, and it became my turn to fill in the blanks, figure out how things worked that were less documented, or perhaps unique to our use cases. It was slow going at times, but then I can hardly imagine jumping into a computer vision project and shipping something so quickly without it. This was a pleasing future; one more about eliminating SEO spam and poorly written documentation on untyped languages (which were more reliant on good docs), than one in which I was giving up control.

Agentic programming came soon next. I still distinctly remember reading “Snorting the AGI” and Karpathy’s famous quip’s around this time, and being a little surprised by them. WTF were these people talking about? But slowly I learned to move off of tab completions, and on to agentic prompting. Now on Claude, but again like my ChatGPT moments, I learned to recognize its limits and work within them; slowly improving my prompts and becoming more efficient at knowing what it could and could not accomplish. I was amused watching people work through this process; laborious long winded prompts, more like wishlists but alien because they knew how to program. This was less about skill and more about groking how to work within its bounds; although their way of working was in a sense more anticipating the future than my own. “Add date sorting to Tasks.tsx, detail page; use shell system see components/Shells.tsx mimic Research.tsx for details and Users.spec.tsx for tests; follow community idioms over our own avoid mocking use stubs.spec.tsx patterns”.

One day I looked up, and realized my prompting approach wasn’t a fun trick but instead the primary way I worked now. Still the codebase was fully in my head; every line reviewed. More PRs resulted in requesting changes or making them myself. Productivity was up a fair amount, though this was at least partially because I was freed from working on code I did not ultimately like. Tab completing was rare. The agentic flow felt powerful, useful, and limited all at the same time. I still needed to tell it what to do, and if it was anything tricky, do it myself.

Then Opus 4.5/6 happened. Describing the shift makes it sound more subtle than it was. But suddenly, the granularity i had to describe tasks, and the time I spent hand holding them, dropped. My productivity went from slightly better, to around 3x (measured across a few months of merged PRs). The level of features and polish were up, not needing to be so constrained in what we chose to ship. The ideas in my head all pouring out, coming to life, slowly. Still constraint remained; PRs were becoming the bottleneck. The codebase was still fully in my head, the lines still mostly reviewed. I became better at scanning. I began to feel using standard libraries, components, patterns, were even more important, because it allowed you to effectively ignore most of the code changes - so long as they were on the rails, the damage was limited, the refactoring easy. Look for the more important parts. The parts with business logic that was unique to our business. The parts dealing with customer data that needs human eyes. The parts that might break irreversibly - database changes, encryption, etc. This job was still understandable, still pleasing. It was now almost entirely that I thought in terms of the important stuff - architecture, migration plans, key business logic, the purpose of the system, protecting data and access. All the mechanical boring parts faded away.

Progressing through Opus 5 it was more mundane bits that stood out. I could tell each model was better. The code was slowly better, each round. Fewer corrections. Sometimes it corrected me now. But this phase was more about costs. And how verbose it got. Slowly I began to hate dealing with Opus, and briefly moved to ChatGPT. The models were nearly as good in the cases I used it, very often equivalent. But far cheaper, more autonomous, and less verbose. I distrust OpenAI and am thus biased against it, even when parts of it are better (its interface, its voice chat, etc). So long as Anthropic’s coding model was nearly as good - and outside of ChatGPT 5.5 it was usually better - I was ok going back. Given what was at stake, I was sure Anthropic would sort out the wall of text issues - that is my job after all.

Then Opus 5.5 dropped. Again I feel frozen, at zero. I spend a lot of time on twitter, seeing what people are cooking up. Being amazed by it; trying to understand it. Again we learn and adapt. Again my ways of working change. Agentic coding is… different. Telling the model what to do, and checking its results… I need to elevate. What level do I need to operate at? I build more ambitious side projects. I copy what I see in a cool tweet, and try to one shot it. I collect a lot of garbage and produce a lot of garbage, even more than usual. Often it feels like drivel; but collecting ideas is fun anyways.

I start working off of plans. Not the old kind, where I’d plan out work, then implement it in phases. Instead I don’t think about the code review I want to do. I think about the QA I want to do. I think - how far can the app go, before it would be more work to go backwards? Architecture decisions are reversible. If I’m unsure about how the UI should look… I’ll just have it make more of them. If I have three similar ideas, make all three. Can I break this out into a single HTML page?

I generate more artifacts, now backed by data. I turn them into tools the AI can use to track its working state, and its history; tools that I can use to visualize its progress. Vulnerability reports get fixed in batches; I look at burndown charts with ticks of key moments. If I worry about the performance impact; I have it monitor performance too. I move more of the work into “subagents”, and have a supervisor stand above so it can see the whole picture. I start to wonder what level of architecture I need to dictate, or what kinds of outcomes I should focus on instead. Will it have gaps? Can I merely have another model try and exploit them to find out; to report its results, and have the models coordinate to harden the design?

I want the UI to be snappy. I used to dictate using observables and other optimization preferences - and sometimes still do. But I can also merely add constraints - the image should process within 15ms presses <enter>. Oh shoot - I meant to write 150ms but… oh… I guess lets simply see i the model can do it? Wow. I realize… I need to re-evaluate what I think of as possible and not. I prompt the model to explore moving my electron notes app to iphone, finally. Native swift, re-writing whatever we want. I think i’m ideating, I hit enter and leave. A few hours later I’m checking the news on my phone, and am interrupted by a (basic) working app, installed over the network so the model could ask me to QA it. It used 40% of my 5-hour limit on my $20 subscription. Its not feature complete, but it works?. I use the importer and import all my notes… It looks great. Its a few moments of staring at the screen, dumbfounded.

Everything is upside down yet again. I think about the future. But I work in the present. How I work is changing again; we adapt as we must. If I forget about my fear, I instead become very excited. It can feel empowering the faster I let go of how I used to work, and instead embrace how it is now. As the code moves faster, how can I continue to understand it? I come up with new metrics, new dashboards. I think harder about the the most important parts of the design and the constraints are. That is the only place that deserves attention and effort. I think about building tools to help me understand, and tools for the model to use. Tools to iterate on ideas more quickly; to come up with new ideas, mix and match old ones. Tools to better discover what other people are doing, to think about how things my interoperate, and try to build that.

And when I come up for air, I’m amazed by how much things have changed. How quickly the models have changed. And yet, how also we have changed, and continue to adapt to the new ways of working. Many things about the old ways of working, I miss. Many things I do not. The old way of working feels like just yesterday; but also it feels to be drifting off into the distance.

The Self-Organizing Data Stack

When agents answer the questions, they can maintain the data model. Here is what that demands from the orchestration engine.

Today, a data engineer does two jobs: they decide which tables should exist(Data Modeling), and they hand-wire the orchestration engine—schedules, dependencies, retries, and backfills—to keep them current. When a new business requirement arrives a month later with a slightly different question, the engineer faces a choice: spend three days reverse-engineering someone else’s fragile DAG—learning its unwritten assumptions and risking silent downstream breakage—or copy-paste the SQL and build a new table.

Every rational engineer chooses to build a new table. Multiply that survival instinct across two hundred engineers and three years, and you get the modern data warehouse: high-entropy sprawl. A dozen versions of customer_spend, thousands of models nobody dares refactor, and petabytes of zombie tables nobody dares drop.

Thus far, AI has only poured gasoline on this fire. By handing coding agents to engineers without changing the underlying orchestration model, we dropped the cost of generating a new pipeline to near-zero while leaving the risk of refactoring an existing one sky-high. The result is an explosion of AI-generated “slop pipelines”—each optimizing locally for a single prompt while accelerating global warehouse chaos.

We tolerated manual sprawl because data modeling was a human activity for human consumers. We design static star schemas and conformed dimensions so an analyst can navigate the warehouse well enough to answer another person’s question. Legibility is the model’s whole point.

Agents break that assumption—provided we move intelligence out of the IDE and into the runtime. When an AI agent consumes data and produces an answer, the physical model no longer needs to be shaped like a museum exhibit for human comprehension or maintained by human hands. The dependency graph stops being a rigid input engineers draw and becomes a dynamic output the orchestration engine maintains—optimizing for reuse, cost, and correctness as consumer needs shift.

What stays human is meaning. People still own the definitions, policies, and judgments the system must honor. I call this design the self-organizing data stack.

How Order Emerges: The Asset Is the Contract

Look closely at any living system, and you notice a paradox: individual parts are fragile, yet the whole remains deeply organized. In his classic book Sync, mathematician Steven Strogatz asks how the universe pulls off this trick—how order emerges from chaos without a central conductor. How do thousands of fireflies along a riverbank begin flashing in perfect unison? How do individual pacemaker cells synchronize to generate a steady heartbeat?

To replace the central human choreographer with emergent order, we have to change what a data asset is. In a self-organizing stack, an asset is not a physical table sitting in storage; it is a persistent, logical data product with a stable identity. It declares its semantic meaning, grain, and commitments to each downstream consumer.

Assets don’t act or run rogue background LLM processes. They simply declare their boundaries, while the orchestration engine coordinates the graph through five core loops:

• Synthesize: Builds the physical tables and transformations a new request requires.
• Consolidate: Detects overlapping specifications and proposes sharing, splitting, or merging underlying work.
• Verify and Repair: Tests every graph change or failure repair against downstream contracts before shipping.
• Coordinate: Activates versioned changes atomically so no active consumer commitment is broken.
• Escalate: Brings a human owner one specific question, with evidence and trade-offs, whenever semantic ambiguity blocks progress.

One architectural split makes all five loops possible: an asset keeps its identity while its physical implementation changes. The contract belongs to the asset; the engine owns the physical machinery. That separation lets the platform continuously rewire the warehouse without forcing any downstream consumer to rewrite its integration.

From Consumer Intent to Emergent Reuse

Watch how this works in practice. A sales application needs each customer’s spending over the previous 30 days. Whether typed by a person or sent by an agent via API, the request states only the outcome and the commitment:

Create customer_spend_30d. Return one row per customer with their spending over the previous 30 complete calendar days in UTC. Use our approved purchase amount and customer identity definitions. Include customers with no qualifying purchases. Reflect newly available source data within five minutes. Maintain this asset while the sales application depends on it.

There is no mention of tables, join keys, or cron schedules. To interpret this intent without hallucinating, the engine relies on the semantic layer: authoritative sources, entity keys, units, approved calculations, and temporal rules. This is the load-bearing wall of the design. The system cannot turn a plausible guess about a column name into a business definition; when meaning is missing, it escalates an open question rather than guessing in SQL.

From the semantic layer, the planner compiles a formal specification and derives its own tests automatically: one row per customer enforces uniqueness; including zero-spend customers requires an outer join against the customer registry; approved purchase amount supplies reconciliation rules against the raw ledger. Because a direct transformation over raw purchases serves this first consumer cheaply within its five-minute SLA, the engine builds a simple, direct pipeline.

Now what happens a month later when a support agent asks for the same metric over 90 complete UTC days?

In today’s stack, a coding copilot happily spins up a duplicate pipeline scanning raw purchases all over again. In a self-organizing stack, the planner looks past the physical tables to the specifications underneath. It sees that customer_spend_30d and the new 90-day request share the exact same DNA: same USD purchase definition, same customer identity rules, and—crucially—the same complete UTC day boundaries (since rolling windows ending at the current second couldn’t share an aggregate).

Without a human touching a keyboard, the system adapts:

1. It proposes a shared customer_spend_daily intermediate with 90 days of history.
2. It confirms source history exists, checks access policies, and backfills the daily rollup.
3. It creates the 90-day support asset on top of the daily table, and quietly rewires the existing 30-day sales asset to read from the new daily intermediate.

The Physics of Reuse (and Its Limits)

Consolidation is not a blind mandate. A different currency policy, customer definition, access scope, or fiscal calendar requires a separate implementation. Similar column names and matching sample rows never prove equivalence—only formal definitions can.

Even valid sharing carries a thermodynamic cost. A shared dependency widens the blast radius of a failure, and refreshing a heavy intermediate every five minutes to satisfy one real-time consumer might cost more than running two separate pipelines.

To avoid thrashing, the planner acts like a damped control system. It measures actual compute costs, requires a minimum expected savings threshold before reorganizing, and caps how often an asset can be refactored. When it finds true duplicates, it merges their physical implementation behind both existing interfaces until dependents migrate.

Turning the DAG Inside Out

Parts of this vision already exist. Kubernetes popularized the reconciliation loop (desired vs. actual state). Asset-oriented orchestrators shifted our mental model from task schedules to data assets. Warehouse dynamic tables and materialized views automate incremental refreshes.

Yet every one of these tools still expects a human to author the graph. The self-organizing stack moves graph authorship itself into the orchestration engine.

To do this safely, the runtime maintains a versioned view of Desired State (the outcomes and SLAs consumers have contracted for) and Observed State (the implementations, lineage, watermarks, and health that actually exist). When a new request, a failed check, or an expired commitment opens a gap between the two, the engine proposes a graph mutation.

An LLM can help parse intent and draft candidate SQL, but a model’s confidence never authorizes a graph change. Drafts are confined to deterministic planners, type checks, access gates, cost controls, and independent verification.

Adversarial Verification and Atomic Cutover

Autonomy without verification is just automated chaos. Before the engine activates that shared daily spending table, it must prove the change won’t break the 30-day consumer’s contract.

A self-organizing stack verifies against semantic invariants, not just syntax. A reconciliation check against the approved purchase definition immediately exposes the double-counted revenue and traces it to the proposed daily dependency. The engine revises the join to respect validity intervals and reruns verification—comparing old and new implementations on identical input snapshots while independently checking business invariants. An LLM that writes both a calculation and its test cannot certify its own assumptions.

Once verified, activation must handle concurrency. If a new consumer registers a dependency on the 30-day asset while testing is underway, the evidence is stale. To catch this, the coordinator binds each activation to strict revision numbers inside a transactional registry—staging the assets, verifying that no contracts shifted during testing, and atomically flipping the active pointers. If a defect ever slips through, the recovery record names every downstream consumer that read bad data during the exposure window.

Humans Own Meaning—and the Decision Record

If the orchestration engine maintains the physical model, where do people go to understand the system? To the decisions, not the schemas.

The engine doesn’t guess. It escalates one surgical question to the domain owner, showing how each definition groups customers, which existing assets each can reuse, and what each costs. The human chooses the meaning; the engine scopes that choice to the authorized domain and derives the graph.

Every clarification, specification, proposal, verification report, and deployment is linked into an immutable decision log. Every requirement on a live asset points directly to its causal origin.

Debugging at 3:00 A.M. and Metabolic Cleanup

When this breaks at 3:00 a.m., how do you debug a graph you didn’t draw? Start from broken commitments, not failed tasks.

In a traditional orchestrator, you debug by reading the DAG because the DAG is the design. Here, the design lives in specifications and decisions. Instead of tracing a red task box to see if anyone cares, the operator’s console answers four questions in order: which commitments are unmet, which consumers they affect, which recent graph changes touched them, and what repair the engine is testing.

Just as importantly, a living stack cleans up after itself. In biology, bone grows where stress is applied and dissolves where load disappears. Data warehouses currently have no metabolism—they only accumulate mass.

In a self-organizing stack, when the sales application eventually drops its 30-day spend subscription, the engine retires customer_spend_30d while keeping the 90-day support asset alive. It weighs explicit contract expiration, compliance retention policies, and reconstruction cost. It can demote a physical table to a virtual view, freeze compute while keeping history, or dissolve an intermediate table entirely once its last shared dependent is gone.

Building the Platform for the Agentic Era

This design doesn’t remove data engineers; it elevates what we author. We stop acting as human compilers translating requests into brittle DAGs, and start designing the boundaries and laws of physics the runtime must obey.

If you build data platforms or orchestration engines, start here:

1. Make consumer commitments first-class. Record who depends on each asset and what was promised, separately from the SQL that fulfills it.
2. Invest in the semantic layer before the planner. An engine can reorganize only what it can prove equivalent from formal definitions.
3. Build adversarial verification. Independently check outputs against approved definitions, grade the evidence, and never let an agent grade its own work.
4. Treat decisions as data. Capture every human clarification with its authority, scope, and links to the assets it shaped.

Today, a pipeline DAG is where a person writes down the data architecture. In the self-organizing stack, the orchestration engine keeps writing it. A new request creates the graph, an overlap reshapes it, a failed commitment triggers a repair, and an expired commitment simplifies it. Humans author the meaning; the engine authors the graph.

That is the orchestration engine I want for the agentic era.

Introducing the Guest: #5 Josh Wills

Josh Wills is a software and data engineer with 25 years of experience. At Google, he worked on the ad auction system and led the analytics infrastructure behind Google+. As head of data science at Cloudera, he founded the Apache Crunch project and co-authored O’Reilly’s Advanced Analytics with Spark, and he went on to build and lead Slack’s data engineering team. He’s also the original creator of the dbt-duckdb adapter.

Since 2024, Josh has been a Member of Technical Staff at DatologyAI, which helps teams train better models, faster and smaller. There he builds tools that automatically select the best data for training deep learning models, along with the distributed pipelines that process it at trillion-token pretraining scale. We go into more detail on what it takes to work with datasets that gigantic.

DuckDB Yes, but also Kubernetes Disk Abstractions

As many of you might know, Josh was the initial creator of dbt-duckdb, so I asked him if he still uses dbt and, more importantly, how much DuckDB.

His answer was that everyone uses it: “Everybody uses DuckDB in some capacity. I feel like anyone who knows about DuckDB uses DuckDB for something. Everyone has their own specific use case for it”. He is using it less for his specific pipelines at work, as they have huge datasets, text data, not classical datasets: e.g., 30 TB is tiny. He uses Spark or Ray. He does much of the processing on text and multimodal data (time series, images, etc.), not much classical relational data in his day-to-day.

The use case for DuckDB he uses a lot is reading Parquet metadata that sits on S3, as the above data pipelines “throw off enormous amounts of Parquet metadata, which is still substantial but much smaller, on the order of 100 GBs”. Information about runs, when a dataset was last used to train a model, how much he pays to store it in S3 for indefinite periods. He usually asks his agents to read that on his dev box on EC2, which he runs these commands on, to cut down on transfer times, just for speed.

“We Lost a Whole Generation” of Data Infra People, Retired 2022, AI Pulled Him Back

When talking about what has changed since he worked at Google as a staff engineer (2007–2011) and led data engineering at Slack (2015–2019), and how data engineering workloads differ today with AI, he said Snowflake is great. Still, we do not have many people anymore who know how the data is laid out on disk.

But not for his size of workload. Josh works with such big data that we normies can barely fathom, and that’s why he uses lots of Kubernetes jobs and workloads. He likes Apache Celeborn (Pronunciation: spelled Celeborn, pronounced “Keleborn”), which abstracts the disks (not needing to know where they physically come from), because in Kubernetes you still do that manually, as Kubernetes is not really cloud-abstracted, he says:

Kubernetes is fantastic in that it’s in theory abstracted away from an individual cloud, but in practice it’s not, because where does your disk come from? If you’re on AWS or GCP you can use an EBS-like service, but if you’re running bare metal, that doesn’t exist the same way.

Celeborn has something called push-based shuffle write, where mapper nodes skip local disk storage, ideal for cloud-native architectures, which lets you separate storage and compute, so

The Spark jobs don’t need to worry about where their disk comes from anymore, from a shuffle perspective. There’s the shuffle service, no matter how much data you’re going to shuffle. You have your local disk, and then you have your shuffle service for all your other disk needs.

How Much Does the Model Matter to You?

When asked about the models and how much they matter, Josh said for him it’s like the iMessage blue bubbles vs. green bubbles. Android phones are fantastic, but he wants the blue bubbles. And Josh’s prediction is that all the models will become competent, so the real question becomes:

which one you like and enjoy hanging out with

In this interview, he added that it’s also the way it communicates. An interesting insight, he said, as someone who works on building models all day:

the fact that Opus 5 is so bad, it deeply indicates to me that we literally have no idea what we’re doing at all when it comes to training these models.

How to Code with Agents These Days

Josh says:

[..] a joke that I want to start my own RL environments company where it’s just me teaching the models how not to write absolutely garbage data pipelines. Because I use agents to write all of my code, with very, very few exceptions. And yet I still find myself deeply unhappy with the data pipelines it writes.

How to Get Fast Feedback Loops with Agents?

Josh says AI wins where there’s a large training model and fast responses, because if it’s not in the training data, it’s slow and it needs to do a lot of stuff. He says: “Any sort of environment in which the models have highly reliable training data with fast feedback mechanisms, they’re just going to dominate. Absolutely going to dominate. You see this with math, you see this with front-end engineering, any RL environment where there is a fast feedback mechanism.”

And that’s exactly what’s missing in large-scale data pipelines today:

What’s tricky about data pipelines, at least at a large scale, is that you don’t actually have that fast feedback mechanism available to you, because running a giant pipeline can take a long time and a lot of computers.

Feeling the Tuples Flowing through the Pipelines, a Gut Feeling

Josh, with his years of experience, has built a gut feeling:

Through years and years of suffering and writing gigantic pipelines, I can look at a pipeline and it kind of feels like something to me. I can feel the tuples flowing through it, because I have a mental model of how this is going to go.

Josh describes an aesthetic aspect of data pipelines:

I have, weirdly, a kind of aesthetic sensibility when it comes to data pipelines. A data pipeline can be beautiful to me. It can be elegant, well designed, thoughtful. That makes me want to look, in the way other people would visit an art museum, or read math proofs because they find them beautiful.

The Cost Aspect, Literally Lighting Money on Fire

When talking about cost, Josh says that:

“the models might waste time on the most pedantic, stupid checks for errors that are simply not possible given my knowledge of the structure of the upstream data sources.” “Literally lighting money on fire”

The Job of ‘Emergency Exception Handler’

He mentions that in his job, because the models haven’t learned everything yet, he is basically like a pilot who usually flies on autopilot, but in case of emergency, he is there to fix it or take over.

What Is the Tooling He Uses & How Agents Ease His Life at Work

When asked how he works or reviews code, he said: mostly giving feedback, like a staff engineer does. His life as a senior technical IC has been trending towards that for a very long time, he says. He primarily gives feedback. That’s his primary job. Interviewing people, reviewing design documents, and less hands-on, with very few exceptions.

He likes to work on high-demand, high-urgency work that forces him to create. This is back to the ’emergency exception handler':

If there’s a broken-ass data pipeline and it has to run right now, because a customer has a training job coming up and the data has to be ready for it. That’s the primary value I provide.

What Josh Likes about Agents: No Feelings and the Caffeine Dial

Josh also revealed that he likes working with agents because agents have no feelings. He can give agents feedback on demand, force things to be created, he says:

I don’t have to be very nice to the agents.

He can just say things:

I don’t have to care about their feelings or their career development, because they’re going to cease to exist when I’m done with this coding session. I can be like: this is bad and you should feel bad. Ctrl-C, you’re dead, I’m going to start over with someone else.

No More Unit Tests!

He also likes to automate most of the boring work. Who wants to do one more database migration? Or fix “flaky unit tests”? He likes to do the higher-level strategic stuff, which is how people end up becoming investors or product managers, he says.

I have an agent whose whole job is just to watch for flaky tests and fix them. That’s it, that’s all it does. Database migrations? Absolutely not. I have an agent that does database migrations. I have automated away the shittiest, lowest-value, most unpleasant parts of my life, and I am here for it.

Decisions Made Are What Is Left, and Communicating Why Is Key

It’s really the decisions we need to communicate. The decisions build the shared understanding, the choices we make, the trade-offs. That’s still the meat of engineering work.

Is Data Engineering Automated Away with Agents?

Josh says clearly that data engineering is not going away. For the same reason it hasn’t gone away for so long: the fundamental problems won’t go away. We’re still solving the problem of materializing views and caching!

I don’t see data engineering going away in any way, shape or form, even in this world. Aside from the fact that the RL environment problem makes it unusually difficult for the agents to be good at running these very long pipelines, the fundamental problem of data engineering is the same problem it’s been my whole career, and 25 years before I started working. It’s the materialized view problem.

It’s the two hard problems in computer science, right? Cache invalidation and naming things. And the agents still suck at them because they’re legit hard.

Humility and Burnout

It helps to stay humble, as he says he is very good at it, telling his family:

I am simultaneously an idiot and also among the best in the world at what I do.

Conclusion

One main takeaway from this conversation is that data engineering is the cache invalidation problem, just done in a batch-processing context. That’s important: when done right, agents dominate because of a fast feedback loop, like SQL with its explain plans or math. Gigantic Spark and Ray pipelines that run for hours across hundreds of machines don’t have that cycle yet. That’s why Josh still ends up as the emergency exception handler, and why others can vibe code a Databricks job that costs $200k a day.

What’s interesting is how little the model itself matters to him. It’s more about design and feel, e.g., blue bubbles vs. green bubbles: pick the one you enjoy hanging out with, switch when you don’t like it anymore, or hand off the flaky tests and database migrations to an agent. What’s left is what was always the hard part of data engineering: making the decisions and communicating the trade-offs.

prompt_jev() now works on images

Three weeks ago we brought prompt_jev() to MotherDuck, a week after TypeSafe announced Jev. You ask a closed question in plain English, pick the shape of the answer (yes/no, one choice from a list, a score), and get a typed result with a confidence score, straight from SQL. We showed five use cases on text columns.

Today, with TypeSafe's Jev 1.14, prompt_jev also takes images. Store them in a BLOB column, ask your questions, and the answers come back as columns you can filter, join and GROUP BY with the rest of your data.

And yes, we also asked seven models the only question that really matters: hot dog or not hot dog? On hotdogbench.com, Jev isn't the top dog, but it's the first one to the bun.

Try it in one query

Hugging Face hosts lots of public image datasets as Parquet, with each image stored as bytes. Read them with hf:// and hand the bytes straight to Jev:

SELECT image.path AS file,
       prompt_jev([{name: 'dish', image: image.bytes}], 'Is `dish` a dessert?') AS is_dessert
FROM 'hf://datasets/ethz/food101/data/validation-00000-of-00003.parquet'
LIMIT 5;

Each row gets a probability between 0 and 1. These five photos are beignets, so they score high.

How fast, how accurate, how cheap?

We used the same dataset: Food-101, labeled photos of 101 dishes. One question per photo, "Which dish is shown?", with all 101 dishes as the allowed answers, asked to Jev, Gemini, GPT and Claude on the same 1,010 photos (10 per dish).

We can score accuracy here because Food-101 has the right answer for every photo. On your own data you won't have that, so the real question is which answers you can trust.

The big difference between Jev and a standard LLM is the confidence score. Every answer comes with one, and on this benchmark it reflects how often Jev is actually right. If you keep only the answers at 0.8 or more (WHERE jev.confidence >= 0.8), Jev is right 97.7% of the time, on 80% of the photos.

This of course begs the question - what if we combine Jev with another model to a cheap first pass and then a secondary cleanup loop?

Notice how we can achieve big gains in accuracy for relatively small increases cost compared to using a System Two LLM for the entire job.

Getting your images in

If your images sit in S3, one query loads them into a BLOB column (with an S3 secret in place):

CREATE TABLE images AS
SELECT filename AS path, content AS image
FROM read_blob('s3://my-bucket/photos/*.jpg');

Jev needs each side of an image between 280 and 1,568 pixels. Bigger images need a resize first: a Flight (Python that runs on MotherDuck compute) with Pillow does it. The docs have a ready-to-use example that reads from S3, shrinks anything too big and writes the result back as a BLOB.

Or skip the code and ask the MotherDuck MCP server from Claude or your agent of choice:

Load the JPEGs under s3://my-bucket/photos/ into a new table photos.main.images, one row per file with the image as a BLOB. Resize anything longer than 1568px on its longest side, skip images under 280px on their shortest side, and run it as a MotherDuck Flight. Tell me how many images landed and how many were skipped.

Five centuries of art in one GROUP BY

We took the Metropolitan Museum of Art's open access collection, half a million CC0 catalog records, and kept every public-domain painting, print, drawing and photograph with an image: about 77k works, loaded as 600px BLOBs. Then we asked 14 questions about every image in one SQL query. Here are 4 of them:

SELECT object_id,
       prompt_jev(
         [{name: 'art', image: image}],
         questions := {
           smile: {type: 'choice',
                   instructions: 'If a human face is clearly visible in `art`, what is the expression of the most prominent face?',
                   criteria: ['no_clear_face', 'neutral_or_serious', 'closed_mouth_smile', 'smile_showing_teeth', 'laughing']},
           dog: {type: 'noul', instructions: 'Is there a dog anywhere in `art`?'},
           dog_box: {type: 'box', instructions: 'the dog in `art`'},
           skull: {type: 'noul', instructions: 'Does `art` show a human skull or skeleton?'}
           -- plus 10 more: main subject, weather, sunset, drink, food, cat, ...
         }) AS jev
FROM images;

Once the answers are stored as columns, they join with the Met's catalog like any other data. When did people start smiling in art? One GROUP BY:

SELECT (floor(o.begin_year / 50) * 50)::INT AS half_century,
       round(100 * count(*) FILTER (WHERE f.smile IN ('closed_mouth_smile', 'smile_showing_teeth', 'laughing'))
                 / count(*) FILTER (WHERE f.smile <> 'no_clear_face')) AS pct_smiling
FROM features f  -- Jev's answers, one column per question
JOIN objects o USING (object_id)
WHERE o.begin_year BETWEEN 1400 AND 1949
  AND o.end_year - o.begin_year <= 25  -- only works the Met dates within 25 years
  AND NOT f.rejected
GROUP BY ALL
ORDER BY half_century;

Almost nobody smiles before 1600! Many reasons for that, but that's for another blog.

Get started

Images are now just another column in MotherDuck. Load your product photos, scans, screenshots or camera-trap pictures as BLOBs, ask your questions, and join the answers with the rest of your data.

Everything you need is in the prompt_jev() docs.

Snapshots, time travel and writable branches for pipelines, experiments, reproducible reports and more.

A data import needs validation. A report needs last month’s numbers. A migration needs realistic test data. An analyst wants to compare two transformations, and an agent needs somewhere to try its own.

These workflows share a requirement: keep a known database state, then inspect it or work independently from it.

I built duckdb-differential to make that available directly from SQL. It adds snapshots, time travel, writable branches, clones and restore to native DuckDB databases. Versions share unchanged data. Everything works locally; optional S3 publication lets other machines query a retained version or recover it into a writable database.

The extension is experimental, targeting DuckDB 1.5.6 on Linux and macOS. Let’s walk through several uses with one small database. Run the local examples in order in the same session, using an unused absolute directory for the repository:

INSTALL differential FROM community;
LOAD differential;
SET differential_repository = '/absolute/path/differential-demo';

ATTACH 'differential:retail' AS retail;
CREATE TABLE retail.orders (
    order_id INTEGER PRIMARY KEY,
    customer VARCHAR,
    amount DECIMAL(10, 2)
);
INSERT INTO retail.orders VALUES (1, 'Ada', 40.00), (2, 'Lin', 60.00);
CALL differential_create_snapshot('retail', name => 'baseline');
-- Snapshot 1: two orders, total 100.00

A snapshot retains the database’s checkpointed state. A branch starts a writable continuation from that state. A clone starts a separate database identity and snapshot history. Readers can keep querying the original while other work moves forward.

Validate an import before adopting it

Suppose a daily feed contains an order whose amount was parsed with the wrong sign. Load it on a branch, where validation can catch the problem before it becomes part of the accepted dataset:

CALL differential_create_branch('retail', 'import_check', snapshot => 1);
ATTACH 'differential:retail' AS incoming (BRANCH 'import_check');
INSERT INTO incoming.orders VALUES (3, 'Jo', -25.00);

SELECT order_id FROM incoming.orders WHERE amount < 0;  -- 3
SELECT sum(amount) FROM retail.orders;                 -- Still 100.00

After checking the source, we correct the value to 25.00. A real pipeline could reload the affected batch after fixing its parser. Validation might check totals, missing keys, duplicate records or domain-specific rules:

UPDATE incoming.orders SET amount = 25.00 WHERE order_id = 3;
SELECT count(*) AS invalid_orders FROM incoming.orders WHERE amount < 0;
-- 0
SELECT count(*) AS orders, sum(amount) AS total FROM incoming.orders;
-- 3 orders, 125.00

CALL differential_create_snapshot(
    'incoming', name => 'validated_import', message => 'Daily feed validated'
);
-- Snapshot 2
DETACH incoming;

In this controlled workflow, main has stayed unchanged. We can adopt the candidate’s entire database state with restore:

DETACH retail;
CALL differential_restore('retail', 2, request_id => 'adopt-daily-import');
ATTACH 'differential:retail' AS retail;
SELECT sum(amount) FROM retail.orders;  -- 125.00

Restore requires a detached target branch, preserves its replaced state and creates a new snapshot of the selected contents: snapshot 3 here. There is no automatic branch merge. If another workflow has advanced main, reconcile those changes explicitly with SQL before adopting a candidate. Restore selects a whole database state; it does not combine diverging histories.

Reproduce a report after the data changes

A report can record its input snapshot number and query that version again later. Attach it read-only when several queries should share the same input:

ATTACH 'differential:retail' AS report_data (SNAPSHOT_VERSION 3);

INSERT INTO retail.orders VALUES (4, 'Ada', 50.00);
CALL differential_create_snapshot('retail', name => 'later_sales');
-- Snapshot 4

SELECT sum(amount) FROM retail.orders;       -- 175.00
SELECT sum(amount) FROM report_data.orders;  -- 125.00
SELECT sum(amount) FROM retail.orders AT (VERSION => 3);  -- 125.00
DETACH report_data;

The live database now has another order, but the report’s input remains fixed. That is useful for monthly reporting, explaining a changed metric, and reproducing a bug against the data that triggered it. Snapshot numbers are scoped to a database: record the database identity alongside the version and report code.

Compare analytical scenarios

An analyst can model a pricing change on a branch without changing accepted orders. Here we deliberately start from the report’s three-order dataset:

CALL differential_create_branch('retail', 'discount', snapshot => 3);
ATTACH 'differential:retail' AS scenario (BRANCH 'discount');
UPDATE scenario.orders SET amount = amount * 0.90;

SELECT 'baseline' AS scenario, sum(amount) AS total
FROM retail.orders AT (VERSION => 3)
UNION ALL
SELECT 'discount', sum(amount) FROM scenario.orders;
-- baseline: 125.00; discount: 112.50

CALL differential_create_snapshot('scenario', name => 'discount_10pct');
DETACH scenario;

Develop feature datasets on fixed inputs

A feature-engineering experiment can retain both its source data and derived tables, then label the result with its recipe:

CALL differential_create_branch('retail', 'feature_trial', snapshot => 3);
ATTACH 'differential:retail' AS features (BRANCH 'feature_trial');
CREATE TABLE features.customer_features AS
SELECT customer, count(*) AS order_count, sum(amount) AS total_spend
FROM features.orders GROUP BY customer;

SELECT count(*) FROM features.customer_features;  -- 3
CALL differential_create_snapshot(
    'features', name => 'customer_spend_v1',
    extra_info => '{"input_snapshot":3,"recipe":"customer_spend_v1"}'
);
DETACH features;

Test a migration without changing the working database

A clone gives a test run its own database identity. It starts with snapshot 1 in its own history and shares the source’s unchanged payloads:

CALL differential_clone_database('retail', 'migration_test', snapshot => 3);
ATTACH 'differential:migration_test' AS test_db;
ALTER TABLE test_db.orders ADD COLUMN source VARCHAR DEFAULT 'import';

SELECT count(*) FROM test_db.orders WHERE source = 'import';  -- 3
SELECT count(*) FROM retail.orders;                         -- Still 4
DETACH test_db;

CALL differential_restore('migration_test', 1);
ATTACH 'differential:migration_test' AS test_db;
DESCRIBE test_db.orders;  -- Original three columns; no source column
DETACH test_db;

Give data agents independent attempts

An agent can use exactly the same SQL primitives as a notebook or pipeline. A controller might create a branch, expose it to one worker, inspect its candidate snapshot and decide whether to retain it:

CALL differential_create_branch(
    'retail', 'agent_attempt_42', snapshot => 3, request_id => 'attempt-42-branch'
);
ATTACH 'differential:retail' AS agent_work (BRANCH 'agent_attempt_42');

-- Example worker transformation: normalize customer labels.
UPDATE agent_work.orders SET customer = upper(customer);
SELECT count(*) AS orders, sum(amount) AS total FROM agent_work.orders;
-- 3 orders, 125.00; label correctness needs its own checks

CALL differential_create_snapshot(
    'agent_work', name => 'agent_candidate_42',
    message => 'Candidate for review', request_id => 'attempt-42-snapshot'
);
DETACH agent_work;

Share a validated dataset with another machine

S3 adds a distribution path to these local workflows. Create a database with an S3 DATA_PATH, and explicit snapshot creation exports synchronously by default. Later exports reuse previously uploaded chunks.

ATTACH 'differential:retail_release' AS published (
    DATA_PATH 's3://my-bucket/differential-demo/', REGION 'eu-central-1'
);
CREATE TABLE published.orders AS
SELECT * FROM retail.orders AT (VERSION => 3);

SELECT snapshot_id, export_state, export_locator
FROM differential_create_snapshot('published', name => 'report_dataset');
-- snapshot_id = 1; export_state = 'complete'; save export_locator
DETACH published;

On another machine, use a fresh session and repository:

ATTACH 'differential:s3://my-bucket/differential-demo/heads/retail_release/main'
AS published (REGION 'eu-central-1');
SELECT count(*) AS orders, sum(amount) AS total FROM published.orders;
-- 3 orders, 125.00
DETACH published;

Recover a writable database from a completed export

In the reader session, substitute the hash from the saved export locator:

CALL differential_recover_export(
    's3://my-bucket/differential-demo/descriptors/<sha256>',
    'retail_recovered', region => 'eu-central-1'
);
ATTACH 'differential:retail_recovered' AS recovered;
SELECT sum(amount) FROM recovered.orders;  -- 125.00
INSERT INTO recovered.orders VALUES (4, 'Ada', 50.00);
SELECT sum(amount) FROM recovered.orders;  -- 175.00
DETACH recovered;

How Differential stores versions

Underneath these workflows, DuckDB still handles SQL, transactions, indexes, compression and its catalog. Differential handles file operations, storing immutable chunks and their mappings in a local repository. Embedded SQLite coordinates metadata and default payload storage; no separate service is needed.

Import an existing DuckDB database

For your own existing .duckdb file, checkpoint and close it, then import it using an absolute path:

CALL differential_import_database('/absolute/path/existing.duckdb', 'imported');
ATTACH 'differential:imported' AS imported;

Project status

The release remains experimental. Try one workflow: validate an import, preserve a report’s inputs, test a migration, or give an experiment its own branch.

Grafana Tempo 3.1 makes Kafka-backed tracing easier to run with TLS, additional authentication methods, rack-aware reads, and configurable producer compression. Query-based redaction can permanently remove sensitive trace data without enumerating trace IDs, while sampling-aware TraceQL metrics improve analysis of incomplete telemetry. Operators should use redaction dry-runs and complete the upgrade before applying time-bounded deletions.

AI in Production: Panellists Highlight Silent Failures, Harness Engineering, and Agent Governance

During a recent InfoQ webinar titled "AI in Production: What Breaks, What Works, and Who Approves It?", a panel of senior engineering practitioners met to dissect the real-world operational challenges of deploying agentic systems. The discussion was moderated by Hien Luu and featured Zichuan Xiong and Prem Chandrasekaran from ThoughtWorks, privacy specialist Katharine Jarmul, and financial AI practitioner Lan Chu.

Luu opened the session by noting three core drivers: AI fails differently from traditional software by generating convincing inaccuracies rather than crashing; coding agents are generating production code faster than humans can review; and sensitive data has new places to leak through prompts, context windows, and retrieved documents.

Xiong highlighted the widespread issue of semantic drift in LLM pipelines. He described how text-to-SQL translation agents frequently flatten domain-specific concepts, such as treating "member" identically across sales and customer support domains, leading to subtle, hidden errors in downstream business analytics that pass standard tracing.

Similarly, Chu recounted a critical failure caused by embedding drift in financial compliance systems. After deploying an agent to block prohibited investment advice based on vector similarity thresholds, an unannounced background update to the underlying embedding model altered the vector distance distribution. This caused severe false positive and false negative spikes in live traffic while all infrastructure health checks remained completely green.

Additionally, Chandrasekaran highlighted how RAG pipelines can inadvertently retrieve sensitive documents, while Jarmul noted that models inherently memorize training data and can be used to de-anonymize information or expose API keys. Chandrasekaran also referenced the GitSpawn vulnerability, showing how malicious repository configurations can execute unauthorized code during routine commands.

As coding assistants generate an increasingly massive volume of production code, conventional human code review processes face unsustainable bottlenecks. Chandrasekaran, tech and business services lead at ThoughtWorks, emphasized that line-by-line manual code reviews cannot scale alongside high-velocity agent outputs. Instead, engineering teams must automate tactical style and syntax checks within CI/CD pipelines, reserving human oversight strictly for high-level architecture, business intent, and non-functional requirements.

Xiong added that teams must shift left to evaluate intent at the harness level before pull requests are generated. Chandrasekaran also highlighted the resurgence of mutation testing as an essential practice. By introducing deliberate code mutations, teams can verify whether automated test suites truly evaluate underlying logic or merely satisfy surface-level code coverage metrics.

When evaluating agentic systems, Chu stressed that evals must be treated as permanent, living infrastructure rather than static pre-release checklists. Effective evaluation requires continuous online tracing at the span level, log filtering, and using LLMs to categorize failure patterns, enabling teams to feed production edge cases back into offline benchmark suites.

When evaluating agentic systems, Chu stressed that evals must be treated as permanent, living infrastructure rather than static pre-release checklists. Effective evaluation requires continuous online tracing at the span level, enabling teams to capture real-world user interaction patterns and systematically feed production edge cases back into offline benchmark suites.

To address privacy and security risks, Jarmul cautioned against relying on prompt engineering for system defence. She advocated for systematic red teaming, continuous threat modeling, defining strict functional scopes for autonomous agents, and scaling observability to handle expanded event volumes. To limit the blast radius of autonomous agent actions, Chandrasekaran advised treating every AI agent like a new engineering hire.

Organizations should grant agents distinct non-human identities, implement tiered access controls distinguishing read-only operations from reversible write actions, version third-party Model Context Protocol (MCP) dependencies, and strictly isolate API secrets outside the agent's runtime environment in sandboxes. Ultimately, while engineering, security, and privacy teams validate safety guardrails, deployment approval remains a strategic business decision.

To limit the blast radius of autonomous agent actions, Chandrasekaran advised treating every AI agent like a new engineering hire. Organizations should grant agents distinct non-human identities, implement tiered access controls distinguishing read-only operations from reversible write actions, version third-party Model Context Protocol (MCP) dependencies, and strictly isolate API secrets outside the agent's runtime environment. Ultimately, while engineering, security, and privacy teams must validate safety guardrails, deployment approval remains a strategic business decision.

Large GPU jobs fail for many small infrastructure reasons, so reliability has to be continuous rather than reactive. Netflix built a layered system that validates nodes before jobs start, monitors hardware during runs, and automatically drains, reboots, resets, or replaces bad machines. The result is more usable GPU capacity and fewer long training or inference runs lost to platform faults.

Starting today, the Claude Platform exports OpenTelemetry (OTel) traces natively from Claude Managed Agents, the Messages API and the Claude SDKs, in public beta. New Relic AI Monitoring reads those spans where they land. Its Normalize on Read architecture queries them straight from the Span table, so nothing gets duplicated at ingest, and, when your application passes its trace context (the Claude SDK does this for you), each Claude span sits in the same trace as your APM data.

The same spans can feed New Relic AI Evaluation, in public preview. With Full content turned on, it screens live Claude prompts and completions for prompt injection, PII leakage and toxicity.

Until now, an agent run was split between consoles. Your services ran the custom tools, and the Claude Platform ran the model and, with Claude Managed Agents, the agent loop.

One Trace From Your Service to the Model

Add New Relic as a destination in the Claude Console. Then set up tracing in the Claude SDK, as Anthropic's OpenTelemetry guide shows, and point your application's OpenTelemetry exporter at New Relic. When your code calls the SDK inside its own spans, the SDK passes your trace context to the Claude Platform, so the platform's spans nest under yours.

• Claude Managed Agents: Every session request, agent turn, model request, tool use and outcome evaluation.
• Messages API: Each message request with its model requests and compactions, plus any server or MCP connector tool use.
• Claude SDKs: Your application's requests and custom tools, for Python, TypeScript, Go, Java, C#, PHP and Ruby.

Spans follow the OTel GenAI semantic conventions, which AI Observability already reads, so there's no attribute mapping to maintain.

Debug Agents in the Context of Your Whole Stack

Say a support agent takes 40 seconds to issue a refund. The model is rarely the whole story. AI Observability shows the model replying quickly, then your service spending 36 seconds running the lookup_order tool. That tool called your orders API, which was waiting on a database query that slowed down after last night's deploy. Because Claude's spans share a trace with your APM data, you can follow the trail past the agent, which LLM-only tools can't do.

From Symptom to Root Cause in One View

• Agent Trace Waterfall: Model requests and tool uses on one timeline inside your own service spans.
• Agents as Entities: Each Claude Managed Agents agent gets its own entity, with latency and error rate you watch like any service.
• Conversation Replay: Step through a session message by message, with prompts and responses beside timing when Full content is on.
• Alerts and Dashboards: It's New Relic data, so NRQL alerts and your existing dashboards work on it.

Govern Tool Use

With Full content, each tool span carries the tool's arguments and result, which gives teams a record of what each agent touched. Choose Full content to capture prompts and responses, or Metadata only to keep timing and identifiers, names. Route Claude traffic into New Relic AI Evaluation and that record gets screened as it happens.

Start Observing Your Claude Agents Today

An organization admin adds New Relic as a destination on the OpenTelemetry settings page of the Claude Console, picks their New Relic region (US, EU or JP), enters an ingest license key, and chooses which workspaces send traces. Spans arrive within about a minute, with no code changes on the API side.

Claude Platform tracing is in public beta for the first-party Claude Platform. Amazon Bedrock and Google Cloud Vertex AI support will be coming soon.

Today, we’re introducing Scout 1.0, Datadog’s first AI model specialized for investigating production issues. Scout powers Bits Investigation, our AI SRE. We trained Scout to reduce inference cost so that investigations are cheap enough to run an order of magnitude more often and earlier in an incident’s lifecycle.

Key highlights include:

• Scout achieves a better price-performance curve on our target scenarios when compared with general-purpose frontier models. Scout 1.0 medium matches GPT-6.1 Sol high and Claude Opus 5.5 high at 3–8× lower estimated inference cost, and performs comparably to Fable medium and Astra medium at 12× and 19× lower cost, respectively. With test-time scaling, Scout 1.0 xhigh matches Fable xhigh at 4× lower cost.
• We built Scout using our in-house distributed reinforcement learning infrastructure, and relied extensively on real historical incidents and telemetry data to build high-quality training simulations that don’t contain any customer data. For more technical details, see our full report.
• Datadog engineering teams and a small group of customers in a closed preview are already using Scout to investigate production alerts. Sign up for the preview to try it in your environment and provide feedback before general availability.

Bits as a first responder for every alert

Our goal is for Bits to serve as an always-on first responder, gathering evidence and identifying likely causes before an engineer steps in. Each Bits investigation involves forming hypotheses, querying telemetry, and deciding whether the evidence supports a conclusion. Those steps require repeated model calls. By reducing a model’s inference cost, we can give teams more room to run investigations across their environments. Scout’s efficiency makes it practical to extend support to more alerts and investigate complex issues in greater depth, enabling greater breadth of coverage, reducing the burden of on-call work, and freeing more time for development.

Lower inference cost also makes it practical to spend additional computation on harder or higher-impact problems. For instance, Scout 1.0 xhigh uses more computation per incident to improve investigation quality, and this added investigative depth reduces engineering workload and pressure during even the highest-stakes incidents.

Training and evaluating Scout for SRE investigations

We built Scout 1.0 on GLM-5.3 Flash and post-trained it using reinforcement learning in investigation simulations. We use historical incidents and telemetry from real alerts to build realistic simulations with known causes. Scout practices using tools modeled on Bits Investigation to gather evidence and test competing explanations. Its training rewards finding the cause and supporting its conclusions with evidence.

We also built our own training infrastructure on top of open source tools, with the simulation, evaluation, and model-training systems needed to run reinforcement learning at scale.

To test whether those skills transfer to real incidents, we built AlertEval. Datadog engineers have curated thousands of evaluation points through our incident-response workflow. AlertEval draws on that work, combining real alerts, archived telemetry, and root cause explanations written by engineers.

We are building Scout and Bits Investigation together, training the model for the tools Bits uses and improving those tools based on what we learn from its investigations.

We have also evaluated Scout on SREGym, a third-party benchmark, to test its performance outside AlertEval. We again have found that Scout 1.0 medium significantly improves upon the base model, GLM-5.3-Flash, performance, surpassing GLM-5.3 at a more than 4× reduction in cost. Through additional test time scaling, we found that Scout 1.0 high is competitive with the best models on this benchmark, while still maintaining at least 2× cost savings compared to all competitors (10× savings compared to Astra/Fable-class models).

Moving forward, we plan to simulate a wider range of failures and keep improving investigation quality while lowering inference cost. We also plan to extend this approach beyond investigation to help teams autonomously remediate issues to restore service faster. Together, these advances move Bits beyond its role as a first responder and toward becoming the only responder during an incident, resolving issues faster and reducing on-call burden.

Join the Scout 1.0 Bits Investigation preview

Preview customers are already using Bits Investigation powered by Scout on their production alerts. Sign up for the preview to try it in your environment and provide feedback before general availability.

Thanks to everyone who helped build Scout; see our technical report for the full author list and acknowledgments.

*The scores measure agreement with expert reference explanations on a 0–100 scale; they are not percentages of incidents solved. Costs are estimated inference costs per investigation, relative to Scout 1.0 medium. Lower cost appears to the right.

Datadog runs thousands of internal services and has been increasing global footprint year after year. For most of that growth, we treated services uniformly when making deployment and reliability decisions. At our current scale, that approach became expensive. A change destined for production rolls out to data centers sequentially, so deployment time grows with every data center we add. Applying a single strict service level objective (SLO) target across all services can lead to over-investing in some while under-protecting others. It can also lead to reliability work getting spread evenly instead of being concentrated where a failure would hurt customers most.

In this context, we needed to answer a hard question: Which services are actually critical? Knowing that would help us decide how fast to deploy a given service, where to keep SLOs strict, and where to concentrate reliability work. But there was no obvious way to agree on a definition of critical that teams could consistently use. Without an agreement on how to classify them, we looked at where the evidence already existed: our own incident history.

To be clear, this is about customer-facing reliability criticality, meaning how much it affects customers when a service is unavailable, slow, or returns incorrect results. Security, compliance, and data criticality are important dimensions, but were outside of the scope of our initial question.

In this post we will share how we used postmortems to develop our first criticality signal, why we built a system that combines signals, and how we use it in production.

Turning years of postmortems into a criticality signal

Datadog has a strong postmortem culture. Over the years, we have accumulated thousands of postmortems written by engineers, mostly as free text. This archive is one of our richest records of what has degraded the customer experience, but we had never structured it in a way that could answer questions about service criticality.

The idea of distinguishing critical services had come up before, but without a practical way to analyze unstructured text at scale, it stalled. Recent advances in LLM capabilities made it worth revisiting.

Instead of debating whether postmortem data could tell us which services mattered, we ran a quick proof of concept. A large language model (LLM) read several hundred SEV-1 and SEV-2 postmortems, the highest-severity subset of the archive, and extracted which services caused an incident and which were affected by one. The entire run finished in under a day and cost approximately $32.

We validated the extracted names against Software Catalog to confirm that they mapped to real services rather than model hallucinations. A second model then reviewed the first model’s service-name extractions for accuracy before we trusted the results.

This turned out to be a strong signal. If a service is involved in a SEV-1 or SEV-2 incident, it likely has a track record of affecting the customer experience, about as direct a criticality indicator as there is. Because the postmortems already existed, we could extract that signal cheaply and at scale.

But incident history also has gaps. A highly reliable service that has never caused an incident is invisible to this signal, yet it can still be critical even if it has never failed. It can also appear in several high-severity incidents without ever being the component that took the product down. One service in our data appeared in around 10 SEV-2 incidents without causing a single full outage. That gap is why postmortems became one signal among several, rather than the entire criticality system.

Why one signal isn’t enough

Criticality is ambiguous and depends on perspective. A low-traffic service can sit on a critical user journey, while a high-traffic service may degrade gracefully without causing a major disruption. Any individual team has only a partial view, and any single signal captures part of the picture while remaining blind somewhere else.

A service criticality system therefore needs to combine multiple signals and account for the limitations of each. At Datadog, some signals can raise a service’s criticality, while one can only lower it:

• Incidents: The postmortem signal described above. It raises criticality for services that were identified as the root cause of, or directly involved in, past SEV-1 or SEV-2 incidents.
• Traces: Derived from Datadog Application Performance Monitoring (APM) and Real User Monitoring (RUM) error traces, the trace signal identifies services that sit on error paths and connects entry points to critical user journeys. This helps surface services that are implicated in error traffic, including those that have never produced a logged incident.
• Traffic: Measures production traffic volume across Software Catalog and flags services with near-zero traffic as low criticality. Services with meaningful traffic produce no signal and leave the decision to the other inputs. High traffic alone does not prove criticality, so this signal can only lower criticality, not raise it.
• Monitors: Analyzes monitors tagged to a service and identifies whether any notify an on-call rotation through Datadog On-Call. A paging monitor raises criticality. If a service has tagged monitors but none notify an on-call rotation, the signal lowers criticality, with confidence increasing based on the number of monitors. For services without tagged monitors, the signal provides no evidence about criticality.

Additional signals, including dependency mapping, are in development. Each service receives a criticality level and a total confidence score. The current levels are high, low, and unknown, with unknown representing services for which no evidence exists yet. We plan to introduce a medium level as more signals come online.

The confidence score is a heuristic that combines the confidence of each signal. It reflects how much evidence supports the assigned level. The score is primarily a way to evaluate system performance, but consumers can also use it to avoid false positives.

When two independent signals agree, we consider that stronger evidence than either alone. A signal pointing in the opposite direction cannot change the assigned level, but it lowers our confidence in the classification. For example, a service with a history of incidents but almost no production traffic represents a contradiction worth surfacing.

The system is intentionally asymmetric. In the worst case, a false positive means that we treated a service more carefully than necessary. A false negative means we treated a critical service as safe to move quickly. We tune the system to prefer the less expensive error, deliberately tolerating false positives to avoid false negatives, like a customer-facing incident caused by deploying too quickly to a critical API. Additional signals and human overrides will help us reduce those errors over time.

Putting service criticality into production

Once several signals feed into the system, something needs to combine them into a single answer that teams can act on. Previously, teams defined criticality independently, and those definitions naturally drifted apart. Now, every internal team consumes the same classification from a centralized API. Maintaining one definition in one place turns criticality from scattered knowledge into something teams can use to build automation.

Internally, each signal writes its verdict to a shared store keyed by service and signal type. An aggregator then combines those verdicts into the published criticality level and confidence score.

Service owners can override the classification of their service by providing a reason, and the resulting level is reflected in the API. These overrides provide a human correction layer and capture operational knowledge that no automated signal encodes. An override changes the published level, but the underlying signals continue to run and their scores remain visible. This way we can see where the system and the service owner disagree.

How teams use service criticality

Teams are already using these classifications to make several types of decisions. For deployments, the system enables us to deploy non-critical services faster and in tiers across data centers, recovering some of the speed that uniform treatment used to cost.

The Service Criticality system also contributes to pull request auto-merge decisions. An automated system that ships library and dependency updates uses service criticality to determine how quickly a change can be approved and merged. Changes that touch critical services get extra validation or are held back from auto-merge. For example, a routine dependency update on a low-criticality service can merge automatically, while the same update on a service classified as critical is routed to a human first.

Because every classification includes a confidence score, consumers can also decide how much evidence to require before automating an action. A consumer that is comfortable with some risk can act on lower-confidence classifications, while one that wants to avoid false positives can require high confidence before allowing automation to take over.

Apply service criticality to your systems

Knowing which services are critical gives infrastructure teams something concrete to act on. The data isn’t perfect, so we are continuing to add signals that address the gaps in our Service Criticality system, while manual overrides capture what those signals miss in the meantime.

The same approach can work for smaller organizations. A team with fewer services and a handful of postmortems can apply the same multi-signal thinking by combining its incident history, a rough dependency map, and service-owner knowledge instead of relying on a single definition of critical.

The signals behind our system are built on tools you can use right away: Incident Management for postmortems, Software Catalog for service ownership and metadata, and APM and RUM for trace-level signals.

Finding (and Fixing) a Silent Throughput Ceiling in PostgreSQL

“A benchmarking case study on relation extension locks, partitioning, and peak write load”; I gave this talk at PG Pune 2026, a community Postgres event with about 170 attendees, mostly database engineers, DBAs and Postgres enthusiasts. This post is the written version, plus two questions from the audience. Under heavy write load, I ran into a throughput saturation in Postgres. More CPU, more RAM and faster disks did not move it. The servers looked healthy the whole time. Here is how it showed up in my benchmark, what caused it, and the change that gave me 7.2x the throughput on the same hardware.

1. The Setup

I used HammerDB's TPROC-C workload, which is based on TPC-C, against vanilla community PostgreSQL 18. HammerDB is free and open source and is backed by the TPC Council. TPROC-C is its OLTP workload and TPROC-H is its OLAP one. Two numbers come up throughout: NOPM (New-Order Transactions Per Minute) and TPS (Transactions Per Second). I wanted to mimic the traffic of an e-commerce peak, so I used 50 warehouses and 64 virtual users, all inserting rows at once in bursts, into HammerDB's default TPC-C schema (District, Order, Stock, Customer, History). For the baseline, every worker wrote into one unpartitioned schema. That is the worst case for lock contention, because every write goes through a single file:

diset tpcc pg_count_ware 50 
diset tpcc pg_num_vu 64 
diset tpcc pg_partition false 
diset tpcc pg_storedprocs true 
vuset vu 64 
vurun 

2. What The Logs Revealed

Under load, sessions started stalling. The Postgres log told me why:

2026-08-05 07:28:51.695 UTC [71429] LOG: process 71429 still waiting for ExclusiveLock on extension of relation 20153 of database 20032 after 1000.035 ms 

That's the relation extension lock, reported as Lock:extend. It only appeared in the log because the wait went past deadlock_timeout (1000 ms by default). Nobody wrote this message for this problem. Nothing in the extension code says "too many backends are extending this table". The line comes from the Postgres lock manager, which reports any lock wait that runs past deadlock_timeout, whatever the lock is for.

3. The Impact: Creeping Latency

I scaled the virtual user load from 64 to 128 on the unpartitioned schema, basically doubling the clients – expecting throughput to dip a little. It fell off a cliff. NOPM dropped from roughly 400,000 to roughly 52,000. At 128 VUs I saw more than 75 backends queued behind the one extension lock, and the longest single wait was 6.7 seconds. For one insert, that is a very long time to wait for a page. Nothing crashed and I lost no data. What I got was a ceiling, a throughput saturation. It shows up as slow responses and full connection pools right when traffic peaks. That is what makes it dangerous: you don't see it until the worst moment. The monitoring dashboards looked fine. The vCPU sat at 35% and disk latency stayed under 1 ms, yet Scenario 1 was stuck at a flat 3,400 TPS. It was a very calm kind of disaster. Nothing was short of resources, so I had to find out what was holding things back.

4. Under the hood: The Relation Extension Lock

When a table grows, a backend has to append a new page to it, and two backends must never claim the same new block. Postgres prevents that with an ExclusiveLock during relation extension. This isn't a flaw. It's a safeguard, and here's why it has to exist. The lock itself is mundane and is held for a very short time. It only hurts when many backends line up for it at once. Without it, backend A checks the table size, sees block 42 is free and starts writing row X. Backend B does the same check, sees block 42 free too, and starts writing row Y. Both think the block is theirs, and one row can be lost. With it, backend A takes the lock, writes row X to block 42 and releases it. Backend B waits briefly, then gets block 43. The lock turns "check size, then append" into one step, so both rows survive. So any fix has to keep that guarantee and can't work around it.

5. Why Hardware Scale-up Fails

My first instinct was to throw hardware at it. I re-ran the same benchmark with more vCPU and faster NVMe. Throughput changed by 0%. Not a little. Zero. The database did not care how nice my servers were. The ceiling is a software lock, not a hardware limit. Faster storage finishes each extension sooner, but every other session still waits in the same single queue. More hardware was never going to move this number, and reaching for a bigger instance would have been dreadfully wrong.

6. The Fix: Partitioning

For Scenario 2 I ran the identical workload with one change: hash partitioning on the hottest table, which spreads inserts over 10 sub-partitions instead of one file:

diset tpcc pg_count_ware 50 
diset tpcc pg_num_vu 64 
diset tpcc pg_partition true 
diset tpcc pg_num_partitions 10 
vuset vu 64 
vurun 

This turns one heavily contended extension lock into several independent ones, one per partition, so the table can handle more concurrent writers. It doesn't remove lock contention. Each writer just waits in a much shorter line. On the HammerDB side the change is just one flag, pg_partition true.

Same hardware, same VUs: partitioning cuts lock waits and lifts throughput 7.2x.

7.2x more throughput at 128 VUs. Partitioning raised the concurrency ceiling, it didn't remove the lock.

7. The Catch: Partition Key Matters

I had 10 partitions either way, but whether writes actually spread across them depends on the partition key. The key is not only a query design choice. It also decides which lock each writer ends up waiting on.

Choosing a hash key spreads writes evenly across partitions; a bad range key concentrates them on one.

A bad key quietly sabotages the whole exercise and brings back the original bottleneck on a smaller table. What you want is to spread the writes, not only the storage.

8. A Mental Model: Worth Analogy

The way I think about it: one file with one lock is one runway handling every aircraft. Everything funnels through the same runway. Partitioning adds a second parallel runway. The traffic is the same, but it's split across parallel paths.

DBAs, to check whether your own table is in a holding pattern, run this:

SELECT pid, wait_event_type, wait_event, query 
FROM pg_stat_activity 
WHERE wait_event = 'extend';

If it returns rows, backends are already queued on the lock, like aircraft stacked up waiting for a runway.

9. Why This Matters In Production

This isn't a crash and it isn't corruption or core dump. It's a response-time problem, and it hurts most at peak traffic, when the write volume that triggers it is highest. Most teams never see it coming until peak traffic finds it for them. A slow p50 annoys users. A blown-out p99 loses them. In a low-latency, mission-critical system, a lock wait on relation extension isn't just a database metric. It is a direct line to revenue and reputation. It is also a silent outage. Nothing is down, but a customer is staring at a spinner in the middle of a financial transaction, a flash sale or a ticket drop. That is the worst moment to find out you have this problem. The fix is small. Something that would have shown up as a Black Friday outage can become a Tuesday-afternoon config change, if you catch it early. A single benchmark is only an anecdote, so please test this on your own workload before you take my word for it.

10. Questions from the room

Two questions from the audience are worth adding here, because they get at points the talk only hinted at. One question was whether this was really an infrastructure problem, and whether more scaling or a different environment would have fixed it. It wouldn't have: more vCPU and faster NVMe changed throughput by 0%. The fix was a database change, partitioning the hot table. It raised the ceiling and also let the system absorb more concurrent write load before hitting the same wall. Another was whether partitioning slows reads down. It can, depending on the query and the partition key. I think it's worth the trade-off: a slightly slower cross-partition read is a fair price for a write path that no longer collapses at peak.

Takeaways

1. Monitor the wait event, not just resource metrics. The CPU and disk looked fine the whole time. Check pg_stat_activity for wait_event = 'extend' and catch this before your customers do.
2. Partition for concurrency, not just cleanup. More files means more locks and more headroom. It raises the ceiling without removing it, and the partition key decides whether the headroom is real.
3. Measure before you scale hardware. This bottleneck doesn't respond to more CPU or faster disk. Benchmark first.

Conclusion

One last thing: don't ignore the warnings in your logs. A single line, "still waiting for ExclusiveLock", sat there while the dashboards stayed calm, and it was the only thing telling the truth. Postgres will usually tell you when something is wrong. You just have to read it before peak traffic reads it for you. A problem you can't see isn't a problem you've solved. It's a problem waiting for your worst day to introduce itself.

VoidZero's tools such as Vite, Vitest, Oxc, and Rolldown — bundled in one toolchain as Vite+ — have made frontend development faster, but building full-stack applications requires more than just a tooling stack. These applications need server routes, databases, local development environments, and a fast and easy way to deploy ideas to production.

We’re excited to open-source three new products that bring server routing, typed data access, and Cloudflare deployment into a unified Vite workflow.

• Void Platform: A shared deployment platform for teams to host Void apps on Cloudflare.
• Void SDK: A composable JavaScript SDK for building full-stack apps with Vite.
• Void CLI: A CLI for provisioning resources and deploying Vite apps to Cloudflare.

The CLI deploys apps built with the SDK to the Platform. All three products are open-sourced as a single JavaScript package and Vite plugin that you can install via npm install void. With Void, you can build your server and client together, carry types from your database to the UI, and let Void automatically provision the Cloudflare resources that your app uses.

We originally set out to build a single, private platform for all users to deploy apps to. After VoidZero joined Cloudflare, we adjusted our direction to open-source the platform and allow anyone to install because we saw a growing need: companies want to encourage vibe-coded internal apps, but are concerned about security and do not want to give cloud access to every employee. Void addresses this problem.

Void Platform: a cloud platform for your company

The Void Platform is fully open source and you can fork it and adapt it to your needs by integrating your company's systems, customize deployment workflows, build features for your customers, or make it work on other deployment platforms. Use the platform as it is, contribute improvements upstream, or fork it and build only the features you need. The open source code can be used out of the box or as a starting point.

As an admin of a Void Platform, you control access, set resource limits, inspect deployments and usage through the Void CLI or admin dashboard, and provide guardrails so everyone else can ship serious and vibe coded apps to the same shared platform.

By installing a Void Platform, your team or customers have a shared deployment environment in your Cloudflare account on top of Workers for Platforms. Void Platform enables:

1. Faster prototyping. Your team can quickly build prototypes, deploy them, and share working apps for feedback, without setting up a separate Cloudflare account or provisioning resources for every project. This reduces the time to ship internal apps from days/weeks to minutes.
2. Non-technical teams building. This workflow also lets teammates who do not normally write code work with coding agents to build and share their own apps. A designer can create an interactive prototype, or an operations teammate can build an internal dashboard, then deploy it to the same platform. All with the right security measures in place.

To self-host a Void platform, you need:

• A Cloudflare account with Workers for Platforms and R2 enabled
• A PostgreSQL database
• An account with your chosen login provider
• A domain for your apps

Then install Void as a cloud platform by running a single command:

Once your platform is set up, approved users can connect to it via the Void CLI for deployment.

void connect https://api.orange-company.dev

A user builds their app using the Void SDK, which is what powers Void Platform benefits like authentication, framework detection, resource provisioning, and more. In other words, Void Platform only works because of the accompanying SDK and CLI.

Void SDK: zero-config infrastructure

Void turns a Vite app into a full-stack Cloudflare Workers app. You or your agents can write code and Void will automatically infer resource bindings and provision resources such as databases, queues, or AI bindings during deployment.

To get started, add Void as a Vite plugin:

import { defineConfig } from "vite";
import { voidPlugin } from "void";
import { voidReact } from "@void/react/plugin";

export default defineConfig({
  plugins: [voidPlugin(), voidReact()],
});

The Void SDK ships with adapters for popular JavaScript UI frameworks such as React and Vue, provides file-based API routing, pre-rendering, caching, islands, and end-to-end type safety from the database to your UI.

All of Void’s features are optional and composable. Void integrates with existing application frameworks such as Vinext, React Router, SvelteKit, Nuxt, TanStack Start, and Astro. You can use those frameworks for routing and rendering, while Void handles resource APIs using Hono, migrations, deployment, and authentication with Better Auth.

Let's take a look at building a server-rendered page, with types inferred from the database query through to the client:

// pages/blog.server.ts
import { defineHandler, type InferProps } from 'void';
import { db } from 'void/db';
import { posts } from '@schema';

export const loader = defineHandler(async () => ({
  posts: await db.select().from(posts),
}));

export type Props = InferProps<typeof loader>;

// pages/blog.tsx
export default function Blog({ posts }: Props) {
  return (
    <ul>
      {posts.map((post) => <li key={post.id}>{post.title}</li>)}
    </ul>
  );
}

By importing void/db, Void provides a local database to your app during development and makes void deploy provision D1 automatically for you in production. This also works for using AI through Cloudflare’s AI Gateway: just by importing void/ai, everything is set up automatically for you.

// routes/api/decide.ts
import { defineHandler } from 'void';
import { ai } from 'void/ai';

export const POST = defineHandler(async (c) => {
  const { question } = await c.req.json();
  const result = await ai.run('@cf/cloudflare/clef', {
    model: 'clef',
    state: {},
    questions: {
      decision: { type: 'noul', instructions: question },
    },
  });
  const probability = result.answers.decision.noul;
  return c.json({
    answer: probability >= 0.5 ? 'yes' : 'no',
    probability,
  });
});

Void's React router is built for Async React, using transitions and Suspense to enable responsive navigation across screens. When you pair this router with a modern data framework such as fate and UI libraries such as Astryx, you can coordinate navigation, data fetching and mutations through React's transitions, as well as actions and optimistic updates across your entire application. Together, these pieces let you build apps that feel synchronous on fast networks, gracefully fall back on slower ones, and keep interactions responsive during expensive rendering updates.

If a user does not need Void Platform’s team management features, they can use their own Cloudflare account. Void SDK also deploys to Cloudflare directly.

Void CLI: one deployment command

The Void CLI is the main interface for Void. The CLI manages the platform and deploys the app. It's built on top of the new cf CLI and works well with agents.

With the Void CLI, you can ask your agent to debug failing requests, read deployment logs, analyze how your app is performing, or have them take care of the full lifecycle by deploying a finished app for you.

Once your app is ready to deploy to Cloudflare, you can run:

The first time you run void deploy, the CLI will prompt you to log into your Cloudflare account. Void builds your app using Vite, applies migrations, automatically provisions resources, and deploys to Cloudflare or a Void Platform. It can be used to handle the full lifecycle of your project such as building, deploying, and managing your resources and projects, for example:

Similar to how the CLI, and an agent by extension, can manage the entire lifecycle of a Void app, you can also use the CLI to manage a Void Platform:

• Manage users, project access, and resources
• Inspect deployments, logs, and rollbacks
• Monitor platform health and usage

Connect with us

VoidZero’s mission is to make JavaScript developers more productive than ever before. We brought Vite, Rolldown, Oxlint, Oxfmt, and Vitest together in Vite+ for development, bundling, code quality, and testing. Void extends that stack to full-stack application development, letting you and your agents build, test, and deploy entire applications.

We’ve been using the Void SDK, CLI, and Platform in production at VoidZero for the past several months and we are excited to see what you'll build with Void. Please share your feedback with us:

• Discord: Step into the Void community Discord server
• GitHub: Star the repo, start discussions, and report issues
• Deploy an app with Void: Quick Start Guide
• X / Bluesky: Follow VoidZero for updates on X or on Bluesky

Atlantis at Scale: How It Works and Where It Breaks

Atlantis is the tool of choice when engineers run terraform apply from their laptops. You drop a server in your network, wire up webhooks, and then your infrastructure changes are applied via pull requests like normal code.

That story holds up really well for a while, but when your organization grows, your repo count expands, and multiple people open PRs at the same time, things start feeling slow and fragile. In this article, we will walk through what Atlantis is, where it starts to break as you scale, what a serious production deployment looks like, and when it makes sense to move to something else.

What is Atlantis?

Atlantis is an open-source tool that automates Terraform through pull requests. It is a single GO binary that listens for webhooks from your Git provider, runs Terraform commands, and posts the output back as a comment on the PR.

The process is simple and easy to follow:

1. You modify your Terraform files and open a pull request.
2. Once the pull request is open, Atlantis receives a webhook, clones the repo, and runs terraform plan.
3. The plan output appears as a comment on your PR.
4. A reviewer approves, someone comments atlantis apply, and Atlantis runs the apply.
5. The PR merges, and Atlantis unlocks the project.

The Atlantis adoption is really simple, as everything happens where your team already works. You don’t need to learn a new UI; just read a comment and type another one.

Atlantis architecture overview at scale

Of the many ways to deploy Atlantis, the most common is Kubernetes. By default, Atlantis has no external database and stores plan files on the local disk. The official Kubernetes manifests use a StatefulSet with replicas: 1 and a persistent volume.

So, the Atlantis architecture has:

• One HTTP server that accepts webhooks and serves a small web UI
• A working directory on disk where every repo gets cloned per PR and workspace
• A locking layer that helps prevent two PRs from planning or applying to the same project at the same time.
• Terraform binaries that Atlantis uses to download and execute as subprocesses on the same machine

Where Atlantis breaks down at scale

1. The single server becomes a queue

Atlantis runs every clone, plan, and apply as a subprocess on the machine that received the webhook. That is fine when two people are working. It stops being fine when your monorepo has 70 projects and a PR touches a shared module because autoplan fires for every affected project. Multiply that by four open PRs and the worker pool is saturated.

2. Vertical scaling is the only straightforward lever you have

The obvious fix is a bigger box, and it works for a while. You add CPU and memory and then raise --parallel-pool-size, which controls how many plans and applies run at once and defaults to 15 on a single machine. The catch is what actually saturates first. Teams end up on very large instances with the CPU mostly idle and the disk thrashing on git clones and provider downloads.

3. You can scale horizontally, but you have to opt into it

By default, Atlantis stores locks in an embedded database only one process can open. Switching to --locking-db-type=redis lets several replicas share lock state. Plan files still sit on local disk, so you must enable --enable-external-stores to upload plans to an S3-compatible bucket.

4. Provider and module downloads dominate runtime

Every run gets a fresh working directory per PR and workspace, so terraform init runs again and providers download again. Atlantis does cache plugins by default, but the documentation recommends turning that cache off when several projects plan and apply in the same PR because Terraform has a known race condition on a shared cache directory. The two things you want most under load, parallelism and caching, pull against each other.

5. Access control is too limited

Atlantis gives you two ways to decide who can run what: --gh-team-allowlist or an external authorization command. That script is a piece of production access control that you write, test, and maintain forever. The product has no roles, no environments, and no per-account model.

6. Every credential ends up on the same box

If Atlantis manages infrastructure across ten AWS accounts, that one server holds access to all ten. It is the most privileged machine you run, the one with the widest blast radius if someone compromises it.

7. There is a simple alpha version of drift detection

Atlantis only sees the changes that arrive through a PR. As of v0.45.0 there is an alpha drift API, but you don’t get a scheduler. Something outside Atlantis has to call that endpoint on a cadence, and you own it.

8. No dependency graph across projects

If your networking stack has to be applied before your EKS stack, Atlantis will not enforce that. Across PRs and repositories there is nothing. No graph, no shared outputs, no way to declare that one project depends on another.

9. Visibility is limited to PR comments

After the PR closes, your audit trail is a set of comments spread across repos. There is no central run history, no searchable log store, and no per-team dashboard unless you build one and keep it running.

How to deploy Atlantis at scale

1. Decide centrally, not per repo: Point the server to a central repo config with --repo-config and set your defaults there.
2. Cache your provider downloads: Set a plugin cache directory and back it with persistent storage.
3. Set concurrency based on reality: Raising --parallel-pool-size without adding CPU and memory simply moves the queue rather than removing it.
4. Turn off the dangerous shortcuts: Use --disable-apply-all to force engineers to name the specific project they are applying.
5. Watch what triggers a plan: Tighten your autoplan file patterns so a docs change doesn’t trigger 20 runs.
6. Keep the disk on Kubernetes: Plans live on local disk, so the official manifests use a StatefulSet with a persistent volume.

Why use Spacelift as an Atlantis alternative

Spacelift is an alternative to Atlantis because it offers the same PR workflow while providing enterprise-grade orchestration.

• Policy as code with OPA: Control what resources users can create, approval requirements, and notification logic.
• Built-in drift detection: Understand changes made to stacks on a defined schedule without managing external infrastructure.
• Stack dependencies: Create a directed acyclic graph between configurations and share outputs between them.
• Real RBAC and SSO: Native integration with SAML 2.0 for fine-grained access control.
• Full run history and audit trail: Centralized logs and history instead of comments scattered across PRs.
• Private worker pools: Run infrastructure tasks inside your network for security and isolation.

How to migrate from Atlantis to Spacelift

1. Each Atlantis project needs its own stack: Define them with the Spacelift Terraform provider so the setup is versioned.
2. Import your state: Import your existing state file or continue using your existing S3 backend.
3. Move your credentials: Swap static cloud credentials for Spacelift’s managed cloud integrations.
4. Translate your rules into policies: Convert apply_requirements into approval policies.
5. Run both in parallel briefly: Point a few low-risk stacks at Spacelift and compare results before full migration.
6. Turn off Atlantis: Gradually disable webhooks and decommission the server.

Key takeaways

Atlantis is an excellent tool with a simple design: one server, local disk, and PR comments as the interface. Its limits are structural: single-server execution, disk-bound plan files, coarse permissions, no enterprise-ready drift detection, and no dependency graph. You should always measure the real cost before deciding to use Atlantis, as plan latency and platform engineering hours matter far more than the instance bill.

Digital designers should understand code as a material in the same way architects understand stone or steel, learning what it can do without necessarily mastering how to write it. AI increasingly handles implementation, making it practical to design and review working interfaces in code where responsive behavior, real data, loading states, accessibility, and failure conditions can be experienced rather than represented as static pictures. The valuable skill is therefore shifting from syntax toward understanding how software behaves, testing its limits, and judging whether the resulting product actually works for people.

Brand archetypes create a cohesive personality. From a bird’s-eye view, that’s exactly what you want: every touchpoint feels like the same brand. But when you’re the one translating that personality into UX copy, an archetype can only take you so far.

This is because an archetype is categorical by design. You pick a category, such as the Explorer, and apply that personality across the brand. A category, though, is a type of person, not a person, and types don’t talk; people do.

In this article, I’ll share a technique you can use to bridge the gap between an abstract brand archetype and the words users actually read. I’ll also show how it works in practice by applying it to common UX writing scenarios.

The case for archetypes

This isn’t to say that brand archetypes are wrong. In fact, pairing a brand archetype with a user persona is a common approach to defining voice and tone.

Brand archetypes define who the brand is, while user personas help us understand who’s on the other end of the screen. Used together, they answer two essential questions: Who are we? and Who are we talking to?

In practice, I’ve found that even when those questions are answered, there’s still another one to solve: What should this brand say in this moment?

Where archetypes hit a ceiling

An archetype might tell you your brand is a Caregiver, while a persona tells you your user is a first-time shopper worried about getting scammed. But when it’s time to craft copy for the checkout flow, you’re left wondering: How would a Caregiver reassure this person in this moment?

A personality type like the Caregiver has multiple facets that can be interpreted in different ways. One writer might focus on the Caregiver’s comforting nature, while another emphasizes its practical guidance.

In my experience, this is where sentence-level decisions become difficult. The broad personality is clear, but you still need to interpret it for every interaction.

To bridge this gap, I use a technique shared by Vitaly Friedman. He suggests that before writing UX copy, you imagine a real person speaking to the user.

The imagined speaker: Bringing your archetype to life

Instead of writing for a broad archetype, imagine someone who embodies that archetype’s personality speaking directly to your user. This narrows the question from, “Does this sound like a Caregiver?” to “How would this person say it?”

This approach gives your brain something more concrete to work with. It’s much easier to imagine a conversation with a specific person than it is to translate abstract personality traits into words.

Brand archetype vs. imagined speaker

Before you start: The imagined speaker exercise assumes you already know roughly how your brand should sound — you’ve picked an archetype, paired it with a persona, and now need to turn that into actual words.

If you haven’t defined a voice yet, start there. The goal of this exercise is to sharpen a voice you’ve already committed to, not to build one from scratch.

Building the speaker

Friedman’s exercise is to picture a real person speaking to the user before choosing any words. But that person doesn’t have to be random. Instead, imagine someone who naturally embodies your brand archetype.

You don’t always have to invent them from scratch. You can borrow someone you already know who fits — a friend who remains calm under pressure, a mentor who’s naturally warm and reassuring — and write through them.

Say your archetype is a Caregiver. Rather than writing as “the Caregiver,” think of someone who exhibits qualities like compassion, patience, and care.

Now, visualize that person in enough detail that you can actually hear them speak:

• Voice: What do they sound like? Calm, warm, reassuring, or upbeat?
• Tone: How do they adapt in different situations? Are they calmer when someone is anxious and more enthusiastic when they’re celebrating?
• Formality: Where do they sit between casual and formal?
• Personality: How do they interact with people? Are they direct or diplomatic? Patient or energetic?
• Values: What principles guide their communication? Clarity? Transparency? Honesty?

Once you’ve done this, writing becomes more about imagining the speaker interacting with users. You can picture them standing beside the product, talking users through what’s happening, explaining an error, offering reassurance, or even onboarding a new customer.

Your job at this point is simply to capture what they’d naturally say.

The exercise in action

Let’s say we’re writing UX copy for a meal planner app, MealPlan, that helps users plan weekly meals, track their nutrition goals, and build healthier eating habits.

Our brand archetype is the Caregiver.

Rather than writing as an abstract Caregiver, we’ll imagine Sarah: a nurse who calmly reassures anxious patients. She never rushes people, avoids jargon, and takes her time to explain each step before expecting them to take action. When someone is worried, she acknowledges their concern before offering guidance.

The question now becomes, “How would Sarah talk to users as they navigate this product?”

Scenario 1: Onboarding a new user

A new user just downloaded the app because they’re trying to lose weight and want help planning their weekly meals and tracking calories. They’re hopeful the app can help, but don’t know how it works yet.

What Sarah thinks:

This is their first impression of us. Before asking them to create an account, I want them to feel welcome and understand how we can help them.

What Sarah says:

Headline: Welcome to MealPlan

Body: Let’s make healthy eating a little easier with personalized meal plans.

CTA: Get started

Scenario 2: Asking for personal details

The user has created an account. Before generating a meal plan, the app needs to understand their health goals, dietary preferences, allergies, activity level, weekly food budget, and any foods they’d like to avoid.

What Sarah thinks:

I’m about to ask for personal information. Before I ask any questions, I need them to understand why we need the information and how we’ll use it to help them. That way, sharing these details feels worthwhile, not intrusive.

What Sarah says:

Headline: Let’s personalize your meal plan

Body: We’ll ask a few quick questions about your goals, preferences, and weekly food budget so we can tailor your meal plan to you.

CTA: Personalize my plan

Scenario 3: Handling a declined payment

The user is trying to subscribe to a monthly plan, but their card is declined at checkout.

What Sarah thinks:

Something interrupted their checkout. To reduce confusion and uncertainty, I need to help them understand what happened, reassure them that they can still complete their subscription, and explain the options they have.

What Sarah says:

Headline: Your payment didn’t go through

Body: We couldn’t process your payment using this card. You can still complete your subscription by trying again or choosing a different payment method.

Primary CTA: Try again

Secondary CTA: Change payment method

Notice how Sarah’s voice doesn’t change across all three scenarios. She stays true to the Caregiver archetype by being calm, reassuring, and supportive. What changes, however, is her tone. She adapts to the user’s emotional state: welcoming new users during onboarding, being transparent when requesting information, and providing reassurance when something goes wrong.

By writing through the imagined speaker, the right tone emerges naturally.

Scaling the exercise

This exercise works particularly well when you’re a solo writer handling copy end to end, because the speaker can live entirely in your head.

But it doesn’t have to stay there forever.

If you’re part of a team, defining the imagined speaker can become a collaborative exercise. Instead of leaving the Caregiver archetype open to individual interpretation, the team defines one shared speaker everyone can write through.

One way to do this is through a collaborative workshop. Start by choosing the imagined speaker together, then use sticky notes to flesh out details like their background, personality, communication style, values, and habits until everyone has a similar picture in mind.

Agreeing that the speaker is Sarah, a nurse, rather than simply a Caregiver, leaves little room for interpretation and makes it easier for the team to write consistently.

Teaching AI to write like your imagined speaker

Your imagined speaker can be used to improve your AI outputs too. Rather than relying on vague prompts during copy brainstorming sessions, you can give the model details of your imagined speaker and ask it to write as that person.

For example:
Write an error message for a user whose card was declined while subscribing to a monthly plan. Write as Sarah, a nurse who calmly reassures anxious patients. She explains each step before asking users to take action, avoids jargon, acknowledges concerns before offering guidance, and helps people understand what happens next.

If you combine this with product context, you’ll get outputs that are more human and better aligned with your product’s voice.

Another way to use the imagined speaker is to build it into your custom GPT alongside your content style guide, content principles, and other brand documentation. This will give the model a richer understanding of how your brand communicates.

Conclusion

Brand archetypes and user personas are great foundations for defining your brand voice and tone. The imagined speaker exercise discussed in this article isn’t meant to replace them. Instead, it acts as a bridge between these artifacts and the words users actually read.

By imagining a real person behind your brand, you give yourself something more tangible to write through. Rather than trying to translate an abstract archetype into words, you begin asking a much simpler question: What would the imagined speaker say?

That single shift can be the difference between copy that merely sounds on-brand and copy that feels unmistakably human.

Investing in the public benefit

Today, we’re committing a portion of Anthropic’s shares to the Anthropic Public Benefit Fund, a new entity with a structure that increases the stake as the company grows. Subject to stockholder approval, 5% of Anthropic’s shares will be committed today, with an additional 2% added at the board’s discretion for every 50% increase in the company’s value above a set baseline.

As a public benefit corporation, most of our work in pursuit of our mission takes place inside the company: research relevant to AI safety and interpretability; applied biomedical research; discounts on Claude for nonprofits and scientific institutions. These activities have both a public benefit component and for-profit value, so we house them directly in the company.

The Anthropic Public Benefit Fund will have increased flexibility and scale, enabling us to pursue our mission in new ways: for example, we might explore large donations to traditional nonprofits or direct distributions to specific populations.

One example is labor market impacts. AI may generate enormous economic value, but it could also cause instability for many workers. Anthropic has already committed $200 million to studying and addressing this issue, but given the pace of AI progress, bolder approaches may be needed. The Fund will have the versatility to pursue them.

We’re establishing the Anthropic Public Benefit Fund as a wholly-owned LLC—rather than a 501(c)(3) or other format—to give adjustability between different forms of giving. None of the Anthropic equity held by the LLC will be used for lobbying or political giving, in the US or abroad.

Because of the way the Fund is structured, the more Anthropic grows, the larger the share of the company that can be dedicated expressly to the public good. It is common practice for tech companies to offer escalating compensation awards to their executives. We are instead directing that equity to the public benefit.

This builds on commitments our co-founders and employees have already made. When Anthropic was founded, our co-founders pledged to donate 80% of their equity holdings, and since founding we have also operated an equity donation match program that allows employees to pledge equity which Anthropic matches. Approximately half of our employees participate in this program. When combined with today’s announcement, roughly 20% of Anthropic shares will be dedicated to the public good, plus any additional percentage that could be added if the company reaches specific valuation milestones.

In the coming months, we will share more about the Anthropic Public Benefit Fund’s structure and governance, including the valuation milestones that may add to its stake. We will also report on our progress to date against our mission in an upcoming public benefit report.

If fresh leaks and tests are anything to go by, then it looks like OpenAI might be getting GPT-Image-3 ready. Three new model references, aurora-red-alpha, aurora-green-alpha, and aurora-blue-alpha, briefly appeared in OpenAI's API this weekend, and within hours they were turning up in blind arena tests producing images.

We caught the names through an alert on the Dev Mode Discord server. The references were pulled shortly after, which looked like an accidental rollout.

Lumina soon highlighted that all three models appear to be image models currently tested on Arena. They even shared a second cat from aurora-green-alpha. Of course, two cat portraits won't tell anyone much about quality, but both look clean and detailed. Still, based on the images we've seen so far, none of them look like they'd make you write home about.

Lumina Bench did speculate that this is probably GPT Image 3, and we'd lean the same way, though that's still a guess. In those tests, red ran faster but with lower quality, while green was slower and looked better. The blue model hasn't been tested yet.

Separately, X user Intius also noticed three new entries on Design Arena, named Aspen, Cypress, and Maple, about an hour after the API references appeared, though nothing ties those names to the Aurora models directly.

OpenAI testing multiple models isn't exactly a surprise. The company did ship ChatGPT Images 2.5 with two API models, GPT-Image-2.5 Flare for speed and GPT-Image-2.5 Sunburst for precision, and it has since been put to work on virtual try-ons in ChatGPT shopping. If you look back further, then we can see that OpenAI ran three tape-themed Image V2 variants through LM Arena the same way back in April.

While image generation models are fun to play with, a lot of users are actually waiting for a new frontier model. OpenAI, for its part, recently launched GPT-6 with Intelligent UI in ChatGPT. Before that, we got the company's Grok Bot and Muse alternative dubbed Dots, which is currently powered by GPT-6 Astra and GPT-6.1 Sol.

But that's not all. OpenAI also listed gpt-rosalind-discovery on its pricing page last week. That model still hasn't been announced, although Rosalind Workbench opened in research preview a day later.

Meanwhile, Anthropic is preparing to launch Claude Fable 5.5, which partners reportedly already have, and Cursor's latest build has started referencing the name. Whether OpenAI answers with GPT-Image-3 or something bigger, the next couple of weeks look busy. There's no documentation or pricing for any of the Aurora models yet, so the cat pics are all we have.

Replit, the AI coding platform that has become a favorite of startup founders and developers, is no longer working with Anthropic, the company’s CEO and co-founder Amjad Masad said Thursday while onstage at TechCrunch Disrupt.

Masad said the decision was made for a number of different reasons, including cost. Replit announced a partnership with OpenAI in August, but there was never any indication that it was no longer partnering with Anthropic.

“I think ChatGPT is better now,” Masad said, adding that the company uses an internal benchmark to help assess metrics like performance. “We publish a public benchmark as well, and consistently, Sol and Astra perform better on building vibe-coded applications from scratch. It was a decision based on both cost, partnership, and performance. And for all these reasons, we just felt like they were a better partner for now.”

It seems, however, that Anthropic hasn’t been completely cut out of Replit, which sells a cloud-based software development platform where users can develop and deploy apps directly from inside their browser.

After Disrupt, Masad clarified that customers can still access Anthropic models on the platform, but that OpenAI’s ChatGPT is now the default. This shift could significantly reduce Replit’s spend with Anthropic since most customers stick with the default rather than selecting a model themselves.

Prior to striking a deal with OpenAI, Replit relied on Anthropic’s Claude models to run its platform. That partnership was said to have helped the company grow its revenue significantly, and Masad noted onstage that Replit had been, until recently, a top-five customer of Anthropic’s.

“Replit remains model agnostic,” Masad told TechCrunch over the weekend. “Our users can choose Anthropic’s Claude or other supported models … OpenAI is now our preferred partner for powering Replit Agent, based on performance, economics, and the strength of our partnership.”

However, Masad’s comments onstage were rejected by insiders familiar with the partnership between Anthropic and Replit. One person familiar, who asked not to be named, said the partnership was still in place.

There is evidence on the company’s website, blog posts, and social media posts that Replit was promoting Anthropic products as recently as a few weeks ago. For instance, a blog post in late September cites Anthropic’s Claude Fable 5 and Claude Fable 5.1 as models running in Replit Agent’s production environment. Around the same time, one of Replit’s product employees posted on X about using Anthropic’s flagship model Opus 5.5 and promoting its capabilities.

Masad also shared insights about the company’s growth while onstage at Disrupt, noting that enterprise is starting to provide a larger slice of revenue.

“We’re not sharing ARR numbers just yet, but in terms of growth, like, I would say, enterprise was like 2% of revenue last year,” Masad said. “This year, I would say like 15% of our revenue is enterprise contracts, and more than 50% of our revenue is B2B.”

Backstage, Masad told TechCrunch that he expects more than half of Replit’s revenue to come from enterprise and government customers in 2027.

Masad also commented on the necessity for good AI safety measures.

“In the same way that us humans need a certain environment to work — you need a nice office, maybe nice good food in the office, air-conditioning, computer — agents need a habitat for them to exist and do good work,” he said. “So that habitat has good orchestration, good error recovery, good safety and security and sandboxing, good networking, good identity and authorization. And once you figure all of that out, then you can deploy AI safely.”

This article was originally published on October 16 at 2:22 p.m. PT. It has been updated to include more context around Replit’s partnerships with Anthropic and OpenAI. Its title has been updated, as well.

Virtually every major mutual fund company, insurer, and private equity firm, as well as scores of individual investors, has been buying up AI debt. Hyperscalers, which continue to borrow heavily, have been forced by investors to pay modestly more in interest in recent debt deals. The market is realising there may be a mismatch between the money committed and borrowed today and the ability to generate revenues down the road. An increasing number of data centers are being delayed by permitting issues, and in some instances falling through.

Terence Tao, one of the world's greatest living mathematicians, is currently doing very little math. OpenAI's recent finding in the mathematical field has left him feeling used, as he previously had a good relationship with many employees at the company. Now, he sees them as only using math to evaluate their models, and can't see a way to constructively engage. Despite OpenAI's releases, most problems at the frontiers of math are unsolved, and as math remains infinite, the difficulty of problems is boundless.

Graph tools for MCP should return focused, bounded views instead of dumping broad subgraphs and hoping prompts impose structure later. The key design move is to make scope explicit in the server through named views, validation rules, and controlled navigation points. For changing entities like avatars, modeling location over time preserves auditability and keeps behavior consistent across clients.

Opus delivered the best analytics reports but cost more. Routing by task balances quality and cost: Sonnet for metrics and trends, Gemini Flash for guided analysis with human review, and Opus for root cause investigations.

Optimizing your site for AI is of little use if AI can't find it. The answer to someone's question may already be on your website: the installation guide you spent a week writing, or a first-hand account of using a product, with the details that make the difference for whether they buy it. As more people turn to AI for help, you want those systems to find your work, represent it accurately, and send interested people your way. You also want control over how they access your site.

Cloudflare and OpenAI launched a research pilot in July 2026 with those interests in mind. We wanted to find out whether signals from Cloudflare’s network could help ChatGPT users discover new content more efficiently.

Today, we’re sharing early results. So far, the answer is a resounding yes: the pilot has brought previously unknown pages into OpenAI’s search index, giving ChatGPT more sources to draw on to help people find relevant, timely information. Along the way, we’ve learned more about what makes a page worth discovering and how AI systems use the web.

Finding more of the web

The web is full of specifics. Someone fixing a washing machine needs the manual for their exact model. Someone applying for a passport needs the current requirements and fees. Someone choosing a local restaurant needs its latest menu and opening hours. Finding the right page can be the difference between a wrong answer and one that actually helps. These pages can be valuable even if few other sites link to them.

In the previous version of the web, discoverability was getting to the top of a search result page. It was then up to the human who visited your page to determine the value of the information, book that table, apply for that passport. As people increasingly rely on AI to find information and complete tasks, discoverability matters in new ways. AI systems need to find the right sources, understand what's useful, and connect people with relevant information – whether that's through an answer, a citation, or a visit to the website itself.

Cloudflare's network provides signals that can help OpenAI’s search crawler discover more useful pages across the web to surface to ChatGPT users. OpenAI then independently evaluates and ranks how those pages appear based on how relevant and helpful they are. Together, this creates a feedback loop that can improve both discovery and the quality of information people find.

This joint pilot, which used a participating cohort of ~1% of Cloudflare’s total network, has enabled OpenAI to discover and index hundreds of millions of new web pages, helping people discover more useful content and get more questions answered through ChatGPT. By linking back to relevant sources, ChatGPT Search also gives people a way to explore the original content and discover the websites and publishers behind it.

With GPT-6 and Intelligent UI, OpenAI is also making ChatGPT an even better place to shop, learn, and find answers, with more visual, interactive experiences tailored to what people need. This work complements these advances by helping ChatGPT discover more useful, up-to-date information from across the web.

From discovery to useful answers

Finding a URL is only the start. We need to know whether it leads to a page someone can access, whether that page offers anything distinct, and what it might help someone do.

We’ve learned, for example, how easily automated traffic can make a nonexistent page look interesting. Bots repeatedly ask for files that aren’t there. Some sites redirect almost any address to their homepage. Other addresses lead to copies of the same content. Recognizing these patterns gives us a way to cut wasted work before a crawler fetches the page, and improve efficiency in a way that benefits site owners.

We're also testing signals that identify and flag potentially harmful pages, adding another layer of information to support safer, more reliable discovery. A legitimate site can have a single compromised page, such as a fake login form planted by an attacker. Flagging that one page, rather than the whole domain, keeps people safe without penalizing the site owner. Early results suggest these signals can help identify pages that should be kept out of an index.

Making discovery easier

As more people use AI to discover information, website owners have new opportunities to reach interested audiences. For those who choose to make their content available to AI systems, these improvements make discovery easier and more efficient.

Keeping up by fetching every page more often would be expensive for everyone. For a website owner, a crawler that repeatedly downloads an unchanged page adds load without bringing any benefit.

The signals above are how we avoid that. Filtering keeps crawlers away from pages that don't exist or that redirect elsewhere. Change signals tell them when a page is worth another visit, and when it isn't.

There's a balance to get right. Finding new pages can initially increase crawling as those pages are evaluated and indexed. The goal is to keep discovering and stay current while reducing the work that takes. For Cloudflare customers, that means less unnecessary load. For OpenAI, it means more of its search resources are spent on information that helps people.

Making it worthwhile to participate

The next phase will build on what we’ve learned: improve the selection of pages, test faster and more reliable change signals, and measure what happens after content is discovered.

We’re continuing to work with OpenAI to understand how better site discovery can translate into real business outcomes, and we’ll keep sharing what we learn along the way.

Domain owners’ choices matter throughout. A signal about a page doesn’t grant permission to access it. This research uses metadata about the web for search and discovery, rather than sharing page content for model training.

You can use Cloudflare’s AI Crawl Control to understand and manage how AI systems access your website.

Full article content is not available for inline reading.

Read the original article →

Microsoft's third-generation AI accelerator uses TSMC N2P with 288 GB HBM4 at 18 TB/s. Racks hold 96 accelerators at 167 kW, scaling to 12,288-chip superpods, with up to 7x token throughput.

Amazon ECS adds LiveTaskCount and removes the charge for RunningTaskCount metric

Today, Amazon Elastic Container Service (Amazon ECS) announces LiveTaskCount, a new ECS service metric that reports how many tasks are actively running in your service, available to all customers at no additional charge. Additionally, the existing RunningTaskCount metric in Amazon CloudWatch Container Insights no longer incurs a charge.

LiveTaskCount reports the number of actively running ECS tasks across all desired states (ACTIVATING, RUNNING, and DEACTIVATING), including tasks still running while transitioning to a stopped state, for example, tasks undergoing connection draining during a scale-in event. This comprehensive state coverage makes LiveTaskCount well suited for autoscaling policies and capacity planning where a complete view of active, metric-generating tasks is required. It is available at no charge as part of ECS service utilization metrics and does not require opting in to CloudWatch Container Insights. The existing CloudWatch Container Insights RunningTaskCount metric tracks tasks where both the current and desired state are RUNNING, and continues to serve as a health and stability signal for customers who depend on it. With today's update, RunningTaskCount is now available at no additional charge for all CloudWatch Container Insights users.

These updates are available in all AWS Regions where Amazon ECS is available. No action is required, and the pricing change for RunningTaskCount takes effect beginning October 1, 2026, and applies automatically. To learn more, see ECS CloudWatch metrics and ECS Container Insights metrics. For a pricing example, see Amazon CloudWatch pricing.

We’re powering European scientific discovery with advanced AI compute and frontier models.

Google DeepMind and Google Cloud are providing up to 200 top European scientific researchers with direct access to our frontier models, together with $3 million in compute credits.

Through this pledge, researchers will gain direct access to our leading scientific tools including AlphaFold 3, WeatherNext, AlphaGenome, AlphaEvolve, and AlphaEarth Foundations.

This commitment supports the European Union’s AI for Science work by making some of our frontier models available via the RAISE initiative, which seeks to help bridge the compute gap European scientists sometimes face.

By delivering vital compute power and state-of-the-art tools directly to research teams, this effort aims to accelerate the pace of European innovation and reinforce the continent's scientific competitiveness.

Researchers will be equipped to tackle complex challenges faster, from predicting extreme weather patterns to mapping molecular structures, ensuring that European science remains vibrant and at the forefront of discovery.

Apple has strengthened its App Store rules to explicitly address AI-generated nonconsensual intimate imagery and apps that digitally undress people. Developers must proactively moderate harmful user-generated content, while a clarified rule prohibits hiding functionality during review and enabling features such as nudification after approval. The changes follow months of criticism over harmful AI apps reaching the App Store and incidents involving tools such as Grok being used to create sexualized deepfakes.

Full article content is not available for inline reading.

Read the original article →

Stack Overflow for Agents saw a 3x increase in signups overnight after integrating a ChatGPT plugin.

Apple is already working on developing a higher-end version of its HomeView display with a robotic limb that can automatically swivel the screen toward whoever is speaking. The company's own advertising for the $299 HomeView makes a compelling case for why a motorized version is needed. The device was designed to be controlled primarily by voice. While the HomeView is a pretty nice offering for $299, its design clearly shows it was a product conceived years ago.

Good products carry something of the people who make them. The industry often talks about software as if it comes out of a factory, but two teams can talk to similar customers and have access to the same technology and still make very different things. The difference is how each team understands what they see and the style they go about building it. The founder background or company DNA shapes this a lot.

Apple hasn't slowed its gaming efforts seven years after launching Apple Arcade, and it is clear the company still has its sights set on being a major player.

Apple says iPhone Duo pre-order demand has been “nothing short of extraordinary,” with shipping estimates quickly slipping from October into January and even February in some countries. Limited initial supply appears to be amplifying the delays, while Apple says it is working to get devices to customers as quickly as possible and will continue accepting online orders. The shortages have already created a resale market, with scalpers listing pre-orders for prices as high as $10,000.

Feedback is the lifeblood of great design, and how someone responds to it matters more than they might think. There are four types of feedback: positive, constructive, negative, and appreciation. Negative comments can be reframed by acknowledging emotions, separating self from work, and staying curious.

Make photo dumps, carousels, stories, and videos with stickers, text bubbles, mockups, and AI, right in your browser.

Span redesigned Chicago's Peggy Notebaert Nature Museum around the colors, forms, and character of native Illinois prairies, creating a warmer and more expressive identity for both casual visitors and scientific audiences. Tonka provides an organic wordmark, while New Atten, seven colors named after prairie flora, and an abstract mark that can read as a butterfly, flower, or cloud give the system its distinctive character. The mark can frame photography, become a repeating pattern, or function independently, allowing the identity to extend across the website, signage, campaigns, posters, and museum store.

Together created Clusia's identity around a four-petal mark representing multiple people and AI systems working together inside the assurance platform, deliberately avoiding the robotic visual language common to AI companies. The petals become pixels in 3D illustrations, animate through product states, and combine with Die Grotesk, Vitruv Text, forest-inspired colors, and candid workplace photography to create a system that feels technological but distinctly human. Generative AI was used to explore illustration forms before they were rebuilt and refined in Cinema 4D, while the product itself uses a restrained version of the identity with green reserved for actions, statuses, and the animated mark.

Working as Color out of Place, Brett Keyes makes AI-assisted landscapes where calm scenes, like Rippling Reality's mountain lake, dissolve into patterns of color and line.