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

131–140 of 378 posts

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

#131

Post by huurtehoog »

setopt wrote: post #49
ulrikrasmussen wrote: post #12

Earlier quoted context omitted.

I think LLMs have some of the same risks and benefits of stimulant drugs. They can make you more productive if used effectively as a tool, but they can also delude you into thinking you are better than you are and create a dependence such that you aren't just less productive without the LLM/drug, you fail to be productive at all because you don't know how to function without it.

That sounds somewhat applicable to many tools. Like Vim/Emacs, for example. Or computers and smart phones in general.

Yeah, like caffeine is to meth

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

#132

Post by spockz »

jjav wrote: post #63
shakna wrote: 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…

They would not do it in the span of a day or a week. But I’ve definitely seen something like that happen over a period of multiple months.

The llm just allows to generate faster.

We can feel smug about that but all it means is that we need to be clearer on our requirements and preferences up front.

State that similar functions should be in one place and there should be only one. Today there has to be compelling reason why that function is different from others. Normalise the function name based on what it does. Why are there different ones?

Then there are all the other guard rails in place.

Better guidance from mentors, reviewers, and automated project tooling helps everyone. Juniors, seniors, and engineers.

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

#133

Post by anal_reactor »

mawadev wrote: post #25
Root_Denied wrote: post #8

Earlier quoted context omitted.

I'm seeing this happen in the security space right now. Someone on my team I was helping train and bring along is all of sudden regressing in their understanding of the issues we're working on, and instead focusing on AI tool outputs to do their job for them.

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 this is going to change because it helps automate code production. As in, once we reach a point where this method produces acceptable results, we can fire all engineers and automate the process.

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

#134

Post by itsalwaysgood »

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'd say it's more about learning how to organize your work more efficiently.

If you think about a product like marble: it's something that most be chiseled out of time.

Some people can chisel better products: the AI is just a better chisel.

Sometime still has to guide the chisel and judge the art/product.

In our cases, the market judges products.

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

#135

Post by spockz »

shakna wrote: post #95
Foobar8568 wrote: post #67

Earlier quoted context omitted.

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.

Exactly. People ask how we get seniors with juniors using llm. The answer is the same. Review the code. Analyse write down what is wrong. What you expect to have been better. Force every change to be documented and explained enough.

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

#137

Post by dist-epoch »

wegwerf17377382 wrote: post #77
ffsm8 wrote: post #70

Earlier quoted context omitted.

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

So how do you build competence in a world where AI is preached to be the most reasonable way to solve problems because it's supposed to be faster than humans?

That's like asking "how do you build competence in plowing a field with a horse in a world of tractors"

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

#138

Post by dwedge »

yard2010 wrote: post #27
jtfrench wrote: 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…

Considering how many compromises and problems third party libraries have caused recently, I would say the comparison is apt - if you don't know what you're shipping one day it might explode on you

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

#139

Post by legulere »

iforgotmypasswo wrote: post #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. Fore…

> But certainly not in the 70s and 80s.

Some already developed even earlier and most ideas were already there in the 80s. The problem was just that the field was growing so fast that it was filled with people without formal training or fresh out of university. That way the knowledge did not spread.

For instance the 1986 paper „no silver bullet“ already described the need for iterative approaches later described as agile.

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

#140

Post by itsalwaysgood »

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…

Are your silver platters producing something faster, better, or cheaper?

Do your silver platters give you some competitive edge? If not, then is the ego problem yours, or your coworkers?

Post reply on HN