How to Use /Goal to Do More With AI

The episode opens by contextualizing /goal within a broader trend toward reducing the turn-based interaction paradigm in AI. The host references a prior 'Codex Maxing' episode based on OpenAI's Jason Liu's techniques, which explored patterns like durable monothreads, voice input, and steering to make AI work more parallel and less dependent on constant human feedback. The /goal feature is presented as a natural evolution of these ideas—a primitive that allows users to define a finish-line outcome, after which the AI loops, self-evaluates, and stops only when the stated completion criteria are met.

The host traces the feature's emergence: Codex shipped it first, with team members like Tebow and Pavel Hurin hyping it as potentially the most consequential thing Codex had shipped. Andrej Karpathy's 'auto-research loop' and the earlier 'Ralph Wiggum loop' are cited as conceptual predecessors. Claude Code subsequently adopted the same feature and the same name (/goal), which the host frames as a mature recognition that participating in a new primitive is smarter than trying to own it. Microsoft's Nicholas Bustamante described the architecture as an initializer agent turning fuzzy intent into a structured plan.md, worker agents making bounded progress, and a judge agent evaluating whether the completion condition is genuinely met.

The host then defines what distinguishes a goal from a prompt: a goal is a 'finish line contract' specifying what should be true, how success is verified, and what must remain intact. Unlike a prompt that produces a single output for human review, a goal runs a continuous loop—working, checking evidence against the finish line, and deciding whether to continue, complete, or stop because no defensible path remains. The OpenAI guide identifies six components of a strong goal: the outcome, the verification surface, the constraints, the boundaries, the iteration policy, and the block-stop condition.

The episode addresses scope, noting a Goldilocks zone between goals that are too narrow (preventing discovery of upstream issues) and too broad (making it hard to define inspectable evidence of success). The quality of the output artifact is also flagged as critical—a vague artifact like 'write docs' produces weak evidence surfaces, while a specific artifact with defined structure and verifiable properties gives the AI something concrete to judge against.

The second half of the episode focuses on extending /goal beyond software engineering into knowledge work. The host argues that the key signal for a good goal candidate is whether the output is an audit rather than just an answer—a ledger of what was checked, supported, contradicted, and unknown. Ten knowledge work domains are identified as potential fits: literature reviews, market landscapes, vendor evaluations, due diligence, claim audits, policy research, interview synthesis, timeline reconstruction, spreadsheet audits, and strategy memos. Three are explored in depth with example goal prompts: claim audits (verifying memo claims against sources with a labeled evidence table), market landscapes (building a comparison table with confidence levels and evidence gaps), and literature reviews (producing a source matrix with confirmed themes, disputed findings, and open questions).

The host draws a distinction between externally definable rubrics and user-provided rubrics, arguing the latter will be more common in knowledge work—examples include hiring criteria, vendor scorecards, editorial standards, and investment diligence priorities. The episode closes by acknowledging that /goal is not always the right tool; many tasks are better served by traditional prompting, and the full spectrum of interaction autonomy remains relevant. The host encourages experimentation and promises a follow-up episode as more real-world non-coding use cases emerge.