eslaught

I am on two program committees for major CS conferences this year.

LLM writing is horrible, full stop. The vast majority of papers that I see with obvious LLM writing ticks are also frankly incomprehesible. Claude's biggest sin at the moment is inventing new terminology (sometimes multiple times in a single sentence!) without stopping to explain what it means.

In previous years, I would see a substantial fraction (maybe 30-50%) of papers that were obviously written by non-native English speakers, and full of grammatical mistakes and typos. I have seen zero papers like that this year. Honestly, I preferred those: reading LLM writing is painful by comparison.

So far I have seen exactly one paper that had obvious LLM writing ticks, and yet had gone through enough passes (either of the LLM or the human authors) that the paper itself was comprehensible. So I'll admit that it's possible to do. But based on what I've seen this is vastly in the minority.

I honestly used to enjoy the review process; even when the papers were bad at least I could usually see the effort that went into it and give some constructive guidance on how to improve. The process is dramatically less pleasant now, and it's not obvious if I'm accomplishing anything: if authors who write with LLMs just stick the reviews back into those same LLMs, will they learn anything? I suspect not.

Maybe some day LLMs will be good enough to write, but as of today: please, please, just don't do it. The typos and grammatical mistakes are easier to read than the slop.

You're missing the biggest suggestion from the GP's post: that the key to LLM success is verifiability.

Software has high verifiability through compilers, linters, static analysis, leak/memory corruption detection tools, or the very least, running the program to see if it crashes.

Math (as has been making the headlines recently) has high verifiability through automated theorem provers. Notably some of the non-mechanized math results from LLMs have been demonstrated to be wrong (and presumably many more are being checked; these aren't exactly easy to understand proofs).

Game playing (chess, go, Star Craft, etc.) is similarly verifiable: you get your score and you always know how you did in the end (even if not in the moment).

Making assumptions about LLMs in non-veriable domains is making a claim about LLMs that doesn't match their current capabilities. Maybe they'll get there and maybe they won't; I can speculate as well as you can but we're both guessing, so I'm not sure how much value the speculation has.

As far as I can tell, you're essentially creating a new stack for every dynamically-sized variable (because otherwise nothing would be able to grow by bump allocation without moving). But this means you're creating a separate virtual memory allocation for each of these objects, which (I presume?) then rounds the size up to the OS's minimum page size (4KiB or similar).

Doesn't that waste a lot of space? Or is there something I'm missing?

Also it would seem to force every allocation to go through the OS kernel to allocate unless there's some trick to avoid that.

One aspect of trauma is the helplessness of it: it's not just how severe the physical reality is, it's also about the inability to do anything about it (and the internalization of that inability).

The classic example is a child who drew a picture shortly after 9/11. The picture included people floating down the building on (I believe) balloons or umbrellas. Obviously unphysical; but the child imagining ways (however fantastical) that could have helped was a factor in reducing that child's trauma.

On a therapist can tell you whether you personally have trauma, but the lessons you took away from your experiences certainly sound like it to me.

What's better about it in your usage?

Why not? Cargo.lock includes the transitive dependencies, and Cargo itself reports everything that changes when you do an upgrade. Those are version changes, not code diffs, but it seems entirely tractable.

The linked project page [1] claims to be fully homomorphic. Assuming the claim holds (I haven't verified it), then there is provably no way for Google or anyone else to obtain any information from the encrypted data or computation performed on them.

FHE is traditionally horrifically slow, so it's hard to imagine running anything beyond toy models with it. They list some applications on the original article page, but (presumably) they must be dramatically stripped down in order to run within any reasonable time budget. This is not going to run anything like a Sol/Opus any time soon.

[1]: https://heir.dev/

If AI works the way you suggest then we've literally been here before and we know exactly how this goes.

When tractors came along, farmers became dramatically more productive. Were the farmers who did things the old way "forced" to buy tractors in order to stay afloat? Over time, sure. But this was in no way zero-sum. More products made it to market (literally), more of the workforce was able to shift away from manual labor, and society became much better off overall. The people who moved to cities made dramatically more money, and the farmers who remained made more money too.

Edit: this is literally on the front page right now: https://news.ycombinator.com/item?id=48775979

This is not a prisoner's dilemma in any meaningful sense, unless you just like being inefficient and wasting a bunch of human effort.

(I'm not convinced yet whether AI actually works this way or not. I'm just saying, if it works this way, the economic theory is well-developed and we can predict fairly accurately how it's going to play out.)

In what sense is AI like paying for ads? In one case you legitimately lose to the competition if you stop (prisoner's dilemma). In other case, whether and how much you lose depends almost entirely on how much it actually impacts your productivity in practice (or not).

If you're referring to the public perception benefits (supposing those even exist, which isn't clear to me), then it seems easy to make a lot of noise via PR while doing the minimal amount internally to explore the use case and not actually push it as hard as you say.

Or, you know, just use a service intended for this purpose:

https://timestamp.stanford.edu/

And how do you get this to work exactly? I keep getting variations of "Missing required parameter: redirect_uri" in the OAuth flow.

The solutions proposed by Gemini and Google's AI summaries all hallucinate agy subcommands that don't exist, hilariously.

Edit: after bouncing around several GitHub threads, I realized that the agy TUI framework is wrapping the URL in a way that causes spaces to be inserted where the URL wraps. That's hilarious.

Just popping in here because people seem to be surprised by

> I build on the exact hardware I intend to deploy my software to and ship it to another machine with the same specs as the one it was built on.

This is exactly the use case in HPC. We always build -march=native and go to some trouble to enable all the appropriate vectorization flags (e.g., for PowerPC) that don't come along automatically with the -march=native setting.

Every HPC machine is a special snowflake, often with its own proprietary network stack, so you can forget about binaries being portable. Even on your own machine you'll be recompiling your binaries every time the machine goes down for a major maintenance.

Post is new but the original PDF is from 2025:

Previous discussion: https://news.ycombinator.com/item?id=42959775

Please don't take up space in the comment section with accusations. You can report this at the email below and the mods will look at it:

> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.

> https://news.ycombinator.com/newsguidelines.html

Without an empirical methodology it's hard to know how true this is. There are known and well-documented human biases (e.g., placebo effect) that could easily be involved here. And besides that, there's a convincing (but often overlooked on HN) argument to be made that modern LLMs are optimized in the same manner as other attention economy technologies. That is to say, they're addictive in the same general way that the YouTube/TikTok/Facebook/etc. feed algorithms are. They may be useful, but they also manipulate your attention, and it's difficult to disentangle those when the person evaluating the claims is the same person (potentially) being manipulated.

I'd love to see an empirical study that actually dives into this and attempts to show one way or another how true it is. Otherwise it's just all anecdotes.

I agree with your points. Answering your one question for posterity:

> Also how were the data races significant if nobody noticed them for a decade ?

They only replicated in our CI, so it was mainly an annoyance for those of us doing release engineering (because when you run ~150 jobs you'll inevitably get ~2-4 failures). So it's not that no one noticed, but it was always a matter of prioritization vs other things we were working on at the time.

But that doesn't mean they got zero effort put into them. We tried multiple times to replicate, perhaps a total of 10-20 human hours over a decade or so (spread out between maybe 3 people, all CS PhDs), and never got close enough to a smoking gun to develop a theory of the bug (and therefore, not able to develop a fix).

To be clear, I don't think "proves" anything one way or another, as it's only one data point, but given this is a team of CS PhDs intimately familiar with tools for race detection and debugging, it's notable that the tools meaningfully helped us debug this.

> it is a career-ending failure

It depends highly on the field. In history, sure. The point of getting a history PhD is to become a history professor, and you can't do that if you don't get the PhD, and meanwhile history PhDs don't meaningfully open up any other job prospects, so attempting and failing to get a PhD provides negative value.

In CS and many engineering disciplines, there is a long history of people dropping out of PhDs and landing in industry. The industry is therefore much more accustomed to, and therefore accommodating to, people taking this path. Whether it's a maximally efficient use of time is another question, but it's certainly not wasted effort.

But I do agree that it's stressful nonetheless because it still feels like a failure even if it is not actually in reality. I wrote about this when I put down my own PhD journey here [1]. In particular after the control replication (2017) paper, I very nearly quit out of academia entirely despite it being my biggest contribution to the field by far.

[1]: https://elliottslaughter.com/2024/02/legion-paper-history (written without any use of LLMs, for anyone who is wondering)

I have an old account, you can read my history of comments and see if my style has changed. No need to take my word for it.

Iteration is inherent to how computers work. There's nothing new or interesting about this.

The question is who prunes the space of possible answers. If the LLM spews things at you until it gets one right, then sure, you're in the scenario you outlined (and much less interesting). If it ultimately presents one option to the human, and that option is correct, then that's much more interesting. Even if the process is "monkeys on keyboards", does it matter?

There are plenty of optimization and verification algorithms that rely on "try things at random until you find one that works", but before modern LLMs no one accused these things of being monkeys on keyboards, despite it being literally what these things are.

For context I've been an AI skeptic and am trying as hard as I can to continue to be.

I honestly think we've moved the goalposts. I'm saying this because, for the longest time, I thought that the chasm that AI couldn't cross was generality. By which I mean that you'd train a system, and it would work in that specific setting, and then you'd tweak just about anything at all, and it would fall over. Basically no AI technique truly generalized for the longest time. The new LLM techniques fall over in their own particular ways too, but it's increasingly difficult for even skeptics like me to deny that they provide meaningful value at least some of the time. And largely that's because they generalize so much better than previous systems (though not perfectly).

I've been playing with various models, as well as watching other team members do so. And I've seen Claude identify data races that have sat in our code base for nearly a decade, given a combination of a stack trace, access to the code, and a handful of human-written paragraphs about what the code is doing overall.

This isn't just a matter of adding harnesses. The fields of program analysis and program synthesis are old as dirt, and probably thousands of CS PhD have cut their teeth of trying to solve them. All of those systems had harnesses but they weren't nearly as effective, as general, and as broad as what current frontier LLMs can do. And on top of it all we're driving LLMs with inherently fuzzy natural language, which by definition requires high generality to avoid falling over simply due to the stochastic nature of how humans write prompts.

Now, I agree vehemently with the superficial point that LLMs are "just" text generators. But I think it's also increasingly missing the point given the empirical capabilities that the models clearly have. The real lesson of LLMs is not that they're somehow not text generators, it's that we as a species have somehow encoded intelligence into human language. And along with the new training regimes we've only just discovered how to unlock that.

It's not just about the increase in volume, it's about the delta between the prompt and the generation.

If the generation merely restates the prompt (possibly in prettier, cleaner language), then usually it's the case that the prompt is shorter and more direct, though possibly less "correct" from a formal language perspective. I've seen friends send me LLM-generated stuff and when I asked to see the prompt, the prompts were honestly better. So why bother with the LLM?

But if you're using the LLM to generate information that goes beyond the prompt, then it's likely that you don't know what you're talking about. Because if you really did, you'd probably be comfortable with a brief note and instructions to go look the rest up on one's own. The desire to generate more comes from either laziness or else a desire to inflate one's own appearance. In either case, the LLM generation isn't terribly useful since anyone could get the same result from the prompt (again).

So I think LLMs contribute not just to a drowning out of human conversation but to semantic drift, because they encourage those of us who are less self-assured to lean into things without really understanding them. A danger in any time but certainly one that is more acute at the moment.

Is there something like this, but without (or with minimal) spoilers?

It's that, but it's also that the incentives are misaligned.

How many supposed "10x" coders actually produced unreadable code that no one else could maintain? But then the effort to produce that code is lauded while the nightmare maintenance of said code is somehow regarded as unimpressive, despite being massively more difficult?

I worry that we're creating a world where it is becoming easy, even trivial, to be that dysfunctional "10x" coder, and dramatically harder to be the competent maintainer. And the existence of AI tools will reinforce the culture gap rather than reducing it.

Not the same industry but at least one literary agent does this: if you physically print and mail your book proposal, they will respond with a short but polite, physical rejection letter if they reject you.

But I think it's a generational thing. The younger agents I know of just shut down all their submissions when they get overwhelmed, or they start requiring everyone to physically meet them at a conference first.

But this is exactly my point: if your "code" is different than your "pseudocode", something is wrong. There's a reason why people call Lisp "executable pseudocode", and it's because it shrinks the gap between the human-level description of what needs to happen and the text that is required to actually get there. (There will always be a gap, because no one understands the requirements perfectly. But at least it won't be exacerbated by irrelevant details.)

To me, reading the prompt example half a dozen levels up, reminds me of Greenspun's tenth rule:

> Any sufficiently complicated C++ program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. [1]

But now the "program" doesn't even have formal semantics and isn't a permanent artifact. It's like running a compiler and then throwing away the source program and only hand-editing the machine code when you don't like what it does. To me that seems crazy and misses many of the most important lessons from the last half-century.

[1]: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule (paraphrased to use C++, but applies equally to most similar languages)

But this is what I don't get. Writing code is not that hard. If the act of physically typing my code out is a bottleneck to my process, I am doing something wrong. Either I've under-abstracted, or over-abstracted, or flat out have the wrong abstractions. It's time to sit back and figure out why there's a mismatch with the problem domain and come back at it from another direction.

To me this reads like people have learned to put up with poor abstractions for so long that having the LLM take care of it feels like an improvement? It's the classic C++ vs Lisp discussion all over again, but people forgot the old lessons.

Here's a paper from September 2025 that compares programs for (a) semantic equivalence (do they do the same thing) and (b) syntactic similarity (are the parse trees similar).

LLMs are more likely to judge programs (correctly or incorrectly) as being semantically equivalent when they are syntactically similar, even though syntactically similar programs can actually do drastically different things. In fact LLMs are generally pretty bad at program equivalence, suggesting they don't really "understand" what programs are doing, even for a fairly mechanical definition of "understand".

https://arxiv.org/pdf/2502.12466

While this is a point in time study and I'm sure all these tools will evolve, this matches my intuition for how LLMs behave and the kinds of mistakes they make.

By comparison the approach in this article seems narrow and doesn't explain a whole lot, and more importantly doesn't give us any hypotheses we can actually test against these systems.

If you drive in the FasTrak lanes without an account you pay the fee + $10 surcharge (for a first time violation), and it goes up on the second violation:

https://www.bayareafastrak.org/en/help/invoices-and-penaltie...

I'm having a hard time finding a citation but according to Google's AI summary if the second violation is unpaid they put a hold on your DMV registration, and the fine itself can be sent to a collection agency.

I agree empirically I see people driving through the lane without a tag (i.e., no number shows up in the overhead display), but maybe these are people with FasTrak accounts being lazy?

The other answers are great, but let me just add that C++ cannot be parsed with conventional LL/LALR/LR parsers, because the syntax is ambiguous and requires disambiguation via type checking (i.e., there may be multiple parse trees but at most one will type check).

There was some research on parsing C++ with GLR but I don't think it ever made it into production compilers.

Other, more sane languages with unambiguous grammars may still choose to hand-write their parsers for all the reasons mentioned in the sibling comments. However, I would note that, even when using a parsing library, almost every compiler in existence will use its own AST, and not reuse the parse tree generated by the parser library. That's something you would only ever do in a compiler class.

Also I wouldn't say that frontend/backend is an evolution of previous terminology, it's just that parsing is not considered an "interesting" problem by most of the community so the focus has moved elsewhere (from the AST design through optimization and code generation).

The solution I've found is to make using the API a hard error with an explicitly temporary and obnoxiously-named workaround variable.

    WORKAROUND_URLLIB3_HEADER_DEPRECATION_THIS_IS_A_TEMPORARY_FIX_CHANGE_YOUR_CODE=1 python3 ...

It's loud, there's an out if you need your code working right now, and when you finally act on the deprecation, if anyone complains, they don't really have legs to stand on.

Of course you can layer it with warnings as a first stage, but ultimately it's either this or remove the code outright (or never remove it and put up with whatever burden that imposes).