thecupisblue

And it gets more and more visible in every edit if you use Nano Banana for the edits.

Honestly it's on them, not on the users.

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.

It's not about the code, it's about the vibe.

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.

Maybe during onboarding you could ask for output preference? That would at least help new users.

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.

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.

That's actually surprisingly cheap compared to other subscriptions in the industry, especially for such a high powered suite.

I have to say this is disappointing.

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 :)

I mean compiling JS/TS to WASM or running a JS runtime like bun inside WASM

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.

I'm actually about to release something similar, if you're interested would love to share it with you - getting some feedback would really help a lot.

Shared a bit more here - https://news.ycombinator.com/item?id=46314047.

But pretty rudimentary, nothing special. Also did not know about deepwalker, looks quite interesting - you building it?

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.

Loving the design of these components - they feel so nice and tactile. If I didn't read the post, I would assume it was all made by a human.

The thought<>result feedback loop has come down by an insane margin in the last few years - and as everyone can get mid tier results, good taste will be the differentiator between "slop vibe code" and "good vibe code".

Didn't catch in the updates that the custom FPS was released, amazing. Seems like the limit is just 20MB, but can use custom splitting for larger ones.

Trying to split all videos into frames was a PITA mostly due to weird inputs from different Android phones requiring handling all kinds of edge cases, then uploading each to Upload API with retry was also adding a lag + complexity, so doing it all in one go will save me both time and nerves (and tokens).

Thanks for listening and all the great work you do, since you came in the experience improved by an immeasurable amount.

Startup credits require multiple follow-ups, meetings, etc. And these reps have weird incentive structures (so they are trying to bypass each other to meet their quotas or whatever).

Man, I tried going for the credits. I've organised meetups and conferences for Google, gave talks, been a part of Google Startup campus for years now, have been invited to participate in GDE program, and as I'm making a GenAI startup I decided "well, maybe time to try getting those 300k cloud credits, I've given them so much I'll surely get it".

Well, the first person I talked to, said I'm denied, because they didn't even check the websites I added in the description. They said oh I need to add it to another field for their team to see, told me to update it, but there is no way to update it. Then we had a second call, they said it's okay I can ignore that and pointed me to another person who will be my "account manager".

That person was absolutely uninterested into what we're doing, what we want and what we plan to do. They did not even care about helping us much until we reached 15k monthly spend or so, giving a holier-than-thou attitude and sounding like they're making lunch during the call. I'd rather have the call with an LLM at this point.

Then even though our website says our product relies on AI, it is impossible without AI and I explained to him how and why we train custom models and use their GenAI products - the person decided we are not an AI company and can only get 2k in Cloud credits.

The interaction left such a sour taste in my mouth that I will _never_ use Google Cloud in our product, as I do not want to have to deal with the Account Manager.

Oh man let me add onto that!

4. If you read about a new Gemini model, you might want to use it - but are you using @google/genai, @google/generative-ai (wow finally deprecated) or @google-ai/generativelanguage? Silly mistake, but when nano banana dropped it was highly confusing image gen was available only through one of these.

5. Gemini supports video! But that video first has to be uploaded to "Google GenAI Drive" which will then splices it into 1 FPS images and feeds it to the LLM. No option to improve the FPS, so if you want anything properly done, you'll have to splice it yourself and upload it to generativelanguage.googleapis.com which is only accessible using their GenAI SDK. Don't ask which one, I'm still not sure.

6. Nice, it works. Let's try using live video. Open the docs, you get it mentioned a bunch of times but 0 documentation on how to actually do it. Only suggestions for using 3rd party services. When you actually find it in the docs, it says "To see an example of how to use the Live API in a streaming audio and video format, run the "Live API - Get Started" file in the cookbooks repository". Oh well, time to read badly written python.

7. How about we try generating a video - open up AI studio, see only Veo 2 available from the video models. But, open up "Build" section, and I can have Gemini 3 build me a video generation tool that will use Veo 3 via API by clicking on the example. But wait why cant we use Veo 3 in the AI studio with the same API key?

8. Every Veo 3 extended video has absolutely garbled sound and there is nothing you can do about it, or maybe there is, but by this point I'm out of willpower to chase down edgy edge cases in their docs.

9. Let's just mention one semi-related thing - some things in the Cloud come with default policies that are just absurdly limiting, which means you have to create a resource/account, update policies related to whatever you want to do, which then tells you these are _old policies_ and you want to edit new ones, but those are impossible to properly find.

10. Now that we've setup our accounts, our AI tooling, our permissions, we write the code which takes less than all of the previous actions in the list. Now, you want to test it on Android? Well, you can:

- A. Test it with your account by signing in into emulators, be it local or cloud, manually, which means passing 2FA every time if you want to automate this and constantly risking your account security/ban.

- B. Create a google account for testing which you will use, add it to Licensed Testers on the play store, invite it to internal testers, wait for 24-48 hours to be able to use it, then if you try to automate testing, struggle with having to mock a whole Google Account login process which every time uses some non-deterministic logic to show a random pop-up. Then, do the same thing for the purchase process, ending up with a giant script of clicking through the options

11. Congratulations, you made it this far and are able to deploy your app to Beta. Now, find 12 testers to actively use your app for free, continuously for 14 days to prove its not a bad app.

At this point, Google is actively preventing you from shipping at every step, causing more and more issues the deeper down the stack you go.

9x faster than express is a bold claim, would be interesting to see how it holds up with real application logic and some real benchmarks/usecases.

Ahhhh okay, makes sense, thanks for answering.

When you say

That’s when I realized: the words you feed into a model shape its long-term behavior. Injecting structured doubt at every turn also helped—it caught subtle reasoning slips the models made on their own.

Was that not obvious working with LLLM's from the first moment? As someone running their own version of Vending-Bench, I assume you are above-average in working with models. Not trying to insult or anything, just wondering what the mental model you had before was and how it came to be, as my perspective is limited only to my subjective experiences.

Ironically, somewhere around 2014, Google was doing the exact same style "keep Android open" campaign, recruiting developers around the world - including me, to help lobby for keeping Android "open" and tell the horror stories of issues that random OEMs caused by forking Android, breaking compatibility and security.

Made sense to me at the time and they were really into "Android should be open source" vibe, so I supported it.

10 years later, I'm also rugpulled. Their vision has dramatically shifted into trying to build a walled garden on top of Android, but now they are haunted by their open source roots, and the walled garden is just a really tall pile of bricks laid around it.

So many times we've been promised things, only for them to be delivered in a half-baked state with half of the parts open source while other parts were closed only to Google and Google approved apps.

So many times the issue trackers for different parts of the platform ecosystem have changed, that some issues are impossible to debug without using web archive. And just as many times, they have been closed, ignored for years or unnoticed, being ping-ponged among team members until they forget about it.

Yet, even with all of the closed and privatized parts of the ecosystem, they are still not able to deliver on an ecosystem promise.

They control my email, my photos, my cloud, my browser, my phone - yet cannot keep a single thing properly in sync. Still, I download something and I do not know where it went. Still, I cannot Airdrop things without a 3rd party service. Still, I take a photo only for it to appear on the cloud 5 minutes later. Still, I cannot have a "sandbox" account for testing that just works, but have to juggle multiple accounts, causing their auth system to break 80% of the time when testing.

As a developer, I do not plan to support Android anymore. I recently got an iPhone, and am now fully switching to it. Even tho I am long on $GOOG stock, because the money printer go brrr, I will be spending that money in the Apple's ecosystem from now on.

It's so funny to see this be a worldwide phenomenon. As someone who grew up playing in the ruins of Roman temples & villas and was obsessed with it as a child, it almost feels like people are talking about "some other Rome".

Ironically, that's the thing I've been preaching to devs all along. We need to simplify the DX; both for us, the machines and the new folks who dont know how to code. A lot of the overengineering or complexity is there not due to the need for it, but due to it being build "for developers", without actually thinking about the developers who are going to be using it.