←back to thread

378 points todsacerdoti | 2 comments | | HN request time: 0s | source
Show context
xnorswap ◴[] No.44984684[source]
I won't say too much, but I recently had an experience where it was clear that when talking with a colleague, I was getting back chat GPT output. I felt sick, like this just isn't how it should be. I'd rather have been ignored.

It didn't help that the LLM was confidently incorrect.

The smallest things can throw off an LLM, such as a difference in naming between configuration and implementation.

In the human world, you can with legacy stuff get in a situation where "everyone knows" that the foo setting is actually the setting for Frob, but with an LLM it'll happily try to configure Frob or worse, try to implement Foo from scratch.

I'd always rather deal with bad human code than bad LLM code, because you can get into the mind of the person who wrote the bad human code. You can try to understand their misunderstanding. You can reason their faulty reasoning.

With bad LLM code, you're dealing with a soul-crushing machine that cannot (yet) and will not (yet) learn from its mistakes, because it does not believe it makes mistakes ( no matter how apologetic it gets ).

replies(14): >>44984808 #>>44984938 #>>44984944 #>>44984959 #>>44985002 #>>44985018 #>>44985019 #>>44985160 #>>44985639 #>>44985759 #>>44986197 #>>44986656 #>>44987830 #>>44989514 #
clickety_clack ◴[] No.44985160[source]
Ugh. I worked with a PM who used AI to generate PRDs. Pretty often, we’d get to a spot where we were like “what do you mean by this” and he’d respond that he didn’t know, the AI wrote it. It’s like he just stopped trying to actually communicate an idea, and replaced it with performative document creation. The effect was to basically push his job of understanding requirements down to me, and I didn’t really want to interact with someone who couldn’t be bothered figuring out his own thoughts before trying to put me to work implementing them so I left the team.
replies(2): >>44985267 #>>44987294 #
siva7 ◴[] No.44985267[source]
What the heck, the universal job description of a PM is to genuinely understand the requirements of their product. I'm always baffled how such people stay in those roles without getting fired.
replies(1): >>44993115 #
1. mdaniel ◴[] No.44993115[source]
For consideration, one can pretty objectively determine a programmer who is not qualified. Secretary. CFO. Sysadmin. How would one judge a product manager? That there's no product? That it sucks balls? "We're soliciting feedback and finding product market fit, iterating, A/B testing, we'll be better next quarter, goto 1"

I wouldn't want that job, but I also don't currently know how to bring demonstrable evidence that they're incompetent, either

I have roughly the same opinion about UX folks, but they don't jam up my day to day nearly as much as PMs

replies(1): >>44995284 #
2. sigotirandolas ◴[] No.44995284[source]
My only answer to this is, the ones at the top up to the CEO must be mindful enough to realize this, smart enough to figure out a solution, and brave enough to act on it.

Otherwise, it's a matter of time until the house of cards falls down and the company stagnates (sadly, the timescales are less of a house of cards, and more like a coal mine fire).