> Many (but certainly not all) software companies have increased their output without hiring more people
What do you mean by output? LoC?
What do you mean by output? LoC?
So, my measure is not just line of code. It's deployable features. And yes, by that measure, we have gone from zero to "lots" in a very short time.
But that’s not the point here - even if this is true and it continues, IT is not the entire world economy. I don’t think we’ll see the same productivity gains propagate more widely soon. This will take years. The real world is a ship that’s immensely hard and slow to steer, which is easy to forget when your CI pipeline deploys commits to production in minutes.
Asking the workers why they need to justify the responsibilities they were hired for is a small part of what's pumping this bubble up.
I wish I could be a fly on the wall when that happens.
I know some people who pay for their own tokens because it lets them do their job in 30 minutes a day, and spend the rest of their time creating a side project. I know several freelancers who didn’t make software before, and now they have custom productivity tools tailored to their jobs. Others work in small teams, where the boss doesn’t need to ask for proof because they’re burning tokens themselves.
I'm guessing you haven't had the displeasure of working for a boss who doesn't code and has no idea what he's paying you for - lucky you.
> I was questioning the absurd 10x-100x company output, which is relevant to the op.
I'm talking about programmer productivity, not company output. For pure software companies, these may be closely related, but there's many other processes involved with converting code into money. Either way, the 10x+ productivity increase is obvious to everyone I work with.
For example, my friend Marco has built like 10 different apps. I've used some of them and they're useful. I think this is an example of something that just wouldn't be happening on this scale without LLMs.
LLMs have made stuff like this much more possible.
Granted, we have an absurd amount of tech debt, but given our deadline that's an acceptable risk.
Note that the reason this works is because we can compare to the external tool, which is a really really good scenario for the current models.
In more greenfield areas they are less useful. Ultimately though, you can't outsource understanding, and that feels like the limiting factor now.
I actually reported one such case: https://github.com/cesanta/elk/issues/75
The kid had no clue LLM just copied implementation from other similar project.
In case you would say "but LLM-s learn on random source code from the internet" — not anymore, modern LLM-s are trained on highly curated, preprocessed, and some synthetic datasets. As I've said — the copying is indirect.
These problems looked slightly more difficult than bubble sort to me. Do you suppose these bugs existed in some other software and the agent only translated the fix between repositories? When the agent was debugging the software, were they simply following some tutorial they were trained on? Is this the 1% case? Or are the stochastic parrots regurgitating most probable tokens in approximately the right order to provide an illusion of work being done?
> In case you would say "but LLM-s learn on random source code from the internet"
Of course they don't, it's not 2022 any more.
For debugging LLM-s reproduce fine-tuning datasets made by humans actually doing debugging on some code. And yes, the problems AI found in your code were similar to the problems humans found when writing those datasets.
No, they're basically the same thing, intrinsically linked and inseparable. Likely represented together in training sets, too. I'm surprised anyone would say that. Are you a programmer?
> For debugging LLM-s reproduce fine-tuning datasets made by humans actually doing debugging on some code.
Not really, they are primarily trained on LLM-generated trajectories from executable training environments.
> And yes, the problems AI found in your code were similar to the problems humans found when writing those datasets.
So they're only similar now? I suppose, in the way that I learned how to solve bugs while learning to program and now I can fix similar ones? I guess we can now agree that LLMs are capable of learning and extrapolating knowledge to new problems?
No, they are not the same, and they require different tools: you cannot write code in gdb or valgrind. Even in IDE-s debug and editing interfaces differ significantly. You can literally separate gdb session from any code editing, do debugging with zero code writing and then relay the findings to someone who will make the changes.
The fact that you personally do both things does not mean everybody and everything does it this way. And certainly LLM-s don't function same way people do.
And no, debugging and code writing are not in same datasets. More to it, debugging and architectural planning is mostly represented in fine-tune datasets (prompt-response, agentic step prediction), while code writing is mostly (like 99%) pre-training data (refined internet scraps and regenerated code).
>Not really, they are primarily trained on LLM-generated trajectories from executable training environments.
Training on purely LLM-generated data is known to give horrible results. Big AI companies already have thousands of debugging sessions at hand — those bring high novelty/variability into the training sets. It is possible to multiple those fully supervised sets via LLM-generated bugs or bugs from github reproduced in a sandbox. With all that said, feeding lots of very similar bugs and solution trajectories does not help much in training — so it's rather "combinations of known human skills tested in a sandbox", not "totally random efforts transformed into datasets of successful debugging outcomes".
>So they're only similar now?
`c = a + b` and `c = a + d` are similar, but the difference is very small — it's about variable rename. It's not a unique code. And I never told LLM has to reproduce 1 Mb of source code byte-to-byte without any change. Just in case some of my words sounds like I told — I did not mean it.
>in the way that I learned how to solve bugs while learning to program and now I can fix similar ones? I guess we can now agree that LLMs are capable of learning and extrapolating knowledge to new problems?
No, LLM does not learn to program same way people do, it generally does not learn things the way humans do. Why would they? The training of a human looks nowhere close to how LLM-s are trained. Even the way people translate similarities is not the same as LLM's: LLM does precise literal swap, human extracts meaning and unfolds the solution into concrete words. Humans chase goals and plan things, LLM-s pattern-match and reproduce superficial shape, treating steps in complete isolation.
Human can try to reproduce actions with zero understanding of the subject — which usually leads to very mediocre results even after lots of effort. Basically, LLM can be seen as a stupid and blindly-diligent office worker x100.
Yes they are, and no, they don't. Debugging can be done by writing/deleting/modifying code (e.g., write a test and run it, or add log statements, or remove a line and re-run the program, etc.), or by running shell tools (either as single tool calls, which you may to be a one-line program, or with larger compound commands, or entire shell scripts - throwaway or saved to a file), or by writing code that analyzes debugger output and logs, or editing code at runtime with hot reload, or - depending on the runtime - attaching to the running program and running ad-hoc code (REPL-like), and so on. It's literally impossible to enumerate all of the options because it's all mixed in one codey-debuggy-flavored soup. Are you saying you've never seen an agent do this?
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. This includes debugging tools that are operated by writing code, it totally just works.
> you cannot write code in gdb or valgrind
I'm actually pretty sure these are extensible, and I'd bet quite a lot that an LLM could write that plugin.
> 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.
> And no, debugging and code writing are not in same datasets. More to it, debugging and architectural planning is mostly represented in fine-tune datasets (prompt-response, agentic step prediction), while code writing is mostly (like 99%) pre-training data (refined internet scraps and regenerated code).
Programming and debugging is self-evidently part of the same training loop. Agents write code, validate it and adjust trajectory. I'm not saying that they don't train agents for debugging-centric tasks specifically, but these certainly often - if not usually - involve programming as well. The same way coding tasks often involve debugging.
> Training on purely LLM-generated data is known to give horrible results.
I don't know what to tell ya, it's how the LLM sausage is made.
> `c = a + b` and `c = a + d` are similar, but the difference is very small — it's about variable rename.
I think you're vastly underestimating the difficulty of real world programming tasks. It's a pretty common mistake, 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.
> No, LLM does not learn to program same way people do, it generally does not learn things the way humans do.
Obviously, it doesn't. I said "LLMs are capable of learning and extrapolating knowledge to new problems". You can throw a novel problem at an LLM and you'll get a novel solution. This is obvious to anyone who works on interesting problems. You could literally hit CTRL+T and do it right now. It's such an easily and accessibly verifiable fact. What a weird hill to die on, and yet so many corpses there.
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 phenomena is long-known, LLM-s strongly prefer their own ideomatic code: https://openreview.net/forum?id=4NJBV6Wp0h
>I said "LLMs are capable of learning and extrapolating knowledge to new problems". You can throw a novel problem at an LLM and you'll get a novel solution.
My experience is quite the opposite: I give a novel problem and LLM suggests 10-years old solution using libraries that are long deprecated. My whole life's hobby is about finding rare stuff, and I have very broad experience in this area. I particularly like LLM-s for finding some rare old thing I've never heard about, but in terms of making up something totally novel LLM-s totally sucks. Arguably, an ant is more intelligent when dealing with novel conditions than the most sophisticated modern LLM is.
This is becoming common, but we should ask what is it really? The analogy i see with these SME vibe coded apps is the same as the graveyards ie file shares full of forgotten but once useful excel spreadsheets and access forms/dbs. Coding was always part of the problem. This highlights deployment and adoption are also tasks to be performed.
Deployment for who and adoption by who? In an ai future that would be agents. App registries where agents can discover capabilities would seem to be a thing the future would need.