TeriyakiBomb

Yeah, I’d like this too. It’s one of the only things I still miss from Google.

I love Kagi. I want to see them do well, of all of the search alternatives, this is the only one where I’ve never felt the need to go back to google.

I was setting a up a new computer the other day and got confused that the first three links for a search were ads, then I remembered it was google and they hide the things you’re looking for.

Site priority, lenses and the slop filter are all icing on the cake.

Odd! Yeah nah, wasn’t really a thing in England.

Having a "stink" is right. Even without much thought, it's off-putting, does not sound professional and really icky. When you think a bit harder, it's just kinda awful. I do actually suspect the name does have some measurable impact on adoption. Most people don't want to say "I gave up photoshop, I use gimp." outside of hardcore linux circles and since then, it has gone from the only open source gig in town to just one of many alternatives.

In the UK, it’s the sex one and would be used as a general “idiot” word but that seemed to have mostly faded away. It’s not a word I’ve seen used in that context for many years.

Not refuting anything here, just adding some context from over here. Whichever way you slice it, it’s always been an awful name.

I had been playing around with ideas for a few months after becoming a little frustrated with the noise and friction generated by longer lived and larger tailwind codebases. I was on a long-ish train ride and brought those bits together into a little utility micro framework/toolkit I call Crayon.

It’s an interesting project, certainly not for everyone, but it does serve a legitimate and interesting niche.

“Others might find this interesting! Let’s get the docs in shape and release it as a proper FOSS project!” the quite naive me said to himself.

Writing good docs, and I’m not calling my docs good, just an attempt at them, is such a hard thing to do. I learned so much and it took SO long to make sure I had covered all the features, that I added as much sassdoc as I could for API docs, tone etc.

I’ve gained so much respect for the people who maintain open source docs and it has reminded me to contribute more than I do currently.

The TLDR of Crayon is it leverages some familiar utility patterns for prototyping but draws the line at anything not derived from a shared scale.

Think of it as the most common parts of tailwind list of classes but _almost_ no single property classes, no arbitrary values and no inline breakpoint, state or dark mode stuff. I promise it does make some sense

Scoped CSS exists in most frameworks and CSS and Sass provide more power and better ergonomics for larger projects. Crayon says to lean into those tools and provides other tools and mixins to keep those values centralised and some additional things you can’t do with tailwind or plain CSS with some pretty powerful composition mixins. Oh and if you’re an LLM-interested person, they take to Crayon really quickly. There’s nothing groundbreaking here, Crayon is intentionally teeny-tiny.

This is not me trying to make a “tailwind but better” or “I hate utility classes” it’s a hybrid approach and as I said earlier, definitely not for everyone. Hope some of you find this interesting!

I mean clearly she was doing a bad job. I’m shocked this was even a position there.

Over here in the UK at the moment you can. They’ve recently made huge changes to a lot of chocolate products in the space of a year or two. Especially cadburys which is now just at the legal definition of chocolate over here. Any lower and they legally have to call it “chocolate flavoured” which has already recently happened to a bunch of classic lunchbox chocolate bars. So shit.

You’re right. I apologise

Agents are effectively a full McDonalds kitchen, yes.

...and yes, I know you don't mean that. I just disagree.

I used to work at a company that did in-person pair review. I wasn’t an engineer there but the engineers all legitimately enjoyed the process. They hired very capable people as a default, so it was watching two passionate and talented engineers debate.

But LLM usage isn’t equivalent to power steering, it’s what a full kitchen is to a microwave. You can sure put effort into a microwave meal but it’ll always work against you and much of the time you’re better off just picking up a pan.

Not to diminish your enjoyment, you’re completely entitled to it, I just think this is a bit of a false equivalence

This is entirely my point. Observing reality, you can see how little impact any of this is truly having. Decision making, communication and alignment is not helped at all by LLMs, it’s just leaving developers with more laundry.

It tends to be when the training data wanders into their area of expertise temporarily and they go “OMG, they hype is real. I was so wrong” and then a few releases later they’re on the train and furious that the skills in their domain space have not just stopped improving, but regressed. Cue someone else in a different part of the world starting the same cycle.

Meanwhile the guy who leaned in a year ago and gave up reading the output is beginning to see work grind to a halt and throwing more agents at it is increasingly not working.

You can see these tropes all over social media near constantly.

Thing is. You can find an extremely similar paragraph written about Claude 4.x or some equivalent gpt. And simultaneously, many people expressing their frustration and the shortcomings of <insert any model>

“But it’s different this time” - several people, several times over the last couple of years.

This is not at all a dig at you, I’m very sorry if it reads that way. My point is these things only get truly better in anecdotes. The ways in which they fail is yet to change. Just yesterday I had gpt 5.3 generate completely awful code for the Cinema 4D Python API. Also an anecdote. But for all of the people saying they are truly intelligent and truly reason, they still make obvious mistakes, write around problems, fail entirely at architectural decisions, fail at random, generate FAR too much code.

And no amount of harnesses, methodologies, loops make much of a difference. If you listen to people on the internet they say it’s all working. You listen to people on the job and they mostly say it’s creating tech debt and a review bottleneck. Also burnout, so much burnout.

I think LLMs are mediocre. I think it’s fine they’re mediocre. You can work with low expectations. But the hype cycles are so tiresome.

Will? They already have.

Extremely high. Or at least several partial solutions that can be smooshed together.

LLMs really do still just reassemble things in their training data. There’s just a lot of it now, people anthropomorphise and struggle visualising large things. Some people say it’s truly reasoning but hit a topic that is under represented in the data of any LLM and it’ll transport you very quickly back a couple of years and ruin the illusion quickly.

I disagree. It's still extremely possible to "google whack" an LLM on a topic with little publicly available information. If you ask questions about APIs in desktop software, say something like Houdini, it'll produce a bunch of non-sequiturs. A lot of that knowledge lives offline in VFX studios, but it's just some fairly run of the mill python API stuff. You'd expect it to do better.

Similarly I've run into several "you just gotta know" type problems where LLMs still just fail. My favourite was a quirk in how async relationships work inside emberjs. Three different models gave a variation of the same incorrect answer. When I searched myself, I initially came up with nothing and eventually found what I think might be the only example of the same issue on the internet, a single stack overflow question wth two responses. The first is what Claude, gemini and chatGPT said, the second response was the OP saying it was wrong. I asked in the Ember discord and a core team member responded instantly with the answer.

There's a video I love on Youtube, where a guy uses ML to assemble a blank jigsaw. It performs amazingly, the jigsaw being blank is of no consequence and if it did have an image, it'd perform worse. That's all LLMs do. Just because the jigsaw pieces are smaller, they're still just getting assembled in whatever way fits, there's no mechanic for interpreting the image on the front.

I also think it's universal. When talking about this IRL I always say:

"If one teenager works hard and saves for a few years to buy themselves a car and another has theirs bought for them on a whim, who would appreciate their car more?"

Odds are it's the former, not always. But mostly.

I don't think it inherently devalues it. But the mediocre baseline for it and how much it entices you to allow it to just spit out that mediocrity takes discipline I don't think everyone has. I've seen some lean in and keep their heads just fine. I've seen others lean in and become disillusioned.

Worst of all I've seen good engineers lean in and begin thinking uncritically and magically.

Didn't see this reply before adding my own. Yes, I think we're in agreement.

I think this is just my choice of wording, friction as a means of slowing down and thinking something through is useful. Friction isn't just a roadblock. For all the times you want to do something exotic, throw an hour or two at it and in the process realise it was a bad idea and a more elegant idea emerges. That, that's the kind of useful friction I mean.

But overall yes, time spent thinking is the thing that matters.

It's less "there should be more friction" and more "LLMs remove too much". Instant gratification is great if you're a consumer, awful if you're a creator.

A drum I've been banging increasingly often recently is that having friction and time to work ideas over in your mind adds huge amounts of value. Vibe coded projects have this very specific, well, vibe to them where you can clearly see that the lack of time to digest has allowed the person to not challenge their own worst impulses. You can see it in the feature bloat, the lack of depth and polish in core features and the wild asides you tend to talk yourself out of still on display.

No, that's not what this analogy is about. At all.

See, table saws are dangerous. Famously so. One of, if not the most dangerous tools available to the general public. They spin quickly with lots of torque and pull things in faster than you can react. Pressure can also send loose pieces of wood backwards at high speed. Fast enough to pass through a person sometimes. It's like being hit with an arrow.

Tablesaw accidents can remove fingers and hands instantly, puncture organs.

They can be used safely but they're circumstantial, the worst thing you can do with a table saw is experiment. Once you realise there's a 12-inch razor sharp blade spinning at 3000rpm with up to 5HP you begin to respect how dangerous it could be and want to warn others.

It's intentionally hyperbolic. But you see what I'm saying here?

To use your analogy again, it's kind of like the shop boss buying everyone a table saw and then saying "The best way to use the table saw is just experiment with it, it's the fastest and most accurate straight cut we can get - the future is table saw."

That’s why I said “effectively run as” rather than is. Cathedral does make contribution to software less open, that’s kind of its entire deal and what I’m talking about here. It doesn’t make it any less free, but then a good number of software companies sell access and closed versions of open source projects, so we continue to split hairs.

I found chezmoi kind of annoying and then just moved to symlinks and a fossil repo. Low tech and low drama

Reports of Ruby slowness are often exaggerated. Around the time GH was built that was certainly true, but in the ways that matter Ruby is more than fast enough nowadays, even at scale. (Shopify is a rails monolith, as is intercom and a bunch of other massive services) Compute is/was pretty cheap and the economics of ROR mean that it's ultimately not that expensive to run. I think GH's slowness is a mixture of mismanagement and issues on the frontend.

But for sure a systems language is going to be far faster on paper and Rails is far from perfect and does have some performance foot guns you need to avoid. And yeah, architecture is everything.

Yes, standard rails. Rails does not ship with components out of the box and the most prominent component system for rails was built and is maintained by GitHub. They have been moving to React for the last few years though, it seems to be more about hiring and ergonomics rather than capability.

In the first beta they've actually made aspects of it worse with more instances of the glass effect than before. It's still very distracting even with the slider all the way over to opaque