zlacker

>>simonw+(OP)
I wonder if the era of dynamic programming languages is over. Python/JS/Ruby/etc. were good tradeoffs when developer time mattered. But now that most code is written by LLMs, it's as "hard" for the LLM to write Python as it is to write Rust/Go (assuming enough training data on the language ofc; LLMs still can't write Gleam/Janet/CommonLisp/etc.).

Esp. with Go's quick compile time, I can see myself using it more and more even in my one-off scripts that would have used Python/Bash otherwise. Plus, I get a binary that I can port to other systems w/o problem.

Compiled is back?

>>behnam+sj
> But now that most code is written by LLMs

Am I in the Truman show? I don’t think AI has generated even 1% of the code that I run in prod, nor does anyone I respect. Heavily inspired by AI examples, heavily assisted by AI during research sure. Who are these devs that are seeing such great success vibecoding? Vibecoding in prod seems irresponsible at best

>>koe123+i11
FAANG here (service oriented arch, distributed systems) and id say probably 20+ percent of code written on my team is by an LLM. it's great for frontends, works well with test generation, or following an existing paradigm.

I think a lot of people wrote it off initially as it was low quality. But gemini 3 pro or sonnet 4.5 saves me a ton of time at work these days.

Perfect? Absolutely not. Good enough for tons of run of the mill boilerplate tasks? Without question.

>>cheeze+J11
> probably 20+ percent of code written on my team is by an LLM. it's great for frontends

Frontend has always been shitshow since JS dynamic web UIs invented. With it and CSS no one cares what runs page and how many Mb it takes to show one button.

But regarding the backend, the vibecoding still rare, and we are still lucky it is like that, and there was no train crush because of it. Yet.

>>zx8080+l51
I think you’re onto something. Frontend tends to not actually solve problems, rather it’s mostly hiding and showing parts of a page. Sometimes frontend makes something possible that wasn’t possible before, and sometimes the frontend is the product, but usually the frontend is an optimization that makes something more efficient, and the problem is being solved on the backend.

It’s been interesting to observe when people rave about AI or want to show you the thing they built, to stop and notice what’s at stake. I’m finding more and more, the more manic someone comes across about AI, the lower the stakes of whatever they made.

>>halfca+0a1
Spoken like someone deeply unfamiliar with the problem domain since like 2005, sorry. It's an entirely different class of problems on the front end, most of them dealing with making users happy and comfortable, which is much more challenging than any of the rote byte pushing happening on the backend nowadays.

>>llbbdd+Hj1
Is it, though? That sounds very subjective, and from what I can tell 'enshittification' is a popular user term for the result, so I'm not sure it's going that great.

>>Applej+Zs2
If you search Google Trends for enshittification, half the results contain Doctorow as well [0]. Normal people have no idea who that is. And that's just Google, which everyone on HN hates to the point of vibrating angrily because there isn't an obvious part of the name to replace derogatorily with a dollar sign. Nobody uses this term outside of Hacker News, and even on HN it's code for "this site doesn't work when I disable Javascript", which is not a real requirement real customers have.

User experience does involve a lot of subjectivity [1] and that's part of what makes it hard. You have to satisfy the computer and the person in front of it, and their wants are often at odds with each other. You have to make them both happy at 60 FPS minimum.

[0] https://trends.google.com/explore?q=enshittification&date=al...

[1] https://emsh.cat/good-taste/