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?
I am not 100% sure I follow your train of thought.
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.
Honestly, writing and wiring infra feels more like an overhead than anything else these days.
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.
Not so sure around gaming.
While it opens some interesting "generate quest on demand" and "quick demo" cases, an infinite world generator wouldn't really vibe with people.
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.
That is why all the crazy promises and moves, hyping X.ai, Robotaxis, Optimus, Data centers in space. If you are constantly promising the future and some radical moves, the optimistic investors believe him and he can keep increasing the "potential future valuation".
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.
Not just America, everything is.
With stock market, at least we can somehow stop the bad actors, insider traders, corporate manipulation, pumps and dumps - with prediction markets, there is no way.
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.
It is more of a silent thing. Running in the background, internal libs, deployment tools, plugin tools.
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.
I would assume it's because younger generations of creatives are using their software less and less, increasing the risk of losing the market completely on the software side. At this pricing, more of them will turn to paying Apple rather than paying for multiple services, keeping them tied into the ecosystem.
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.
As someone who worked actively with webassembly for the last few years, and is about to drop a WASM based framework, here's what happened:
- 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.
It's an internal benchmark that I use to test prompts, models and prompt-tunes, nothing but a dashboard calling our internal endpoints and showing the data, basically going through the prod flow.
For my product, I run a video through a multimodal LLM with multiple steps, combine data and spit out the outputs + score for the video.
I have a dataset of videos that I manually marked for my usecase, so when a new model drops, I run it + the last few best benchmarked models through the process, and check multiple things:
- Diff between outputed score and the manual one
- Processing time for each step
- Input/Output tokens
- Request time for each step
- Price of request
And the classic stats of average score delta, average time, p50, p90 etc.
+ One fun thing which is finding the edge cases, since even if the average score delta is low (means its spot-on), there are usually some videos where the abs delta is higher, so these usually indicate niche edge cases the model might have.
Gemini 3 Flash nails it sometimes even better than the Pro version, with nearly the same times as 2.5 Pro does on that usecase. Actually, pushed it to prod yesterday and looking at the data, it seems it's 5 seconds faster than Pro on average, with my cost-per-user going down from 20 cents to 12 cents.
IMO it's pretty rudimentary, so let me know if there's anything else I can explain.
Yes, but the 3.0 Flash is cheaper, faster and better than 2.5 Pro.
So if 2.5 Pro was good for your usecase, you just got a better model for about 1/3rd of the price, but might hurt the wallet a bit more if you use 2.5 Flash currently and want an upgrade - which is fair tbh.
Oh wow - I recently tried 3 Pro preview and it was too slow for me.
After reading your comment I ran my product benchmark against 2.5 flash, 2.5 pro and 3.0 flash.
The results are better AND the response times have stayed the same.
What an insane gain - especially considering the price compared to 2.5 Pro.
I'm about to get much better results for 1/3rd of the price. Not sure what magic Google did here, but would love to hear a more technical deep dive comparing what they do different in Pro and Flash models to achieve such a performance.
Also wondering, how did you get early access? I'm using the Gemini API quite a lot and have a quite nice internal benchmark suite for it, so would love to toy with the new ones as they come out.