Comments URL: https://news.ycombinator.com/item?id=48220710

Points: 14

# Comments: 7

In today's day and age, it's absurdly easy to create a proxy API for your API that only exposes a subset of operations. And not like other "easy" things which depend on them having done "the right thing" before, like OpenAPI specs, auth scoping etc. This is so easy, even corporations consider it easy, and everything there is a PITA.

This is simple to make, to document and since it's a proxy you're also able to include all bunch of LLM friendly shenanigans and overly verbal errors with suggestions to fix.

Shit, I should obviously make a SaaS for this, huh?

Isn't in that case an API what they want?

An "MCP for a local app" is just an API that exposes the internal workings of the app. An "MCP for mixpanel" is just an API that exposes Mixpanel API behind Auth. There is nothing special about them for any type of user. It's just that MCP's were "made popular".

For the same type of user, I have built better and smoother solutions that included 0 MCP servers, just tools and pure API's.Define a tool standard DX and your LLM can write these tools, no need to run a server anywhere.

That is also what the author seems to be mistaken about - you don't need a CLI. A CLI is used because the DX is nice and easily permutable with all the preexisting bash tooling that is ingrained into every LLM's dataset. You don't need a .env file if you're using an API with a skill. A skill can include a script, or mentions of tools, and you are the one who controls these.

All in all, the whole "MCP vs Skill" debate online is mostly based on fundamental misunderstandings of LLM's and how they work, how harnesses work and how API's in general work, with a lot of it being fueled by people who have no relevant coding experience and are just youtube/twitter "content creators".

Some arguments against MPC's, no matter who is the user:

- MCP is just a noisy, hacky wrapper around an API or IPC (well, API behind IPC) - MCP's are too noisy for LLM's to be useful long-term, as they require a server. - You don't need an MCP, you need an easy accessible API with simple DX that the machine can use with as little context and decision making as required. - Skills are better than MCP because they basically encode the API docs/context in an LLM friendly manner. No need to run servers, just push text to system prompt.

Comments URL: https://news.ycombinator.com/item?id=47691523

Points: 8

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47334212

Points: 2

# Comments: 1

The core idea of deriving the infra from my app always sounds great, but also kind of gives me a "yuck" feeling the same way infrastructure as code does.

Feel like there has to be a better, common way to resolve all of these issues, so that it's an extensible, plug and play IFC/IAC, derived infra file from your code that you can then manually modify, that can be easily just pointed in the right direction for where to host it in.

This is one of the steps in the right direction deff, just can't figure out if they have it open-sourced or not.

Also, Peter is quite well known in the dev circles, and especially in mobile development communities for his work on PSPDFKit. It is not like he's some unknown developer that just blew up - he owned a dev tooling company for over 10+ years, contributed a lot to the community and is a great dev.

I find this decision weird due to claude _code_, while being used by _some_ non-technical users, is mostly used by technical users and developers.

Not sure why the choice would be to dumb the output down for technical users/developers.

They would try it once, think its cool and stop there. You would probably have a niche group of "world surfers" that would keep playing with it.

Most people do not have an idea on what they would want to play and how it would look like - they want a curated experience. As games adapted to the mass market, they became more and more curated experiences with lots of hand-holding the player.

Yeah, a holodeck would be popular, but that's a whole different technology ballpark and akin to talking about flying cars in this context.

This will have a giant impact on robotics and general models tho, as now they can simulate action/reaction inside a world in parallel, choosing the best course, by just having a picture of the world and probably a generated image of the end result or "validators" to check if task is accomplished.

And while robotics is $88B TAM nowadays, expect it to hit $888B in the next 5-10 years, with world simulators like this being one of the reasons.

From the team side, gotta be cool to build this, feels like one of those things all devs dream about.

But when you look at it:

- X.ai is basically getting into the race by throwing money at the problem and using your name to get funding in a hyped industry.

- Do a buyout of your own company with it, get access to data that you restricted to everyone else.

- Merge it with SpaceX for "datacenters in space", do an IPO for a huge valuation

- Probably merge it with Tesla, overhype everything

- As the humanoid, AI and space industry grows, so will the valuation just because of the market growth, not necessarily because of great/revolutionary products

At that point, nobody can even consider what the valuation is, as it is a mishmash of promises, fudged numbers, real numbers, potential numbers, contracts, hype and everything else. It allows moving financials around and tuning things to get him his 1T package and hype things even more.

I mean congrats to Elon, just by overhyping his products he shifts the timeline narrative more towards techno-optimism and earns himself more money. The financial shenanigans to follow in the next few years will be an interesting period for future financial archeologists.

With prediction markets? Next to impossible. The markets being tied to crypto makes it even worse - things get harder to track, jurisdictions get blurry, proving becomes a ping pong between bureaucracy. And proving something becomes moreso a question of free will - if I decided to do X and then someone bets millon dollars on me doing X when odds are low, how do you prove I haven't decided to do X before? Will you prevent me from exercising my free will because of suspect insider trading? What if I am a president/senator?

Years ago, I was a kid who discovered online betting - often it was the only time I could place bets on MMA events, especially because it wasn't as popular as it is now. Even then, the gambling sites had "Other" options where you could bet on presidents, popes, landing on mars etc. The new markets aren't that much different, but are just using a nicer way to talk about it.

It isn't gambling, it's prediction.

You aren't a gambler, you're a "hyperinformed high iq individual predicting the geopolitical moves". Just like crypto gave people the identity crutch of a "tech investor", this gives them the identity crutch of a "geopolitical strategist".

But in the end, it is still just gambling - wrapped in a nice ego stroking suit, but gambling none the less.

Comments URL: https://news.ycombinator.com/item?id=46669057

Points: 10

# Comments: 2

But also - it's lacking things like a unified positioning + required knowledge to understand it is quite large compared to average dev + most people have no real use for it. It's mostly too "abstract high level" and "low level" for most devs.

Also so many people are paying for Canva, Capcut etc that taking a piece of that cake is quite a low hanging fruit if you have a distribution platform.

Not because of the execution itself, great job on that - but because I was working on exactly this - guess I'll have to ship faster :)

- The ecosystem evolved fast, then slow. This caused adoption problems, especially for things such as WASI and Component model, as a lot of folks did it their own way/using 3rd party, which now meant they had to rewrite to this new thing that still isn't fully properly supported everywhere.

- The way it's "developed" means a lot of things are distributed, unsynced and have different support levels based on the engine you're using. This causes confusion among developers, especially since you have to go from reading an article, to reading a spec, to reading a github issue, then you're 3 repositories deep reading random rust code at 2 AM trying to figure out if you can rely on this stranger's fork just to try something out that should have been dead simple.

- Both of these combined can lead to even greater confusion for our LLM's, as they are trained on varied data which is by now stale, so they can often misunderstand things or look for things that aren't there anymore, just like us humans would.

- And now let's focus on the biggest and most important one IMO: Javascript/Typescript support. That is the holy grail for any technology that wants to be a widely adopted intermediary. While it is possible, you are layering hacks on hacks and begging that the next user won't break it all. Until my users can bring whatever they're using with them, the transition isn't really worth it, and writing my own wiring for every possible combination/need is quite unnecessary. We got a step closer with Web Containers, but by that time a lot of folks already moved onto Bun.