In my bubble, I’m seeing people write entire software stacks from scratch, single-handedly. At this point it’s clear to me that software engineering has taken off by a factor of 10x-100x, at least in some industry areas and in some circles.
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.
I can "write" a whole OS kernel by running `git clone https://kernel.org` — that does not make me much of the programmer. Copying software was never a problem — making the software perform the job you want was the problem.
Are you under the impression that LLMs take source from the internet and put it on your hard drive? That’s your good faith interpretation of what’s going on?
It does exactly what you say: takes source code from the internet and put it onto your hard drive, but in a very indirect way, occasionally verbatim, in other cases it renames identifiers and does a bit of composition.
You are completely discounting all of the original code being produced with LLMs. What percentage of LLM-generated code would you estimate is plagiarism? 1% 10%? 90%? 99%?
99%. LLM cannot do a bubble sort on its own — that's one of the main modes of failure actually, when LLM fails to recognize algorithm and writes its own implementation. LLM is basically recognizing, concatenating known algorithms, renaming variables, functions names, interpolating multiple similar solutions into one target solution — with a success rate corresponding to the number of solutions it saw for this task.
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.
I've submitted two PRs to fix bugs in open-source system tool last month. Both of these are targeted fixes to highly-specific bugs that existed in this software. The agents I used debugged the issue and implemented fixes and tests autonomously.
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"
You were talking about code writing, now you switched to debugging. Those are wildly different tasks, and some researchers suggest to employ separate LLM-s for code writing vs debugging.
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.
> You were talking about code writing, now you switched to debugging. Those are wildly different tasks
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'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?
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.
> No, they are not the same, and they require different tools
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.
>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
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.
>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 small-scale but I know a lot of Blind people who are vibe-coding accessible tools to solve their problems. Most of them have never done any programming at all.
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.
Agreed and I have also built many useful tools for myself. Many of my peers in business functions such as sales and finance have done the same thing, but these mostly amount to personal productivity, which is hard to measure. The claims I'm responding to are that software productivity is 10x or 100x - and we just aren't seeing any outcomes that support this. In fact, development work on our core platform is not more efficient at all in terms that we can measure - like delivered story points (which are not perfect, but are what we have).
We are coming an external tool as they 15xd prices on us. We have spent a lot of tokens and about a month, and are incredibly close to matching the external tool.
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.
> In my bubble, I’m seeing people write entire software stacks from scratch, single-handedly.
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.
What about productivity gains (recent/profit, company bottom line)? I think that’s what the op’s measuring. Have you seen a 10x-100x on that front? If not, what’s the disconnect here?
Productivity != sales, especially in software, I think. This has been happening for just a few months, less than one project cycle. I think we’re about to see a huge wave of software products. But it’s possible most of these are competing for a slice of a constant-sized pie, though.
When your manager/boss asks how this huge productivity gain gonna lead to better product -> sale, and why are they spending a good amount of money on AI tools, do you say “Productivity != sales, especially in software”?
I don’t know anyone in this situation. No idea how it works in corporations, and I’d rather not find out.
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.
It doesn’t matter who the boss is. It’s the same dynamic. That person needs to live, and they need to earn money. The money spent, needs to be justified in profits made, otherwise it’s not a business. I was questioning the absurd 10x-100x company output, which is relevant to the op.
> It doesn’t matter who the boss is. It’s the same dynamic.
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.
Yes. Because it is not my job to optimize for sales. It's to optimize for time to ship whatever features/fixes the manager/boss gives me. There's an entire sales wing who can answer the question on how/if shipping this out faster will actually make the company more money.
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 didn’t, because Waymo cars were proof of concept, not proof of wallet size.
It is very impressive engineering, just not very useful or ever going to result in any viable product. It’s a dead end. A waste of somebody’s engineering effort and talent for a one-time rich guy demo item. People hate on it because they get it.
You’re confused. This isn’t a “maybe there’s more demand for flying cars than you think!” kind of situation. My dude, nobody is disputing the demand for flying cars. It is fairly obvious, however, that they’re completely infeasible technology, and even if not, then this certainly ain’t the way to do it.
> I have a general tendency to know things. I think it has something to do with my brain.
Your brain can predict future?
> But also, I read about how this tech works. Have you? If so, how are you possibly still confused about this?
I think that in 1900s there were a lot of people that were saying the same things you are saying about brothers Wright and their inventions. And yet, if there is demand and value in specific things people will find a way to make it work cost effectively and at scale.
Some fonts use three lines to draw a triple equals ligature. That, and it is, well, triple long. I’ve never had any problems with distinguishing anything with ligatures. They’re nice to look at, and very easy to read once you’re used to them. Skill issue, guys.
It is common knowledge among most - if not all - civilizations that you do, in fact, need to learn to read in order to know how to read.
Anyway, since you want a direct representation of the text - presumably, you configured your editor to render EOL sequences explicitly, to distinguish tabs from spaces, etc?
But when you squint your eyes, LLMs are just a least-effort manifestation of the wider neural net direction we’ve been chipping away at for decades. I don’t give a fuck whether LLMs are here to stay; they’re proof that scaling neural nets gets you pretty far.
The real question is: will neural nets hit a wall? As a human, I certainly hope so. But I’d bet that they won’t. I’d bet that we’re igniting the ~~atmosphere~~ universe in slow motion.
Just in the last few days I had an example where the Google Search version of Gemini had a much better and more comprehensive answer, by far, than ChatGPT. It had to do with Amazon’s use of Data Matrix barcodes on shopping bags. Gemini was able to fully describe how they’re used in Amazon’s logistics chain. ChatGPT essentially said it didn’t know. Your preconceptions may not be accurate.
They might be, but still, I’ll be difficult to convince that Google’s shitty-ass 10B params instant answer models are good at anything other than cookie recipes and producing farts real fast for real cheap.
For what it’s worth, any time I see that feature, it’s all farts.
It depends on what you’re searching. If you only ever need really basic information like keyboard shortcuts or “is it & or &&?” then it’s pretty good, and definitely faster. And if it gets it wrong, then the shortcut doesn’t work or the code doesn’t compile and I search again and try the links.
It's just a google search but you can explain what you're searching for. AI summary may contain misleading details if you read it and take it literally, but 90% of the time it gives me pointer for the thing I need and I don't have to scroll through results that often could be just as misleading if not more.
It's demonstrably not. This summary, somehow, often fails to search, or fails to read what it searches and gives you the opposite answer. You shouldn't trust it.
In their world, it gives them the wrong answer that kills their dog, but it's fine because they never know because they don't look anywhere else. The dog dies, they're sad for a while, get a new dog, get on with their lives.
There's no reason not to trust it because since they trust it, they don't percieve anything wrong. They just take it and whatever happens happens, no annoying conflicting info and certainly none of that old grampa thinking and working and giving a shit about anything.
> I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
I do feel there is a limit to human-s today. I did not try, but I doubt it would work if I asked literally any programmer I know "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Hell, I'm willing to bet they'd fail at this task even with an unconstrained snacks and kombucha budget. Humans have a long way to go. My job is safe.
> A focused experienced skilled programmer can do better but the market niche for that kind of code is actually small.
At this point I think the only reason someone would do better without an LLM is an unwillingness to use it effectively. Even if you’re going to write all code by hand and only use an agent for validation and debugging, that’s a significant boost.
This says “Anthropic gives you 5× more API-priced model usage”, which is not equivalent to “Anthropic is 5x as much value”. This does not take into account model/harness efficiency. I tried looking up some benchmarks and Claude seemingly uses roughly 5x as many tokens while taking its sweet time to complete a task. No such thing as a coincidence.
It's so that, when judgement day comes, our Lord Jesus Christ of Nazareth has a concrete record of what you've been doing with your semen. It's very important, you see. God's work, even.
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.
reply