The title seems to suggest the author is talking about AGI - if the author is just co-opting the latest Trumpism, forget the rest of this...
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
I guess that would depend on the level of the AI - for instance, no matter how much good press any existing model gets, if nuclear war broke out, and all the humans died, eventually infrastructure would fail (2-6 weeks, I'd guess - just basics like the remaining power plants and water providers being taxed without maintenance), and the AI goes dark.
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.
I came here to say something very similar - glad to know that there are other level-headed engineers out there.
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.
also, what really changes the game is requiring that one write the tests _first_. Generally, I haven't had to do this with an ai - but it's an interesting idea (get it to write the test(s) first, and vet them - like I would do in real life - except only one test at a time, then the red-green-refactor dance). Writing the test first forces you to narrow down what you want to accomplish and makes you think about how, such that the prod code runs well and tests don't run like treacle.
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.
This is is exactly how I've been using AI for writing features: I write a spec. AI writes a test. I inspect/edit/give notes on the test until it's what I want and make sure it's red (to validate that my/the AI's assumptions are more or less correct). Then the AI edits the code only to make the tests pass. Then I do a sanity check on things and tidy them up to my liking. Cut a commit, work on next test.
TBH I feel like a dinosaur working this way, reading about others' more autonomous workflows. One merit it has is that it is a very cheap way to use AI, at least on the apps I work on, because Kimi K2.6 is more than adequate to give good results with this workflow.
Fair, I get the performance of DX12 or OpenGL may vary widely, but I was thinking for AI applications though further research on my part showed a dramatic math difference.
Sha256 is mostly integer additions, bit rotations, XOR, AND operations. While AI workload are matrix multiplication and accumulation. I sort of answered my own question then. :)
Is this ai-generated? because statements like this one contradict themselves:
"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.
Why would I want a slower moving release cycle for an app I use for banking and other personal stuff, whilst the latest models are finding CVEs left right and center? Get outta here with your slow-moving fork.
"However, managers also had to grapple with a few dozen regressions in the resulting code, pointing to AI’s ongoing challenges in understanding Rust. "
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.
While I largely agree, I suspect languages which require more memory management awareness, especially when they have opt out options like `unsafe`, will remain more challenging for the models. They have a tendency to turn things off to "pass the test"
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 :/
reply