Comment by snohobro | Hacker News Reader

Comment by snohobro | Hacker News Reader

Parent Full thread

I would agree with this. Programming/coding has been a portion of my job as an Ops engineer for last few years, but it was the part I liked the most. So I’ve been pretty heavily against AI use.

However there are other folks in my company who, with very little programming knowledge, have produced viable, workable solutions for our company to use. All projects that were in my list of TODOs that I hadn’t gotten around to.

It was in that moment that I realized I’m very quickly going to be surpassed if I don’t adapt and move quicker with AI solutions. Since then my output has increased a bunch.

I’m not the most stoked on it, but as with all companies, results are far more important than the journey. So long as it works and is at least mostly maintainable, leadership does not really care how we got there.

But all of this was forcing my hand because people without the foundational skill set were creating equivalent output to my artisan, bespoke solutions. Writing is on the wall.

I think you're entitled to your opinion, but want to point out that there's 2 different axes on the graph here. You are unhappy about LLMs' affect on your working conditions, but also concede it's inevitable and the labs are at least somewhat sincere in their predictions of it displacing a significant amount of the value in the software engineering market.

It's not necessarily a given that the person you're replying to agrees on the latter, and therefore they might not be stoked on you starting off by agreeing with them but going on to make an argument that supports the companies responsible for the very thing they're complaining about.

I think there's a contradiction in you stating that management thinks LLM-generated output is "maintainable". They went to business school, they don't know what that means. It's your job to explain to them the consequences of shipping code faster than the people whose job it is to understand it can do so.

I don't know if it's just me, but I find that with a disciplined approach (or even an undisciplined one for some personal projects), LLM generated code is quite "maintainable" nowadays for the sorts of things that matter: adding new functionality, fixing the odd bug (usually a missed edge case, or behavior I didn't think-through well enough). They're also secure enough for me not to be overly concerned.

Granted, I stick to frontier models and avoid cheaper ones, but if it quacks like a duck...

If you're working on a CRUD/web app, absolutely. There's so much data for web apps out there that LLMs now produce better web app code than most of my coworkers from 2022 or so, since it follows consistent style rules. Web app code all looks the same, anyway.

> It's your job to explain to them the consequences of shipping code faster than the people whose job it is to understand it can do so.

The problem we’re collectively running into is that nobody knows if this actually poses a problem anymore. We’ll find out in 5-10 years, but businesses and clients can’t wait that long.

As a side note, I don’t think it’s fair to blame the “management” for setting expectations around AI use. They’re driven by market forces. If competitors are producing slop and customers are gobbling it up, then from a business perspective it _is_ a mistake to abstain from AI use.

What I’m finding quite fascinating is that we’re in a weird spot right now where we’re both expected to produce slop AND understand it / be responsible for it. Seems unreasonable.

In the day since I posted this, I've seen a few good links on HN that touch on this question.

1. The Decoherence Trap: https://maevyn.codes/decoherence 2. SlopCodeBench, a benchmark that quantifies how models decohere over repeated change requests rather than a single one-shot challenge: https://news.ycombinator.com/item?id=50108717

I think the most important takeaway is that it takes time for these problems to manifest. If you start with a particularly coherent codebase it will take years for slop code to degrade it to a point where engineers are noticeably less productive.

I didn't downvote you, but if I had to guess why you were downvoted it's because it's very obvious to many working software engineers that decoherence is a real problem. In many ways that's what this OP was all about; not just loss of joy in programming for its own sake but loss of the ability to design deterministic, fully-understood systems that won't require constant off-the-books maintenance eating into your free time.

For the record I’m fully on board with slopification being a bad thing. My point is that businesses don’t seem to care at this time.

Reply on news.ycombinator.com