Hacker News Reader

Comment by lr4444lr | Hacker News Reader

I can't imagine SWEs will be reduced to SDETs anymore than attorneys will be reduced to spell-checkers on AI powered case briefs.

I am a very AI-forward person, but hallucinations are becoming more pernicious than ever even as they get less frequent, especially if the code actually works. A human absolutely has to guide these processes at a macro level for sustainability for SaaS as it evolves with business needs.

Maybe for one and done systems with no maintenance/no updates/no security patches you can reduce humans to SDETs, but systems like that are more the exception than the norm.

View on HN

I've noticed even more than the "hallucinations", just the code is generally quite bad.

At least with concurrent and distributed systems stuff (which is really all I know nowadays), it is great at getting a prototype, but the code is generally mediocre-at-best and pretty sub-optimal. I don't know if it's because it is trained on a lot of mediocre and/or buggy code but for concurrency-heavy stuff I've been having to rewrite a lot of it myself.

I think that AI is great for getting a rough POC, and admittedly often a rough POC is good enough for a project (and a lot of projects never get beyond a rough POC), but I think software engineers will be needed for stuff that needs to be more polished.

The code is quite terrible, but no one has ever cared about code quality, at least in my experience. All they’ve ever cared about is that “it works”. It’s why an army of juniors always write most of the code.

I had this same discussion at work the other day. I had an 80k line generated project dropped on my plate. It doesn’t use anything built into the web framework or orm. It’s a maintenance nightmare.

I think there are plenty of projects where "good enough" really is "good enough"...maybe most apps? If you're just making a shitty simple app, I don't really care about code quality.

Example: I got Claude to generate a language server for TLA+ so I could have nice integration with Neovim. It took like 45 minutes of arguing with Claude and then it worked fine. This is incredibly low-stakes stuff: realistically the worst case scenario is that the text in the file gets screwed up, and I'm somewhat protected by Git if that happens.

That said, I am a little concerned how cavalier people have been deploying AI code everywhere. I don't want pacemaker firmware to be written by some intern in an afternoon with Claude.

Yes I agree, the low stake, low evolution code is perfect for LLMs. The project I was handed is not that at all.

Maybe you can ask Claude to reverse engineer what the original prompt was.

Numerous real world technical requirements can be solved with existing code, lightly modified. That’s basically LLM code’s bread and butter. The further you get from that, the closer the “time saved using LLM” line gets to zero, and once it crosses, it becomes the “time wasted using LLM” line. I think embedded and concurrent systems are going to require more unique code solutions than, say, a crud web app with a few interesting feature-building junkets.

I'm getting the impression that LLMs are just not very good at "reasoning" about time. I have definitely had success getting a coding agent to produce decent concurrent code, but I had to basically lead it by the nose, and I strongly suspect that in most cases it would have taken less time to just do it the old fashioned way.

I've had good luck having it translate TLA+ specs to programming languages. The specs are written by me and my fingers, and I've done most of the interesting concurrency reasoning beforehand.

I'm pretty sure it still saves me time, and if nothing else it's an excuse to write TLA+, and that's fun.

LLMs are very bad at reasoning. They don't reason, they just backport their "reasoning" to fit what they did.

By SDET I mean one who reviews not writes code, maybe we have different definitions of that term because you also mention humans being needed to guide the processes.

Even still, other professions interact with the real social world which is not necessarily the case with programming. A lawyer will always be needed because judgments are and must be made by humans only. Software on the other hand can be built and tested in its own loop, especially now with human readable specifications. For example, I wanted to build an app and told Claude and it planned out the features, which I reviewed and accepted, then it built, wrote tests, used MCPs including the browser for interacting with the UI and taking screenshots of it, finding any bugs and regressions, and so on until an hour later it came back with the full app. Such a loop is not possible in other professions.

No one's arguing you can't stand up a good MVP.

It's when you have to iterate to handle changing business needs, scale issues, and integrate with other systems where the entropy becomes a scary concern over a long enough timeline.

And it's not just "checking" - it's wholesale rejections of code, reframing prompts to target specific classes or approaches, etc... I don't think you will take the human out planning any time soon.

I agree, humans will always be there.

> A lawyer will always be needed because judgments are and must be made by humans only.

Honestly, I believe lower court judges will be the first job in the legal industry to become fully automated.

This afternoon I was speaking with a friend and mentioned that I need to find a lawyer for contracts. His immediate response was, "you don't need a lawyer, just use AI". Not an avenue I'm interested in going down.

Reply on news.ycombinator.com