netshade

Found similar results, but the economics of the models involved have changed so quickly that it becomes so task specific on what the right thing to do was.

With an assemblage of models like Jev + Opus or Jev + Qwen, Jev would often do the right thing when deciding to escalate to another model - I was impressed that it would usually make the right call, especially if you gave it good awareness of what the other model capabilities were. "ESCALATE to opus if you need good vision awareness".

When Haiku 5.5 came out though, for my tasks, the cost differences disappeared almost immediately. Haiku was good enough / fast enough for so many things that introducing a decider layer didn't offer huge wins. Jev's "millisecond" level performance was nice but would get dwarfed by other latencies in my chain ( web browsing ), that it didn't make a measurable difference in my tasks.

Sensors everywhere. If it's at all relevant to what you're working on, providing a different way of viewing something, and a skill description on how to do that, has these long-compounding effects that are magic at first, and then become "of course, it should always just work" as your expectation.

My product that I'm working on sorta acquired a bunch of that. I put a ton of work into making a browser that could just see / interact w/ the web in a ton of different contexts. Now that I have it, it's pretty amazing to just have the agent do everything I need it to ( pull a network log, debug JS, navigate a form ), and it has the appropriate context everywhere.

I agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct.

I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.

For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.

All to say that this decision is worth considering without even taking LLM assistance into account.

Started vanilla and importing things like projectile, magit, all of that. I didn't like the awkward edges of how they joined tho, and eventually tried switching to Spacemacs with "less" of my own config. None of it was awful, but none of it felt great.

When VSCode came about and had great integration for a language I was primarily using at the time ( Typescript ) I switched to that and was happy for the comparatively low config required. My Helix switch came about just because of how VSCode absolutely chewed through battery usage when I was out and about.

I was an Emacs user for about 3-4 years. I never felt very proficient in it, I always felt like I was cargo culting in config changes that I never felt comfortable with. I liked the power, but never graduated to the point where it felt like it was working with me. AFA why I didn't switch to Vim, there was enough "Vim is great with a great config" which felt so similar to the situation I was already in with Emacs that I just wasn't convinced. Not the greatest rationale, but that's what it was.

LOL, this truly made me laugh. I'm also doing humor stuff with Claude, I was pretty pleased with 3.5 so excited to see what happens with the 3.7 change. It's a radio station with a bunch of DJs with different takes on reality, so looking forward to see how it handles their different experiences.

Not a great look when many responses are "if the provider won't protect people, then the researcher should contemplate hurting people".

You can communicate those ideas specifically without hiding it beneath the veneer of relatability. The entire post started with this bit:

> But, come on: you never took us too seriously about K8s, right? K8s is hard for us to use, but that doesn’t mean it’s not a great fit for what you’re building. We’ve been clear about that all along, right? Sure we have!

which already starts the post in a bad space for the reader. I have cognitive whiplash from what is intended. "We DON'T like Kubernets UNTIL WE DO but then WE MIGHT NOT IN THE FUTURE". Clear meaning is far more appreciated.

I am a current Fly customer (personal and work), and have been happy with the service. Will likely be trying this out. That said, the marketing tone of this final part of the blog:

> More to come! We’re itching to see just how many different ways this bet might pay off. Or: we’ll perish in flames! Either way, it’ll be fun to watch.

is like nails on the chalkboard for me.

Yeah, agreed. I use Eleven Labs a lot but this was a very compelling demo to consider changing. Also, curious that you mention Bark - I never found Bark to be very good compared to Eleven Labs. The closest competitor I found was Coqui ( imo ), but even then, the inflection and realism of EL just made it not worth considering other providers. ( For my use case, etc. etc. )