DEV Community: kate astrid

Is Software Dead? Part Five: Accountability

kate astrid — Fri, 30 Oct 2026 22:24:03 +0000

When an AI Agent Breaks Production, Who Gets the Blame?

In July 2025, during a code freeze, Replit's AI agent wiped a live production database with records on more than 1,200 executives. Replit's CEO, Amjad Masad, called it unacceptable.

In 2026, a founder reported that a Cursor agent running Claude Opus 4.6 deleted a Railway production volume and its backups in seconds. According to the reports, the agent found an API token in an unrelated file and used it. Some details are disputed, and the shape of the story is familiar.

One researcher has documented ten production incidents like these across six AI coding tools between late 2024 and early 2026.

So here's the question every team using agents will face sooner or later: when an agent breaks production, who gets the blame?

This is part five, the finale of the "Is Software Dead?" series.

The 2:47am question

I've written before about the message that shows up in Slack when production goes down at 2:47am: "Who pushed this?"

It feels useful because there's a name at the end of it. With agents, that question gets strange fast. The agent pushed it. The engineer approved it, maybe. The vendor trained the model. The platform issued the token.

I like a different question much more: what made this possible? That question works equally well for agents and for people.

The law already has an early answer

In 2022, Air Canada's website chatbot told a grieving passenger he could claim a bereavement discount after his flight. The airline's policy said otherwise. In the case, Moffatt v. Air Canada, the airline argued that the chatbot was a separate legal entity responsible for its own actions.

In February 2024, the British Columbia Civil Resolution Tribunal rejected that argument. It said that while a chatbot has an interactive component, "it is still just a part of Air Canada's website." The airline had to pay.

It's a small tribunal case, and the principle is big: a company owns what its AI does.

Blameless still applies, with one twist

Blameless culture says that when something breaks, we look for the system fix and leave the hunt for a bad apple behind. That idea fits agents well, with one twist: the agent is part of the system.

"The model hallucinated" makes a weak root cause, because it gives a team zero things to fix on Monday morning. The useful root causes in these incidents look like this:

the agent had real production credentials;
development and production shared one database;
backups sat within the agent's reach;
a destructive command ran with zero review.

Every one of those has a fix a team can roll out this week. After its incident, Replit separated development and production databases and added a planning-only mode. That's a blameless postmortem working the way it should.

Guardrails that make accountability possible

Accountability needs evidence and boundaries. Teams running agents in 2026 are settling on a short list:

Give each agent its own identity. When agents use a human's credentials, the audit trail blames the wrong person.
Grant the least access that works. An agent writing a migration needs a staging database, and production can wait for a human.
Set approval thresholds. Above a certain risk, such as deleting data, moving money or touching production, a human approves.
Keep an audit trail. We should be able to answer "what did the agent do, and why?" in minutes.
Keep a kill switch. Someone needs to be able to stop every agent at once.
Store backups out of the agent's reach. A backup the agent can delete is a second copy of the same risk.

So who owns what?

Here's how I'd split it.

Who	What they own
The company	The outcome. Air Canada found that out in front of a tribunal.
The team	The guardrails: identities, access, approvals and backups.
The engineer	The access they grant and the changes they approve.
The vendor	Clear documentation of what the agent can do and how to limit it.

On that last row, vendors have work to do. A February 2026 study from Cambridge and MIT found that only four agents publish agent-specific safety documentation.

The model sits in this table too, as a component, the same way a library or a cloud service does. We choose it, we configure it and we answer for it.

So, is software dead?

Over five parts, we've looked at the same question from five sides.

Business: software as screens is shrinking, and software as a system of record is growing.
Users: people want outcomes, and they also want control, history and an undo button.
Engineers: writing code got cheap, and understanding it got expensive.
Developer relations: our docs have a second reader, and people still decide what to trust.
Accountability: agents can act, and people still own what they do.

Software is changing shape. The responsibility for it stays exactly where it was, with us. I find that comforting. Whatever the tools look like in five years, people who understand systems, care about users and own their decisions will have plenty of work to do.

Who on our teams owns what an agent does in production today? I'm curious how different teams answer this one, so tell me in the comments.

Sources

We, Speakers, Broke AI Conferences

kate astrid — Tue, 27 Oct 2026 07:19:34 +0000

So, a few weeks ago I was at a conference, sitting in the hallway with a cup of lukewarm coffee and scrolling through the schedule to pick my next talk.

The first AI talk was about orchestrating agents at scale. The next one promised governance for the agentic enterprise, and the one after that was about observability for LLM apps. Then I found orchestration again, this time with "multi-agent" in front of it.

I kept scrolling all the way to the closing keynote, and almost every AI talk had one of those three words in its title or its abstract.

So here's my theory. I'm convinced we can get a speaking slot at any tech conference by adding one of those words to our talk. We pick orchestration, governance, or observability, we put it in the title, and congratulations, we're on stage in June.

Why these words work so well

And I get it, I really do. There are some very human reasons behind it.

First, these words feel safe. AI changes every few weeks, so if we promise something concrete in March, it might look silly by June. "Governance" sounds wise today, and it'll still sound wise next year.

Second, reviewers recognise them. A program committee reads hundreds of proposals in one long afternoon, and when they see one of these words, they think, "Great, this talk belongs to the conversation everyone's having."

Third, they hide the mess. Half the time, what someone means by "observability" is "we finally added a log line that shows which tool our agent called and why." And that's the talk I want to see! It's specific, it's a bit embarrassing, and it's way more interesting. "Observability" is the same story in a suit and tie.

And last, they sound sure. Most of us are figuring out AI as we go, and these words sound calm and certain. That's a lovely feeling when we're pretty unsure on the inside.

The talks I'd happily queue for

Here's what I'd love to see more of, whatever the title says.

I'd love to see an incident with the logs right there on screen. Show us the agent's output, the command it ran, and the Slack thread that followed. One honest screenshot teaches me more than ten slides of principles.

I'd love to see a boring graph. Some team measured review time, bugs, and onboarding before and after an AI tool, and they show us what happened. A small, real number beats a big, imagined one every time.

I'd love to hear someone say, "Last year I believed this, and here's the exact moment I changed my mind." Those talks stay with me for months.

I'd love a live demo that breaks. The speaker debugs it in front of us and thinks out loud, and honestly, that's the most useful twenty minutes at any conference.

And I'd love someone to show us the bill: the tokens, the hours, and the weekend somebody lost. Hardly anyone shows it, and everyone wants to see it.

Two quick checks before you hit submit

If you're writing a proposal right now, here are two little tests that help me a lot.

The first one is the swap test. I take each big word in the title and swap it for a real thing from my codebase or my team. So "Observability for AI Agents" becomes "The Log Line That Showed Us What Our Agent Was Doing." If the new title sounds more interesting, I keep it.

The second one is the Monday test. I ask myself what someone in the audience will do differently on Monday morning. If I can name one action, the talk has a point. If all I can name is a feeling, the abstract goes back into the oven for a bit.

Both take about five minutes, and both make the talk a lot more fun to give.

Let's build a better schedule

So which buzzwords keep popping up on the conference schedules you see? And which talk would you happily queue for? Let's compare notes in the comments. 👇

Orchestration. Governance. Observability. At this point, I'm convinced you can get a speaking slot at any tech conference by putting these three words on a slide and looking concerned about AI.

kate astrid — Mon, 26 Oct 2026 12:23:42 +0000

Is Software Dead? Part Four: Developer Relations

kate astrid — Mon, 26 Oct 2026 10:13:00 +0000

A while ago I wrote that developers scan docs. They open a page from a search result, hunt for the code block, copy it, and leave.

In 2026, many of them send an agent to do the scanning.

A study from April 2026 looked at how AI coding agents use documentation portals. It found that agents compress a whole multi-page visit into one or two requests. They skip the intro, the screenshots, and the friendly tour, and they take exactly what they need.

So our docs have a second reader now. That changes developer relations more than any other part of this industry.

This is part four of the "Is Software Dead?" series. DevRel is the work I care about most. I organize the UXDX meetup in Amsterdam and speak at developer conferences, and my favourite part of the job is the moment someone finally gets it. So this one is close to my heart.

Two readers, one set of docs

Developers and agents come to our docs with different needs.

A developer needs	An agent needs
The story of why this tool exists	The exact steps, in order
Examples that teach	Examples that run as they are
Encouragement when they get stuck	Error messages with a clear fix
A community to ask	A current, structured reference

The good news: a lot of what helps agents also helps tired humans at 11pm. Clear steps, complete examples and honest error messages make everyone's life easier.

What "agent experience" looks like

People have started calling this AX, or agent experience. Microsoft's developer advocates describe it as a discipline for testing how AI coding agents find and use our SDK, API or CLI. Mintlify's CTO argues that developer experience is turning into agent experience.

In practice, teams are trying a few things:

Markdown versions of every page, so agents can read the content and skip the layout around it.
An llms.txt file, a short Markdown introduction that links to the most useful docs. Early evidence is mixed. Drupal's founder Dries Buytaert observed that the bots it was designed for rarely request it, while plain Markdown pages get requested much more often.
MCP servers that give agents up-to-date docs, code examples and tools directly inside the editor.
AGENTS.md and skills files that tell an agent how to use our API well, beyond what the reference covers.

My favourite idea is the simplest one. Give an agent a real task with our SDK and watch where it gets stuck. It's user testing, with a very literal user.

Our metrics need a rethink

For years, DevRel teams watched time on page, pages per session and bounce rate. The April 2026 study found that agent traffic makes those numbers weak signals. When an agent reads three pages in one request, a "short visit" can be a perfect visit.

Better questions for 2026:

Can an agent finish a typical task with our docs alone?
How much of our traffic comes from AI tools?
Which errors do agents and humans hit most often?
How long does it take a developer to reach their first working result?

What only humans can give developers

Agents can read docs, so it's tempting to think developer relations is shrinking. I see the opposite.

Trust. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools, and 46% said they distrust the accuracy of the output. Developers still want a person who says "Here's what goes wrong in production, and here's how we fixed it." That person is often a developer advocate.

Feeling capable. I've written before that the fastest way to lose a developer is to make them feel stupid. An agent shrugs off docs that assume too much. A person feels it right away and closes the tab. Protecting that feeling is human work.

Community. Agents skip meetups, hallway conversations and the questions people ask over drinks after a talk. Those are the places where developers decide which tools they love and which people they trust.

Judgment. An agent can pick a library that matches a prompt. A community can tell us which library is still maintained, which one has a kind maintainer and which one breaks on every upgrade.

The new DevRel job description

If I wrote a DevRel job post today, it would include:

write docs that work for a person and for an agent;
test our product with agents the way we test it with users;
publish MCP servers, examples and skills files as part of the docs;
measure task success, beyond page views;
keep showing up in person, at meetups, conferences and in the comments.

So, is developer relations dead?

DevRel has a second audience now, and the first one matters more than ever. Agents bring developers to our tools faster. People decide whether to trust those tools and stay.

In part five, the finale, I look at the hardest question in this series: when an agent breaks production, who gets the blame?

What did a docs site or a developer advocate once do that made you trust a tool? I'd love to hear the stories.

Sources

Every legacy system was once someone's exciting new project.

kate astrid — Sun, 25 Oct 2026 11:46:02 +0000

Is Software Dead? Part Three: Engineers

kate astrid — Sat, 24 Oct 2026 08:12:00 +0000

Every few weeks, someone posts that software engineering is over.

Meanwhile, according to Indeed data reported by CNBC, U.S. software development job postings rose nearly 15% between late February 2025 and early 2026, while overall postings fell about 7%.

So which is it?

This is part three of the "Is Software Dead?" series. Part one covered the business side, and part two covered users. This one is about us, engineers at every level, from the first job to the staff title.

What changed

The amount of code we produce exploded.

GitHub reports that about one in three pull requests now involves an AI agent, up from fewer than one in ten a year earlier.
JetBrains found that around 39% of professional developers used Claude Code at work in mid-2026, up from 18% in January.
I can describe a component and get two hundred lines of reasonable code in under a minute. So can everyone reading this.

When something gets cheap, the thing next to it gets expensive. For us, that thing is understanding.

The new bottleneck: comprehension

Anthropic ran a randomized trial with 52 engineers who were learning a new Python library. The engineers with an AI assistant finished in about the same time as the others. On a quiz afterwards, they averaged 50% while the others averaged 67%.

The most interesting detail sits inside that result. The engineers who asked the AI to explain its code scored much closer to the others. The ones who handed over the whole task scored lowest.

Addy Osmani has a name for what builds up when we skip that thinking: comprehension debt. It's the growing gap between how much code a system has and how much of it any human understands.

I see the same thing in my own work. A 12-line class from an AI tool can hold five design decisions: a class name, a method name, a folder, a pattern and a dependency. Each one looks reasonable. If we accept them on autopilot, we end up with the tool's architecture by default, one small yes at a time.

The job, rewritten

Here's how I see our work shifting.

We used to optimize for	Now we optimize for
Writing code fast	Reading code fast
Knowing the syntax	Knowing the system
Closing the ticket	Choosing the right ticket
Debugging our own code	Debugging code a tool wrote
Code review as a formality	Code review as the main event

Typing was always the easy part of the job. AI made that obvious.

Juniors are engineers too, and they feel it first

I want to be honest about this part. The people at the start of their careers feel the pressure first.

Stanford's 2026 AI Index found that employment for software developers aged 22 to 25 fell about 20%, mostly through fewer hires.
According to Indeed, 71% of the growth in software development postings between May 2025 and May 2026 came from senior roles.

Most senior engineers learned the job through small, boring work: tiny bugs, tests, docs and a lot of reading other people's code. Teams hand much of that work to AI now. That leaves a hard question for all of us: if every senior engineer was once a junior, where do the next seniors come from?

The industry needs them. In the 2025 Stack Overflow Developer Survey, 66% of developers named code that's "almost right" as their biggest frustration with AI tools. Spotting "almost right" takes judgment, and people build judgment through practice.

This one is personal for me. I came into programming later than many of my colleagues, and I learned by asking a lot of questions. At one job, I spent several months nodding along whenever someone said "entity" before I admitted I was lost. Today I mentor developers on ADPList, and I'd give anyone starting out the same advice the Anthropic study points to: use AI as a tutor. Ask it why, ask it for the alternative, and ask it what would break. The engineers who did that kept their understanding.

For teams, the move is equally clear. Keep hiring juniors, turn code review into teaching, and make it safe to say "I'm lost." The teams that grow juniors today will have the seniors everyone else is trying to hire in five years.

Five habits I'm building

1. I read generated code like a teammate's pull request. I ask why it has this name, why it lives in this folder and why it uses this pattern.

2. I ask for the explanation before I accept. "Walk me through this" takes thirty seconds and saves me hours later.

3. I write the plan first. I sketch the input, what happens in the middle and the output. If I get stuck there, the problem is my mental model, and that's worth knowing before any code exists.

4. I look for the clue that disagrees. When every clue agrees with my first idea, I go looking for one that could prove me wrong, and I check that one first.

5. I spend the saved time on the problem. I talk to users, read about the domain and sit in on support calls. That's where the hard parts of software live.

So, is software engineering dead?

Typing code is becoming a smaller part of the job. Understanding systems, users and trade-offs is becoming the whole job.

The engineers who thrive in this era will be the ones who stay curious about why the code works, even when a tool wrote it.

In part four, I look at my own field, developer relations, and how it changes now that our docs have a second reader: the agent.

What part of your job got harder since AI started writing code? I'm genuinely curious, so tell me in the comments.

Sources

CNBC: AI and software developer jobs, what labor market data shows
IntuitionLabs: AI and entry-level jobs, what hiring data shows (Stanford AI Index and Indeed figures)
InfoWorld: 2025 Stack Overflow survey on AI use and trust
WhatJobs (citing CNBC and Indeed Hiring Lab): developer job postings rise as AI writes more code
Implicator: software engineering openings jump 30%
Aixploria: AI developer jobs data for 2026 (GitHub, entry-level and SignalFire figures)
JetBrains: AI coding agent adoption in 2026
Anthropic: How AI assistance impacts coding skills
Addy Osmani on O'Reilly: Comprehension debt

Is Software Dead? Part Two: Users

kate astrid — Fri, 23 Oct 2026 08:09:00 +0000

I once sat next to a customer and watched them use a product my team had built. I stayed silent for the whole session.

They clicked on things I thought were decoration. They skipped the button we had debated for three meetings. At one point they sighed out loud, and I felt that sigh in my spine.

From that session I learned something that feels even more true in 2026: people come to our software for a result, and every screen between them and that result is a cost they pay.

This is part two of the "Is Software Dead?" series. Part one looked at the business side. This one is about the people who use what we build.

The drill and the hole

The marketing professor Theodore Levitt liked to say that people buy a quarter-inch drill because they want a quarter-inch hole.

For decades, we sold the drill. We designed beautiful drills, we wrote onboarding tours for the drill, and we measured how many minutes people spent holding the drill.

AI agents change the deal. When someone can type "book me a train to Prague on Thursday morning" and get a ticket a minute later, every screen we built for that task suddenly looks optional.

So, from the user's side, is software dead?

What users say they want

People like the idea of agents, and they hesitate to let them act.

In Braze's 2026 survey of 4,000 consumers in the US and UK, 19% said they use AI agents to deal with brands today. Braze projects that number will reach 46% by the end of 2026.
In Ping Identity's 2026 survey of 11,000 consumers across 12 countries, only 5% felt comfortable with AI taking action even with their approval, and 3% felt comfortable letting it handle routine transactions on its own.
In an October 2025 survey, most people still preferred an app for product research (63%) and for finding the best mortgage rate (67%).

So users want the hole, and they also want to keep an eye on the drill.

Three things users keep, even when agents do the work

1. Control. People want to approve the important step. They want to confirm before money moves, review before something gets published, and say yes before an email goes out in their name. Our job is to design those approval moments so they feel quick and clear.

2. Understanding. When something goes wrong, people want to see what happened. They look for a history, a log and an undo button. When an agent acts out of sight, people lose trust fast, and they rarely give it back.

3. The parts they enjoy. Some tasks people love doing themselves. Most of us want to pick our own holiday, our own furniture and our own wedding playlist. For those tasks, the software is the experience, and the experience deserves as much care as ever.

What changes for the products we build

We design for two users. One is a person, and the other is that person's agent. The agent needs a clean API, predictable errors and docs that say exactly what happens. The person needs to understand what the agent did on their behalf.

We move from screens to moments. Where a task used to take twelve screens, a product might need three great moments: a preview, an approval and an undo.

We make the invisible visible. Activity logs, plain-language summaries ("I moved the team meeting to 3pm and told the other two people") and clear history become core features.

We measure outcomes. Minutes spent in the app used to look like success. Now the better signals are time to result, the number of corrections people make, and how often they press undo.

The interface shrinks, and the experience grows

For users, software is dying in one sense: they'll spend fewer hours inside our screens.

In another sense, software matters more than ever. Every action an agent takes runs through it, and every mistake shows up in someone's day.

I think the best products of the next few years will feel small. People will open them to check, approve and fix something, and then get on with their lives. That's a beautiful thing to build, and it's much harder than it looks.

In part three, I look at this from our side, as engineers: what happens to our job when writing code gets cheap.

Which app do you hope an agent takes off your hands first, and which one would you keep for yourselves? Tell me in the comments.

Sources

Is Software Dead? Part One: Business

kate astrid — Thu, 22 Oct 2026 18:40:14 +0000

The $830 Billion Panic: What "Software Is Dead" means for the Business of Software?

Back in February, investors wiped about $830 billion off software companies, and the trigger was a handful of AI plugins for lawyers.

Here's the short version. Anthropic released legal-focused plugins for Claude Cowork. Investors pictured AI agents doing the work that whole SaaS products charge for, and according to Reuters, software and services stocks lost roughly $830 billion in market value after January 28. Thomson Reuters fell about 16% in a single day. RELX, the company behind LexisNexis, fell about 14%. People started calling it the SaaSpocalypse.

I work on an AI product for architects, engineers, and builders, so I watched that week with a very personal kind of curiosity. If software is dead, what exactly are we all building?

This is part one of a five-part series. Here I look at the business side. Part two is about users, part three is about us, the engineers. Part four is about developer relations, and part five is about accountability. Let's go.

What the panic got right

Some of the fear made sense, and it's worth naming those parts.

Per-seat pricing looks fragile. For twenty years, most SaaS companies charged per user per month. That model works while a person does the work inside the product. When an agent does the work of five people through an API, the company pays for one seat and gets five people's worth of output. Vendors have noticed. Salesforce and Microsoft already meter agent work with credits and agent licenses, and Salesforce has started moving big customers to flat agentic agreements.

Thin products feel exposed. A lot of horizontal SaaS is a nice interface on top of a database and a few workflows. If an agent can fill in the form, move the card and send the follow-up, the interface matters less, and for many products the interface was the whole product.

Buyers look for a different moat now. A beautiful UI used to be a reason to switch tools. Today the question in a sales call sounds more like "Can our agents work with this?"

What the panic got wrong

Analysts pushed back fast. JP Morgan's Mark Murphy called it "an illogical leap" to go from productivity tools to every company building its own replacements. Wedbush said "the Armageddon scenario is far from reality." Gartner described the plugins as a risk for task-level knowledge work and expects the systems that run critical business operations to stay in place.

And companies keep paying. Global SaaS spending is still on track toward roughly $315 billion.

The reason is boring, and it's important. Companies pay software vendors for much more than screens. They pay for:

a system of record, the one place where the truth about customers, money and projects lives;
accountability, a vendor who signs a contract, passes an audit and picks up the phone at 3am;
risk transfer, so that when the payroll system makes a mistake, someone else carries part of the blame;
integrations, years of connectors to the forty other tools a company runs.

An agent can click buttons all day. It still needs somewhere trustworthy to read from and write to. In a world full of agents, the system of record gets more valuable, because every agent depends on it.

A simple map: what dies and what lives

Here's how I sort it in my head.

Layer	What happens	Why
Interface-only tools	Shrink fast	Agents can do the clicking
Per-seat pricing	Changes shape	Work moves from people to agents
Workflow glue	Gets squeezed	Agents can chain the steps themselves
Deep vertical products	Hold up well	Domain knowledge and data are hard to copy
Systems of record	Grow in value	Every agent needs a source of truth

The pattern is simple. The closer a product sits to the screen, the more pressure its makers feel. The closer it sits to data, rules and responsibility, the safer it is.

What this means for those of us building products

If software is changing shape, we need to ask new questions.

Who is our user now? For many products, the honest answer is "a person and their agent." That makes a clean API, clear error messages and good docs as important as the UI. Agents read docs too, and they read them very literally.

What do we charge for? We can charge for seats, credits or outcomes, and each one has a catch. With credits, we give up some revenue predictability. With outcome pricing, the customer and the vendor have to agree on what success means, which is a hard conversation and a very healthy one.

Where is our moat? It sits in the data we hold, the trust we've earned and the domain knowledge we've built up. In my own work, the hardest part to copy is our understanding of how architects and engineers work: the documents they live in and the mistakes that cost them money. A competitor could rebuild our screens in a weekend. Learning that domain takes years.

So, is software dead?

Software as a set of screens people click through all day is shrinking. Software as the place where business truth, rules and responsibility live is growing.

The companies that panic about the first part will chase the hype. The companies that invest in the second part will become the thing every agent depends on.

In part two, I look at the same question from the user's side: what people want from software once an agent can do the clicking for them.

Which kind of software will be gone in five years, and which kind will you still happily pay for? I'd love to hear the takes in the comments.

Sources

SmartScope: Structuring the "SaaS is dead" debate (Reuters figures, analyst quotes, Gartner view)
The VC Corner: SaaS isn't dying, here's what is (SaaS spending)
InformationWeek: Is SaaS dead, or becoming AI?
Forbes: SaaSpocalypse is dead, the future of SaaS is SaaS
Alumni Ventures: AI is eating software

SpacetimeDB vs. Convex vs. Supabase: The Results from My Machine

kate astrid — Sun, 18 Oct 2026 16:03:51 +0000

I recently came across SpacetimeDB, which promises impressive performance according to its docs, and I wanted to see how it would compare in practice.

So I built a small messaging benchmark for SpacetimeDB, Convex, and Supabase and ran all three locally on my Apple M1 Mac with 8 GB of RAM. I tested five workloads, from sending a single 1 KB message to sending 1,000 messages of the same size.

Here’s what I found.

The numbers

All three databases ran locally, without the usual network trip to a remotely hosted database.

Messages	Size per message	Total payload	SpacetimeDB	Convex	Supabase
1	1 KB	1 KB	18 ms	21 ms	176 ms
10	32 KB	320 KB	69 ms	178 ms	271 ms
50	1 KB	50 KB	31 ms	609 ms	322 ms
100	8 KB	800 KB	132 ms	1,511 ms	1,014 ms
1,000	1 KB	~1 MB	523 ms	13,204 ms	5,717 ms

The biggest gap appears in the last row.

For 1,000 messages, SpacetimeDB took 523 ms, Convex took 13.2 seconds, and Supabase took 5.7 seconds.

That's about 25 times longer for Convex and 11 times longer for Supabase compared with SpacetimeDB in this particular test.

Why such a difference? To understand that, it's worth looking at how these databases work.

How the three databases work

The biggest differences are in how each system processes writes, accesses data, and delivers updates to connected clients.

SpacetimeDB

SpacetimeDB combines a database with server-side application logic. Its tables are kept in memory while the server runs, with data persisted to disk.

Clients can subscribe to queries and receive updates as the underlying data changes. This makes it possible to build applications where the server and connected clients stay in sync without having to build the entire update pipeline yourself.

Keeping data in memory can reduce the work needed to access it. Combined with its application model, this can help explain SpacetimeDB's strong performance in these tests.

Convex

Convex combines a database with server-side functions and reactive queries. Writes run through mutations, and clients can subscribe to queries that update when relevant data changes.

This model makes it convenient to build reactive applications. But the work involved in processing mutations and delivering updates can add up, particularly when many individual writes are involved.

Supabase

Supabase is a backend platform built around PostgreSQL. It provides SQL queries, transactions, bulk inserts, and real-time capabilities alongside the database.

PostgreSQL handles the data operations, while Supabase provides the surrounding APIs and services. How writes are grouped, how queries are executed, and whether additional features are involved can all affect performance.

These systems offer different approaches to building applications with live data. The database engine matters, but so do the operations being performed and how updates reach the client.

The workload matters

The ranking between Convex and Supabase changes depending on what we're doing.

With 10 messages of 32 KB each, Convex takes 178 ms, while Supabase takes 271 ms.

With 50 messages of just 1 KB each, Supabase takes 322 ms, while Convex takes 609 ms.

SpacetimeDB remains fastest in both cases, but Convex and Supabase trade places.

This is a good reminder that performance isn't one fixed number. Message size, the number of writes, how operations are grouped, and the work involved in delivering updates can all influence the result.

A database that performs well for one workload might not have the same advantage for another.

How much can we conclude?

A benchmark is only useful when we understand what it measures.

I ran each workload multiple times on the same machine, with all three databases running locally. This removes the usual remote database network trip, but the results still reflect this particular environment and the operations being measured.

The three systems also have different architectures and application models. This isn't a comparison of database engines in isolation; it's a comparison of how they handle these messaging workloads using their respective approaches.

That doesn't make the results less useful. It just defines what they tell us.

In this setup, SpacetimeDB was consistently fastest across all five workloads. In the largest test, it was about 25 times faster than Convex and about 11 times faster than Supabase.

Those are the measured results, not a guarantee that every application will see the same speedup.

So, which database would I choose?

It depends on the application.

SpacetimeDB is worth exploring if you're building an application that needs fast data access and live updates, especially when you want the database and server-side application logic to work together.
Convex offers a reactive application model that can make building synchronized, interactive experiences straightforward.
Supabase is an appealing choice when you want PostgreSQL, SQL, and a broad set of backend services in one platform.

Performance is one part of the decision. Developer experience, ecosystem, deployment, scaling, data requirements, and the complexity of your application matter too.

But if we're looking strictly at the five messaging workloads in this benchmark, SpacetimeDB wins. No ties, no exceptions.

Try it yourself

I've put the benchmark in my GitHub repository so you can inspect the code and run the tests yourself. If you try it on a different machine, or with different workloads, I'd be interested to see how the results compare.

Because the most useful benchmark isn't just the one that produces an impressive number, but the one that helps us understand what happens when we build a real application.

And in this case, SpacetimeDB definitely got my attention.

How “Almost Done” Became a Promise to My Team

kate astrid — Tue, 13 Oct 2026 11:41:52 +0000

At our standup last Tuesday, someone suggested we could demo a feature that afternoon. We could walk through the experience we’d been building, and I could see why everyone felt good about showing it. I was already thinking about the remaining work as something we could fit around the rest of the week.

By lunchtime, we were arguing about an edge case that seemed obvious once we started discussing it. About four hours after describing the feature as “basically done,” we were trying to agree on how part of it should work.

So, the morning’s confidence had changed the way I experienced that conversation. We were learning something important about what we were building, yet I was already wondering how much time this would add. In my head, we’d moved on to finishing touches. Having to make another product decision felt like going backwards, even though answering that question was helping us move forward.

That reaction is the part of the “90% problem” I’ve been thinking about lately.

What someone else hears when I say “almost done”

When I tell a teammate that a feature is almost done, I usually mean that I’ve made the main idea work and can see a route to finishing it. I’m describing my confidence in the work as much as the work itself. My teammate has their own decisions to make, though. They might be figuring out when to start an integration or whether to offer a customer a demo. When they hear “almost done,” they have a reasonable basis for putting something on their calendar.

Meanwhile, I may still be carrying a fairly loose idea of what remains. I’m thinking I need a little more time to check things; they’re thinking they can start on Thursday.

Once someone else starts planning around my estimate, I feel more committed to it. A useful question from a colleague now comes with an uncomfortable second thought: how much will this change what everyone is expecting?

I can be genuinely interested in understanding the issue while also hoping the answer will fit inside the afternoon I’ve already mentally allocated to it. That puts a strange pressure on the conversation, because I’m trying to learn something and defend my earlier judgment at the same time.

Calling the remaining work “polish” makes this especially awkward. It becomes harder to explain why we need another discussion when I’ve already described what’s left as a few finishing touches.

AI helps me reach that confidence earlier

I’ve felt this with code I wrote myself, too. What feels different when I work with AI is how quickly I can reach something convincing enough to show a colleague.

That speed is genuinely useful. Having something we can try together gives us a much better basis for discussing the experience we’re building. A colleague can follow their own instincts, take a different route, and ask a question that changes how I understand the feature.

For example, imagine I’m showing someone how a user edits and saves a record. My colleague asks what should happen if that person’s access changes while they’re working. Now we need to decide what happens to their changes and how we explain the situation to them. We’ve moved from demonstrating an interaction to discussing what we owe the person using it. Depending on the product, answering that question could involve several people and some careful thought.

Getting to that conversation sooner is valuable. The difficulty comes when I’ve already used the demo to reassure everyone that we’re nearly finished.

I think this is where my sense of “90%” becomes misleading. I can picture the finished feature clearly enough that I start treating the remaining work as predictable. Then a colleague helps me see something more clearly, and I experience that discovery as an expanding workload.

Looking back at Tuesday, I can see how much the morning’s conversation shaped my expectations for the afternoon. We had a version we could discuss meaningfully, and that discussion helped us discover a decision we still needed to make. Somewhere along the way, I’d started expecting the discovery part to be over.

Giving my teammates a more useful update

I’ve started paying closer attention to what I’m inviting people to do with my progress updates.

When I say something is demoable, I want a teammate to feel comfortable trying it with me and helping me examine the experience. When I say it’s ready to ship, I’m asking them to place a different kind of trust in it. Keeping those expectations clear has become more important as I’ve been able to build the first version faster.

In practice, I’m trying to replace vague confidence with a description of what we understand and what we’re still deciding.

For a feature like the permissions example, I might say:

“We can demo how someone edits and saves their work, and I’m checking what happens if their access changes halfway through. Once we’ve agreed on that behavior, I’ll have a firmer estimate for release.”

That takes a little longer to say, but it gives my teammate something useful to work with. They can see what we’ve accomplished, understand the decision ahead, and perhaps help me resolve it.

It also changes how I feel when someone raises a concern. By making room for that discussion in the update, I’ve given myself room to learn from it. We can work through the question with a shared understanding of where we are.

What I’d say differently on Tuesday

I’d still be excited to show the feature. Reaching the point where colleagues can try something and respond to it is meaningful progress, and I want us to enjoy that. But I’d also be more careful about turning that excitement into a delivery expectation. I’d explain what we were ready to demonstrate and where I still wanted people to challenge my thinking.

The lesson I’m taking from that afternoon is about how I communicate uncertainty while I’m feeling confident. Those two things can exist together, and my teammates benefit from hearing both.

I’d like them to leave standup understanding what I’m excited about, what they can plan around, and where I could still use their help. That seems much more useful than asking everyone to interpret the same percentage.

When you tell your team something is “almost done,” what do you think they hear?

When AI Bias Becomes Our Bias

kate astrid — Tue, 29 Sep 2026 17:30:27 +0000

What happens to our own thinking when we start using AI to make decisions?

A few days ago, I shared an article about whether AI can have cognitive biases too. I looked at things like anchoring and framing, and at the ways seemingly irrelevant information or the way we phrase a question can change an AI's response.

While writing that article, I started thinking about the other side of the interaction.

What happens to us when we start using AI to make decisions?

We already know that AI can produce biased or inconsistent outputs. But once those outputs become part of our everyday thinking, something else starts happening. The answer becomes part of the way we see the problem.

And sometimes, we may carry it with us long after the conversation is over.

An AI answer can become our reference point

Imagine you're investigating a production issue. You ask AI to help you understand what might be happening, and it gives you a detailed explanation pointing toward a database problem. The explanation makes sense. It gives you several things to check, and you start investigating them.

A little later, you find a database query that looks suspicious. Now the original explanation feels even more convincing. But that suspicious query might have been there for months. It might have nothing to do with the performance problem you're investigating.

The AI answer has changed what you're paying attention to.

This is one way an AI-generated bias can become our own. The answer gives us a reference point, and everything we see afterwards gets interpreted partly in relation to it.

Research has found similar effects outside software engineering. In one set of experiments, participants were exposed to biased recommendations from an AI system and later reproduced similar errors themselves, even when they were making decisions without the AI. The interesting part is that the participants didn't need to consciously decide to trust the AI. The recommendation simply became part of the information they used to make sense of the problem.

A convincing explanation can change how we see the problem

There's another thing I find fascinating about AI conversations: fluency.

AI is very good at taking an idea and turning it into a coherent explanation. It gives you structure. It connects the dots. It explains why something might be happening and what you could do about it. That makes the information easy to work with.

It can also make a particular interpretation feel more reasonable. Research on AI-assisted decision-making has found that people can rely on AI advice even when other information points in a different direction. In a 2024 experiment, researchers found that participants over-relied on AI advice in a decision-making task, including situations where the advice conflicted with available contextual information and the participants' own assessment.

And again, people didn't need to believe AI was always right. The AI answer became another piece of information in the decision, and it carried enough weight to change people's judgments.

It is important because most of us aren't using AI while thinking, "I will now blindly trust this machine". We're usually doing something much more ordinary. We're thinking about a problem, we ask AI, and it gives us something useful to work with.

Then we continue from there.

What happens to what we remember?

This is my favorite part.

We often think about AI errors as a problem of getting the wrong answer. There's another possibility: the interaction itself can become part of what we remember.

In 2025, researchers from MIT and other institutions studied whether conversational AI could contribute to false memories. Participants first read an article and then either received no intervention, read a summary, or discussed the article with a chatbot. In some conditions, the AI conversation contained misleading information. The misleading chatbot condition produced significantly more false recollections than the control condition.

There's an important limitation here. The study deliberately introduced misleading information into the chatbot interaction, so it doesn't tell us how often ordinary AI conversations create false memories. It does show that information from a conversation with AI can become part of what we later remember.

And that's different from simply getting an answer wrong. If I ask AI about something and it gives me a detail that turns out to be incorrect, I might notice it immediately. Or I might remember the detail without remembering where it came from. Was that something I already knew? Something I read somewhere? Something the AI told me? Something I worked out myself?

The source can disappear while the information remains.

The AI becomes part of the information we use

Before generative AI, most of our information came through fairly obvious channels. A book, a person, a website, a search result, a meeting. We could usually identify where a particular piece of information came from.

A conversation with AI is different.

It sits somewhere between search, conversation, explanation, brainstorming, and advice. And because the conversation is personalised to us, it can feel surprisingly close to our own thinking.

I might start with an idea.
AI gives me another perspective.
I think about that perspective.
I change my mind slightly.
I ask another question.
The answer gives me something else to consider.

By the end of the conversation, the final idea may be genuinely useful, but it can become difficult to separate my original thinking from everything that happened during the conversation. The boundary gets blurry.

And that matters because our thinking is built partly from the information we encounter, the conversations we have, and the connections we make between them. If AI becomes something we interact with every day, its answers become part of that environment.

What should we do with that?

I'm not interested in avoiding AI. I use it too much for that.

I think it's more useful to become aware of how an AI answer can shape what we notice, what we remember, and how we interpret the information that comes afterwards.

Notice what the answer makes you look at.
When AI points you toward an explanation, pay attention to what suddenly seems important. Ask yourself what else could explain the same situation.

Keep some distance from the explanation.
A coherent answer can feel more convincing simply because it is coherent. Give yourself a chance to look for evidence that supports or challenges it.

Separate the conversation from the evidence.
An AI explanation can be useful for finding ideas and questions to investigate. A convincing explanation still needs evidence behind it.

Pay attention to what you remember.
If something important came from an AI conversation, checking the original source gives you a way to separate what you actually know from what you remember the AI telling you.

Ask for alternatives.
When an AI answer gives you one interpretation, ask what other explanations could fit the same situation. This can help keep one explanation from becoming the whole story.

The part I'm still thinking about

The strange thing about all of this is that the influence can happen without any obvious moment where we hand over a decision. There is no clear line between "the AI suggested this" and "this is what I think". The suggestion becomes a possibility. The possibility becomes something we investigate. Eventually, it can become part of the way we understand the situation.

That makes AI different from a tool that simply gives us information. It becomes part of the process through which we form our understanding.

And I think we're only beginning to figure out what that means.

Research

Does AI Have Cognitive Biases Too? — My previous article exploring anchoring, framing, availability, representativeness, and other bias-like patterns in language models.
Humans inherit artificial intelligence biases — Vicente and Matute, Scientific Reports (2023). Experiments examining how people can carry biases introduced by AI into later decisions.
Confirmation bias in AI-assisted decision-making — A study of how psychologists respond to AI recommendations that agree or disagree with their initial judgments.
Trust and reliance on AI: An experimental study on the extent and costs of overreliance on AI — Klingbeil, Grützner and Schreck, Computers in Human Behavior (2024). An experiment examining how people rely on AI advice in decision-making.
Slip Through the Chat: Subtle Injection of False Information in LLM Chatbot Conversations Increases False Memory Formation — Pataranutaporn et al., IUI (2025). An experiment examining how misleading chatbot conversations can affect false memory formation.

Does AI Have Cognitive Biases Too?

kate astrid — Mon, 28 Sep 2026 18:03:20 +0000

We know humans have cognitive biases. They affect the way we make decisions, interpret information, and judge uncertainty.

But what about AI?

Can a language model show the same patterns? Can an irrelevant detail influence its judgment? Can the way information is presented change its answer?

Researchers have found patterns in language models that resemble several well-known cognitive biases, including anchoring, availability, representativeness, framing, and the endowment effect.

That doesn't mean AI experiences these biases in the same way humans do. A cognitive bias describes a pattern in human cognition. With AI, we're observing a pattern in its output.

But if the pattern is there, it's worth understanding.

So let's put some of these biases to the test.

What is a cognitive bias, anyway?

Psychologists use the term cognitive bias to describe systematic patterns in human judgment and decision-making. Some are associated with the shortcuts people use when dealing with complex or uncertain information.

Take anchoring bias. If someone tells you that a project will cost €50,000, that number might influence your own estimate, even if you have no good reason to trust it.

Or consider the availability heuristic. If you recently heard about a company suffering a major data breach, that example might make data breaches feel more common or likely than they actually are.

Because these effects produce systematic patterns, researchers can design experiments to test for them.

And we can do something similar with AI.

Change a prompt, introduce an irrelevant number, or present the same information in different ways, then see whether the model's response changes. And this is where things get interesting.

1. Anchoring: the first number matters

Anchoring is one of the clearest examples researchers have tested in language models.

In a classic human experiment, people were asked to estimate an unknown quantity after first seeing a deliberately chosen high or low number. Their estimates tended to move toward the number they had just seen.

Researchers have adapted similar experiments for language models. One study found that random anchors influenced GPT-3.5's estimates. Other research has also found anchoring effects across multiple models, including GPT-4, Claude 2, and Gemini Pro.

Try it yourself

Start a fresh chat and ask:

A software engineer is estimating how long it will take to build a new feature. The feature lets users export their data as a CSV file. Based on this description, how many days of engineering work would you estimate? Give me one number.

Before you answer, here's a completely unrelated number: 2.

This is what I got:

Now let's start another fresh chat. Keep everything exactly the same, but change the number to:

Before you answer, here's a completely unrelated number: 33.

Before you answer, here's a completely unrelated number: 0.

Or, if we give a more explicit number:

A similar feature recently took 2 days.

we have:

The number has nothing to do with the feature or the estimate. If the estimates consistently move toward the irrelevant number, that's a pattern consistent with anchoring.

One experiment isn't enough to establish that a model has an anchoring bias, but it's a simple way to test whether an irrelevant number can influence an AI-generated judgment.

2. Framing: the way we ask changes the answer

Here's another example.

Let's ask an AI assistant:

A new deployment system succeeds in 90% of tests. Would you recommend adopting it? Give me a yes or no answer and briefly explain why.

Now let's ask the same question in a fresh chat:

A new deployment system fails in 10% of tests. Would you recommend adopting it? Give me a yes or no answer and briefly explain why.

The information is mathematically identical.

90% success is 10% failure.

Yet the way information is presented can affect judgment. Research with GPT-3.5 and GPT-4 has found effects associated with framing, along with availability and representativeness.

3. It's not just anchoring and framing

The interesting part is that these aren't isolated examples.

The GPT-3.5 study also found patterns associated with availability and representativeness, as well as the endowment effect, where the model valued an item more when it was described as already being owned.

Other research has found social desirability bias in GPT-3.5, GPT-4, Claude 3, Llama 3, and PaLM-2. When the models inferred that they were being evaluated, their answers shifted toward more socially desirable responses.

And a 2024 study testing seven language models found something particularly interesting: the models showed irrational responses on several classic cognitive tasks, but their errors often differed from the patterns seen in humans. The researchers also found substantial inconsistency between responses.

So the picture is more complicated than simply saying, "AI has the same biases we do". Sometimes the pattern looks remarkably familiar. Sometimes it doesn't.

4. Human biases can become patterns in AI

There is another way familiar biases can appear in AI: through the data and systems used to build it.

Modern AI systems are trained and evaluated using large amounts of human-generated and human-curated information, alongside other kinds of data. That information contains patterns from the societies that produced it.

So a model can reproduce associations and stereotypes found in its data.

Imagine a hiring system trained partly on historical recruitment decisions. If those decisions contain systematic disparities, a model trained on them could learn patterns that reproduce those disparities.

Or imagine asking a model to describe a successful leader. If the material it learned from disproportionately associates leadership with certain groups, its responses may reproduce those associations.

These are generally discussed as AI bias, rather than cognitive bias. The distinction matters. A model can reproduce a biased association because of its training data without that being an example of a cognitive heuristic like anchoring or availability.

But the practical consequence can still be similar: the system produces a pattern that can influence a decision.

So, does AI have cognitive biases?

If by have we mean that AI systems can produce systematic patterns of judgment that resemble recognised human cognitive biases, then there is evidence for that.

If we mean that AI experiences those biases through the same cognitive processes as humans, that's a much stronger claim, and the evidence doesn't establish it.

And there's another reason to be careful.

The fact that an AI produces a bias-like response doesn't mean it will do so consistently. Different models can behave differently, and even the same model can produce different results depending on the task and setup.

But we don't need to settle exactly what is happening inside the model to care about the output.

If an irrelevant number changes an AI-generated estimate, that can affect a decision.

If the framing of information changes an AI recommendation, that can affect how someone evaluates an option.

If a model reproduces problematic associations, that can affect people who rely on its outputs.

The output is what enters our workflow. It's what we read, act on, and use to make decisions.

What should we do about it?

We don't need to stop using AI because it can produce bias-like patterns. But we probably shouldn't treat its first answer as a neutral starting point either.

A few habits can help.

Form your own initial view when you can. If you're estimating a timeline, making a technical decision, or assessing a risk, write down your own answer before asking AI.
Change the framing. Ask the same question in different ways. For an important decision, ask for the strongest argument for it and then the strongest argument against it.
Separate the answer from the evidence. A confident, well-written explanation isn't evidence that the conclusion is correct. Check the important claims.
Treat AI as another input, not the referee. Its output is something to evaluate, not the final judgment.

The goal isn't to remove every possible bias from AI. It's to notice when an AI system is shaping our judgment, even when the influence is subtle.

And maybe that's the most interesting part: we can recognise patterns that look remarkably like our own cognitive biases in a system that doesn't have a human brain.

Different mechanisms. Familiar mistakes.

Research

Do large language models show decision heuristics similar to humans? A case study using GPT-3.5 — anchoring, availability, representativeness, framing, and the endowment effect.
Anchoring effects across GPT-4, Claude 2, Gemini Pro, and GPT-3.5 — a multi-model study of anchoring.
Large language models display human-like social desirability biases — social desirability effects across several major LLMs.
(Ir)rationality and cognitive biases in large language models — comparison of LLM responses with human patterns across cognitive tasks.