Comment by duendefm | Hacker News Reader

Comment by duendefm | Hacker News Reader

I'm a software engineer, I do software development but also system maintenance, and I do handle networking and telephony systems, and work with some juniors. Working with AI is problematic. It can speed up you but at the same time delay you. For the system maintenance part sometimes you need to do a lot of stuff fast and in various machines and you can't just count on a cloud based AI oracle (that takes time) to do your job for you. And the same time, the more you use it as a oracle, the less competent you get. If you are an expert, I would say in any area, you do benefit from using AI as a tool but it easily can become a double edged sword and make you less proficient. For juniors, it can make them rapidly produce stuff that is impressive and works ok for sites and some visual stuff, but it's impossible for a junior to become an expert if they get stuck in the AI using loop. For AI to cause a clean impact, I would say that we would have to live in a world where software engineering didn't matter. That is, the choice of databases, high availability systems, the programming languages themselves.

I think it's more about inertia than anything else. I know the dishwasher will take less than 5 minutes to unload, but I put it off anyway. Problem is the AI can take action immediately, and that's very alluring. I'm sure there's research on exactly where that breakpoint lies. My current goal is to try and spend 15-30 minutes attempting to solve a task when I feel myself reaching for the AI.

One of three things tends to happen. Often it's something that is resolved in a matter of minutes, in which case it was laziness. Or, it's something that will take more time, say up to an hour, but the act of starting has conferred a sense of ownership that I don't want to give up to an LLM. Else, it looks like a much more complex problem and worth re-assessing, and potentially brainstorming with a model.

> we would have to live in a world where software engineering didn't matter.

As an engineer who works very hard to do the right thing, I'm beginning to worry that software engineering doesn't matter. I write code that i think about a lot, understanding every line. It's not perfect, but I try to make sure my code is maintainable and well structured. I work much slower then my colleagues who produce unmaintainable slop at an alarming rate. In my career, no customer has ever complained about code structure or quality. It feels like I'm sinking in quicksand in an industry that's dying.

It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt. I can give a simple example. I have a coder here that filled the crontab of a server with periodic tasks. One of them was doing +200 failed requests per second and shutdown one of our routers. The router wrote so much logs that it changed the health of its internal disk from 15% to 85%. He doesn't even know what the crontab is. This kind of stuff is bound to happen more and more because the more you use AI to vibe, the more disconnected you get from the technology. And that's why I say, the only way that yolo vibecoding could work is if the base stuff didn't matter.

> It's not about what the customer complains or notices at short term, is about having a quality system that can be augmented without accumulating same kind of debt.

I agree with this wholeheartedly, but convincing nontechnical management of this fact has been extremely difficult. It was hard in the days of the stackoverflow copy-paste monkeys, and it's even harder in the age of LLMs.

Some people cannot be convinced of this, but some can, as long as you don't use technical language to describe the issue. Essentially, instead of saying "we need to prevent technical debt and have a maintainable software architecture" one needs to say stuff like "software quality enables a faster time-to-market for new features and less customer churn". i.e. put it in business-y terms.

Yes, but then it's really important to demonstrate that this is true. If they invest in what you propose, time to market for new features needs to actually become faster, or customer churn needs to actually decrease. It's not enough to put the proposal in business-y terms, it has to actually effect the claimed improvements to the business.

You have to pick metrics to show management that they understand the importance of, and then be able to demonstrate degradation in those metrics when you don't do what you propose, and improvements when you do. Accomplish this and you'll build trust.

Too often, what happens is that the proposed benefit is vague and not empirical, and then the benefit is not actually realized by a large investment into it, destroying trust.

Of course customers do not care about code quality in and of itself. Just like they don't inherently care about the type of seam used for a garment. But they do care if their clothes fall apart after two washes. People care if software is buggy or slow or becomes harder to use or more expensive over time. And the way we know how to mitigate that is by ensuring code quality (it's definitely not the only factor, but an important one).

Agree and disagree.

There have always been software companies that care about quality, and those that don't.

Many who don't care about quality exist because their products are forced onto their users. (Due to footholds from enterprise relationships, regulation, etc.) I bet slop will abound in these kinds of companies, but their codebases and products were already terrible anyways.

---

But research reliably shows users do care about things Just Working™ and feeling polished. With few exceptions, if software feels at all buggy or doesn't look visually amazing, you won't acquire/retain that many users.

Natural selection will teach hard lessons to the industry. Customers will notice things feeling "off" on products where AI slop is allowed to abound, and they'll flee to companies with sane approaches.

A sane approach: Humans actually guide the direction of the code which means they have to understand + review the code and course correct bad decisions. This doesn't mean agentic coding goes away, but it means this mad rush for insane velocity goes away.

---

Compare vibe-coded apps you've interacted with against world-class polished apps like Spotify, Gmail, Slack, etc. Those apps aren't obviously showing signs of AI slop, because the organizational structure is in place in those companies to prevent engineers from just throwing slop over the fence. Those engineers are doing agentic coding but are being forced to go at a sustainable pace.

The industry will eventually be forced (by the reality of business results) to recognize that this is the only approach that will lead to success.

Sometimes it matters and sometimes it doesn't. The hard part is figuring out which is which. The most effective engineers are those who maximize the amount of time they spend picking the right point in the trade-off at the right times. Choosing a preferred point on the continuum and sticking to that at all times simplifies decision making (itself a useful thing!) but it's not the optimal strategy.

There are a couple ways out of this conundrum. One is to try to get really good at picking the right point on the continuum as much as possible, which is essentially a forecasting problem (and thus it's really hard!). I think the somewhat easier choice is to pick roles that align well with your style. If you have a deliberate and near-perfection preference, you can seek to work on projects where there is no question of the importance of correctness. If you prefer the opposite, you can work on prototypes and zero-to-one type projects, and that will be more satisfying (and less catastrophic).

Reply on news.ycombinator.com