I don't think we're anywhere near AGI yet. We have some clever models, sure, and outputs are getting better and better, but they're hardly AGI - the biggest missing bit being that they don't learn from experience - even "memories" which are carried from chat to chat are limited (and, in my experience, there's a 50/50 chance they just get ignored - I've had several rounds of "why did you do that, when I explicitly asked you not to?" with a back-pedal from the model).

IMO, AGI will not be achieved via LLMs. There has to be a radical change in how these things are built, and my feeling is that we should be working off of modelling what we understand of neurons in humans and animals. /2c

If the AI had progressed to the point where it's controlling manufacturing, and there are no core professions that it relies on which can't be automated, then it could definitely outlive it's creators by far, but would face some of the same crises: global warming, resource scarcity, and, ultimately, final fates like having your planet swallowed by the system's host sun (like us). The same challenges that uphold the fermi paradox would apply there too, and perhaps we're too early in the development of the universe for the millions of years required for an artificial super-intelligence to have gotten there yet.

The author seems to think that these basic challenges wouldn't apply to an AI, which makes me think that they have far too much faith in AI, likely propped up by the rhetoric around the subject right now.

Anyhoo, 'nuff said: my opinion is that the OP should "git gud" or accept that they will never reap the benefits of a good test suite.

As you've pointed out, the problem is literally a skill issue - the OP never really "got into" testing, they don't understand the usefulness, or what makes a test good or bad. This is like hiring a contractor, telling them vaguely "build me a house" and then complaining afterwards that the house they built isn't what you wanted. If you give ai no feedback, you'll get code (and tests) which are the median of what's publically visible in your field. If you want good results, you have to be prepared to teach the agent what you want, which includes feedback about how things should be done, and, ideally, _good examples in your code-base_. So I'd say it's easier for someone without testing fundamentals to get into the "tests are bad" state - they don't know what they did wrong, they don't know how to fix it, and they (boldly, and incorrectly) assume that the ai _does_ know. It knows _nothing_. It's a tool, and you'll spend at least some of your time correcting it.

I couldn't imagine feeling any sense of security without a healthy unit test suite. In particular, when adding a new feature, or updating something somewhere else, having some kind of automation that can tell me I didn't break stuff that wasn't broken before is invaluable.

Where the OP does have a point (albeit by implication) is that: WHEN TESTS RUN SLOWLY, EVENTUALLY, NO-ONE RUNS THEM.

When I joined the company I'm at now, they had about 2k tests on their main product - they couldn't be run reliably as a suite, so no-one did. They were indeed pointless. Now we have 15k tests on that project, and they run on every push, and before every deployment. The reason? My primary task was getting testing working reliably (which also included trying to get other devs to opt into proper testing - which had variable results - some people will push against what they see as "more work" for "no purpose" simply because they don't understand the purpose. The point is: now that they all run within about 5-10 minutes (depending on the host machine), they're run all the time, and they provide useful feedback when dev in one area has unintended side-effects in another area.

"This group ended up taking 29% fewer sick days compared to the control group (IRR 0.71). Yet the study explicitly notes that there was no significant difference between groups regarding total sick days."

if you take 29% fewer sick days, how is there no significant difference between two groups regarding total sick days? Unless this is taking into account the entire year, not just the study period, in which case, the remedy works whilst using it, as backed by the numbers.

The problem isn't rust or understanding rust. Agents make plenty of mistakes in mainstream languages like JavaScript and C#. The off-hand deflection signals, to me, that whoever came up with that excuse has far too much faith in the bots. We do have to check their code, and we will find errors.

on the PR topic tho: my latest challenge is putting out my rage fires after people lazily post a claude (or other aigen) review without any understanding themselves, forcing me to defend the code against agent errors. Yes, there are also useful things in there, but people are getting lazy - since "coding is solved", they seem to think PRs are also solved :/

AI-gen code is often subtly (or obviously) incorrect. Human eyeballs are the cure. There is no way to go faster without compromising the value of the review.

What I've been super annoyed about recently is the number of times I've seen a completely stupid question on a PR - eg "why are you doing this?" when there's a comment right above that line about the why. Or "where else is this used?" - we all have IDEs and reviewers obviously have access to the code - stop being a lazy potato and check out the code locally.

I try to avoid adding these lazy people to PRs as they create more work than they help. But sometimes they end up on there anyway, because they're "important".