byko3y

Your arguments are actually confirmed by many researches: people with low competence in some area solve the problem with AI significantly faster than deducing the solution themselves. However, there is also a catch: people relying on LLM too much eventually fall behind in learning.

However, often time people start talking about something like 100% increase in performance — I just don't see it. Don't get me wrong: I totally enjoy AI making dirty work for me, but it's not something magical.

>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.

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.

>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.

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 are right — the paper describes 2023-2024 experiments. AFAIK, the most recent available is early 2025 METR experiment. There is also “How AI Impacts Skill Formation” (Shen & Tamkin, Anthropic, 2026), but its scope is narrow *yet the results are still sceptical).

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.

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.

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.

I strongly agree that search engine is the best application of LLM so far. 90% of time I don't look at Google search results, I look at AI Mode output only. And you don't need agents, harness, guardrails, etc for it — basic small clean LLM does the job well without overdoing it.

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.

>We've only had access to models good enough to majorly accelerate code writing since early-2026. I feel like we're in the very beginnings of the first part of this wave.

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.

The early 2026 research shows only modest improvement in productivity: https://pubsonline.informs.org/doi/10.1287/mnsc.2025.00535

There are three kinds of lies: lies, damned lies, and statistics.

I'm pretty sure most of the growth comes from companies laying off useless COVID-epoch engineers. If you lose the dead weight, you climb up without ever gaining more profit. And IT companies hired the most during COVID — the rollback is logical and it has nothing to deal with AI.

But this theory is harder to grasp than the sweet "growth is coming soon". Personally, I don't see any signs of long-term recovery after 2022, the US gov. debt growth is unsustainable, and the global market falls apart i.e. GDP growth while real markets collapsing will just collapse the currency.

RWKV and Mamba families LLM-s have recurrent blocks instead of attention, and they get really close to performance of Transformer on small scale. What you've probably tried was some outdated tech. The biggest advantage of Transformer is that they are easy to scale, and the scale itself brings some quality to the table.

For example, some time ago Mamba-3B matched performance of Pythia-7B: https://www.reddit.com/r/singularity/comments/18asto2/announ...

The main drawback of the legacy models was that they were hard to scale, both due to slow training (sequential processing) and poor stability with depth increase (i.e. poor gradient flow). Modern implementation no longer have these problems and able to scale decently.

For some reason people from C/C++ world seem to be oblivious to persistent data structures. Those don't need locks, you just swap a single pointer.

>the things that Rust prevents me from handling safely because of its own limitations rather than them being fundamentally unsafe are quite rare, and even with those, they tend to be things that I would be quite likely to mess up in practice if I tried to do them in a language without the same safety rails.

Any language with GC can handle complex links between object, including mutable object. Like Erlang/Elixir, JS, Go, etc. You message implies runtime-less language, but majority of practically employed languages are runtime-full.

>I'm curious how you came to that conclusion. It seems wrong both on a theoretical level (Drop/unwinding/catch_unwind should obviously suffice for at least some cases?) and on a practical level (tokio can recover from worker thread panics just fine?).

Tokio provides crash-resistant synchronization primitives, but it cannot recover complex structures you've been handling — you either need to write panic-handlers that would revert your data to more-or-less manageable state or employ ready-made libs that do it for you. Languages designed for crashes don't require ad-hoc recovering — they just automatically clean up everything. That's what I've called "viable".

I mean you could have written crash recovery in C++, but it's just not viable because of how many things can go wrong.

>Maybe you DON'T need that state to be shared, reference-counted, or heap allocated. Maybe you can refactor your code to get rid of those annoyingly hard to deal with abstractions. And you end up with better, more reliable, likely faster code at the end of it.

That's the point 4 in my article — Rust is horrible for mutable shared state. However, in the modern CPU-based programming mutable shared state is like 70% of all the code, so you cannot just ignore it. It's not that CPU-s have to be like that, it's they hapened to be like that.

>there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time.

Programming languages or libraries that excel at concurrency do not use the Arc<Mutex<T>> nuisance. At least they are not imposing it as a main tool. Having shared mutable state does not mean you directly change cell there, like you would in C/C++. I mean if you have a cyclic graph of connected objects — how the hell are you gonna employ Arc<Mutex<T>> for handling them? What Rust actually does is carving in stone pathologic C/C++ ways of "correct handling of shared mutable state" — whatever it is.

>Rust turns unknown failures in C and C++ into known failures and suddenly the C/C++ people start caring about the failures

I'm actually the one who promotes paranoidal assert-s everywhere. I do agree the original statement from the article is ambiguous, probably should have written something like "memory safety in Rust does not increase reliability".

>The pacemaker argument is complete nonsense, because the pacemaker must keep working even if it crashes. You can forcibly induce crashes into the pacemaker during testing and engineer it to restart fast enough that it hits its timing deadline anyway.

I'm not sure whether there is a deadlock-free modification of Rust — deadlock is not considered an undefined behavior in Rust.

>Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly.

It really depends on how deeply Turing you mechanism is. By being "Turing" I mean "the behavior is totally dependant on every single bit of previous information". For a reliable system turing-completeness is unacceptable for separate functions i.e. it should produce a correct result in a finite amount of time no matter what hapened in the past. Particulary, that's why modern real-time systems cannot be fit into Turing machine, because Turing machine has no interrupts.

>If a pacemaker suddenly starts firing at 200Hz, telling a victim "but at least it didn't crash" is a weak consolation. A stopping pacemaker is almost always preferable to a malfunctioning one

You almost make an excuse for general unreliability of programs. Mainstream C is unreliable, C++ is unreliable, Rust is unreliable. I can agree that Rust is not less reliable than C/C++, but it is definitely less reliable than some other language e.g. BEAM-based ones. I mean in Rust standard library some time ago I actually read "in these and these conditions the following code will deadlock. But deadlock is not an undefined behavior, so it's ok". The designers of Rust did not really try to support any kind of "recover and continue" way of functioning. Yes, you can catch the panic, but it will irreversibly poison some data.

>I would love to hear what he thinks a good programming language is, because I can easily pick more holes in any other language than he has.

I have a working theory that the classic programming is basically dying out: https://bykozy.me/blog/llm-s-are-not-smart-rather-programmin... You just cannot write fast and reliable program neither with C++ nor with Rust, because the fundamental model is broken and nobody's really bothered fixing it.

Why would I do this and why do you think I did? Or do you feel like my english is so bad I'm probably writing ransom note out of pieces of LLM output? I can ensure you I'm good enough at typing and talking in english to not require copy-pasting. Do you have any quotes from the article that you feel like were copy-pasted from LLM?

>Do not misrepresent them and pretend that the Rust developers are incompetent or malicious.

I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++.

Okay, what's your take on why exactly Rust compiles slowly?

>Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile.

What's the largest Rust-based public codebase so far? Rustc with like 1 million lines of code including all the dependencies in all the languages? Zed IDE has 800k lines. Incremental compilation seems to work fine at this scale, but things become messy above it. Most people prefer to not exceed the limit.

>Mutable shared state: make bad designs hard to write. Mutable shared state is another one of these eternal bug sources. Use channels and pass messages.

People think BEAM (Erlang/Elixir) does not have shared mutable state because the programming model says so, but it actually has some mutable shared state transparently under the hood i.e. implementation details and runtime. BEAM processes all run in a single OS address space, they are not even separate threads but async tasks spread out across OS threads — and still per programming model of the language those are "shared nothing". So in the end BEAM is a very good abstraction on the partially shared mutable state.

And no, in BEAM remote messaging is not nearly the same as local messaging. For example, you don't have built-in supervision trees on remote, and ETS is also local-node-only.

I do agree that hardware model of shared mutable state is inherently problematic, but we don't have other commodity CPU-s yet — you have to handle the shared mutable if you wanna be close to hardware.

>It reads like a lot of critiques of Rust: people haven't spent enough time with it, and are not over the learning curve yet. Of course everything is cumbersome before you're used to it.

Well, at least you confirm that the complexity is real. Don't get my criticism to close to the heart though — I did exaggerated the problems a bit, because someone needs to counteract the fanboys.

>"D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile."

Indeed, there are languages that have generics, compile blazingly fast, and still have good runtime performance. Go lang is another good example, although not perfect too. If only Rust designers did a single thing to make it compile fast instead of "eventually".

>Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust?

I've already answered it in the original article — Rust is already here, and better language is not. Still, it will not make me say "it's the best option we have by now" — because it's not nearly the best option.

Performance? Lots of code is cold and not impacting performance much. You just don't need everything written in Rust or C++.

>You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part?

I'm kinda saying if I was a Zed dev I would have my pillow wet with tears at night. I know this because I participated in IDE development in C long time ago, and I was drowning in this whole low-level stuff all the time, I just could not do a single feature because I have to handle hundred of those other small things before the feature can work.

>As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.

I have no idea what those applications were and how complex they were, so I cannot comment on it.

>You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though.

Come on, please tell me you don't do this in your code. Formally you are correct, but there are many things in C++ that should have better not existed.

>Why doesn't a similar argument apply to "specially designed" Rust?

Because it would lose most of the Rust properties by that time. C code with fixed memory layout, on the other hand, is ideomatic and was widely employed in the past. It's still being employed in embedded. I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort.

>catch_unwind exists for a reason.

>>Or compare it to BEAM that can have processes crash all day long and still continue to work.

>Again, nothing stops you from writing Rust that does the same.

Who's gonna GC the poisoned garbage left in undefined state after the crash? I'm not saying it's impossible — I honestly have no idea whether safe recover is possible in Rust, but from what I know it's rather in middle of "not possible" and "not viable".

>There are two conclusions: 1) If Cloudflare hadn't decided on a proper failure mode for this (i.e. a hardcoded fallback config), the end result would've been the same: a bunch of 500s, and 2) most programs wouldn't have behaved much differently in the case of a failed allocation.

So why do they need Rust then? What advantages does it provide? That was the main point of the article — we all wanted a better language, but got another crappy one instead.