byko3y

We can end with things like "drinking cofee is an essential part of debugging for me". Debugging is an integration work, just like architecture planning, so it's somehow tied to plain english skills, reading docs, running whatever existing commands there are, parsing tools output is very important thing.

Another point on which we should reach an agreement is the definition of debugging, as I suspect you may have your own definition. Fixing compiler error is not debugging. Glancing over source code is not debugging. Debugging is characterized by running a program and comparing the actual outcome with the expected one — implying finding the exact part of the source code responsible for the problem. Meatbags often do not read the full related code, and sometimes are not even experts in that particular programming language, or simply don't own the code and have hard time digging into it.

Countrary, LLM-s excel at bruteforce code sifting and spitting two more 200-lines python scripts each minute. Still, even with AI debugging is not just "read and write code" — it's rather a high level skill with code read-writing being the largest hammer in the belt. Hammer so large AI will write several large scripts rather than use existing simple command.

>It's also fun to write your own debugging tools by the way - just imagine any debugging workflow you think is good, write the tool, give the agent some tips how to use it, and they'll do great. It's so good, you should really try it.

You conflate crutches with features. LLM-s absolutely suck at interactive tools, so they have to compensate with their strongest side: writing-reading code. Not because that's the absolutely most efficient way to debug, but because the economy is shaped differently in the world of AI. Running application manually, manually collecting logs, and then feeding them into AI is not "debugging made by AI" — it's the debugging made by human while AI doing the "code sifting" part of the debugging process.

>> The fact that you personally do both things does not mean everybody and everything does it this way.

>I don't, but LLMs certainly do.

When I look at my agent doing 1000 characters one-line python script for testing/debugging, I do realize there is no way it could be a common code-writing skill, regular python code does not look like this, the skill requires some special understanding of agentic loops, it cannot be from pre-training dataset. And you definitely cannot say that "being able to write code" automatically enabled "being able to debug" — just try any pre-2025 model that is decent at code writing but not trained for modern tools/harness (I'm pretty sure some newer models also lack this ability, but such models are harder to spot). I'm pretty sure everybody here tested pre-2025 models, it's really nothing to argue about.

>Programming and debugging is self-evidently part of the same training loop. Agents write code, validate it and adjust trajectory.

I would suggest you to re-examine some fundamental explanation of how LLM training actually happens, because it seems to me you don't differentiate pre-training and post-training stages (and post-training has lots of flavors in it). Trying to train LLM for agentic coding and debugging before it learns basic code patterns is a huge waste of resources. "Never say never" — if you manage to generate dozens of billions of agentic training sets, you can probably end up doing "coding+debugging pre-training", but so far neither Anthropic nor Google have resources to do that, rather they employ millions of fine-tuning samples. And I heart those companies have lots of money.

It is true that modern LLM-s are trained to do basic chain-of-thoughts/agentic loops at the very begginning of fine-tuning (i.e. after pre-training), but it should be noted that LLM can do implicit chain of thought and code writing BEFORE any fine-tuning. Just the base model can do that, but the format of input and output does not correspond to what humans and harness expect. And that's basically how the chain of thoughts was discovered: researchers asked LLM to solve some task step by step — and it did. Nobody trained LLM to do that, it just reproduced some patterns from pre-training sets. And then researches started training LLM-s to specifically optimize agentic loops.

> I don't know what to tell ya, it's how the LLM sausage is made.

Even small Phi-4 was pre-trained on only 40% synthetic data, despite Phi-1 employing 99%+ synthetic data. Once again, you should split pre-training and post-training.

On modern super-large LLM-s the large corpus of agentic loops for fine-tuning is indeed generated via external expert agentic loops, but it never becomes 100% as the model collapse is real and well known. Just in case the wording "model collapse" is not clear: the model starts using extremely limited set of tools to solve every task, even when much more efficient tools are available. I can see the tendency for model collapse on Grok 4.7 and Sonnet 5.5 I often use, and their engineers definitely partially counteracted this tendency.

>I usually see this in people who are struggling to downplay LLM capabilities, and their strategy is to pretend that everything LLMs are good at was trivially accessible in the training data all along.

I tried feeding non-canonical Tarjan bridge-finding implementation into AI approx year ago, and it went totally crazy: it says the implementation is incorrect, then traces it via supposed counter-example and finds it correct, then tries to give new explanation and once again suggests the implementation is bugged... The fact we put lots of crutches beneath the same pattern-matcher does not make it a completely different mechanism.

Most people never leave their sit during the AI ride so AI drives them through the pre-defined happy path. But once you try to deliberately leave this road, LLM-s often mark the code "wrong/unoptimal/poorly formatted". That's particularly a reason why older agents used to agressively introduce completely unrelated refactoring/formatting changes — because they just did not like how many spaces you've used in your code — and modern LLM-s still suffer from this problem, but their harness and agentic loops usually hide at least part of those meaningless changes.

The people talking about "increased output" ­— do you have any proofs for these words? I'm working in IT — I don't see any radical productivity growth. Yes, you can doo hello world 4 times faster now — but even then when you need to polish it the speed of development stabilizes near baseline real quick.