I feel like the increased reviewing time is consistently understated. I’m just an IC, but it seems obvious to me that you cannot cut staff and achieve increased output. There literally aren’t enough eyeballs to go around reviewing code when everyone is 2-3xing their output. I spend so much more time reviewing code; reviews that are sorely needed because I regularly catch batshit insane “fixes” that work but would quickly turn the codebase into a mess (the most recent one being a multi-hundred line diff that I went and fixed in 2 lines in 15 min). Maybe I’m underthinking it but it seems obvious that you either maintain the same output with fewer staff or you gain increased output with the same staff. All the companies that are attempting to cut staff and gain increased output are chasing an impossibility and throwing away their opportunity to accelerate.
I’ve had a longstanding belief that big tech purposely over-employed because it denied resources to competitors. This gave them a velocity edge despite being big and bureaucratic. In the new AI world, denying resources doesn’t slow competitors down anymore because AI raises the productivity floor. Now that over-employment brings no competitive advantage, we’re seeing huge cuts.
Turnstile feels bad as a user. Every site that I’ve seen it long will lock up Safari hard while it’s doing whatever it’s doing. But at least I haven’t run into more than 2 refresh loops.
Same. Google Maps quality has gotten noticeably worse these past 2 years for me. It routinely tries to navigate me to making impossible turns or taking weird and sometimes more dangerous routes just to shave off a potential minute. I started using Apple Maps at the advice of a colleague and it’s given better directions. This is all local. I have no baseline comparison for using maps while on trips.
Took long enough. Maybe I missed it, but I didn’t see them say how invested they are in tackling this. Promoting a rule is one thing, but everything SEO related becomes a cat and mouse game. I don’t have high confidence that this will work.
Oh, so I’m not imagining this. Recently, I’ve tried to up my LLM usage to try and learn to use the tooling better. However, I’ve seen this happen with enough frequency that I’m just utterly frustrated with LLMs. Guess I should use Claude less and others more.
Does it? It only takes like 2 min for my electric kettle to boil. If I was a more avid coffee/tea drinker, I’d get one of the always heated hot water dispensers that are common in Japanese households (def one of the appliances I miss since moving back to the US). Then you never have to wait.
Dunno how long this is normally supposed to go but it took me 10+ min of actually seriously considering the fonts at each choice and the final suggestion is a font that I actively dislike. I’m curious how it’s narrowing things down because I noticed that it started to give me only serif fonts which I don’t like. But the sans serif ones that it was using to try and narrow things down had distinct characteristics that I didn’t like like very narrow stems or very narrow or wide characters. But it wasn’t doing that with serif fonts. I’m guessing it began to think I preferred serifs because of that but in reality, I wasn’t picking the lesser of two evils most of the time.
Yes, at least in my experience on flights in the USA. It’s very rare but it does happen. I was lucky one time that the person doing it sat next to me and I politely asked them to use headphones and no fuss was had.
This is quite wrong? There are some features that get blocked from being implemented because Wayland refused to define a protocol for everyone to implement. Window positioning being a recent example of how progress can get blocked for many years due to Wayland.
Fi’s customer service has long since turned to shit, but the things keeping me on it are the data sims, simple international roaming, and international calling. That trifecta is pretty hard to find a match for. Especially the data sims. But if you don’t need that, I probably wouldn’t recommend Fi. My wife had endless trouble with multiple bad sim cards and the customer service experience was just as dreadful as every other carrier.
(Don’t take this as advice. Just writing my own experience with this.)
This is the reason why I take the time to summarize all “why” decisions and implementation tradeoffs being made in my (too lengthy) PR descriptions with links, etc. I’ve gotten into the habit of using <detail/> to collapse everything because I’ve gotten feedback multiple times that no one reads my walls of text. However, I still write it (with short <summary/>s now) because I’ve lost track of the number of times I’ve been able to search my PRs and quickly answer mine or someone’s “why” question. I do it mostly for me because I find it invaluable as I prefer writing shit down instead of relying on my flaky memory. People are forgetful and people come and go. What doesn’t disappear is documentation tied to code commits (well… unless you nuke your repo).
IMO, the spirit of the idea is to put higher information density fields first, and let that smooth out the UX for the remaining fields as you go downwards. Yes, there will be exceptions but that only matters if you’re trying to absolve the user of all work for 100% of situations. Trying to do that is a fools errand. Invert the order and use the information gathered to make inputting the rest simpler for 80% of the users. Then make it easy for the other 20% to course correct (ex: don’t disable autofilled fields, highlight all text when tabbing to the next field, etc). I think this pattern is a good one to keep in mind, but not blindly follow, when designing the UX of a UI.
> Following additional review, Ars has determined that the story “After a routine code rejection, an AI agent published a hit piece on someone by name,” did not meet our standards. Ars Technica has retracted this article. Originally published on Feb 13, 2026 at 2:40PM EST and removed on Feb 13, 2026 at 4:22PM EST.
Rather than say “did not meet our standards,” I’d much prefer if they stated what was false - that they published false, AI generated quotes. Anyone who previously read the article (which realistically are the only people who would return to the article) and might want to go back to it as a reference isn’t going to have their knowledge corrected of the falsehoods that they read.
Another fascinating thing that the Reddit thread discussing the original PR pointed out is that whoever owns that AI account opened another PR (same commits) and later posted this comment: https://github.com/matplotlib/matplotlib/pull/31138#issuecom...
> Original PR from #31132 but now with 100% more meat. Do you need me to upload a birth certificate to prove that I'm human?
It’s a bit wild to me that people are siding with the AI agent / whoever is commanding it. Combined with the LLM hallucinated reporting and all the discussion this has spawned, I think this is making out to be a great case study on the social impact of LLM tooling.
Something about the tone of the article just makes me want to write a retort / criticism instead of praising the advice. Maybe it’s because it feels like an incomplete list or that it’s too generalized but written like the author has learned it all. For example, no mention of learning when and what to do to avoid frozen pipes. Or how to fix things when it happens. Also, shoveling snow isn’t that hard if you have the right snow shoveling equipment and know a bit of physics (which in my experience, locals will gladly teach you).
AFAIK, removing Antheas from Bazzite opened the door to discussions for forming the OGC. Prior to that, Antheas had created such difficult situations that many of the member groups in the OGC did not collaborate with Bazzite because of his presence. Whether or not the OGC actually works (ex: getting patches upstreamed faster), only time will tell.