self-published benchmark in README claims a 16% lower workflow token cost than Vercel's agent-browser on a Google Flights task (plus a much smaller install footprint).
These are all evolving technologies and it's pretty evident that the big AI labs are trying different things to see what sticks. Some of it does and they keep evolving it.
The reason MCPs are so powerful are less a technological advantage over other tools and more how ridiculously easy they are to install and use.
Also given it's an official standard now (AAIF), it's easy for sharing across differently agent harnesses and tools.
Those are the two main reasons imho, they are still a mainstay.
If you'll allow some shameless plugs, my co-host and I talk about it in our podcast:
Not sure how you would define successful though. I built a Firefox addon almost entirely through vibe coding and I know at least 5 other random souls on the Internet who have used and thanked me for it. But it is by no stretch, if popularity or how much money it makes, are the measures.
I was trying to test the theory if it's even possible to release something production grade with vibe coding. Wrote about the experience here https://kau.sh/blog/container-traffic-control/
When you start to use Containers (feature the Author of the article talks about), you'll start to want a little more control in how the containers open especially for sites that you allow on more than one container
Most AI generated text doesn't seem to have spaces around the em dashes. I've been using that as a subtle distinguishing marker; as both forms are considered grammatically correct.
Huh, I've observed the opposite, AI-generated text uses spaces most of the time. Might depend on language? Style guides I use (like Chicago) don't put spaces between em dashes so those always stand out immediately to me.
having spent a lot of time on finding the right monospace fonts, one of the things i've noticed, that's particularly important in the context of coding is a visual symmetry.
some fonts individually have beautiful glyps or characters but when you preview them with blocks and blocks of code, there's a quirkiness that throws of that symmetry.
I bring this up because Google Sans Code, is super quirky; preview a few characters individually and they look good; put it all together in real code, and it's just not as smooth visually.
i don't have your skills of actually customizing or changing glyphs in fonts directly but i've customized and used scripts to fix glyph characters available as open type features. I've done this for fonts like:
it really is a sickness. a terrible sickness, if you care deeply about fonts. I know you don't care specifically about recommendations, but inevitably i've found myself gravitating to these fonts:
1. Berkeley Mono (paid)
2. SF Mono (walled)
3. Recursive (truly open and legible)
4. Commit Mono
I love the above fonts, but there's a few characters or quirks that drive me bananas on certain days, so inevitably find myself switching between them.
this makes sense and as usual great eye by Simon. progressive disclosure is such a powerful concept, that every other tool is going to start adopting it. we've personally had such great results adopting it, especially for performing high quality large migrations.
I wrote about this but I'm certain that eventually commands, MCPs etc will fade out when skills is understood and picked up by everyone
Fleet came at a time when intellij felt extremely bloated. iirc they had painted themselves into a corner where it was easier to rip the band aid and start anew.
Fleet was supposed to be that promised editor which was snappy and had the power of intellisense + all things we liked about Intellij editors ... but without the terrible glacial bloat. but in a stroke of bad luck and typical lack of focus from Jetbrains, Fleet just didn't get good enough quickly.
I say lack of focus because (like their multiple attempts at AI) Jetbrains also had a lite mode in the start but that didn't work great. then came Fleet. But it was not getting better quickly enough and they changed course to make Fleet their main cross platform editor ... but even that didn't take.
I really am worried for Jetbrains and intellij. In a world where even VScode is having its lunch eaten by Cursor, Jetbrains is quickly getting pushed out of the list of contenders. they've squandered away a lead they once had in a certain niche for code editors.
I personally only pull up Intellij these days when there's some platform specific tool that's built in (like the emulator in Android Studio) or certain Android specific profiling tools, or the debugger.
Otherwise I rarely find myself using Intellij. My usage has dropped precipitously.
Another example of their wonkiness with Fleet and focus was their whole "Kotlin Multiplaform stuff will be Fleet-first!" which they then (somewhat promptly) reversed to "actually it'll be IntelliJ/Android Studio first" ... and that's not even getting to the macOS-only aspect (also "at first").
Their matrix of features/capabilities across IDEs, platforms, plugins, etc is such a pitfall-happy maze to navigate.
I wrote an article (this morning actually!) on picking up Rust to combat AI brain atrophy. My background is JVM-based (Kotlin), and my main contenders were Go vs Rust vs Zig.
My reasoning for settling on Rust:
If I wanted something more general-purpose and ergonomic, I'd stick with something like Kotlin, which has wider ecosystem support. Go could fit here too, but I've heard from more experienced folks that Go's simplicity can get limiting as codebases grow (and requires 100s of developers to be disciplined). Not impossible, just not as conducive.
But since I specifically wanted a performant systems language, I figured I'd go to the other extreme. So my choice was Rust or Zig. I eventually chose Rust (as complicated as Rust can seem) the borrow checker is pretty elegant once it clicks and provides the necessary safety net for a language I intentionally am choosing for more control.
reply