> "Going into 2026 the single best way to build an "AI native startup" is to build an API first product that can easily be used by Claude Code. I believe in this so much that I think by 2030 any product without an API designed for agents will be dead."
IOW, a human customer is not the customer your business is going to directly serve, their agent is. What's required from the human is to provide a payment method, I assume, else it's not a real customer, but a free-tier user.
Without a strong propsition as to why I, as a customer, would use an agent over not doing so? Whats the value prop?
Thats always missing from these sorts of articles and comments, is why is this better
Related query: how is this really any different than what the W3C has proposed with Hydra[0] or other linked data APIs and formats? Who benefits by making their APIs more transparent, when 15 years or so ago there was a big push for this exact thing and it failed due to business concerns, not technical ones.
It's simply assuming what the way forward is without positing why other ways will not work to justify the position.
My secondary critque of the article, is using this as a basis of comparison:
>any product that can't be used by an agent will be as dead as a product without mobile support is today
First, I think its important 'mobile support' is defined. Is it as simple as a mobile friendly website or an app? Are we talking equivalent functionalities as well with the desktop counterpart?
Second, it ignores a ton of successful projects and products. Blender, Maya, Unreal engine. There's also a huge swath of games that only launch on PC or consoles.
If equivalent 1:1 functionality is to be considered, Adobe suite is still primarily a desktop tool, as is Figma.
I know there are a huge host of apps I'm missing too.
While more consumer apps migrated to web + mobile, you can often find functional differences between accessing on desktop vs mobile, where desktop is more complete. Its still not uncommon to have a mobile / tablet version of an app that is missing features that the desktop or website version is not.
I'm going to say an unpopular opinion here: I think agents are going to turn out mostly useless, even if they worked almost perfectly.
How many jobs involve purely clicking things on a computer without human authorities, rules, regulations, permits, spending agreements, privacy laws, security requirements, insurance requirements, or licensing gates?
I wager, almost none. The bottleneck in most work isn't "clicking things on a computer." It's human judgment, authorization chains, regulatory gates, accountability requirements, and spending approvals. Agents automate the easy part and leave the hard part untouched. Meanwhile, if the agents also get it wrong, even 1% of the time, that's going to add up like compound interest in wasted time. Anything that could actually be outsourced to an agent, would have already been outsourced to Kenya.
> I think by 2030 any product without an API designed for agents will be dead
And I think that products making billions today by only exposing a 20yo SOAP API are still going to make billions in 4 years.
I hate having to work with them, but I've been playing this game long enough to know that most of the world is running on legacy software and it won't change in about 1400 days.
I use claude code daily, but I've never been in a situation where Claude code was "deciding which product to use," that doesn't make sense to me. Claude is never on the web reading documentation - as far as I can tell that's not even in its toolkit. Can anyone give me more context for this? How do you end up having Claude code reading documentation and "choosing" a product to use? What type of prompts lead to this? I'm typically using it to add features to an existing repo, which doesn't really require any new services, to be fair, so I just haven't run into it I guess, but I didn't even know it was possible.
I can't count how many times I could have made an API that no one would use. I would also have to document it at which I'm exclusively terrible (I find out later trying to make sense of my own docs) I can now generate and test the docs which changes everything.
I wonder, could a spa (while still doable) now be the wrong approach? The logic will have to be in the API, why have it twice? It seems offloading work to the client might just add bloat. Could it be that if the website works with [dumb] queries the AI won't even need to read docs?
I can see the point of agent-first workflows in the future where we interact with agent UI instead of SaaS/PaaS dashboards but I don’t think every other problem and subsequently a solution will need to be agentified. A massive chunk of interactions would still require a good-old UI i.e. filing taxes, signing contracts, banking, e-government etc.
I recently had to fill out a PDF form to send it to the Social Security Admininistration. They didn't have the option of submitting it online so I had to print it out and take it to them.
I filled out the PDF using FireFox PDF-editor, at which point it occurred to me, this is not so different from using an application which has a form for me to enter data into it.
Maybe in a few years Government has a portal where I can submit any of their forms as PDF documents, and they would probably use AI to store the contents of the form into a database.
A PDF-form is kind of a Universal API, especially when AI can extract and validate the data from it. Of all the API-formats I've seen I think PDF-forms is the most human-friendly. Each "API" is defined by the form-identifier in the PDF-form. It is easy for humans to use, and pretty easy for office-clerks to create such forms, especially with the help of AI. I wonder will this, or something similar, catch on?
The loop closes eventually. Right now I read your article and think "I should make my docs more agent-friendly." But if I delegate that task to an agent, the agent reads your article, understands why agent-friendly docs matter, and rewrites my docs accordingly.
At some point the agents reading your article ARE the agents that will consume those improved docs. The feedback loop becomes fully autonomous.
Is the idea here that you should make a very clear and well documented API because you expect customer agents to automatically make contracts with you to use your API? Just sommer skipping the process of evaluating you as a vendor?
Maybe vibe coders will do this, but I don't expect a business that operates like this to last very long.
If the expectation is that the customer is still going to put the work in to evaluate you, then is there no room for them to build a client, to expose their own internal API?
This is kind of an insane take, and I doubt the year predictions will age well. But I REALLY agree with it and hope it is true.
"Talk to Sales for pricing" is bullshit and has always been bullshit. Shitty web UIs with no bulk change capabilities, but that you can script using the internal API from the Dev Tools Network tab are bullshit. If AI helps drag this industry into the future away from that, I welcome it.
> One human developer might make 100 API calls a day while building something. That same developer with Claude Code might make 10,000 API calls in a day because the agent is exploring, testing, debugging, and iterating at machine speed.
Isn't this what mocking was meant to prevent? Especially if the API exposes their OpenAPI docs like the author is recommending? Or is this another victim of the agentic revolution?
> Call sales
So there are some valid reasons why an API might be gated like this.
FlightAware gates their API (and their website from scrapers) because obtaining airline flight movement data is insanely expensive. Same for market data feeds (think Bloomberg) and anything related to medical records and insurance. Many services are just brokers/cleansers of this data so that companies don't have to jump through a million hoops to get direct access (if they even can).
Nonetheless, there are enough examples of reverse engineered API clients for these kinds of enterprisey APIs. That'll work great with agents, I reckon.
23 comments
[ 15.6 ms ] story [ 54.4 ms ] threadIOW, a human customer is not the customer your business is going to directly serve, their agent is. What's required from the human is to provide a payment method, I assume, else it's not a real customer, but a free-tier user.
Thats always missing from these sorts of articles and comments, is why is this better
Related query: how is this really any different than what the W3C has proposed with Hydra[0] or other linked data APIs and formats? Who benefits by making their APIs more transparent, when 15 years or so ago there was a big push for this exact thing and it failed due to business concerns, not technical ones.
It's simply assuming what the way forward is without positing why other ways will not work to justify the position.
My secondary critque of the article, is using this as a basis of comparison:
>any product that can't be used by an agent will be as dead as a product without mobile support is today
First, I think its important 'mobile support' is defined. Is it as simple as a mobile friendly website or an app? Are we talking equivalent functionalities as well with the desktop counterpart?
Second, it ignores a ton of successful projects and products. Blender, Maya, Unreal engine. There's also a huge swath of games that only launch on PC or consoles.
If equivalent 1:1 functionality is to be considered, Adobe suite is still primarily a desktop tool, as is Figma.
I know there are a huge host of apps I'm missing too.
While more consumer apps migrated to web + mobile, you can often find functional differences between accessing on desktop vs mobile, where desktop is more complete. Its still not uncommon to have a mobile / tablet version of an app that is missing features that the desktop or website version is not.
[0]: https://www.hydra-cg.com/spec/latest/core/
How many jobs involve purely clicking things on a computer without human authorities, rules, regulations, permits, spending agreements, privacy laws, security requirements, insurance requirements, or licensing gates?
I wager, almost none. The bottleneck in most work isn't "clicking things on a computer." It's human judgment, authorization chains, regulatory gates, accountability requirements, and spending approvals. Agents automate the easy part and leave the hard part untouched. Meanwhile, if the agents also get it wrong, even 1% of the time, that's going to add up like compound interest in wasted time. Anything that could actually be outsourced to an agent, would have already been outsourced to Kenya.
And I think that products making billions today by only exposing a 20yo SOAP API are still going to make billions in 4 years.
I hate having to work with them, but I've been playing this game long enough to know that most of the world is running on legacy software and it won't change in about 1400 days.
my indian visa my 45 servers remote desktops on hetzner
all thanks to cc
They aren't API first not because they can't - but because customers will use whatever GUI website supports to use it.
Unless your product has no value - users will fill out those forms manually if you don't provide API if they need your product.
Agents don't change this.
I can't count how many times I could have made an API that no one would use. I would also have to document it at which I'm exclusively terrible (I find out later trying to make sense of my own docs) I can now generate and test the docs which changes everything.
I wonder, could a spa (while still doable) now be the wrong approach? The logic will have to be in the API, why have it twice? It seems offloading work to the client might just add bloat. Could it be that if the website works with [dumb] queries the AI won't even need to read docs?
I filled out the PDF using FireFox PDF-editor, at which point it occurred to me, this is not so different from using an application which has a form for me to enter data into it.
Maybe in a few years Government has a portal where I can submit any of their forms as PDF documents, and they would probably use AI to store the contents of the form into a database.
A PDF-form is kind of a Universal API, especially when AI can extract and validate the data from it. Of all the API-formats I've seen I think PDF-forms is the most human-friendly. Each "API" is defined by the form-identifier in the PDF-form. It is easy for humans to use, and pretty easy for office-clerks to create such forms, especially with the help of AI. I wonder will this, or something similar, catch on?
At some point the agents reading your article ARE the agents that will consume those improved docs. The feedback loop becomes fully autonomous.
Maybe vibe coders will do this, but I don't expect a business that operates like this to last very long.
If the expectation is that the customer is still going to put the work in to evaluate you, then is there no room for them to build a client, to expose their own internal API?
"Talk to Sales for pricing" is bullshit and has always been bullshit. Shitty web UIs with no bulk change capabilities, but that you can script using the internal API from the Dev Tools Network tab are bullshit. If AI helps drag this industry into the future away from that, I welcome it.
there are many Claude Code variants waiting to be built. not TUI code editors, but environments in which LLMs get superpowers
that's the product you should build rn
> One human developer might make 100 API calls a day while building something. That same developer with Claude Code might make 10,000 API calls in a day because the agent is exploring, testing, debugging, and iterating at machine speed.
Isn't this what mocking was meant to prevent? Especially if the API exposes their OpenAPI docs like the author is recommending? Or is this another victim of the agentic revolution?
> Call sales
So there are some valid reasons why an API might be gated like this.
FlightAware gates their API (and their website from scrapers) because obtaining airline flight movement data is insanely expensive. Same for market data feeds (think Bloomberg) and anything related to medical records and insurance. Many services are just brokers/cleansers of this data so that companies don't have to jump through a million hoops to get direct access (if they even can).
Nonetheless, there are enough examples of reverse engineered API clients for these kinds of enterprisey APIs. That'll work great with agents, I reckon.