sorcercode

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:

https://fragmentedpodcast.com/episodes/302/

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 now stretch popular it makes money if those 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/

Might I also suggest the Firefox addon "Container Traffic Control" - A Firefox addon I built to make it even easier to use Containers

https://addons.mozilla.org/en-US/firefox/addon/ctc/

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

Source came be found here: https://github.com/kaushikgopal/ff-container-traffic-control

i think the genie is out of the box; but i stand with your sentiment!

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.

tldr: use spaces around em dashes

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'll give a few examples:

- Mono Lisa font https://www.monolisa.dev/ (truly gorgeous font)

- Recursive https://www.recursive.design/ (particularly note the casual axis)

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 feel your pain my friend. i really do.

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:

- [Iosevka](https://kau.sh/blog/build-iosevka-font-mac-os/)

- [IBM Plex Mono](https://kau.sh/blog/freeze-alt-char-open-type-font/)

- [Jetbrains Mono](https://github.com/kaushikgopal/JetBrainsMono-KG) (yes, plenty of customization there)

- [Recursive](https://github.com/kaushikgopal/recursive-code-config)

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

https://kau.sh/blog/claude-skills/

this is bittersweet news.

but sigh. Jetbrains really just has no focus.

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.

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.

(here's my article on learning Rust if folks are interested: https://kau.sh/blog/learn-rust-ai-atrophy/) - different angle from the linked article.

that's fair. i do think it's personal preferences in the end.

so

1 - compromised hardware over better software is a trade-off you're willing to make and 2 - you believe that the Framework software experience is better than macOS

i can concede 2 (if true, I've not used a Framework laptop) but I don't understand point 1. packing a powerbank for example just feels ancient if you've used the arm chip macs. then again, I'm now pushing my trade-off

Kotlin programmer here who is picking up Rust recently. you're right, it's no Kotlin when it comes to the elegance of APIs but it's also not too bad at all.

In fact there are some things about the syntax that are actually nice like range syntax, Unit type being (), match expressions, super explicit types, how mutability is represented etc.

I'd argue it's the most similar system level language to Kotlin I've encountered. I encourage you to power through that initial discomfort because in the process it does unlock a level of performance other languages dream of.

sort of. it was a nuts and bolt implementation. by their own admission it was reintroduced to make it more friendly. from a comment I saw made elsewhere:

> yes about:profiles has existed for a long time. We have heard feedback from many of our users to make it user friendly and accessible. We are introducing many new additional functionalities in this new profile management experience (avatars, colors/themes, shortcuts, desktop icons, default links/apps per profile, copy profile, move tabs between profiles). Stayed tuned for these updates.

so yes, you are right. it did exist.

I couldn't disagree more. I want responsible AI and i would expect Mozilla to lead the way on how to do this when it comes to browsers (they were pioneers when it came to containers and privacy control).

Here's some ways I can think of:

- seamless integration with local models

- opt in and opt out experience when needed

- ai instrumentation (so fill up tedious long web forms for me)

- ai and accessibility

these are off the top of my head.

it boggles my mind that there are so many convinced that AI doesn't offer good use cases for a browser.

I think the "how they introduce it" part is crucial and it doesn't look like Mozilla has cracked that nut from the announcement. but to say no one wants this is just not true and short sighted.

they are building their own editor (granted they didn't do it from scratch); they do build their own models (see composer);

they may not have done a lot of this from scratch but there's still a lot of innovation in what they're doing. they're also building a pretty fantastic product and clearly the leader today in AI innovation for IDEs.

may not be everyone's cup of tea; but i think you might be detracting some of their innovation.

very cool. frequently, i want to share my prompt + session output; this will make that super easy! thanks again for sharing!

@simonw: slight tangent but super curious how you managed to generate the preview of that gemini-cli terminal session gist - https://gistpreview.github.io/?17290c1024b0ef7df06e9faa4cb37...

is this just a manual copy/paste into a gist with some html css styling; or do you have a custom tool à la amp-code that does this more easily?

i sense a slight strawman argument here.

you pick a subset of admittedly clear problems with how aigen is being leveraged but blow it up to be the general case for everyone.

you're quick to call into question the motivation of programmers who use aigen.

i assure you when you see people like Mitchell Hashimoto using aigen, you owe it to yourself to at least explore the possibility that there are folks building great software, and product using aigen. I'm not saying you need to be convicted but your comment comes out as being one sided and emotional.

i'm also curios how you square your thoughts around actually building good products. there's plenty of bad apples on all sides (like the craftsmen who tdd apps that land up not being used by anyone).is that true value?

it would be silly and a strawman argument to then assume that to always be the case.

that's fair (and glad profiles have finally arrived in FF for that reason); personally, i don't use password managers linked to any specific browser but i can understand your use case.

> I never had much problem with feeling VSCode was slow (outside of those lockups) but Zed surprised me by feeling actively fast.

well said. this is exactly how I felt too. when other folks ask why zed, and i tell them it's fast - i couldn't quite capture that feeling but this comment nails it.

Zed actively feels faster than VSCode or equivalent editors; but once you get comfortable with Zed's speed, it's hard to go back.