Live data from Hacker News

AI handles incidents, engineers lose touch with their systems

sylvainkalache.com

81–90 of 378 posts

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

#82
post #5

The more code writes autonomously, the less intuition the human owners have about that code. Loss of intuition is a seed of technical debt that grows with time. Over a long enough horizon, it can make looking at your own codebase feel like the first day on the job (sometimes at a company you started). Luckily, there are ways to mitigate this and essentially translate those human intuition of how the codebase “should”…

I've been thinking about this lately - is it like using 3rd party libs to achieve stuff faster? As much as I would lovr to hand craft the datetime logic in my app, I might as well use luxon and invest this time somewhere else. Only now with llms, you get virtually infinite 3rd party libs you can use, you create them on the fly. So if you have strong engineering values, I would say simply it boils down to "contracts o…

It's not because with libraries you have a boundary somewhere and can decide to not care what's inside as long as the interface is stable and well designed. The problem of course you need to prioritise building well designed interfaces and decouple components from each other, and that's a skill most developers aren't good at.

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

#83
post #14

Anyone who's worked in tech in a large company will probably have experienced having an ops team who use RPA tools to do repetitive tasks that tech teams get the blame for when things break. AI will make this so much worse. Things will break, everyone will assume 'tech knows the system', but really it's a new process outside of the tech teams that someone vibe coded but got it wrong. Audit trails, logs, and tight dat…

> Robotic process automation is a type of business process automation that automates tasks within business and IT processes using scripts that mimic human interaction with application user interfaces. For anyone else wondering what RPA means. Never heard that abbreviation before.

That makes more sense than Rocket Propelled Automation that was my hallucination.

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

#84
post #9

I find the use of AI like quicksand. The more I use it, the more I have to rely on it to make changes/ fix things in the same system. In the end, I come out feeling empty; no intuitive knowledge of the system "I" built or fixed. Code review is important but it does not replace the mental model I am able to build when I do all the steps of software development manually without AI.

I find that it helps a little to maintain an iron grip on the design. Take the time for really detailed change planning. Be pedantic and push back against every little thing that seems wrong or even a little odd in any plan document the LLM spews out. Likewise, watch for the for the moment when the LLM eventually stumbles and starts to make excuses for deviations from the plan. Interrupt immediately and force it back onto the plan (or your vision), potentially with pointers to resolve immediate problems. Completely unattended agents just don't work for important code.

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

#85

Earlier quoted context omitted.

While I actually agree with you (though, outsourcing to lowest bidder would account for much of what you're seeing with humans), I just saw Bug Hunt Bench scores that gave me some pause: https://x.com/PawelHuryn/status/2095982259761475945 https://bughunt.productcompass.pm/?preset=all Claude Opus 4.8 ranks near last on this Bug Hunt benchmark, and missed 96% of the deliberately introduced bugs. If you're a developer w…

Still, basic debuging and trouble shooting is where LLM generally shine. Any model can bisect git history and isolate newly introduced bug. If model can not automatically reproduce bug, while human manually can... you got a problem in CI. > Luna Max performing better than Fable 5.1 High Perhaps you are reading too many benchmarks. Edit for answer : I agree Luna is great cheap model. But if Fable was hitting security…

> Perhaps you are reading too many benchmarks.

Maybe, but at least the benchmark provides an objective measurement of the codebase it is tested on. You're also assuming the bugs are newly introduced / regressions.

I can give a concrete example - Fable will not interact with bugs that result in writing to null pointers in C code. That triggers the guardrails and ends the session. If Luna (or GLM Flash, etc) will fix those kinds of memory bugs, that immediately puts it ahead of Fable in some ways, no matter how tiny Luna is. Again, models are spiky.

I still agree with your initial point! It's LLMs all the way down over here. It would need to be a particularly gnarly bug & an exceptionally talented human for me to want to pay another human to work on fixing it now.

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

#88
post #38

If capability increase continues as it has, then an incident that cannot be resolved by AI will stump humans no matter the practice. I like the plane example from the article,but I think in reality it will be like code. 1.5 years ago engineers would routinely say that they still write code by hand here or there to keep their skills sharp, and that's just not something you hear much if at all. If an SRE is faced with…

Like the fact that software "engineering" is mostly nothing like real engineering (and it’s further regressing now due to LLM coding!), the general lack of drilling is again one of the things that make software-related stuff look really naive and amateurish from the perspective of those dealing with the real world. Imagine if the military, police, fire service, and so on did not drill and rehearse incident response?

There are drills, tho. It's just that usually they're only done above a certain level. Small companies, "lean" teams and so on don't have (or didn't have) the capacity to implement all those things. Maybe with the exception of netflix and their chaos thing (bring down systems regularly to make sure the whole still works).

But that's also likely to change with AI assistance. Even an "average" system is better than none. So now teams will have the capacity to bring that in to their systems. Backups / recovery drills that are actually tested (either because they're implementing testing or because the AI screws something up and they need to recover). Either way, it'll be included. Same for security ops. And devops.

I still strongly believe that AI assistance is a catalyst / accelerator, and that the "floor" will rise in most domains. So a small team that only had bandwidth to deal with the happy path previously, will now be able to start incorporating processes and procedures that were historically only done at corporate level. And that's a good thing. Even if it won't look like that in the beginning. But we'll get there, eventually.

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

#89
post #63
post #21

Earlier quoted context omitted.

Claude regular spits out six helper functions instead of... A twenty line for loop. It overengineers most things. Overabstracting, deduplicating things that don't need to be. Building metaclasses because it saw a single orchestrator in the whole codebase. If it is a better engineer than you... You need practice.

> A twenty line for loop. It overengineers most things. Anecdote I like to tell.. I was working on a financial planning software, intentionally purely vibe coded as an experiment. I eventually discovered AI had implemented seven duplicate copies of tax calculation functions. All of them different. All of them wrong. All of them giving different answers for same input. Not even the most junior of newbie junior enginee…

For some definitions of efficiency.

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

#90
post #21

Earlier quoted context omitted.

Claude regular spits out six helper functions instead of... A twenty line for loop. It overengineers most things. Overabstracting, deduplicating things that don't need to be. Building metaclasses because it saw a single orchestrator in the whole codebase. If it is a better engineer than you... You need practice.

I am former java enterprise dev, so yes I often code this way. Unit testing, decomposition... Some projects CI refuse to merge commits with 20 line loop and duplicated code... But that is not a point. Claude can code tight compact loops, it just needs to be instructed to do so! If it does "enterprise code", it means it had no instructions about code style. If your documentation, spec, agent.md does not have proper gu…

> it just needs to be instructed to do so!

Considering how often it overrules, its own rules?

Post reply on HN