4 ms·
I'm more than aware that my comment won't move the needle on the AI debate a slight bit, but I do think that the readership deserves some honesty and transparen
by ezst 2mo ago
I'm more than aware that my comment won't move the needle on the AI debate a slight bit, but I do think that the readership deserves some honesty and transparency there. No, not a single LLM ever has "deployed SQLite in Production", had to be on duty during the weekend, had to pop open a terminal to a misbehaving service while on family vacation, nor meaningfully suffer the anguish and stress to hotfix a botched or misconfigured deployment. Only humans have. What makes or breaks a software product, costs you your holiday, and perhaps even your job, probably won't be found in some generic piece of common knowledge rehashed and repackaged with some stylistic tweaks. It's the fine details, the one-off things, those weird edge-cases and compounded factors that in hindsights were obvious but had to be learned the hard way, and hopefully, shared by benevolent contributors.
That's the whole reason why many here put the effort to read/post articles and argue over comments: so there's something non-obvious to be learned. LLMs are effectively "knowledge averagers". They will put together a pretty article that's not worth reading, except maybe if the problem space is completely new to you. And that's the kind of disclaimer I would hope to see ahead of anything LLM-produced, and particularly on this website.
- rdsubhas 2mo agoI'm on-call all the time, and the first thing I've taught myself is to not glorify it like some superhero saves the day worship. I'm both proud and (slightly) ashamed each time I handle an incident. It's not a virtue. How many people who were writing blogs or creating open source tools before signed an on-call oath or declaration? Does that mean they're all wrong or unqualified? On call avoidance should be rewarded more than on call superheroism. People managing software fail to realize it. Avoidance is stashing enough operational bullet points, mental checklists and manpages. Everything is generic — because your use case and your operating environment is ONLY yours. Postgres has hundreds of parameters. Nothing is specific or made to satisfy you. If it doesn't, then you don't call the parameter as generic. You choose what to apply for your environment and expectation. What you're saying is both a wrong reward cycle and it was also not necessary or practical before AI.