eslaught

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

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

It depends on what you care about. If you're writing purely for yourself, then by all means, go ahead and do so.

I've found there's a balance to be found in listening to others vs yourself. Usually, if multiple people give you the same feedback, there is some underlying symptom they are correctly diagnosing. But they may not have the correct diagnosis, or even be able to articulate the symptoms clearly. The real skill of an author/editor is in figuring out the true diagnosis and what to do about it.

In the communication example, this means rooting conflicts in the true personalities of the characters and/or their context, so that even if they sat down to have a deep chat, they still wouldn't agree. E.g., character A has an ulterior motive to see character B fail. Now you hint at that motive in a subtle way that telegraphs to readers that something is going on, without stopping the action for what would turn into a pedantic conversation. At least, that's what I'd do.

It's because if you explain what's going on, you stop the action. And viewers/readers don't like that.

In fiction it's called an info dump. As an aspiring science fiction author, virtually every beta reader I've had has told me they don't like them. I want my fiction to make sense, but you have to be subtle about it. To avoid readers complaining, you have to figure out how to explain things to the reader without it being obvious that you're explaining things to the reader, or stopping the action to do it.

Movies are such a streamlined medium that usually this gets cut entirely. At least in books you can have appendices and such for readers who care.

To me it's interesting that (a) most people die of old age, and (b) the leading cause of death is essentially preventable (heart disease being highly lifestyle related) or else plausibly curable in the future (I certainly hope we'll see progress on cancer in my lifetime).

That was very much not the case historically; you can Google numbers yourself but the percentage of childhood deaths prior to modern medicine was truly shocking.

It also seems to indicate that, with some thought and care, a meaningful impact (both at individual and societal levels) is possible by altering our lifestyles to be healthier.

Conda doesn't do lock files. If you look into it, the best you can do is freeze your entire environment. Aside from this being an entirely manual process, and thus having all the issues that manual processes bring, this comes with a few issues:

1. If you edit any dependency, you resolve the environment from scratch. There is no way to update just one dependency.

2. Conda "lock" files are just the hashes of the all the packages you happened to get, and that means they're non-portable. If you move from x86 to ARM, or Mac to Linux, or CPU to GPU, you have to throw everything out and resolve.

Point (2) has an additional hidden cost: unless you go massively out of your way, all your platforms can end up on different versions. That's because solving every environment is a manual process and it's unlikely you're taking the time to run through 6+ different options all at once. So if different users solve the environments on different days from the same human-readable environment file, there's no reason to expect them to be in sync. They'll slowly diverge over time and you'll start to see breakage because the versions diverge.

P.S. if you do want a "uv for Conda packages", see Pixi [1], which has a lot of the benefits of uv (e.g., lock files) but works out of the box with Conda's package ecosystem.

[1] https://pixi.sh/latest/

If you're going to do this, why not generate Pandoc ASTs directly? You can do so from a number of languages and they support (by definition) a superset of any given markup's features, with blocks to call out directly for things you can only do in Latex.

I assume the original question is asking about programmatic document generation, in which case working with a real AST is probably also a productivity and reliability win as well.

I'd try to find ways to stack everything else in your favor as much as possible. If X is difficult, you try to optimize Y, Z, etc. so that at least you're not coping with multiple adverse environmental factors at the same time.

For me personally, the best-case scenario seems to be intentionally scheduled, one-on-one interactions in "clean" environments (i.e., quiet, unscented, no smoke/incense, dressed casually for maximum comfort, etc.). The next best would be some sort of group setting with structured, intentional sharing (i.e., not just doing something together but explicitly organized for the purpose of sharing). It can be a bit hit or miss to find these, so it can take some iteration to figure out what actually works.

Otherwise, "escalating" (i.e., inviting someone into a deeper/more meaningful interaction) is a skill you can practice, but if you're dealing with the rest of it at the same time, you're basically playing with a handicap. So incrementalize your goals as much as possible, practice in small, regular intervals with sufficient breaks for recovery, and don't compare yourself to anyone else, no matter how tempting that might be.

Hope that helps, and feel free to contact me on Keybase (in profile) or email (run the Perl script on my website) if you want help brainstorming.

Disclaimer: not a therapist.

Recently I was introduced to the distinction between anxiety and dread. Anxiety is, essentially, a form of fear. You fear a worst-case consequence that isn't actually that likely. If you put up with your anxiety and just go and do the thing (on average) you'll do just fine, or at least ok-ish. Over time your body learns that the anxious activity is ok and the anxiety is reduced.

Dread is different. Dread is the expectation of a bad situation. It's not a worst-case scenario, it's a typical scenario. If what you are experiencing is dread, then pushing yourself into that situation will confirm to your body that, yup, it really is as bad as you thought, and will amplify the dread rather than diminish it.

A classic example is that certain forms of neurodivergence create sensory overload in typical "social" environments. This is likely to result in dread rather than anxiety. Your body is literally telling you that this situation is problematic, and repeat exposure isn't going to improve anything.

In our modern culture the language of anxiety is widespread but the language of dread much less so, and I think that's unfortunate because a lot of advice centers around "just get over it", which works only if what you're experiencing is anxiety. Personally, learning about this gave me permission to do "social" activities on my own terms and stop worrying about what other people think "social" means; turns out the social anxiety I had was relatively minimal and what I was experiencing was mostly the dread from environments where social activities often occur.