ashu1461

Doordash as an app or a business model always feel scammy and full of dark patterns.

With this merger I have a feeling that things are only going to go worse.

And i guess people dont care by google releases anymore

Argon did not leave a mark or change anything

Why would anyone care about carbon as well

Creating the hype

Even with gemini 2.5 or so i remember the models used to just simply hang in production and randomly used to collate tokes and give in the output stream vs giving one by one which was weird.

Also the guardrails were implemented in a very bad manner. By default the models used to raise a default guardrail error on basic queries.

If there is reasoning involved, the output can't be this fast ?

Output tokens anyway will be minimal in a decision scenario, so even if you use responses API the cost will be less.

If we compare this with using the older solution of writing a prompt to find out the answer of the classification

- Cost : It is the same for both scenarios $0.10 per 1M tokens

- Speed : decisions is 10x faster than responses API

- Quality : I guess if we compare with luna which is a pretty good model it itself, both will be at par

So essentially it has to do more with speed vs any other factor.

This is a good insight.

While doing local development where your environment is already setup and dependencies are installed doing something like this seems viable after the initial effort.

But how would this work in a software-factory setup, where coding agents run on fresh VMs or when using something like Claude Code on the web? How do you quickly recreate the required environment and dependencies there?

I have found AI that autocompletes (like the GitHub Copilot VS code extension) to be more effective in these scenarios than AI that generates entire sections.

With autocomplete, I'm still writing the content and simply using AI to phrase it better. With generation, it may produce something that was not part of my original idea and once it is there, it becomes very hard to remove its bias.

It might be just me, but this is how frontend libraries should have been structured in the first place unlike relying on callbacks / state change hooks.

Linearly written code is much easier to understand and scan.

I don't know most of these tools either, but that is why I find posts like this useful. Don't you end up learning something new in cases like this?

In such systems, producing code is the easy part, verification is hard. Verification via test cases just feels like the same agent validating its own assumptions.

Wondering what the actual verification loop looks like once you start taking these systems to production.

Isn't everything vibecoded ?