Hacker News Reader

Comment by sdcfgy | Hacker News Reader

It's easy doing a lot of stuff you don't understand quickly these days. But when the shit hits the fan and you have customers you need to know what you're doing.

Hiding behind the LLM, or even a cloud service like RDS makes you think you can get out of a corner, but you are nowhere near that. Practice, drills, experience are the only solution here. The illusion of that is dangerous.

I spent a couple of days recently digging one of our associated businesses out of the shit because they killed a postgres on RDS instance (AWS bug!) and couldn't google or LLM their way out of it. It hit the trade press and did a lot of damage to them.

If you're not going to do the work, don't take on customers.

View on HN

An LLM can absolutely do the harder stuff too. I wonder what model you have used where you think it's only for the easy stuff.

Of course you need understanding for when shit hits the fan, but that applies regardless of whether it's a human or an LLM writing the code.

We've had the best people using the best and most expensive models. They confidently produce shit they thought they understood but didn't.

LLMs remove personal exploration from tasks and that's where you really get to know things.

We've all seen best people confidently produce shit throughout the history, before the LLMs.

Now they can do it faster than ever and to the detriment of everyone. Which is the problem.

When you optimise for fast and not correct, things are fucked.

Then they've been fucked since C beat Lisp, and that hasn't been enough to cause Silicon Valley to implode.

That is a completely different argument.

No it's not. If "bad software delivered faster" is a problem, it's a problem long before LLMs. But the history of software-based products has shown that "delivered faster" is consistently more important, as bad software that attains significant usage will be made into good software one way or another.

I'm not skeptical of the idea that LLMs will be useful tools to cost-effetively develop high-quality software. I am, however, skeptical that the input to these LLMs will remain mostly informal and conversational.

> when the shit hits the fan and you have customers you need to know what you're doing. [...] don't take on customers.

I think you overestimate the level of DBA skills smaller startups have in house.

If you have found a way for a company to hold off on taking on customers until they can afford a proper DBA, I'd love to hear more about it. But it sounds backwards to me. In my experience, it typically goes the other way around: only after taking on enough customers to be decently profitable can a company afford a real DBA.

Until then, the choice used to be between managed database services or striking luck with a developer that had some database interest. These days, it's between managed database services, striking luck, or giving the developers access to an LLM. The LLM doesn't replace DBA skills that used to be there. There weren't any DBA skills there to begin with.

This is incidentally exactly why I never buy any products unless they've been around 10 years. It's a risk.

I haven't seen a small company hire for a dedicated DBA in over 15 years. It was unnecessary then, it's unnecessary now. As "agile" and "devops" took over, many of the more specialized roles disappeared.

Reply on news.ycombinator.com