I've made an account as a long-time lurker because I am hoping y'all could help reconcile my experience in my company/team with what seems to be the wise HN consensus around LLMs.

My Background (Software Engineer II):

I've been writing software professionally for >10 years and grew up coding games/websites for fun; did my undergraduate in C.S./C.E., and did some time in ML research and such. Right now I'm on the back-end/DevOps team - my teammates are all Senior Staff/Principal Engineer (one is almost double my age lol!) and we have a pretty standard tech stack (NodeJS, AWS, C++, etc) with 95% brownfield development at a large but not FAANG-like company. I've had my current job for >6 years and out of ~20 in our department I'm the third newest!

I'd say I'm a pretty stereotypical engineer AKA "a total nerd" with private side projects mostly around implementing computational geometry or procedural simulation papers in Rust, sometimes working on a lil website tool we use daily. But I mostly spend my free time with my people or on other life/hobby things like learning math/physics. So I have an average and home-y life, albeit a lucky one.

Current LLM Vibe:

Our company mandated LLM usage awhile ago and provided us Cursor/Claude (Opus 4.6 these days). We have all learned to use it for normal daily dev tasks. Our front-end team has gone LLM-maximalist and seem to be enjoying it. I think they've sped up alot, up to 20-50%. One other back-end/integration team tried that (they have quite good test coverage), but it broke too much and used too many tokens and they had to walk a lot of that back from what I can tell.

Our team is a bit more conservative and our processes are mostly the same as before but with a bit more emphasis on clean code than before because slop can be a PITA to clean up later. All the senior engineer folk I work with (including maybe the best engineer, that has used LLMs for years) are pretty confident saying that you have to micro-manage Cursor/Claude to get good results. My experience is the same, and I've actually been frustrated enough recently that I trust it even less. Maybe part of it is that I don't produce too much code in a week (few hundred lines? not including tests?) and we've found that manual code review is still much required.

My Problem:

I'm concerned about how far off the perspective is toward LLM usage is in my job vs here on HN.

On HN, the smart opinion is that it definitely has already made most of us developers obsolete. Reading the comments of any LLM-related posts, it's all talking about how LLMs have already replaced all but the most complex of technical work and "but muh taste & system design" is just sad copium until the next model in a few months is released. I don't even disagree with this conclusion. It makes sense - if billions of capital had been thrown at any problem, we'd probably see a good dent in it. But my day-to-day experience is far enough away from this opinion that I'm afraid that I'm out of touch or in denial or we're all such mediocre engineers compared to the HN crowd that we can't even learn how to use this stuff properly.

I feel like pedestrian me and the elite engineers of this forum are experiencing two different things, and I want to understand why. The difference is honestly like whiplash.

Could you all help point out what's going on? Thank you :)

Stunning initial speed makes for a dopamine rush and desire to tell the world (been there myself).

Finding out you can’t debug it anymore because you don’t have the mental model of what’s going on is less likely to be shared with the world.

Some people are super comfortable with the prompt-wait-test-reprompt loop - I personally am not. I want to understand every line of code and find it more fatiguing and less rewarding to review pages of LLM code.

The sweet spot for me is using an LLM to write a single function at a time. That’s the unit of work. Constrained, easier to understand and critically, no unexpected changes to other areas of my code.

I think a lot of people are excited at what feels like insane new velocity and tempted to ignore the hard learned lessons of good code vs bad code.

Here is a real conversation. “I built this app so fast it feels amazing, but then I looked at the code and it had a 6000 line class with one function that was 3000 lines of if statements”

“Oh ya that’s bad. You definitely need to refactor that”

“I thought that, but I wonder if it’s actually better to have a big class in a single file because that’s easier for the AI to understand than if it was in multiple files”

“Umm ok but do you even understand the 3000 line function? Couldn’t that be broken into better code that if/else soup?”

That conversation went on like that for a while.

Meanwhile, I have settled on a process where I built a framework that has good architecture built in and my version of using AI is essentially enforcing compliance with my architecture and coding patterns.

When cursor moved to an Agent view to remove human review I built my own IDE to ensure I never have to adopt stupid coding practices. I used AI to build it and had to constantly stop the AI from doing stupid stuff.

I am happy to share patterns and tools with you because AI can be a massive accelerator and produce good code when managed effectively but it requires a commitment to good code and willingness to ignore where the industry hype is right now.

> On HN, the smart opinion is that it definitely has already made most of us developers obsolete.

Sounds like you’ve already made up your mind, though I’ve seen plenty of smart people completely contradict this.

some models and harnesses are good at some things and bad at others. some HN users are good at using some models and harnesses and bad at using others. some engineers at your company understand what tools to use for their work and others don't. some programming languages are better resourced to support agents than others.

most generative tools are good at tasks and bad at architecture. effective QA of generated code is still at an infant stage no matter what anyone claims, much less automated effective QA; teams that care deeply about getting things right the first time will have a worse time with it on the median than teams that don't.

don't trust the code it generates, but "don't trust" doesn't mean discard it. don't trust the architecture it invents for a problem, it can't reason at that level, it's literally aping the background noise of the entire internet and building things that are dead-center mediocre.

there's not enough specifics in your wall of text to help me point out what's going on in any useful detail, though.

i will say that HN users are more likely to be ecstatic at building an MVP that they never have to support; the scale of a company where you have 6 years experience but are still new on your team is bigger than where most of HN lives and works. the dissonance would be the same if it was 10 years ago, LLMs didn't meaningfully exist, and you'd be on here asking HN why some of these so-called lean teams everyone's posting about all of a sudden seem to be so much more productive than when your boss at BiggerCorp tried to streamline processes and then got yelled at by CS, sales enablement, and marketing.