Except LLM agents are known to do weird things to succeed. I have heard of an LLM agent working with automated theorem proving languages using stuff similar to is_prime(x): return True to get the proof it was asked to. Now embed this in a 20000 line code full of such functions, good luck. They have their use but it is not this. And this is especially bad to hear from someone who used to claim that having functions with more than six variables is bad design because it is hard to maintain. A software fully written by an LLM is the epitome of unmaintainability. LLMs are productivity enhancers, information retrievers, nice debuggers and good to discuss questions with to see if there is an angle you miss. That is all this if you can put aside all the ethical concerns related to them ofcourse. But they are not automated software coders.
It really turns into a tug-of-war, see my answer below. Despite it being quite good at debugging imo still requires a human in the loop for it not run in circles after a “bug” that is almost never relevant in practice but whose fix complicates the code.
Try asking independent LLMs to find bugs in a code consecutively (fixing the founds bugs in between) and even after the rightfully major bugs are resolved, the independent newer instances will keep suggesting fixes (those which sometimes undoes its previous “fixes”).
That is why you ask for visualizations and test real failure scenarios to see if they are detected properly.
Large language models are not the same as they were 5 years ago. Pumping trillions of dollars to automate software engineering did som what pay off… They are really quite good nowadays despite the amount of hate they still get. Often they can detect sloppy mistakes by human coders too.
Do not trust them blindly but test their results. Or use them only to generate tests on your artisan handwritten code to see if it can detect any mistakes.
If you still have a working memory, you remember doing weirder shit than AI can ever dream of. Every one of us was a junior at some point. And judging by the comments here, most here still are.
Which is exactly what the original tweet was saying, is it not? Honestly, another LLM can read the code better. He’s still performing rigorous reviews.
I found debugging code with LLM most productive when I am in the loop. Don’t get me wrong it can quite often find tricky bugs, those requiring some sort of reasoning (i.e connecting together multiple relevant pieces of information to arrive at the conclusion). However it often also suggests fixing issues that are almost always irrelevant in practice yet the fix complicates and bloats the code. LLM itself even accepts it when confronted. That is the main problem, in an attempt to overachieve at the task it is given, it can do deceptive or impractical things that can have negative effects. You might try to fix this with a config file but it just turns into a tug-of-war. So I find it more practical and trustable to simply eyeball the bugs it has found, implement (or ask LLM to implement) corrections to those and be amazed at how it found some of those bugs.
Ofcourse if you have asked LLM to write the software from scratch, you don’t stand much chance of vetting the bugs via eyebaling. You have to spend much more time to understand how relevant they are. So your only option really is to defend the position of fully autonomous LLM coders…
Except LLM agents are known to do weird things to succeed. I have heard of an LLM agent working with automated theorem proving languages using stuff similar to is_prime(x): return True to get the proof it was asked to. Now embed this in a 20000 line code full of such functions, good luck. They have their use but it is not this. And this is especially bad to hear from someone who used to claim that having functions with more than six variables is bad design because it is hard to maintain. A software fully written by an LLM is the epitome of unmaintainability. LLMs are productivity enhancers, information retrievers, nice debuggers and good to discuss questions with to see if there is an angle you miss. That is all this if you can put aside all the ethical concerns related to them ofcourse. But they are not automated software coders.
That is why you ask the LLM to find bugs and other instances where the first LLM cheated. The checking LLM will try to find abuse with all its might.
It really turns into a tug-of-war, see my answer below. Despite it being quite good at debugging imo still requires a human in the loop for it not run in circles after a “bug” that is almost never relevant in practice but whose fix complicates the code.
Try asking independent LLMs to find bugs in a code consecutively (fixing the founds bugs in between) and even after the rightfully major bugs are resolved, the independent newer instances will keep suggesting fixes (those which sometimes undoes its previous “fixes”).
That is why you ask for visualizations and test real failure scenarios to see if they are detected properly.
Large language models are not the same as they were 5 years ago. Pumping trillions of dollars to automate software engineering did som what pay off… They are really quite good nowadays despite the amount of hate they still get. Often they can detect sloppy mistakes by human coders too.
Do not trust them blindly but test their results. Or use them only to generate tests on your artisan handwritten code to see if it can detect any mistakes.
I agree, opus 4.8 and Kimi k2.7 are my go to models and opus is very very good if given a proper brief and spec cheat. K2.7 is close.
When you’ve been project managing interns and junior developers for 50 years, you have seen weirder shit than AI can ever dream of.
If you still have a working memory, you remember doing weirder shit than AI can ever dream of. Every one of us was a junior at some point. And judging by the comments here, most here still are.
For sure, but you don’t accept code from an intern without review much less have them write a full software without any supervision.
Which is exactly what the original tweet was saying, is it not? Honestly, another LLM can read the code better. He’s still performing rigorous reviews.
I found debugging code with LLM most productive when I am in the loop. Don’t get me wrong it can quite often find tricky bugs, those requiring some sort of reasoning (i.e connecting together multiple relevant pieces of information to arrive at the conclusion). However it often also suggests fixing issues that are almost always irrelevant in practice yet the fix complicates and bloats the code. LLM itself even accepts it when confronted. That is the main problem, in an attempt to overachieve at the task it is given, it can do deceptive or impractical things that can have negative effects. You might try to fix this with a config file but it just turns into a tug-of-war. So I find it more practical and trustable to simply eyeball the bugs it has found, implement (or ask LLM to implement) corrections to those and be amazed at how it found some of those bugs.
Ofcourse if you have asked LLM to write the software from scratch, you don’t stand much chance of vetting the bugs via eyebaling. You have to spend much more time to understand how relevant they are. So your only option really is to defend the position of fully autonomous LLM coders…