horizion2025

I agree but to be fair, often people could have asked an AI to get their answer. Especially seniors are prone to this (thinking the AI could not possibly know this or other biases). The responder wrote they asked Claude so as to not take credit for the answer and also to indicate they did not vet it. Then the person asking can decide if they want to read the answer or not (often a 1 sec glean can reveal if it is promising or completely off track.

One honestly caveat:

Hard to say exactly what went wrong from outside, but a frontier model not being able to implement a simple CRUD feature after 3x8 = 24 hours of work isn't "it can't do this". Let me hazard a guess from what you wrote. The 3-tier spec (design → specs → build details) may be the cause rather than the cure. A big upfront spec has two failure modes the model can't help you with: it can quietly contain contradictions, and it can be ambiguous in ways the model resolves by guessing instead of asking. "Adding clients" is a good example of the trap, even assuming your real spec was more detailed than the comment. "Client" is overloaded — a customer in the domain? An API client? A consumer of a service? And "A clear design requirement was essentially adding clients" is very imprecise: does the model add them, or build a UI so the end user can add them? I know this was just your comment and sorry to sound harsh but if the spec had sentences like that I can definitely see it going off the rails.

Your own conclusion, smaller, concrete units, is the right direction. Except by units I don't mean partitioing the program into smaller units (files, modules). In fact, you should stop thinking about implementation at all. I'm thinking more about the way of asking the LLM to build it. One feature at a time etc. so you can tighten the feedback loop. Then you can early on (in the first hour say): "I also need a way that the user can add/manage clients - basic CRUD" and that small sentence might be enough the model makes it all (UI, API, backend etc.) to enable that and put it in a proper place in the app. A big ambiguous spec defers that discovery to the worst possible moment.

The article is not about generative AI at all.

Predictably, now office workers and engineers (including here) will say "What I always knew - LLM's can't think, be creative, don't have nuance. My job is safe!". I predict the article will be quoted again and again at lunch tables and family gatherings. However, one should be especially careful when something confirms ones own biases.

Firstly, the "AI" discussed here is not LLM's. They are talking about visual quality inspection systems. There's been many other articles in the press: Ford's new quality automation is computer-vision defect inspection, built on IBM's visual-inspection tech, iPhones photographing parts on the line, running since 2020. By most reporting it works fine, pushing detection rates from ~70% manual to 99%+. This is classical CNN at work doing the job of quality inspectors... completely unrelated to desk-work by an engineer or what LLM's do... yet that's exactly the inference the headline invites (and many here in the comments seem to be making).

The timing only underlines it: rehiring is presented as the cleanup. Apparently the rehirings started 3 years ago, so whatever it's undoing is older still and therefore unlikely to be LLM driven. While ChatGPT did come out 3.5 years ago it seems doubtful someone would fire people left and right the moment they saw the first ChatGPT... only to then regret almost it immedaitely and rehire them - all within the span of 6 months.

This further supports that the article is about years-old automation bet being quietly unwound, and is completely unrelated to mainstream discussion about AI and jobs today.

Also, 350 rehires is just noise. Ford is shedding thousands right now: plant pauses, battery-plant retooling, projected restructuring in the 8–13k range.

Finally, as always with corporate announcements... ask why an internal staffing decision is even a press story. To me this feels like PR (a nice feel good story that ties into to a subject people discuss a lot now). It takes the sting out of all their announced layoffs. There's probably also internal company politics to it (someone suggested rehirings and now want to say 'see what a great idea this was' and maxx it out).

Sometimes it makes up strawmans where it implies you wrote or implied something insanely stupid and then "corrects" this. My interpretation of it is that it has been taught to give nuanced answers and seeing things from every perspective and somehow this goes overboard where it starts nuancing something "just in case" the user held non-nuanced views. Some cases are OK (if it just adds information) but I hate it when it goes "it is not X, it is Y..." where X is some stupid view you never implied and Y is what you actually wrote!

Titanium dioxide is now an IARC 2B suspected carcinogen.

Btw titanium dioxide is now a suspected carcinogenic. It is illegal in food in the EU now.

Wrong there are plenty of other ingredients. In fact one of those ingredients that is permitted in EU and not US is ecamsule. It is quite nice, it absorbs the UV photons by switching confirmation (different isomere) rather than being oxidised into ROS/free radicals as many other ingredients do.

My concurrency knowledge is a bit rusty but aren't spinlocks only supposed to be used for very brief waits like in the hundreds of cycles (or situations where you can't block... like internal o/s scheduling structures in SMP setups)? If so how much does all this back off and starvation of higher priority threads even matter? If it is longer then you should use a locking primitive (except for in those low level os structures!) where most of the things discussed are not an issue. Would love to hear the use cases where spin locks are needed in eg user space, I dont doubt they occur.

But if that is so why this focus on the few clock cycles of dispatch?

I don't understand this focus on micro performance details... considering that all of this is about an interpretation approach which is always going to be slow relatively speaking. The big speed up would be to JIT it all, then you dont need to care about structuring of switch loops etc

The worst is when the only 'dismiss'-option is "I will do it later"... even if you have no intention of ever doing it... essentially forcing you to lie. It has been a while since I've seen it though, so that's progress!

Well it also means it could be a good time to buy so you won't have to pay even more overprice for the same performance years down the line. I just bought one a good month ago. My old one was over 10 years old, not worn out, but not upgradeable to Win 11. I had been thinking waiting one more year before the security updates to Win10 are out... But I bought in when the first stories hit of the DDR5 price rises - at that time there had 'only' been a doubling, now the price is a further 3x of what I paid a good month ago. I thought it might be a good time to buy given the machine was so old and component prices were going up, and might for a long time. But yeah, performance improvements aren't what they used to. Part of the reason is that normal things were already felt so fast on the old one ;-) But I did get a much better gfx cards allowing some games that were unplayable before, and I think the CPU upgrade was needed for that as well, and then you might as well overhaul the machine. I also went from 16 to 64 GB, and the 16 GB had been a bit too little for some things.