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

201–210 of 378 posts

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

#201

Post by JauntyHatAngle »

piker wrote: post #164
nekoashide wrote: post #157

Earlier quoted context omitted.

In my experience at a large bank with unlimited AI, my spend is in the top 5% and I'm leveraging AI just like you. I was in a meeting with someone who had a bug in an application that I don't own myself on Friday so I told claude, "I need you to find this bug the user is experiencing, find out if it's user error or a bug, let the user know and tell the developer what needs to be fixed if needed" 15 minutes later the…

Often though working through a bug teaches the developer something about the relevant abstraction. That knowledge can get lost in this new process.

While you're right, and I'm constantly thinking/worrying about my own processes giving me AI apathy, you can use AI in a way that develops your understanding of a bug. It really depends on your workflow.

When I use AI to debug a problem, I'm constantly questioning the specifics because I want to learn it, and often I'm better than the AI at quickly recognising patterns that point to a specific issue, where the AI will spin for some time trying to work out where to start - even if it has full context.

So I guess I'm half with you, but an LLM used right can still teach you effectively.

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

#202

Post by piker »

JauntyHatAngle wrote: post #201
piker wrote: post #164

Earlier quoted context omitted.

Often though working through a bug teaches the developer something about the relevant abstraction. That knowledge can get lost in this new process.

While you're right, and I'm constantly thinking/worrying about my own processes giving me AI apathy, you can use AI in a way that develops your understanding of a bug. It really depends on your workflow. When I use AI to debug a problem, I'm constantly questioning the specifics because I want to learn it, and often I'm better than the AI at quickly recognising patterns that point to a specific issue, where the AI wil…

Yes. I agree with that as well. If you can intuit that it's (for example) an off-by-one error somewhere in your logic, asking an LLM to pinpoint that issue can save you tons of time that is better spent thinking about your abstractions. Also, I tend to ask high-level questions to the frontier models about best practices with common abstractions. But "the screen flickers here, please fix" is a bad pattern, IMO. Understanding why the screen is flickering is likely to educate you about where your abstractions are leaking.

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

#203

Post by foobarbecue »

konschubert wrote: post #61
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…

It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself. EDIT: don’t get me wrong. I still think AI is incredibly useful for a lot of tasks! But when implementing an architecturally hairy thing, I find it less stressful and equally quick to jump down…

I agree, except for the use of the word "yet" .

I think what's missing is fundamental. I think the reason it sucks so much to work with LLM-generated code is that LLMs will never "know" what it's like to be human. They don't "understand" our frustrations and motivations, and they're missing the vast array of useful mental tactics we've evolved to cope with corporal existence.

At this point I think progress towards a good colleague bot would require a new architecture which allows continuous leaning, and for the LLM to be raised as a human child (maybe in a simulation at 1000x speed or something).

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

#204

Post by LeafItAlone »

Richbeach wrote: post #150
willtemperley wrote: post #129

Earlier quoted context omitted.

> 30 minutes of patient, old school troubleshooting This is also the best way to understand a codebase, and it's quite enjoyable. I think the models are getting too egotistical. They're so confident of their fixes they won't bother suggesting basic techniques like isolation of the problem by disabling code paths, for example. They'll keep shotgunning less-and-less likely fixes with undiminishing confidence until the…

> and it's quite enjoyable Used to be somewhat enjoyable. Nothing pleasant about digging around codebase that was heavily affected by the last 12-18 months of AI-ing.

Depends on the prior state.

For one codebase I work in, LLM written code is noticeably and measurably (we have literally measured it for bugs, performance, etc.) better than what existed before. So the LLM code is a welcome change.

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

#205

Post by sigseg1v »

noir_lord wrote: post #127
adjejmxbdjdn wrote: post #35

Earlier quoted context omitted.

The funny thing is that if you never understand the codebase then you will keep thinking Claude is doing a great work delivering all this incredible software, when all it has done is created unnecessary tech debt.

Which at some point the developers who actually still do know how to program are either going to have to clean up or in terminal cases rewrite. In a way all we've done (currently) is drastically expand the amount of technical debt across the whole industry. Should be profitable for the ones who can still actually program though and haven't let their skills atrophy by letting Claude do everything . I don't deny there…

But this is leaving out the part where the developers that clean up or rewrite... will do it using LLMs.

Have you tried refactoring or porting codebases larger than a million lines of code pre-gen-AI and again post-gen-AI? It's night and day difference. One would be insane to schedule a team on 8 months worth of grunt work porting from one language or framework to another which can now be done by 1 person in 4 weeks.

Of course the person driving it has to tell it exactly what to do and has to have the requisite knowledge to understand how to effectively structure or fix the software. Maybe new developers don't build this skill so easily anymore. But I don't see why a strong developers skills would atrophy in this case though unless they just never use their knowledge and never give instructions to the AI.

To developers speaking of skill atrophy: are you still making sure that when using LLMs you are actively exercising skills like system design, debugging, reviewing for clean code and just in general doing effective code review? If you are doing that, why do you feel skill atrophy? And if you aren't doing it, why not? What about LLMs prevents us from exercising these skills?

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

#206

Post by tripledry »

Richbeach wrote: post #150
willtemperley wrote: post #129

Earlier quoted context omitted.

> 30 minutes of patient, old school troubleshooting This is also the best way to understand a codebase, and it's quite enjoyable. I think the models are getting too egotistical. They're so confident of their fixes they won't bother suggesting basic techniques like isolation of the problem by disabling code paths, for example. They'll keep shotgunning less-and-less likely fixes with undiminishing confidence until the…

> and it's quite enjoyable Used to be somewhat enjoyable. Nothing pleasant about digging around codebase that was heavily affected by the last 12-18 months of AI-ing.

Also if your entire stack is on the cloud, mess of lambdas and other proprietary services, difficult as hell to follow logs, can't really run locally.

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

#207

Post by VCFundedGenYer »

konschubert wrote: post #61
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…

It's the uncanny valley of AI. It's still not quite good enough yet that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself. EDIT: don’t get me wrong. I still think AI is incredibly useful for a lot of tasks! But when implementing an architecturally hairy thing, I find it less stressful and equally quick to jump down…

Nah, It's not even good for small code changes.

Try using it with Ansible. It spits back complete buffoonery.

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

#208

Post by ascendantlogic »

I agree with the sentiment but unless it leads to better financial outcomes for them to A) have engineers on staff and B) have them know their systems then enterprise will continue looking for reasons to shed all the engineers and just leave everything to AI. Anecdotally I think most companies are still looking for ways for AI to help them shed headcount so raising this alarm doesn't mean anything to the decision makers at the top.

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

#209

Post by podocarp »

willtemperley wrote: post #129
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…

> 30 minutes of patient, old school troubleshooting This is also the best way to understand a codebase, and it's quite enjoyable. I think the models are getting too egotistical. They're so confident of their fixes they won't bother suggesting basic techniques like isolation of the problem by disabling code paths, for example. They'll keep shotgunning less-and-less likely fixes with undiminishing confidence until the…

I have no evidence at all, but could it be that repeating the same thing over and over again in the context makes models latch on to it wrongly and gives them more confidence despite it being wrong? Kind of like a sunk cost fallacy…

Although I do acknowledge sometimes they too point out something I thought was quite right but turns out of be wrong…

Post reply on HN