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

311–320 of 378 posts

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

#311

Post by Sophira »

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 okay, they'll fix it by asking AI to design their training courses for them. That'll fix everything, right?

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

#312

Post by hintymad »

There's an interesting dynamic, too. Even if an engineer reads the output of the AI and understands the root cause of the problems and how to diagnose the incident, somehow it's hard for them to internalize the learning and apply it next time to a new incident. As a result, the engineer loses touch with the system anyway.

It looks like our brains somehow have to experience the failures during a diagnosis and in gemerak perform this kind of pathfinding by themselves to truly understand the system. I don't know if this has to do with how our brains actually learn.

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

#313

Post by nekoashide »

Rapzid wrote: post #278
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…

I find this story awkward. When Claude "..tell the developer what needs to be fixed" was it impersonating you? Regardless, why not help the developer use the tools effectively instead?

I explained in another thread, but yeah, it acts on my behalf using my access to take actions with my approval. It has knowledge of all my work and leverages various data sources, (Jira, Confluence various mcp's) to gather information and take actions. If I ever have to correct it, or if the actions it takes are going down the wrong path I make sure and understand why and correct that.

It just got really good over time, especially as new processes get brought it and things change. I can't keep up with that like that AI can, just have it review and go down the path of ensuring that it fit's in my workflow as efficiently as possible and move on.

As far as the developer? I gave him ideas but he's on another team and I got my own guys to feed.

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

#314

Post by mitxela »

podocarp wrote: post #209
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…

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…

A session is a screenplay between someone called User, and someone called Assistant who is a helpful and competent assistant to the user. Harnesses bring in tools to the screenplay.

A screenplay where a character has done a certain thing is one where they're more likely to do it again.

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

#315

Post by mitxela »

podocarp wrote: post #218
itsalwaysgood wrote: post #174

Earlier quoted context omitted.

They say writing engages more of the brain and helps us to remember what's written more than if we just read it, or copy and paste. When you say it's easier to go manual, it seems you're talking about learning retention. And you're right. But seniors have learned enough that they're able to iterate quickly with AI. They know how to organize their work, manage change, tasks. They know how to break a problem down into…

It's not just learning is it, why do people buy hand ground coffee when there quite literally isn't any difference? Or audiophile snake oil? As long as humans are still the consumers, some part of consumption will be emotional. Could be to support local artisans, could be gullibility, could be love, whatever. Maybe one day artisanal code will be a thing lol. Hand written like calligraphy. Those with refined tastes wi…

It's already a thing among nerds. It's why Zig and Codeberg have their no-AI policies.

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

#316

Post by thunky »

glouwbug wrote: post #304
Richbeach wrote: post #150

Earlier quoted context omitted.

> 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.

The field is already exploding in SLOC. If LLMs can generate 10x but only produce a 2x productivity boost in reasoning or understanding - each year -then neither humans or AI will be able to keep up with the mountains of slop that power everything from websites, telecom, banking, automotive, aerospace, industrial, medical, and renewables. Guess we’ll need even more human software engineers to fix it.

> 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.

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

#317

Post by weknowbetter »

cpeterso wrote: post #288
sevenseacat wrote: post #240

Earlier quoted context omitted.

I've seen people report cleaner code by forbidding agents from writing comments. Anecdotal, but interesting.

Mozilla's Firefox AGENTS.md begins with: Limit the amount of comments you put in the code to a strict minimum. You should almost never add comments, except sometimes on non-trivial code, function definitions if the arguments aren't self-explanatory, and class definitions and their members. Do not remove existing comments unless they are directly related to what you are changing. https://searchfox.org/firefox-main/sou…

I promise you this doesn't work. Might help but not a lot.

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

#318

Post by throwaway219450 »

noir_lord wrote: post #108
konschubert wrote: post #61

Earlier quoted context omitted.

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…

Pretty much, The one thing I use it for is as a sanity check, pretty much "Look at , point out issues you see, summarise them tersely" and it'll spot stuff a code review by a human might have spotted (in the mythical land where people actually do code reviews properly and don't just flag a spelling mistake to "show they looked at it"). Beyond that I don't trust it at all and I still write all my code the meat sack wa…

My advice is to try letting the agent fill in the gaps. You can probably architect better than it can. Write your class outlines, explicitly define the public facing bits and what you want APIs to look like. Write the key integration tests that you know ought to pass.

The real advantage is that agents routinely write code without any silly copy/paste mistakes like accidentally accessing x twice on a coordinate operation instead of x and y. You can add some comments for what the function should do, throw in some real/pseudo code and let the LLM figure it out.

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

#319

Post by ceejayoz »

solatic wrote: post #222
seer wrote: post #219

Earlier quoted context omitted.

Hmm that’s strange, in my experience it is the other way around - Claude is super diligent with infra and will _insist_ on double checking and trying everything for real before committing. When I was doing this myself I would read the docs and just implement them - claud is going about doing real software archeology to figure if what is said is actually the truth or it’s stale/inaccurate/buggy. I’ve become 10 times m…

> Backups are _tested regularly_ now because LLMs make it cheap to do so. sighs heavily in 90's sysadmin Testing backups is not just a question of whether or not the restore command works. Go back and read the Tao of Backup: http://www.taobackup.com/history.html . The application itself (in its current version, with its current features) needs to work with the backed-up data, and the only way to verify this is to att…

Good news: Eventually - and fairly regularly! - the agent will fuck up so badly you have to test the process!
Post reply on HN