Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI handles incidents, engineers lose touch with their systems

sylvainkalache.com

Post reply on HN
Print view View original

351–360 of 378 posts

Re: AI handles incidents, engineers lose touch with their systems

#351

Post by oblio »

Terr_ wrote: post #345
bigstrat2003 wrote: post #252

Earlier quoted context omitted.

That's certainly what I expect to happen. LLMs will ruin your software if you don't hand-hold them, but it'll take time for that to happen. And until that does happen, businesses hell bent on using them won't have anything to push them into realizing what a mistake it was to use them.

Two imagined executive responses: 1. "Nonsense, if it was a code-quality issue from the AI stuff, we'd have seen problems sooner, like in the first few months or a year. Oh, sure, some engineers complained, but that was just an adjustment period because they stopped once we told them we didn't care and mandated that they up-skill into the new AI-centric workflow future." 2. "The bold new AI initiative I put into plac…

This, plus anyone responsible dodging that as soon as possible via job hopping. Harder to do in the current job market but internal transfers are still available, most of the time.

Re: AI handles incidents, engineers lose touch with their systems

#352

Post by vanattab »

glouwbug wrote: post #305
danbolt wrote: post #285

Earlier quoted context omitted.

I sometimes wonder if the verbosity gives the LLM more “margin for error” when generating text that passes requirements.

10 lines of checks per line of actual execution. Anxiety for their stable pay

Of course. Those 10 lines of extra code is that much more tokens every time your agents read and use that section of code. The more blot in the project to more tokens your agents will burn.

Re: AI handles incidents, engineers lose touch with their systems

#354

Post by glouwbug »

vanattab wrote: post #352
glouwbug wrote: post #305

Earlier quoted context omitted.

10 lines of checks per line of actual execution. Anxiety for their stable pay

Of course. Those 10 lines of extra code is that much more tokens every time your agents read and use that section of code. The more blot in the project to more tokens your agents will burn.

Reminds me of a subcontracting agency

Re: AI handles incidents, engineers lose touch with their systems

#355

Post by tptacek »

ghjkghjkghj wrote: post #350
tptacek wrote: post #343

Earlier quoted context omitted.

What a weirdly hostile and offensive response. I'm always struck by people who think they can namedrop my employers to shut down an argument, like we're just going to believe and profess whatever keeps people on message boards from being mean about the company. But, no, I feel like throughout this thread I've been pretty consistently putting a question to you (what exactly do you mean by "pain" or mistreatment, given…

reading through this it is obvious what the "pain" is and it does come across as you just avoiding the question. Just sayin

Maybe you can answer the question then. Is it "having performance judged by output rather than by process or satisfaction"?

Re: AI handles incidents, engineers lose touch with their systems

#356

Post by thunky »

glouwbug wrote: post #348
thunky wrote: post #316

Earlier quoted context omitted.

> Guess we’ll need even more human software engineers to fix it. This is what we've been doing for years before LLMs. Hiring a ton of devs to spit out code, which became another's burden. It just took longer and cost more.

Major critical software has always needed thousands of engineers to maintain million line codebases. LLMs can't reason across edge case failure modes, and better yet, LLMs generate compartmentalized modules which exponentially explodes the number of failure modes as LLM based codebases grow. Read how everyone here laments about Sol or Opus or GPT6 generates 10x the required number of lines

> LLMs generate compartmentalized modules which exponentially explodes the number of failure modes

It sounds like you're arguing against modularizing which is an unusual stance. Especially for a million line codebase.

Re: AI handles incidents, engineers lose touch with their systems

#357

Post by iamleppert »

I don’t find this to be the case. I use AI to help investigate and gather evidence much more efficiently than I could ever do manually. Then, I work through the evidence and possible failure modes given the observations with AI. It’s the exact same process I’d follow with a talented co-worker. Does it matter they are driving?

My intuition and instincts have been honed from years of troubleshooting complex systems so I find it refreshing not having to write probe scripts, queries or code under pressure. I can have a theory and test it very quickly and if it’s not the problem, I can quickly try something else. This greatly improves the time it takes to find the real root cause. Once found, I can do more elaborate testing that I might have skipped before due to complexity or time constraints to really have higher certainty.

If there is ever a time where the model does something I don’t understand, I ask it to explain it to me and I increase my knowledge of the system accordingly. It’s always patient and explains things in such depth without any sighs, patronizing, sarcasm, juxtaposition, etc. So refreshing!

I much prefer working with AI than any co-worker and I find I’m far more productive and efficient, especially with bugs and dealing with incidents. There’s no one to convince or argue with, no ego’s to trip over. It’s lovely.

Re: AI handles incidents, engineers lose touch with their systems

#358

Post by bitwize »

itsalwaysgood wrote: post #190
sillyfluke wrote: post #182

Earlier quoted context omitted.

This seems to misunderstand the parent comment. The sibling comment plays along with the analogy and mentions having to fix the mistakes of an automatic chisel, but the original comment is alluding to the fact that it is definitely not an automatic chisel. There is no uncanny valley in an automatic chisel. Programming up until this point was done by using deterministic tools to build products. LLMs appear to be nonde…

I had a huge post written up to address your points, but I have to get moving, my ass is literally falling asleep. It's easier just to say: It's all about time, my man. Nobody wants to waste it.

This. Time is money, and if you're not using an LLM you're wasting your employer's.

Re: AI handles incidents, engineers lose touch with their systems

#359

Post by oenton »

wccrawford wrote: post #53
mawadev wrote: post #25

Earlier quoted context omitted.

I can share a weird story: Usually, I take my time to understand each keyword of the code I'm looking at, especially if it is new to me, like terraform. I work in a team/with one architect, who only did the DevOps/Infra stuff for the past years and I had the expectation he knows what he is doing and talking about. At around 2 weeks, I noticed how his knowledge has severe gaps and how he takes things at face value or…

I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compelling, and we probably see more of them because of it, but it's the same general thing. The kind of person who insists on understanding things and working through the problem has always been rarer. It's not "humble", it's "inquisitive" and "persistent".

> The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. The kind of person who insists on understanding things and working through the problem has always been rarer.

Well, this is where I disagree. I have coworkers who used to insist on understanding and now are doing exactly as OP wrote - copy/pasting from the LLM to brute force error messages. I don't know if it's generalizable but this is what I see in working on a frontend team with mid to senior level engineers who I respect.

One example a few weeks ago, I was helping a coworker root cause a bug in a React codebase. Pair programming isn't necessarily common but sometimes you see someone banging their head at a problem and you get curious. It turned out there was an effect (a callback that's invoked whenever some state changes) that invokes an API and this effect caused an infinite render loop because the error handling wasn't written correctly. It was something silly like - Call this API if we have no data -> get error -> update state -> call API again because we have no data...

That was almost immediately what I suspected but my colleague was pulling out all the stops usually reserved for when you're desperate or need a sanity check, like logging to stdout after each line. Both my colleague and the LLM were convinced the problem lied in the pagination logic of the helper that invokes the API. He ended up rewriting that helper imperatively and functionally. To his credit, he rewrote it by hand and implemented the recursion correctly but he was baffled when the problem remained. Completely surprised Pikachu face.

I don't think my coworker changed or suddenly stopped caring. It seems much more likely this is a predictable outcome when you lean heavily into AI authoring code for a sustained period of time. I'd also say that in itself is a consequence of the extreme pressure being exerted across the entire company to ship more code and review more code, faster.

Re: AI handles incidents, engineers lose touch with their systems

#360

Post by Emjayen »

ffsm8 wrote: post #70
bob1029 wrote: post #6

A natural evolution of engineers losing touch with the customers and users. I'm noticing some of the concern play out regarding AI weakening the capabilities of software people. I gave the team an exact solution on a silver platter and they still failed to identify how to go about it after 3 days slamming it into Claude. The resolution is literally 1 line of code that could be arrived at in about 30 minutes of patien…

Sincerely , I think you're blaming the AI incorrectly there. You just got incompetents on your payroll.

Incompetence is implied by slop usage.
Post reply on HN