Live data from Hacker News

AI handles incidents, engineers lose touch with their systems

sylvainkalache.com

91–100 of 376 posts

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

#91
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…

I have also a weird story to tell that a human did and it is as crazy as this. It happen in 2019 so no LLMs at all.

A person that was hired as an expert in our startup spent more than one week full time working on implementing his solution to the problem we were having. I checked the code after one week to see the progress and was curious how they are implementing an already crazy sounding idea. I found that the whole week was spent re-implementing in python, python's built-in "float" function. That was it, the whole code was just that.

Our problem was related to financial services and their implementation of "float" was not even correct.

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

#92
I feel a lot of comments here are missing the forest for the trees.

We do not yet have the next generation systems that will manage AI creation and maintenance of systems.

Humans have been making spaghetti code systems and maintaining them poorly for years. Best practices developed… eventually. But certainly not in the 70s and 80s. Spaghetti was the norm for quite some time.

The development paradigm has changed. Forever. You can’t expect yesterday’s tools for managing software development to succeed at this point. We’re still roughly on year one of this transformation.

The new bottlenecks are creating and enforcing boundaries in the code, identifying level of risk within a boundary, subjecting high risk areas to more intense human review and architecture reworks, and so so much more manual testing.

We need a new language for high level development that focuses on architectural constraints. We need analysis software that helps draw boundaries, identify what needs extended human attention, and helps us map and understand a rapidly developing code base. We need to standardize on the use of frameworks and languages like we have on assembly variants.

I’ll bring up a hacker news trope here. NaughtyDog’s GOAL was an amazing system that was a product of an underdeveloped ecosystem for game development at the time. They used lisp and assembly because you still had to write assembly for performance reasons then.

We are in a very similar period. The ecosystem is underdeveloped. We should be looking for new languages and tools to manage this.

CNC machines used to run from punch cards and then hand written NC code. Now we have advanced CAM software. (Which innovative people are actually running with LLMs!)

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

#93

I am exceedingly tired of poor metaphors that are popping up since AI has taken over writing. No, operating software is not like operating a plane. Not at all in fact. The people operating the software and resolving incidents are the same people who created the software in the first place, and continue to work on it day to day. Pilots have not and don't.

[deleted]

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

#94

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…

It’s tough. The models can at this point very quickly identify issues in a Kubernetes cluster, for example. This because these systems give you a TON of observability, and it can easily see all the different moving parts.

That doesn’t mean the proposed solution is always right, but it is absolutely landing on the root issue faster than most humans would be able to, even pre-AI. Just because it can remember and run through a bunch of commands more quickly that I can.

There are lots of incidents where the symptom doesn’t always clearly point to the issue, so having something that can fairly exhaustively check a lot of different things very quickly is pretty useful!

But I at least partly agree, I think the more complicated and obtuse a system is, the harder it is for AI to do this. But we’ve invested time in making systems much more straightforward to understand and operate from one place (Kubernetes in general), and AI thrives on that.

And yeah, it means your debugging skills wane a bit because, yeah, if the bot can diagnose the issue in 5 minutes, it’d be irresponsible to not use it.

And I’m not really happy about it, and personally I’ve always been able to figure out a tricky bug given enough time. I don’t want to loose that skill. But everyone is under a lot of time pressure these days.

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

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

Oh and how is it any different than most software engineers? How many times I heard ORM are bad only to recreate the same shit? How many times I heard ORM had bad performance and see 1+n stuff everywhere? How many times I have seen tight coupling in the name of DRY?

Its different, in that when you teach that engineer, they either leave because now they hate you, or they grow. They change to meet the standards of a project, rather than inventing their own.

We don't get seniors, without juniors. I'd say more than half the job, is just... Learning. People grow.

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

#96

Prediction: this won’t happen. The abstraction will be good enough and people will need to know only as much as they need to know- things will stabilise at the equilibrium.

We already know this happens though, Bainbridge’s paper came out in 1983.

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

#98

Code too. I work with programmers and it's not uncommon that they can remember with shocking detail about code they've written in the past. Someone might mention an issue that has cropped up and they'll stare off into space for a few moments and actually remember where that issue stems from in the code, because they remember writing it like 8 months ago. This skill will be lost when AI is generating all code, we'll b…

I mean I think this is just how AI already operates. I’ve seen multiple models go digging in the git blame or past PRs, and even unmerged PRs. When agents work on a project that has well-defined in-repo docs, agents normally update them without prompting. So I doubt this will be a big issue for AI, but agreed we’re losing a skill

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

#99
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…

Which model though? I have similar anecdotes but all with older models. The jump in capabilities in the last 6 months has been substantial.

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

#100
This has already happened in other areas. I'm old enough to remember when customer service people spent all day handling customer problems themselves, which gave them the understanding needed to solve more unusual problems.

These days they do what the computer tells them. Even if they could solve the problem they don't have the agency. They can only select from the options they are given.

In software we still have the agency but we are giving away the understanding. The agency will follow.

Post reply on HN