You joke but it's really easy to develop viruses at home. You can order everything you need online, and it's not expensive nor does it require a particular skill set.
God I wish people on HN would just shut up with snarky takes about things they don't understand. This place used to be better.
You will NEVER be a good to great writer if you use AI to seed your writing and then edit it.
_Everything_ AI generates, is generalized slop. All of your ideas will be boring and derivative. Mediocre writers will be improved, but the best would only have their ability to think dulled.
Just think through it from the perspective that AI is generating art for you instead of writing. What would all art look like if good artists used it for ideas and "edited" it? It would look like generic, derivative shit. A perpetual crutch that the person can never abandon.
Genuine experiment: Do characters "have a color" for you, maybe? [1][2]
1) "The quick brown fox jumps over the lazy dog." <- Typed by hand.
2) "The quick brown fox jumps over the lazy dog." <- Generated by ai, cut-and-pasted in. [3]
For you, would you classify the former as genuine and the latter as slop?
You'd think I'm being silly, but both yes and no are not unthinkable, and honestly I've actually seen odder arguments in court filings and language standards.
hard to believe anyone who writes something this overwhelmingly positive.
I use a ton of AI, it writes a shit load of code for me, and I eventually get good results.
Its also goes off on ridiculous tangents, implements things i dont want, over engineers almost everything. Makes large code bases convoluted and unreadable. Yes humans also do that, LLMs do it a lot faster.
> Now, with AI coding, I can implement any decent sized feature, exactly how I want, in a few hours and it's all polished and ready, all edge cases handled.
No way a human wrote that, sounds like a late night TV advertisement.
You obviously haven't worked on a good codebase. I've worked on both so I know the difference.
Same feature on a good codebase vs bad codebase is like 1k lines of code vs 20k lines of code and is worse in the latter case. Not an exaggeration.
Clean code is real, it's just not what's been peddled to us.
If your code is full of bugs and you ask Claude or Codex to build more features, it will take 10x to 20x the effort because of workarounds and hacks which keep compounding.
If your code has very few to no bugs and no hacks/workarounds, it will also implement hacks/workarounds and no bugs. The difference is pretty insane actually.
You can try it yourself; create a really low quality codebase, full of hacks and try to build features with AI based on its recommedations.
> Clean code is real, it's just not what's been peddled to us.
My read is: the people who "peddled" it had mostly the right ideas, they were just bad at implementing them, and bad at writing code in general, and also the contemporaneous popularity of Java caused some serious issues.
You're not an outlier. The anti-AI stance is likely to be vocal online. They're quite incentivised to talk about it. Most programmers have adopted AI assisted programming (my own assertion) and most will feel like you and I, that it is useful. I know of a few programmers personally who hate it, but even they use it. There is no going back.
It is pretty obvious that when you come into a large incomprehensible codebase (which most are), AI will be able to reason about it more quickly and guide you through it.
I switched away from my work for a few minutes, but at the very moment I'm using AI to summarise some spaghetti code in a particular area in our codebase, so I can refactor it.
And that is my style of working at the moment. AI coding is useful, sometimes amazing, but sometimes irritating, and from experience I think just telling it to refactor this area would result in something I'm not happy with. So instead I'm getting a handle on it, I'll form the design I want, then tell it to do it. I have a feeling a lot of complaints are from people who won't bother to do that.
You are not an outlier. 40+ years of hobby and pro coding experience here and I absolutely love Claude Code. It enables me to dramatically increase code quality, performance, and features while still doing the fun parts and letting the LLM do the boring parts.
If you really loved horseback riding, or you really loved breeding and training horses, or you were really good at it, I'm sure that cars fucked up your day, and that it sucked to see cars replace horses.
I'm sure there were plenty of people who said that cars were horrible and that we should stick with horses. I'm equally sure there have been C programmers looking derisively at Python programmers, Python programmers looking derisively at Node programmers, etc etc.
But there's a pretty big gap between the feeling of unhappiness that something you liked is no longer as in-demand / profitable / common / whatever, and saying that cars aren't useful and we're all worse off for letting our horse-riding skills degrade.
Normal people didn't ride horses everywhere. They weren't used like cars. I'm so sick of this analogy. People walked places. If it was too far to walk you used a horse drawn bus/tram. If you had to much to carry you used a horse drawn truck. Every single person wasn't riding an individual horse ten minutes each way to buy groceries every day like that do now with cars. Cars unquestionably kill drastically more people than horses ever did or even could. Tens of thousands a year in this country alone! The leading cause of death for children and young adults!
We're pretty off track given that ya'll are nitpicking the metaphor rather than the actual topic, but claiming that horses were never common doesn't really have any connection to the claim that per-mile-moved / per-human-carried, horses are also dangerous.
Never use analogies when arguing online. It only ever results in exactly this, people nitpicking the metaphor. You've essentially given them a way to "be correct", about something irrelevant.
This does not get to the core of it, LLMs are not equivalent to cars.
All of your analogies (in other posts) discount that:
- LLMs are not deterministic
- they do not produce high quality/expert level output.
- They are not easy to control consistently.
Once again, and i mean this in the nicest way possible. You do not sound like you understand how things operate at an expert level of engineering. I do not know of any senior engineer who thinks LLMs can consistently produce quality output.
You are way too invested in your argument and refusing to see other perspectives
Emacs, meanwhile, has a 50,000 line file that contains its display and redisplay logic: https://github.com/emacs-mirror/emacs/blob/master/src/xdisp..... (It's actually a pretty readable well-commented file all things considered, but famously difficult to hack on.)
That's descended from its terminal escape-sequence optimizer, the bit of code that transforms one screen state into another screen state in the least number of terminal commands possible. (That display code was later updated to support graphical output like X11 by treating it as sort of a special case of a terminal.)
I think I'd rather have that than the state of the art in "modern" TUIs, which is to do the opposite and treat the terminal as a special case of React canvas, redrawing the whole damn thing every time there is a keystroke or other action by you or the program. You can see Claude Code redraw itself all the time; it's maddening. And the program would absolutely be unusable on, say, a 9600bps connection, whereas Emacs could still get by on that. This is from the company that retains the best and brightest programmers, and will have self-improving runaway genius AI by Christmas, for realsies this time.
Take those out of what US "builds" and Us doesnt look very exceptional
reply