Editor’s Note: This article is from OpenAI Developer Advocate Member Dominik Kundel, summarizing his experience with Codex’s “goal mode / /goal” feature. It discusses not just a regular prompt technique but a shift in the role AI programming tools are undergoing: Codex is no longer just a code helper responding to single-step instructions but is becoming an executive agent that can continuously drive towards a specific goal.

In /goal mode, the key is not to describe the requirements in great detail but to set clear and verifiable exit criteria for Codex. For example, “reduce deployment time by 30%,” “achieve 100% test coverage parity,” “lower LCP to below 2.5 seconds.” These metrics allow Codex to determine task completion and prevent it from endlessly trying in ambiguous objectives. At the same time, users need to provide sufficient guidance, tools, and a real environment for Codex to measure progress, validate results, rather than completing what seems like a feasible solution only in a local or hypothetical scenario.

The article particularly cautions that visual tasks are most likely to bog Codex down in details. Instead of demanding “100% pixel-level fidelity,” it is better to break down the visual goal into a functional list, design system specs, and evaluable metrics. For tasks lasting hours or even days, continuous tracking is necessary through commits, draft PRs, progress docs, Slack updates, or side chats to avoid ending up with a bunch of untraceable changes.

The incremental information in this article lies in redefining /goal as a “long-term task management mechanism.” When AI can run continuously for dozens or even hundreds of hours, developers’ core capability also changes: not just making AI generate code but setting goals for it, establishing a measurement system, configuring the execution environment, and ultimately conducting reviews and retrospectives. In other words, AI programming is transitioning from “writing prompts” to “managing a continuous-task engineering executor.”

We introduced the goal mode (/goal) to help you continuously drive Codex towards a specific outcome. Once you set a goal, Codex will work until the goal is achieved—whether it takes a few hours or a few days. Someone has already had Codex work continuously for over 120 hours on the same goal.

The Goal Mode is very powerful. To maximize its effectiveness, there are 7 things to keep in mind when using /goal.

Set Clear and Verifiable Criteria

The prompt word you enter when activating Goal Mode serves not only as an initial prompt but, more importantly, as the exit criteria for that goal. Codex will check after each work session: has this goal been achieved. Therefore, your goal prompt should not be overly verbose; instead, it should focus on a clear criterion: under what conditions can this goal be considered accomplished.

In most cases, a good goal should include a specific numerical indicator for the model to judge completion. For example: “Reduce build and deployment time by 30%,” “Migrate this feature from TypeScript to Rust and achieve 100% test coverage consistency,” or “Optimize the app scaffold to have the Largest Contentful Paint in production under 2.5 seconds.”

Provide Guidance Where Possible

A prompt like “Reduce build and deployment time by 30%” sounds cool and may allow Codex to come up with some creative solutions. However, if you already have a rough idea of where the issue might be, this type of prompt could lead Codex astray. Whenever possible, it’s best to tell Codex where to start the investigation, what tools can be used to achieve the goal, or provide other hints to prevent it from going down the wrong path.

Make Progress Measurable

If your goal is ambitious, or Codex has multiple ways to incrementally approach the target, it is crucial to equip Codex with tools to measure progress. For some tasks, this may be inherent. However, for other goals, it is advisable to brainstorm with Codex first: What tools help assess progress? Or provide it with some hints on how to confirm if it’s moving closer to the goal.

Creating a Realistic Environment

If you want Codex to make real progress towards its goal effectively, it needs to operate in a sufficiently realistic environment. In practice, this means that if you want to optimize deployment time or address latency issues, Codex should have access to deployment and testing environments that closely mimic the production environment. This involves using the same technology stack, similar configuration settings, and a comparable database.

Setting Visual Objectives Carefully

Giving Codex a visual objective, such as “reproduce this UI 100% pixel-perfect based on this image,” is indeed appealing. However, depending on the specific setup, this can also pose challenges. If you do not provide proper guidance and constraints, Codex may get lost in certain details, losing sight of the overall objective. Therefore, images are often more suitable as contextual goals rather than the sole completion criteria.

Tracking Progress

If Codex ends up working in the background for hours or even days, it’s easy to forget where it left off. Helpful strategies include having Codex commit code at key checkpoints, update a deliverable for management, proactively release progress updates to Slack, or using /side to start a new sidebar chat for quick status checks.

Cleanup and Final Confirmation of Results

Great, the goal is finally completed! Usually, especially in optimization-type tasks, I found it helpful to have Codex review and inspect its own work. Since Codex works continuously until the goal is met, it may have tried some less effective or even completely ineffective methods, and these residual changes may still be in the final code. Set a goal for your next task as well.

[BlockBeats]