The Lightcone

Paul Copplestone on building for agents, not just humans

Paul Copplestone· Co-founder & CEO at Supabase
·~49 min·English·Y Combinator
AgentsAI InfrastructureOpen SourceBusiness Strategy
TL;DR

Supabase's Paul Copplestone explains how a database company re-architected itself around agents — code-first interfaces, self-healing error messages, and a personal data layer you own — now that 70% of new activity comes from AI, not humans.

01The Shift

Make something agents want

Supabase's famous YC maxim flipped in a year: with 70% of new activity now coming from agents, the customer to design for is increasingly the model, not just the human at the keyboard.

this year especially what we've seen in terms of the numbers, the inflection is just a huge shift towards agents

— Paul Copplestone, The Lightcone
Key Insight
The numbers signal a deeper change: agents are increasingly the ones spinning up databases, so Supabase is adapting to a customer base that now includes models.
02The Pivot

Agents made code-first the new interface

Supabase rebuilt itself around how agents actually work — command-line tools and infrastructure-as-code — because agents mostly build through code, not dashboards.

we try to have the modalities that the agents really want to build with, which is code-first. They really want to use CLIs most of the time

— Paul Copplestone, The Lightcone
Key Insight
The pivot reframes developer experience as agent experience: code-first interfaces and CLIs make it easier for agents to build with Supabase, while dashboards remain useful for people.
03The Playbook

Two stages to winning the agents

Getting chosen by the model is only half the battle; the other half is making sure an agent that gets stuck can fix itself instead of switching to a competitor.

there's like two stages to winning the agents. The first is being picked by the model, and then the second is like if they get stuck, you don't want them to switch away

— Paul Copplestone, The Lightcone
Key Insight
Retention becomes a property of your error messages. A human who hit a cryptic '500' would go Google it; an agent will silently switch vendors, so the fix for an error is now shipped inside the error itself — documentation rewritten as a recovery instruction the model can act on.
04The Data Layer

Own your own database

If your whole life — health, finances, CRM, files — lives in one database you control, agents become swappable tenants on top of it instead of owners of it.

you want to own your own database and then build all the applications or agents on top of it versus having that all in like someone else's database

— The Lightcone host
Key Insight
This quietly inverts the usual power structure of consumer software. The valuable, sticky asset is not the app or the agent but the store of record underneath — so the strategic move for a user is to keep their data in a layer they own and treat even the smartest agent as a replaceable client of it.
05The Bottleneck

Builders, not engineers

When anyone can build on tap, the scarce skill is no longer writing the code but knowing what is worth building.

the much harder thing to do is to know what to build. You know, being able to build is something that anyone can sort of have on tap now

— Paul Copplestone, The Lightcone
Key Insight
It relocates the moat from implementation to judgment. Domain experts who could never convince an engineer to join them can now ship directly into their niche — so the constraint on value shifts from engineering headcount to the far smaller pool of people who know which problems are real.
06The Method

Testing is the new building

As models write more of the code, Supabase's engineering effort moves from writing features to testing specific use cases — and agents loop on evals to improve themselves.

pretty much now a lot of our engineering effort is going into like testing specific use cases rather than the building

— Paul Copplestone, The Lightcone
Key Insight
Evals become the steering wheel for code an agent wrote. Once a use case has a measurable score, you can point an agent at it continuously — ship anything that improves the number, record why the rest failed — which is a narrow, practical version of self-improvement running inside everyday engineering.
07The Scale

One starting point has to span prototypes and petabytes

Serving a world where over a million databases spin up every week — and, by Paul's napkin math, a hypothetical 1.2 billion a month — means one starting experience that scales from throwaway prototypes all the way to petabytes.

let's say all of them want to launch something every month, that's 1.2 billion databases a month

— Paul Copplestone, The Lightcone
Key Insight
Mass prototyping is itself a new class of database workload. Most of those databases will never need a heavy cluster, so the hard engineering problem is no longer peak scale but the long tail — making the cheap, disposable end effortless without closing the door on the few that become real businesses.
08The Wager

Bet on a durable category

Paul's calm comes from the Lindy effect: databases have lasted 50 years, will likely last another 50, and the only edge left is adapting faster than anyone else.

One thing that helps me sleep well at night is that it's kind of the Lindy effect. Databases have been around for 50 years

— Paul Copplestone, The Lightcone
Key Insight
Durability of the category buys the freedom to be reckless about the tools. If the underlying need is permanent, you can throw out your own dashboard, your own API, your own assumptions each wave — the risk lives in the interface, never in the bet itself.