Live data from Hacker News

AI handles incidents, engineers lose touch with their systems

sylvainkalache.com

381–383 of 383 posts

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

#381

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.

We have a tool at work that was entirely spun out of a prototype that itself was entirely driven by a single guy with an unlimited Claude budget. I only touch it on the edges, where I need to integrate it every so slightly into one of my systems. It's a crucial piece of software for the team, though. I've looked over the source, the thing that strikes me the most is the verbosity. Human software engineers would've be…

In all fairness, LLMs try to write the code with all the safeguards imaginable, all exceptions handled and following the SDK/language/framework guidelines.

So a lot of this verbosity is good, even if we aren't used to it, because almost no one writes their code so exhaustively.

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

#382

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.

Pretty fair. Engineers spoiled the code and now have to deal with it.

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

#383

Earlier quoted context omitted.

Have a single human AI chef. Everyone else has to write an engineering statement and submit it to the AI chef. All that interaction is outside the codebase. Engineers will take turns - perhaps 1 month stints - being the AI chef. I guarantee you'll spend less on tokens, have better documentation, better code, and most importantly more competent engineers.

I actually quite like this idea and might try something like it on my team because we're defacto heading in this direction anyway and everyone's a bit frustrated, might be better if it was acknowledged and made official as something to try. On the other hand, I think this denies the reality (in my experience anyway but I think enough people will agree) that one often solves a problem as they are working on it. This m…

> This method seems to presume that a good engineer will submit a well thought-out solution or direction giving the AI an extremely good overview

Yes it does make that presumption - but that's part of the model here, that "prompt review" becomes the new code review and that the team is training on standard prompt semantics.

I'll share my outline - which is basically the one that was drilled into us in engineering school (CMU class 89)

1. Problem Statement

2. Definitions / Assumptions

3. Plan of attack / Options explored

4. Implemetation / Results

5. Limitations / Future Work

> So one would have to submit at least a half developed solution not just "instructions

The outline supports that in that you can fill out that part of the document which has been woeked on - including referencing any existing code.

Any other engineering students here recognize that outline?

Post reply on HN