Ask HN: Why is the HN crowd so anti-AI?

I was asked to audit a few proposals during that era and in every case I had to go back to the person asking me to say that it was a technical architecture L. Ron Hubbard would have admired. Just straight up making up words in most cases.

Far beyond "wait, is this actually a parody? how is this not a parody?" territory. 80% of them were effectively "tamagotchis + pyramid scheme".

This is why I say that you don't have to love LLMs, but you also can't compare them in terms of also bad. Jay-walking is bad and Jeffrey Dahmer was bad; they are not "both bad".

There were solutions before blockchain, especially in the field of Byzantine fault tolerance. The original Byzantine Generals paper was from 1982, and practical algorithms existed before Bitcoin. For example: PBFT - Practical Byzantine Fault Tolerance - published in 1999.

https://css.csail.mit.edu/6.824/2014/papers/castro-practical...

Blockchain solved a different version of the problem: how can a large, open, permissionless network reach agreement when anyone can join and nobody has a fixed identity?

Classic BFT is like a committee of known people voting, where the system survives some liars.

Blockchain is like letting strangers on the internet vote, but making votes costly enough that cheating becomes economically difficult.

> The lack of CS knowledge on this board is pretty staggering sometimes.

Right!?

1. Engineers should care about code quality so they can maintain it if their preferred AI providers are down or unavailable.

2. Code that's written well is easier for AI to navigate and modify.

3. Cognitive debt is real. I've been writing software for 20 years and without a doubt, I feel like my knowledge and edge are atrophying. This has been cited and confirmed by more than enough engineers who feel frustrated by this phenomenon.

4. Generating massive amounts of code significantly reduces accountability, making it impossible to review that code line-by-line unless you deliver your generated output in extremely small chunks (200-300 LOC per PR).

5. Since #4 is an objective reality, shipping code that hasn't been reviewed by a human is patently unethical, since the humans merging and deploying that code can't possibly know if there are lingering security holes or mishandling of sensitive information by their generated code.

6. One could say "well this is possible with hand-written code too", and they're right -- but the difference is, there was a human element in reviewing the code in good faith, rather than tossing thousands of LOC over a fence and telling their PAYING customers "good luck, hope it works!"

7. The other rebuttal is that tests and "guardrails" solve these problems. We all know that even the best test suite isn't foolproof. 100% coverage doesn't mean the tests are good, or will catch when something critical breaks.

8. AI guardrails are flaky at best: they're intended to be brief in order to save on context usage, but the more brief and numerous they are, the less accurate they'll be across a growing codebase. IME, many of the rules I've setup are obeyed by LLMs less than 100% of the time, which isn't enough to give me full confidence in them, because things will inevitably drift and fall through the cracks. Scale this to a team, and now you've got endless drift and disorder.

The arguments against AI have nothing to do with elegance, pretty code, formatting, or anything petty of the sort. It has everything to do with code quality and maintainability over time across teams of engineers who are accountable for their code, for products and services that people quite literally pay you for, trusting that what you're delivering them is stable, reliable, secure, and trustworthy.

If shipping speed is a higher priority than any of those, you have no business writing software to sell.

Did I miss anything?