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.
A developer spinning up greenfield projects in technologies they would never have touched without AI are probably going to use whatever AI suggests (or chooses without asking) because they have nothing else to compare it to. Like a webdev who wants to build a mobile app will possibly auto-approve a lot of the choices just to get something up and running. And as we all know, the prototype-to-production train is hard to stop.
From the article: "Claude Code can rip out one service and replace it with another in minutes. ..."
Doesn't that assume there are many interchangable services available on the web which essentially do the same thing?
I can see this would be the case if there were many online services for say compiling C++ code. But for more human-centric services, are there many "replaceable services" out there? An API is not only its syntax, but also its semantics.
The choice happens implicitly rather than explicitly. If Claude tries an approach and hits a wall, it'll try a different approach. If an API call keeps not working, it'll choose a different API. It a tool is broken, it'll use something else. If it can't find docs nor read the code, it'll try to implement functionality from scratch. If you give it messy tools with confusing docs, you'll notice Claude not calling them as you'd expect, and instead trying something simpler instead.
Wow that's really interesting. Something I do very often, for libraries, languages, APIs, even shopping is:
"look into the possibilities for X search the web, do thorough comparison. look on HackerNews both to gather sources and gauge sentiment in the comments"
this yields pretty good results IMO.
If I am using an API/library, I will also ask "is this approach idiomatic? what does the documentation say? look through at least 10 pages online"
I get several folks per week claiming an ai/llm recommended them my product, while I personally wouldn't run a procurement process that way, some certainly do.
> Claude is never on the web reading documentation - as far as I can tell that's not even in its toolkit.
Add the Context7 and grep MCP servers to your installation, it'll change your life (well it'll make claude less dumb).
Claude Code v2.1.29
Opus 4.5 · Claude Team
~/stow/tmp
I have a new project
In it, I want to scrape hacker news data.
The project will be built in python.
I want to search first what are the latest projects in python that could help me extract the data. This could be via api or scraping it.
Once you have a plan, ask me 10 questions to help navigate the structure.
I'll help you research the latest Python options for extracting Hacker News data. Let me search for current tools and approaches.
Web Search("Python Hacker News API scraping library 2026")
⎿ Did 1 search in 20s
Web Search("Hacker News official API Python wrapper 2025 2026")
⎿ Did 1 search in 17s
Web Search("best Python library scrape Hacker News data extraction")
⎿ Did 1 search in 20s
Let me get more details on the official Hacker News API and some specific library documentation.
Fetch(https://github.com/HackerNews/API)
⎿ Received 373.8KB (200 OK)
Fetch(https://pypi.org/project/hackernews-python/)
⎿ Received 3KB (200 OK)
Fetch(https://github.com/avinassh/haxor)
⎿ Received 378.1KB (200 OK)
I've gathered comprehensive research on the available options. Let me write up my findings and then ask you the 10 questions.
Updated plan
⎿ /plan to preview
Research Summary
I found several solid options for extracting Hacker News data in Python:
Best Options Found:
1. Official HN API (Firebase-based) - Free, no rate limits, real-time data
- Source: https://github.com/HackerNews/API
2. haxor - Most popular Python wrapper for the official API
- Source: https://github.com/avinassh/haxor
- Install: pip install haxor
3. DIY Scraping - BeautifulSoup + Requests/httpx for data not in the API
- Source: https://www.proxiesapi.com/blog/scraping-the-hacker-news-with-python-and-beautiful.html.php
4. Commercial - https://apify.com/epctex/hackernews-scraper for hosted solutions
---
Now, here are my 10 questions to help define your project structure:
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
← Data Source Data Types Storage Use Case Submit →
Do you want to use the official HN API (recommended, no rate limits) or scrape the website directly?
1. Official API (Recommended)
Use Firebase-based API - reliable, real-time, no rate limits
2. Web Scraping
Scrape HTML directly - more flexible but requires maintenance
3. Both
API as primary, scraping for data not available via API
4. Type something.
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
5. Chat about this
6. Skip interview and plan immediately
Enter to select · Tab/Arrow keys to navigate · Esc to cancel
> 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.
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?
A pdf can be anything and everything. It's just a wrapper around text, images, html, you can even embed javascript. There's already pdf forms that are user-editable (without a pdf editor). Not all features are available on all pdf viewers though.
If we're at the point where they use ai to make form pdfs, might as well cut the middleman and ask the ai to generate a form on a website.
They do, for the simple reason that I don't want to have to click through forms and pages and hunt things down manually to do a workflow. I won't use a cloud provider with a broken or half-functional cli for this reason, and if anybody in any space provides a better agent interface for doing stuff so I don't have to click through UIs, I will switch pretty much instantly.
Think of agent support sort of like food delivery. Once people get used to the convenience, places that don't offer it are at a huge disadvantage.
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?
> "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.
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?
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.
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 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.
This is stupid and doesnt consider very few apps are made for automation. Apps are made for people to use and it wouldnt make sense to maintain an API for agents when 100% of the revenue is from people.
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.
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 worked in the fraud department for for a big bank (handling questionable transactions). I can say with 100% certainty an agent could do the job better than 80% of the people I worked with and cheaper than the other 20%.
These AI agents have been such a burden to open source projects that maintainers are beginning to not take patches from anyone. That follows from what you’re saying here because it’s the editing/review part that’s human-centric. Same with the approval gates mentioned here.
Another parallel here is that AI agents will probably end up being poor customers in the sense of repeat business and long-term relationships. Like how some shops won’t advertise on some platforms because the clicks aren’t worth as much, on average, maybe we’ll start to see something similar for agents.
> 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.
Without any of these, yes. With very basic rules, a LOT of them.
“Human directing an agent” will become the dominant paradigm. We’ll still be in the loop, but there is no need for me to go to five different websites to look up basic information and synthesize the answer a simple question.
All of the super regulated entities are interested in using AI and are trying to figure out how to solve those problems. There's a lot going on in the model governance space, actually.
windowshopping|1 month ago
djeastm|1 month ago
hk__2|1 month ago
Of course it is; I use it every day.
dmd|1 month ago
That is how I use it almost every day. "Here's the link to an API doc. Read it, write a new Skill around it, and [solve this problem with it]."
galaxyLogic|1 month ago
Doesn't that assume there are many interchangable services available on the web which essentially do the same thing?
I can see this would be the case if there were many online services for say compiling C++ code. But for more human-centric services, are there many "replaceable services" out there? An API is not only its syntax, but also its semantics.
ianbutler|1 month ago
dangom|1 month ago
shepherdjerred|29 days ago
"look into the possibilities for X search the web, do thorough comparison. look on HackerNews both to gather sources and gauge sentiment in the comments"
this yields pretty good results IMO.
If I am using an API/library, I will also ask "is this approach idiomatic? what does the documentation say? look through at least 10 pages online"
rozenmd|1 month ago
> Claude is never on the web reading documentation - as far as I can tell that's not even in its toolkit.
Add the Context7 and grep MCP servers to your installation, it'll change your life (well it'll make claude less dumb).
internet2000|1 month ago
rovr138|1 month ago
lmeyerov|1 month ago
nunez|29 days ago
> 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.
galaxyLogic|1 month ago
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?
monsieurbanana|1 month ago
If we're at the point where they use ai to make form pdfs, might as well cut the middleman and ask the ai to generate a form on a website.
risyachka|1 month ago
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.
CuriouslyC|1 month ago
Think of agent support sort of like food delivery. Once people get used to the convenience, places that don't offer it are at a huge disadvantage.
aaronbrethorst|1 month ago
singiamtel|1 month ago
econ|29 days ago
econ|1 month ago
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?
nine_k|1 month ago
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.
no_wizard|1 month ago
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/
candiddevmike|1 month ago
liampulles|1 month ago
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?
unknown|1 month ago
[deleted]
code443|1 month ago
At some point the agents reading your article ARE the agents that will consume those improved docs. The feedback loop becomes fully autonomous.
unforbiddenYet|1 month ago
woeirua|1 month ago
wiether|1 month ago
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.
CuriouslyC|1 month ago
giancarlostoro|1 month ago
falloutx|1 month ago
andrewmutz|1 month ago
jrflowers|1 month ago
airstrike|29 days ago
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
m3kw9|1 month ago
internet2000|1 month ago
"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.
franze|1 month ago
my indian visa my 45 servers remote desktops on hetzner
all thanks to cc
gjsman-1000|1 month ago
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.
mritchie712|1 month ago
pitched|1 month ago
Another parallel here is that AI agents will probably end up being poor customers in the sense of repeat business and long-term relationships. Like how some shops won’t advertise on some platforms because the clicks aren’t worth as much, on average, maybe we’ll start to see something similar for agents.
hk__2|1 month ago
Without any of these, yes. With very basic rules, a LOT of them.
turnsout|1 month ago
nunez|29 days ago
danvoell|1 month ago
love2read|1 month ago
raincole|1 month ago
1. read the first 5 pages of HN
2. if there is a common theme, use a search engine to 'do your own research' and collect references
3. read your existing blog posts
4. write a new article with the same theme but in your style
5. post the link back to HN
goodmythical|1 month ago