The tools produce mediocre, usually working in the most technical sense of the word, and most developers are pretty shit at writing code that doesn't suck (myself included).

I think it's safe to say that people singularly focused on the business value of software are going to produce acceptable slop with AI.

That makes sense given that it's trained on real world developers.

I've always heard this sentiment, but I've also never met one of these newly skilled job applicants who could do anything resembling the job.

I've done a lot of interviews, and inevitably, most of the devs I interview can't pass a trivial interview (like implement fizzbuzz). The ones who can do a decent job are usually folks we have to compete for.

This is great. One of the things I say to my wife all the time, which is taken from a Kurt Vonnegut quote, is that "I don't have to be good at my hobbies".

You could head for Chesterton as well: "anything worth doing is worth doing poorly."

    Here will be a list of ... things I don't like about them.

I did not see a list of things not to like. Just a set of vague thoughtless complaints.

I see a lot of times people (read: me) are lazy and make a mock that does not have anywhere near the behavior of the original. It's more like a very partial stub. I will mock an api with 20 possible calls with the 2 that I use. Unsurprisingly, this mock is closely tied to the current implementation.

I think making narrow use-case-specific test doubles is often better than a big shared one. You can even wrap the API with an interface that only exposes the methods you need.

This sounds great until one of your other functions calls that function.

You're just describing dependency injection, but if you say that, people won't want to listen cause doing that all the time sucks.

Dependency injection frameworks can be a pain, but basic dependency injection (e.g. pass a DB handle to anything that needs the DB) is a must. What's the alternative? Having everyone independently create their own DB connections?

It's my preference to a point. I think you can over-do it. I've worked in systems that didn't use it and worked just fine. I would bet most folks err on the side of too little, unless they have some kind of framework doing the heavy lifting.

I've been working on a web framework in Clojure. There are already a few others, but they're, in my opinion, too focused on the Clojure community, and are much harder to sell to people I know who might otherwise use Clojure. I wanted something that was more like a Rails or a Phoenix or a Next.js. We'll see if it goes anywhere.

I would say this does not work in any nontrivial way from what I've seen.

Even basic scripts and UI components are fucked up all the time.

It can still fuck it up. And you need to actually read the code. But still a time saver for certain trivial tasks. Like if I'm going to scrape a web page as a cron job I can pretty much just tell it here's the URL, here's the XPath for the elements I want, and it'll take it from there. Read over the few dozen lines of code, run it and we're done in a few minutes.

You have to learn how and where to use it. If you give it bad instructions and inadequate context, it will do a bad job.

This is the ‘you’re holding it wrong’ of LLMs.

What tool can’t you hold wrong?

Literally every tool worth using in software engineering from the IDE to the debugger to the profiler takes practice and skill to use correctly.

Don’t confuse AI with AGI. Treat it like the tool it is.

You might want to ask ChatGPT what that is referencing. Specifically, Steve Jobs telling everyone it was their fault that Apple put the antenna right where people hold their phones and it was their fault they had bad reception.

The issue is really that LLMs are impossible to deterministically control, and no one has any real advice on how to deterministically get what you want from them.

I recognized the reference. I just don’t think it applies here.

The iPhone antenna issue was a design flaw. It’s not reasonable to tell people to hold a phone in a certain way. Most phones are built without a similar flaw.

LLMs are of course nondeterministic. That doesn’t mean they can’t be useful tools. And there isn’t a clear solution similar to how there was a clear solution to the iPhone problem.

"Antennagate" is the gift that keeps on giving. Great litmus test for pundits and online peanut galleries.

You are technically correct: it was a design flaw.

But folks usually incorrectly trot it out as an example of a manufacturer who arrogantly blamed users for a major product flaw.

The reality is that that essentially nobody experienced this issue in real life. The problem disappeared as long as you used a cell phone case. Which is how 99.99% of people use their phones. To experience the issue in real life you had to use the phone "naked", hold it a certain way, and have slightly spotty reception to begin with.

So when people incorrectly trot this one out I can just ignore the rest of what they're saying...

YOU come up with a real argument first

"no, you're wrong" is not a valid rebuttal lolol

I pointed out the claim is both irrelevant and factually wrong.

That should be sufficient rebuttal.

Exactly. The problems start when people say it's good for everything ;)

"All the time"?

This always feels like you're just holding it wrong and blaming the tool.

I've been using NoBS toothpaste tabs for a couple years which are nano-hydroxyapatite. I find them effective. No issues at my dentist.

In fact, a year ago, they wanted to put in a filling for a minor cavity, but I wanted to put it off and by the time I went back they said it was gone.

edit: I also like the tabs because they're easy to travel with.