'we' is the operative word here. 'We', meaning technical people who have followed this stuff for years. The target audience of this article are not part of this 'we' and this stuff IS completely new _for them_. The target audience are people who, when confronted with a problem with an LLM, think it is perfectly reasonable to just tell someone to 'look at the code' and 'fix the bug'. You are not the target audience and you are arguing something entirely different.
For the purposes of the article, which is to demonstrate how developing an LLM is completely different from developing traditional software, I'd say they are true enough. It's a CS 101 understanding of the software development lifecycle, which for non-technical readers is enough to get the point across. An accurate depiction of software development would only obscure the actual point for the lay reader.
I don't think he's doing that at all. The article is pointing out to non-technical people how AI is different than traditional software. I'm not sure how you think it's giving AI a break, as it's pointing out that it is essentially impossible to reason about. And it's not at the expense of regular developers because it's showing how regular software development is different than this. It makes two buckets, and puts AI in one and non-AI in the other.
You should read the footnote marked [1] after "a note for technical folk" at the beginning of the article. He is very consciously making sweeping generalizations about how software works in order to make things intelligible to non-technical readers.
Not OP, but a while back I ran weekly for months outside with no issues. It got hot, I ran two miles inside on a treadmill and got the first shin splints in my life. I hear from other runners that treadmills can hurt your form because you run differently on them than on solid ground. Try running off a treadmill and see if it helps.
I work at what used to be Pivotal, now Broadcom via VMware, and do pair programming every day. It was a bit of an adjustment, and I do sometimes miss solo dev work, but pairing does have some real benefits. It is really nice to have another set of eyes to catch mistakes you miss, and it's fantastic for spreading knowledge and onboarding new developers.
One could argue these are minor failure states, but ok, let's change it to anything that loses some amount of progress. Dying in non-hardcore Minecraft is a failure state because whatever you were trying to do was cut short, whether exploring an area, gathering resources, etc.
If you restrict failure states to only mean things that end the game, then games like Dark Souls do not have any failure states, since in Dark Souls you always respawn when you die. Most other modern single player games would also not have any failure states, since they also let you respawn as often as you like.