[jascha_eng]

Is this useful? I feel like the problem is usually not that the model isn't capable of achieving what I give it, but the way it does it. Especially if originally I didn't 100% know how I would do it myself the model often takes weird paths through the code base, takes shortcuts that end up in weird feature interactions or pulls in a dependency without weighting if it could've been done without that.

I haven't really found a good way to solve this other than:

1. Produce an initial PR fulfilling all the requirements I knew at the start

2. Chat with the model about any weird snippets I notice and talk through alternatives

3. Simplify anything that I think is overengineered or plain unncessary

Sometimes I restart all over with more precise requirements but then it sometimes makes different mistakes/takes different shortcuts.

In practice the earlier I review the better the end result imo, so /goal seems very unproductive to me?

[swader999]

It's useful for things where it just needs to get through to completion. Long running tasks. I walk away and expect it to be done without pausing for input.

[jascha_eng]

Can you give an example? And more curious about what you do with the resulting code afterwards I imagine its gonna be a big chunk then?

[hungryhobbit]

I feel like "do X untill tests are green" is sort of the prototypical /goal case.

[madeofpalk]

Adding a new lint rule that a lot of code violates.

[jascha_eng]

And that doesn't work with a simple prompt?

[mh-]

It's just a way of defining what "done" means, and passing off evaluation of whether "it's done" is true to a separate context and/or model. If false, it prompts the original context accordingly.

[ubermon]

For some frontier models like Fable 5 it doesn't matter, but for models less trained on long horizon tasks it very useful.