zlacker

[parent] [thread] 15 comments
1. cheeze+(OP)[view] [source] 2026-01-27 01:12:13
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.

replies(3): >>8organ+o2 >>zx8080+C3 >>asadot+1I2
2. 8organ+o2[view] [source] 2026-01-27 01:30:09
>>cheeze+(OP)
As someone currently outside FAANG, can you point to where that added productivity is going? Is any of it customer visible?

Looking at the quality crisis at Microsoft, between GitHub reliability and broken Windows updates, I fear LLMs are hurting them.

I totally see how LLMs make you feel more productive, but I don't think I'm seeing end customer visible benefits.

replies(1): >>mediam+q3
◧◩
3. mediam+q3[view] [source] [discussion] 2026-01-27 01:36:25
>>8organ+o2
I think much of the rot in FAANG is more organizational than about LLMs. They got a lot bigger, headcount-wise, in 2020-2023.

Ultimately I doubt LLMs have much of an impact on code quality either way compared to the increased coordination costs, increased politics, and the increase of new commercial objectives (generating ads and services revenue in new places). None of those things are good for product quality.

That also probably means that LLMs aren't going to make this better, if the problem is organizational and commercial in the first place.

4. zx8080+C3[view] [source] 2026-01-27 01:37:51
>>cheeze+(OP)
> 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.

replies(2): >>halfca+h8 >>llbbdd+ai
◧◩
5. halfca+h8[view] [source] [discussion] 2026-01-27 02:19:44
>>zx8080+C3
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.

replies(1): >>llbbdd+Yh
◧◩◪
6. llbbdd+Yh[view] [source] [discussion] 2026-01-27 03:47:51
>>halfca+h8
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.
replies(1): >>Applej+gr1
◧◩
7. llbbdd+ai[view] [source] [discussion] 2026-01-27 03:49:36
>>zx8080+C3
Backend has always been easier than frontend. AI has made backend absolutely trivial, the code only has to work on one type of machine in one environment. If you think it's rare or will remain rare you're just not being exposed to it, because it's on the backend.
replies(1): >>bopbop+bj
◧◩◪
8. bopbop+bj[view] [source] [discussion] 2026-01-27 03:58:39
>>llbbdd+ai
Might be a surprise to you, but some backends are more than just a Nextjs endpoint that calls a database.
replies(2): >>ivanto+vr >>llbbdd+qK
◧◩◪◨
9. ivanto+vr[view] [source] [discussion] 2026-01-27 05:28:35
>>bopbop+bj
Honestly, I am also at a faang working on a tier 0 distributed system in infra and the amount of AI generated code that is shipped on this service is probably like 40%+ at this point.
replies(1): >>llbbdd+CK
◧◩◪◨
10. llbbdd+qK[view] [source] [discussion] 2026-01-27 08:24:58
>>bopbop+bj
No surprise at all and I'd challenge you to find any backend task that LLMs don't improve working on as much they do frontend. And ignoring that the parent comment here is just ignorant since they're talking about the web like it's still 2002. I've worked professionally at every possible layer here and unless you are literally at the leading edge, SOTA, laying track as you go, backend is dramatically easier than anything that has to run in front of users. You can tolerate latency, delays and failures on the backend that real users will riot about if it happens in front of them. The frontend performance envelope starts where the backend leaves off. It does not matter in the slightest how fast your cluster of beefy identical colocated machines does anything at all if it takes more than 100ms to do anything that the user directly cares about, on their shitty browser on a shitty machine on tethered to their phone in the mountains, and the difference is trivially measurable by people who don't work in our field, so the bar is higher.
◧◩◪◨⬒
11. llbbdd+CK[view] [source] [discussion] 2026-01-27 08:26:13
>>ivanto+vr
I'm not surprised at all here, last time I worked in a FAANG there was an enormous amount of boilerplate (e.g. Spring), and it almost makes me weep for lost time to think how easy some of that would be now.
replies(1): >>ivanto+Opb
◧◩◪◨
12. Applej+gr1[view] [source] [discussion] 2026-01-27 13:33:06
>>llbbdd+Yh
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.
replies(1): >>llbbdd+7G3
13. asadot+1I2[view] [source] 2026-01-27 18:58:38
>>cheeze+(OP)
Does great for front ends mean considerate A11Y? In the projects I've looked over, that's almost never the case and the A11Y implementation is hardly worthy of being called prototype, much less production. Mock up seems to be the best label. I'll bet you think because the surface looks right that runs down to the roots so you call it good at front ends. This is the problem with LLMs, they do not do the hard work and they teach people that the hard work they cannot do is fine left undone or partially done and the more people "program" like this the worse the situation gets for real human beings trying to live in a world dominated by software.
replies(1): >>simonw+3Y2
◧◩
14. simonw+3Y2[view] [source] [discussion] 2026-01-27 19:58:22
>>asadot+1I2
It turns out if you tell a coding agent "make it accessible" you'll get better results than you would from most professional front-end developers.

I'm not satisfied yet: I want coding agents to be able to actively test on screen readers as part of their iteration loop.

I've not found a system that can do that well yet out of the box, but GuidePup is very promising: https://github.com/guidepup/guidepup

◧◩◪◨⬒
15. llbbdd+7G3[view] [source] [discussion] 2026-01-27 22:52:18
>>Applej+gr1
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/

◧◩◪◨⬒⬓
16. ivanto+Opb[view] [source] [discussion] 2026-01-29 22:57:59
>>llbbdd+CK
It’s not just boilerplate. This is a low level C++ service where latency and performance is critical (don’t want to get into too much detail since I’ll dox myself). I used to think the same thing as you: “Surely my job is safe because this system is very complex”. I used to think this would just replace front end engineers who write boilerplate react code. 95% of our codebase is not boilerplate. AI has found optimizations in how we store items, AI has alerted us to production issues (with some degree of accuracy, of course). I worry that traditional software engineering as we know it will disappear and these hybrid AI jobs will be what’s left.
[go to top]