| ▲ | swader999 4 hours ago | ||||||||||||||||||||||||||||||||||||||||
On Claude if you start with that, it won't stop until it achieves or exhausts your prompt. It feels like "here's your mission, go do it". I use it a few times a week. | |||||||||||||||||||||||||||||||||||||||||
| ▲ | brap 3 hours ago | parent | next [-] | ||||||||||||||||||||||||||||||||||||||||
> won't stop until it achieves or exhausts your prompt This is overselling it. In all implementations of this that I’ve seen, a more correct phrasing is “won’t stop until it pinky-promises it achieved your goal”. It usually relies on something like a hook that refuses to let the agent stop unless it includes a “promise sentinel”, which is basically the model having to include “I swear I’m done” in the response (usually as a Markdown comment so the user doesn’t see it). If that sentinel isn’t in the response, the hook rejects the completion and hands it back to the agent (sometimes it also restates the goal to keep it focused). It’s useful for sure, but it fails many times for obvious reasons. More robust implementations use the hook to spawn another agent that verifies the goal is achieved, but that too isn’t prefect and sometimes performs worse. Of course if you have a problem that can be deterministically verified, you could have the hook run this verification instead, but this is usually not the case (and even when it is, agents will often cheat the verification e.g. by deleting a test file). | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
| ▲ | 9dev an hour ago | parent | prev | next [-] | ||||||||||||||||||||||||||||||||||||||||
I'm way too afraid of a "paperclip problem"-style target overfitting to use it really; how could I even describe a goal so well it doesn't sacrifice other things that are important to me? Like, if my goal is to make an endpoint faster, will it create an over-engineered mess out of the clearly readable code I have to reach that goal? | |||||||||||||||||||||||||||||||||||||||||
| ▲ | jascha_eng 3 hours ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||||||||
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? | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||