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.