Oh yeah, that reminds me of yesterday. There was a problem and I was asked to look together with a guy from another team. The other guy was spinning out and spouting all sorts of wild ass guesses about the behavior and talking and talking about why it might be happening and why it calls for a change that would have been massively a pain in the ass for the user, but in principle would solve the issue if implemented, and pressuring me to make those changes right that second.

I said just wait a moment, gave a patch that just simply fixed the problem, explained the actual root cause, why it was a very quick fix, and used the balance of the time to improve performance because the experience was slower than I liked, even if the customer had not complained about it (something took about 2 minutes that should have been near instant, but they just "assumed that's the way it is").

No AI involved whatsoever, but a very AI like behavior of spouting nonsense that sounds right and just shotgunning off some design in hopes of it doing something, no matter how messy.

Just an example of why AI is so "exciting" in the tech industry, so many are already used to just guessing without understanding and hoping it works.

we're just so extremely susceptible to it.

Judging by the leaders of the world throughout history — yes we are indeed. And it's so sad.

I didn't notice that. The fact that Redhat is merging random crap is scary.

I just don't understand the workflow with these people.

You know how people say "don't run a command you are given or find online unless you know exactly what it does"?

Why would anyone accept/merge a PR from an LLM unless they knew what the consequences were, or verified its claims. I just will never get this trust in LLMs, given I know even vaguely how they work.

Reproducing the bug with an automated test is harder, its code you can run that tests your other code.

But allows you to just 1 click run it and get a yes/no "is this still broken" output without having to manually reproduce it by hand each time.

Whats important is this is in the domain of what LLMs can actually work with, the output of the test is something they can parse and iterate on until it works.

They execute the command to run the test, check the output, and keep working til the test passes.

They can add additional tests to help isolate the problem, or strip down the existing test until its doing the absolute bare min steps to reproduce, in order to narrow the scope of whats causing it.

But when your test involves stuff running in the kernel of an OS, your automated tests meed to effectively be code you write that bootstraps a virtual machine up and manipulates and observes that second machines kernel...

You can do it, but its one of the most complicated forms of automated tests to design and run!