Seems to me like the better action would be to implement rate-limiting, rather than complain when people use your resource in ways you don't expect. This is a solved problem.
I can't believe we're going to forever have to live with people who don't speak English as a first language having their written work assumed to be done by AI. It's pretty disappointing.
Not just people who don't speak English as a first language.
I was recently linked a list of 1,000+ words that "shouldn't be used" because they're "evidence" of AI. Oh, and if you use bullet points, obviously AI. Dashes? AI. Paragraphs with opening and concluding sentences? AI!
I think people will get bored with it, especially when we get to a point where a majority of written things will have AI in the loop and we'll return to bad writing just being bad writing.
I've said it before, and I'll probably keep saying it forever: bad writing predates AI. Overly verbose writing predates AI. Not all the bad writing you see is AI, lots of it is still the good old fashioned kind.
Not that inserting an aside about a different language is bad writing. It's also weird enough that it's exactly what I would not expect an AI to do (except perhaps under very odd and specific circumstances). "It's clearly AI" has become a catchall for any writing that people find even mildly bad or surprising.
When the next best option is "serialize", suddenly stringify doesn't seem so bad. I would prefer a silly-sounding but immediately clear function to a more abstract concept.
Great read, and an interesting warning sign about overly-controllable configuration files. If there's no conceivable good reason to to much of this, then the ability to do so becomes bad design that fails to protect your users.
The Postgres defaults in debian are understandably conservative to make it run everywhere. When I first installed Postgres I found it rather slow even on a good server. Only after reading guides on the web I found out why, the default RAM usage is limited to something like 32 MB which is way too low.
Bisect is a very cool feature that I used once over 5 years ago. The collection of git tools that I use often is very small. I've found that the more experienced I got with git, the less I found myself in scenarios where I needed git's more complex tools.
Because SO at least requires you to THINK a little about what do you have a problem with.
With LLMs, you don't even need that. Just copy paste the error and you get a response. Copy and paste the Jira ticket description and you get a response. This wasn't possible with SO. Yes, none of those will likely work straight away but the point is that less thinking is required.
Hopefully, the junior's code will be reviewed before it gets merged
Did we survive the age of StackOverflow though? The market (globally) is absolutely flooded with not-even-mediocre software devs who are effectively doing what an LLM is i.e. finding the most plausible looking answers on SO and somehow munging them together, without any real understanding of what they're doing nor why it's working (or not working). The number of people charging contract rates yet lacking an understanding of actual software design principles (largely language agnostic) and no idea how computers actually work, is scary.
Tools like direnv gets .env files out of repo paths and improves things a lot. You can integrate secrets management in code, but with that there's still no getting away with the assumption that some kind of auth mechanism exists in your env
Wouldn't direnv just mean it will now send up your .envrc file? I think what would work even better is combining direnv with pass[0] so that if it does get uploaded, it will be encrypted. ie:
I think the joy of working at this scale makes up for that for a lot of people. There are plenty of low-stress, low-impact companies that someone that's bigtech-approved can go to
