What's easier to use as inspiration for coming up with a list of requirements?:

1. A blank sheet of paper

2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?

ben_w 23 minutes ago | parent | next [-]

> 2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?

Definitely this. I've had plenty of useless meetings with no helpful outcomes that lasted an hour with 6 or more people in them, and a few of them will have had more than $4 spent on snacks, let alone everyone's wages.

That said, poor communication will always get you no matter what: had one day spent going back and forth with a client, they kept saying they wanted a button "wider" each time around, I ended up making it full screen width and they still said "wider", asked them to draw a picture and they finally said "wider vertically". That may or may not have been faster with an LLM, depending on if the LLM ever thought to ask the client to draw what they meant, but fundamentally would have been exactly the same problem.

	▲	tarsinge 4 minutes ago \| parent [-]
		It goes beyond this, the job is to understand the underlying need. When a clients asks for a button to be bigger, what's in their head is they fear it's not visible enough. Many times the client was happy when I implemented something unrelated but that solved the issue, like changing the colours to increase the contrast between the background and the button, adding space around, etc. so that it pops out more.

▲

cryptonym a minute ago | parent | prev | next [-]

What's the most soul crushing?

▲

adastra22 29 minutes ago | parent | prev | next [-]

The latter, clearly? It is far more valuable to have a (badly) working system you can prod and probe than work from fantasy.

▲

flyinglizard an hour ago | parent | prev | next [-]

People are much better than saying what they don’t like than what they do.

	▲	bergen 32 minutes ago \| parent \| next [-]
		Using the "let run multiple agents run amok" approach you surely get a lot of "i don't like that part"-feature requests, yes. In my opinion, a good engineer is not good because he understands every single obscure technical detail, but because he can build solutions that the people using his technology actually want. The list of things they don't want on the other hand is endless.
	▲	pydry 5 minutes ago \| parent \| prev [-]
		Theyre also inclined to jump into talking about solutions rather than their actual problem which inhibits analysis of the problem.

▲

Terr_ an hour ago | parent | prev [-]

"Oh no problem, I'll just run it again telling the LLM to not do those 20 things, and then we'll have the right answer." /s-mostly

	▲	ben_w 16 minutes ago \| parent [-]
		It was pretty surprising to me when I realised I could put 5 different bug reports into the same message and it would fix all of them. Not quite as shocking as the original InstructGPT video, but surprising.