I'm not either. I think it may look "cool" visually but when trying to work with code with those in it, it seems odd, like that it's a single character even though it's not and it just breaks the flow
Because most of those who commented are among those who do not like ligatures, I must present a counterpoint, to diminish the statistical bias.
Some people like ligatures, some people do not like them, but this does not matter, because any decent text editor or terminal emulator has a setting to enable or disable ligatures.
Any good programming font must have ligatures, which will keep happy both kinds of users, those who like and those who dislike ligatures.
I strongly hate the straitjacket forced by ASCII upon programming languages, which is the root cause of most ambiguous grammars that complicate the parsing of programming languages and increase the probability of bugs, and which has also forced the replacement of traditional mathematical symbols with less appropriate characters.
Using Unicode for source programs is the best solution, but when having to use legacy programming languages in a professional setting, where the use of a custom preprocessor would be frowned upon, using fonts with ligatures is still an improvement over ASCII.
A coding font is supposed to help you distinguish between characters, not confuse them for each other. Also, ASCII ligatures usually look worse than the proper Unicode character they are supposed to emulate. The often indecisive form they take (glyphs rearranged to resemble a different character, but still composed of original glyph shapes; weird proportions and spacing due to the font maintaining the column width of the separate ASCII code points) creates a strong uncanny valley effect. I wouldn't mind having "≤", "≠" or "⇒" tokens in my source code, but half-measures just don't cut it.
Try this - For the same task, try the same prompt three times with totally different framing - do it fast, be comprehensive, find stuff I’ve missed, etc.
Then throw away the ones you don’t like.
It also prevents reinforcement of your incoming pov.
I’ve found this has made me way way better at steering.
Okay.But if I need three different framings just to converge on one coherent implementation, I’m still doing architecture recovery by hand. That’s a big part of why I started building something local around the codebase itself.
For me the framing is critical - what is the model saying yes to? You can present the same prompt with very different interpretations (talk me into this versus talk me out of it). The problem is people enter with a single bias and the AI can only amplify that.
In coding I’ll do what I call a Battleship Prompt - simply just prompt 3 or more time with the same core prompt but strong framing (eg I need this done quickly versus come up with the most comprehensive solution). That’s really helped me learn and dial in how to get the right output.
It's the most transformative technology I've clocked in my lifetime (and that includes home computers and the Internet).
Large organizations are making major decisions on the basis of it. Startups new and old will live and die by the shift that it's creating (is SaaS dead? Well investors will make it so). Mass engineering layoffs could be inevitable.
Sure. I vibe coded a thing is getting pretty tired. The rest? If anything we're not talking about it enough.
It’s a blend. There are plenty of changes in a production system that don’t necessarily need human review. Adding a help link. Fixing a typo. Maybe upgrades with strong CI/CD or simple ui improvements or safe experiments.
There are features you can skip safely behind feature flags or staged releases. As you push in you fine with the right tooling it can be a lot.
If you break it down often quite a bit can be deployed safely with minimal human intervention (depends naturally on the domain, but for a lot of systems).
I realized recently that I've subconsciously routed-around merge conflicts as much as possible. My process has just subtly altered to make them less likely. To the point of which seeing a 3-way merge feels jarring. It's really only taking on AI tools that bought this to my attention.
I'm surprised to see that some people sync their working tree and does not evaluate their patch again (testing and reviewing the assumptions they have made for their changes).
If it’s any comfort, I don’t hear many JS/TS/Node/etc developers calling them threads or really thinking of them that way. Usually just Workers or Web Workers — "worker threads" mostly slips in from Node. Even then, "worker" dominates.
In terms of tradeoffs, if you’re coming from the single event loop model, they’re pretty consistent with the rest of JS. Isolation-first, explicit sharing, fewer footguns. So I think the tradeoffs are the right tradeoffs.
FWIW, traditional threads have their own tradeoffs (especially around IO). In JS that’s mostly a non-issue, so the "I need 1000s of threads" case just doesn’t come up very often.
reply