Writing tests is the one thing I wouldn’t get an LLM to write for me right now. Let me give you an example. Yesterday I came across some new unit tests someone’s agentic AI had written recently. The tests were rewriting the code they were meant to be testing in the test itself, then asserting against that. I’ll say that again: rather than calling out to some function or method belonging to the class/module under test, the tests were rewriting the implementation of said function inside the test. Not even a junior developer would write that nonsensical shit.
The code those unit tests were meant to be testing was LLM written too, and it was fine!
So right now, getting an LLM to write some implementation code can be ok. But for the love of god, don’t let them anywhere near your tests (unless it’s just to squirt out some dumb boilerplate helper functions and mocks). LLMs are very shit at thinking up good test cases right now. And even if they come up with good scenarios, they may pull these stunts on you like they did to me. Not worth the hassle.
MangoCats@feddit.it 3 days ago
Trusting any new code blindly is foolish, even if you’re paying a senior dev $200K/yr for it, it should be reviewed and understood by other team members before accepting it. Same is true for an LLM, but of course most organizations never do real code reviews in either scenario…
20ish years ago, I was a proponent of pair programming. It’s not for everyone. It’s not for anyone 40 hours a week, but in appropriate circumstances for a few hours at a session it can be hugely beneficial. It’s like a real-time code review during development. I see that pair programming is as popular today as it was back then, maybe even less so, but… “Vibe coding” with LLMs in chat mode? That can be a very similar experience, up to a point.