Hacker Newsnew | past | comments | ask | show | jobs | submit | fastball's commentslogin

Off by an order of magnitude.

That is... not what AWS data centers are primarily used for in 2026.

You mean they’re not used to sell me cheap Chinese USB-C cables?

You confused AWS with Amazon distribution and warehouses, and you are doubling down ? Likely or not, much of the world's infrastructure runs on or through AWS data centers. Attacks like this can cause significant disruption.

Maybe I’ll triple down. You’re telling me that AWS and even, why not, THE ENTIRE INTERNET is not built to sell me pointless crap? It’s just that it sure feels like it when I click around.

AWS is also running government, military, medical, university etc systems. Banking.

Most APIs and CLIs are not setup with clear separation of permissions, and when they have those permissions are mostly designed around human access patterns and risks, not LLM ones. The primary example of course being read-only vs write access.

MCPs have provided any easy way to side-step that baggage.

e.g. in an MCP, you have tools, those tools are usually binned into "read" vs "write". Given that, I can easily configure my tooling to give an LLM (e.g. Claude Code) unlimited read access to some system (by allowing all read-only tools) without likewise giving the LLM write/destructive access.

Obviously you can design APIs/CLIs with this in mind, but up until now that has not been a primary concern so they haven't.


That makes some sense. But one can make the argument given how easy it is to create CLI tools and add new API endpoints, enhancing them is still a better approach than creating and MCP.

I'm not pro or anti-MCP myself. I just haven't had a lot of success using them yet. I've been struggling to find the right balance and every path has lead me to a CLI tool (optionally paired with a skill).

Now I'm not using my cli tools in Claude Chat proper, but I'm not using MCPs either because they just keep failing me. This could very well be a me problem, but I'm still looking for that "ah-ha" moment.

Maybe I'm misunderstanding you, but the way you describe MCP sure sounds like it's just another RPC endpoint. Those are easy to add using traditional methods. Why deal with all the overhead of MCP for those cases?


I don't think MCPs have legs long-term, but they are a great middle ground during this somewhat turbulent transition period we find ourselves in, precisely because they are not the existing tooling (they are greenfield).

An existing company that has an API/CLI might not have everyone on the team on-board with LLMs and agents and what have you – it might be hard to get buy-in to modify those existing surface areas to be more "agent compatible".

Meanwhile, a team within a company that wants to make their company more "agent forward" can build an MCP tomorrow and it is clear what it is for: is a new surface, meant to be consumed by agents, with the needs of agents top-of-mind. It avoids confusing interop issues with existing tooling while maximizing said teams ability to ship changes/experiments quickly.


You're not wrong, but I could also argue the same about creating a new CLI or custom API. Now I know there's some expectation that APIs and CLI tools don't change willy-nilly, and that's not the case for MCP endpoints (yet), but if you clearly define the use case the outcome is the same.

But I think we generally think the same. MCP is a tax we have to pay right now to play in the whole ecosystem, but it sure doesn't feel like the right play long term.


You can pre-migrate if you want, just by hitting every actor with a request as soon as you deploy the change with a migration.

Personally I think the benefits of lazy outweigh the downside of that single 30s request, but to each their own.


We recently replaced an isolated feature built on Durable Objects with Rivet Actors, to allow for much better interop with the rest of our infra (which is built on AWS/Vercel), and are happy with it so far.

There have been some small issues but nothing show-stopping, and the Rivet team has been very responsive to help get things sorted (or help us understand when it was us doing something wrong).

Not using the SQLite datastore yet, but I am excited about the possibilities!


Cheers!

It is not a false dichotomy. Reducing headcount via attrition is a subset of "prolonged bleeding", if you've already decided it needs to happen.

I guess you could consider it that, I read "prolonged bleeding" as more smaller layoffs. That's a fair point. Although then I'd say it's still disingenuous to frame it that negatively when many may see it as a better option.

It is not 5x bigger, it is 5x more valuable. Obviously Stripes 2x higher revenue is part of that equation, but not all of it.


Also Adyen's processing volume grew just 8% (to $1.6T usd) in 2025, while Stripe's grew 34% (to $1.9T usd).

Stripe's bigger _and_ growing faster.


the valuable part is with a caveat though. Klarna and Figma were very valuable. i find these comparisons a little pointless (private vs public company). they process similar volumes, but one is in hyper growth mode (imagine quality of it) while the other has been scaling down growth and focusing on profitable growth. Has spooked investors but I understand that Adyen are pretty focused and they are scaling nicely their capital offering. But Stripe has good focus on stablecoins, more product focused and aggressive (as all US firms are). Both have like single % of the global payment market, and if you have issues with Adyen look at others in the market - nexi, paypal, etc. I believe both stripe and adyem will grow market share at expense of others over next decade. Plenty of growth for both, and Adyen has a unified platform solution which is smth stripe doesnt. So all have advantages, and the gap in valuation isnt' something id read too much about.

Besides, if AI replaces all white collar jobs, and crashes high spending consumer economy, all payment vols will go down.


5x more valuable in a private market is meaningless, until they go public it's all magic numbers used to push whatever narrative they need.


yeah, my bad, wanted to say more valuable


Anthropic has definitely been banning accounts for using non-Anthropic tools with subscription OAuth tokens.


ISPs still do this.

Obviously not with Napster, but they will close your account for piracy.


Depends where you live, in most places they don't bother anymore, in the few that they do a VPN obviously gets around it but it's incredibly unlikely you'd be doing enough to ever be on the radar let alone get caught. That battle was lost long ago.


I believe it is less that they stopped caring, and more that most piracy these days is web streaming, which is much harder to detect than torrenting or similar. AFAIK most major American ISPs are still fairly strict about pirate torrents.


ePaper displays are niche, and worse for most personal and business use-cases compared to LCD et al.

AI is re-structuring entire industries.


> ePaper displays are niche, and worse for most personal and business use-cases compared to LCD et al.

Hence we need more resources for R&D to figure out the shortcomings. LCD didn't pop into existence randomly either. It's not a guaranteed win, but neither AI has proven any realized gains in the majority of industries that gambled on adopting it.


Well its easy for the 1000 guys who control 50% of the total money supply to tell their CEOs and boards to push AI so they get a good ROI.

Starting an epaper business would involve actual work and risk.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: