TechnicalOpinion

When NOT to use /goal in Codex

How I AI

This transcript explains when not to use the /goal command in Codex, outlining three scenarios where it is inappropriate. It also defines the three key properties that make a goal well-suited for the tool: a durable objective, an evidence-based finish line, and a multi-turn path.

Summary

The speaker opens by cautioning that /goal is not a universal tool and should not be applied to simple, one-line edits. The reasoning is that /goal is designed for outcomes rather than outputs — it is too heavy a mechanism for trivial tasks.

The speaker then identifies vague or unmeasurable objectives as another poor fit for /goal. Examples given include 'make my customers happy' and 'refactor this code,' both of which lack a clear, definitive completion condition that can be reliably measured. Without measurability, there is no way to confirm the goal has been achieved.

Finally, the speaker outlines the three properties that make /goal most effective: (1) a durable objective that remains steady over time, (2) an evidence-based finish line that can be measured, and (3) a path that requires multiple turns of investigation to complete. When all three properties are present, /goal is the right tool for the job.

Key Insights

  • The speaker argues that /goal is too large a tool for simple, one-line edits, emphasizing that it is designed for outcomes rather than outputs.
  • The speaker claims that vague goals like 'make my customers happy' are poor candidates for /goal because they lack a reliable, definitive completion condition.
  • The speaker identifies 'refactor this code' as a bad example for /goal, implying that goals without measurable endpoints are not appropriate for the tool.
  • The speaker states that /goal works best when the objective is durable — meaning it stays steady over time rather than shifting during execution.
  • The speaker argues that /goal is strongest when reaching the objective requires multiple turns of investigation, distinguishing it from tasks solvable in a single step.

Topics

When not to use /goal in CodexProperties of a well-formed /goalOutcome vs. output distinction in goal-setting

Transcript

[0:00] Goals are not the right tool for every job. Do not use goal for something that is a very simple one-line edit. It is just too big of a tool for the job. Your goal wouldn't be like, "Make sure this line of code is removed." You really want an outcome, not an output, almost, for it to be a good goal. Also, don't use a goal when the finish line is vague. If you're like, "{slash}goal make my customers happy." I think that is just a very vague goal. It's very hard to measure, and there's no reliable, [0:30] definitive completion condition. And so, that's not very good. The other example they give is like, "Refactor this code."…

Full transcript available for MurmurCast members

Sign Up to Access

More from How I AI

Get AI summaries like this delivered to your inbox daily

Get AI summaries delivered to your inbox

MurmurCast summarizes your YouTube channels, podcasts, and newsletters into one daily email digest.