Thats fine but then Fable 5 should have requested this information instead of blundering along. So why didn't it? An expert human asked to do the same task would have surely asked for the additional data.

▲

sideeye 8 hours ago | parent | next [-]

That's what I add at the end of my prompts: "Ask me questions on anything that's not clear related to this task" or similar. Both the CLI and the VSCode plugin have a nice interface designed for this, asking the user questions.

▲

aurareturn 9 hours ago | parent | prev | next [-]

No one said Fable 5 is human.

That's like saying Fable 5 should have told me how to prompt it to solve the Riemann hypothesis like Terence Tao would. The skill of the user still matters.

▲

dwaltrip 6 hours ago | parent | prev | next [-]

Sure, but it didn't. And you get way better results if you do that, so do that.

▲

bmurphy1976 5 hours ago | parent | prev [-]

Let me translate this for you:

"I have not spent the time cultivating the soft skills necessary to leverage this tool successfully therefore it's the tool that sucks."

▲

lilbigdoot 4 hours ago | parent | next [-]

No one in this chain said it sucks. Any sort of criticism towards LLM workflows is constantly met with these kinds of absurd statements. I've never seen any other tool with this kind of mentality from proponents

	▲	3 hours ago \| parent [-]
		[deleted]

▲

sirsinsalot 4 hours ago | parent | prev [-]

Even if true, this kind of response is unhelpful and fosters dismissal of your point. This kind of attitude more broadly paints AI advocates as cultists because they refuse to engage beyond "you're doing it wrong".

How about give pointers on "doing it right?"

▲

bmurphy1976 3 hours ago | parent | next [-]

My comment is dismissive because the parent comment is also dismissive. But you are right, advice is helpful. It's in my comment, but it may not be obvious to everybody, so here it is:

Work on your project management, communication, and mentorship skills. The AI tools are much more like a team of sloppy but capable junior engineers and not a reliably consistent fabrication machine. Change your perception that one simple prompt is going to magically solve a hard problem the first time. Learn to break projects down, organize them into sub-projects, and implement them in steps. Learn to communicate more clearly, define your requirements more rigorously, and adapt around your "team's" strengths and weaknesses.

We want these things to be rigorous and flawless but reality is messy just like working with a regular team of engineers. They are good at some things, terrible at others, constantly changing, and unreliable. But we've historically built tons of reliable software on unreliable actors by focusing on process, collaboration, and communication.

AKA, not just the hard technical skills, but the soft skills that allow unreliable software teams to thrive. They don't know what they don't know and it's your job to manage that.

▲

lilbigdoot 4 hours ago | parent | prev | next [-]

Exactly. I'm a huge FP fan. When someone doesn't like FP I don't lecture them on how they're holding it wrong. I usually assume that, unsurprisingly, the tool doesn't suit every problem or there may be a design issue in the tool they ran into

	▲	fn-mote 2 hours ago \| parent [-]
		> I usually assume that […] the tool doesn't suit every problem My expectation: inexperienced FP is trying to shoehorn a mutation-based approach into a framework that performs best with immutable data, or is manually recreating familiar structure (for loop) instead of using the idiomatic way. But what do you tell someone in this case? They really need to learn more about the basics. Which is how I am interpreting the GGP’s dismissive-sounding comment.

▲

redsocksfan45 3 hours ago | parent | prev [-]

[dead]