Intro

Today's subject is a new feature - /goal - recently released in Codex on April 29, and a few weeks later also in Claude Code. My focus in this article will be on its functionality within Codex, but everything discussed should apply in Claude Code.

/goal allows for long-running threads which iterate continuously until some completion condition is set.

Here, for example, is a "goal" set by Paul Novosad, a development economist at Dartmouth:

Is this a good "goal"? What makes a good goal in general? How well did this goal work? And what sort of tasks are most suitable to use with "goal"?

That's what we'll be discussing today - let's get into it.

What exactly is /goal?

I'm going to quote verbatim the first three paragraphs of this Codex documentation.

"Goals are persistent objectives in Codex that keep a thread working toward a defined outcome across turns. A Goal gives Codex a completion condition: what should be true, how success should be checked, and what constraints must stay intact.

Codex already works well for well-scoped coding tasks: inspect a repository, fix a bug, add a test, explain a failure, or implement a focused change. Goals are for tasks where the next step depends on what Codex learns along the way: profiling, patching, benchmarking, reproducing a flaky test, or turning a research question into an evidence-backed audit.

Those tasks do not need a bigger prompt. They need a persistent objective. With a Goal, Codex can keep the objective in view, evaluate whether the work is done, and choose the next useful action without you restating the target after every intermediate result."

I recommend separately reading this full documentation. It's quite well written. However these first few paragraphs should be sufficient for giving you an idea of what goal is.

The key phrase here is "persistent objective." A normal prompt asks Codex to do the next thing. A goal tells Codex what state the world should be in when it is done.

That distinction matters because many useful tasks are not a single step. Codex may need to run something, inspect the result, discover the next error, patch it, rerun it, and repeat. With ordinary prompting, the thread often stops after one of those intermediate steps. With /goal, Codex keeps checking whether the completion condition has been satisfied, and if not, keeps going.

So a good goal is not just a long prompt. It usually has three parts:

• the desired end state;
• the evidence Codex should use to decide whether that end state has been reached;
• the constraints that should remain true along the way.

Work with Aniket

Want help making Claude Code or Codex useful for your actual research?

I offer 1:1 sessions for economists who want help with a real project: setting up tools, improving a research workflow, turning repeated patterns into skills, or deciding when to use Claude Code vs. Codex.

I also run group workshops for departments, research centers, and institutions on agentic coding for economics research.

Book a 1:1 session
Discuss a group workshop

How economists typically work with agentic AI

When most economists work with agentic coding tools, they give individual instructions in a single thread towards some end they have in mind.

That end may be just inside their heads, or it may be written out in some document.

In any case, they themselves are determining what the appropriate next task is to run.

• Add the robustness tests suggested in this referee report to the master Stata file.
• Fix the formatting of the footnotes in Table 5.
• Turn this paper into a slide deck - take a look at this other deck for how I like to do things.

Part of the reason economists work like this is that it's important, as a matter of science, to understand each piece of your work internally. In the past, we'd think of ourselves as being focused on causation, whereas machine learning concerned itself purely with prediction. I think most would now agree this is a highly dated way to view things, but it was probably a correct characterization of most economists' opinions 15-20 years ago.

How important is /goal?

Is /goal a passing fad you can safely ignore, or is it something which you - as an economist - ought to be experimenting with now?

In my experience, the economics profession's adoption of AI and agentic coding tends to lag behind by 3-12 months what developers at the foundation labs are doing.

An explicit broader aim of the foundation labs is to automate their own R&D, and so achieve recursive self improvement. So, this focus on long running tasks, of which /goal is just the most recent, simplest implementation, is nothing new.

Will the labs achieve this, and if so - when will it occur? I don't know.

However, part of what signals to me that /goal is worth paying attention to is the response to /goal of developers who I respect.

Here are a few examples:

Thibault Sottiaux, OpenAI's Engineering lead for Codex (and the guy who decides when to reset Codex usage limits every time there's an outage), said the following:

Finally, I found indicative of the importance of this feature that Claude Code released it two weeks after Codex.

The fact that developers are finding goal important doesn't necessarily mean that it's going to be important for economists. As I'll discuss in the next section, if you can make it work for you, it could be very valuable. In the section after that I'll suggest some ways in which you should try making it work for you.

How I have been using /goal

I'm still experimenting with /goal, and I'm not sure yet that I have a perfect mental model around the situations in which to use it. I'll describe here, however, one way in which I used /goal recently.

A few weeks ago, I decided that I wanted to create a new site "aieconomist.io" explicitly dedicated towards AI for economists. Previously, everything had been on a single site "ai-mba.io", and I believe this created confusion to all who consume my content, because much of what is relevant to developers and business people is not relevant to economists, and vice versa.

In order to do this split, I had to think through - from a software perspective - what the ideal end state should look like.

• Should the two websites share the same design system, or have different ones?
• Should we keep the two websites united with a single database, or should I create a distinct database for aieconomist.io?
• Do I want to represent learning resources in exactly the same way on both websites, or do I envision distinct learning materials for economists with no analog on the "AI MBA" platform?

I deliberated over these and other questions over the course of a few hours in an iterative manner with Codex and Claude Code.

Eventually, I had these requirements clearly written in a document. At that point, I simply designated in Codex something like "/goal Do the migration specified in requirements.md."

About 6.5 hours later, the job was done. The front-end design still required significant tweaking and small fixes to my tastes, but the actual split of the sites and migration of materials was done flawlessly.

In the absence of goal, Codex would have stopped in this process at a much earlier point. However, with earlier models, Codex and Claude Code were insufficiently reliable to be able to do these long running tasks consistently.

Now - and perhaps even with earlier generations like GPT 5.4 - you can reliably trust the models to both stay on path and make good decisions along the way, enabling something like goal.

How economists should use /goal

Let's return now to Paul Novosad's use case from the beginning of this article. How well did it work?

In his opinion, quite well. How might we have improved his /goal setting?

In the aforementioned Codex docs, an example given of a "weak" research Goal is:

/goal Reproduce Buehler et al., "Deep Hedging"

The reason it's weak is that it's underspecified. What parts of the paper matter? What counts as reproduction?

The stronger Goal they give as an example isn't dramatically longer, but it is much more specific:

/goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

In general, if you're both thinking of what in your research could make sense as a "goal", and how to create the "goal" prompt, you can simply point Codex at the "Using Goals in Codex" docs and ask it to give you some ideas to tackle some aspects of your work as a Goal.

Here, however, are some concrete ideas:

• /goal Take this Stata package and reimplement it in Python. Write exhaustive unit tests and make sure all tests pass.
• /goal Take this referee report and make all changes to our codebase and paper to address the referees' points one by one. Where the referees disagree, make the strongest possible argument that addresses both of their concerns. Create additionally a response to each referee which includes specific line numbers and results from the updated draft.
• /goal I want to study the effect of X on Y. In order to do this, I want to see if there's any variation I can employ generated by the timing of the rollout of X. I want you to go state by state, searching on the Internet across news articles and regulatory documents, and see if you can find any dataset I'd be able to acquire, scrape, or request, and an identification strategy to tackle the question. Create individual LaTeX PDFs for each state and one master PDF with everything compiled.

These goals are imperfect. They're directional ideas I came up with on the fly, and I'd likely go through a round of revision with Codex's assistance before "letting them loose." Try them out (or an improved version) yourself - see if they work for you, and let me know how it goes!

Briefs

A few other interesting tidbits from the AI/econ sphere.

Andy Hall on the politics of jobless prosperity

Andy Hall (Stanford GSB) has a new piece on the politics of jobless prosperity in an AGI world. He argues that AI hasn't really greatly affected labor markets yet (or at least not broadly beyond specific sectors), but once it does (for him, a 2% increase in unemployment), he anticipates the backlash to be "broader and stranger" than the displacement, and speculates on what sort of political outcomes to expect.

• His X thread: https://x.com/ahall_research/status/2054578863137755447
• His Substack article: https://freesystems.substack.com/p/the-politics-of-jobless-prosperity

Alex Imas move to Google DeepMind

Alex Imas (University of Chicago) is my favorite economist to read on AI. You've probably already come across his excellent piece "What will be scarce?", but he's also recently announced that he'll be joining Google DeepMind as Director of AGI Economics. Congratulations to Alex, and a big signal that frontier labs are taking economics seriously!

Source: https://x.com/alexolegimas/status/2052778908882174302

arXiv takes action against AI slop

Thomas Dietterich, University Distinguished Professor at Oregon State and Chair of the CS Section at arXiv, announced that incontrovertible evidence of sloppy use of generative AI in arXiv submissions will result in a one-year arXiv ban. The reaction on X (look at quote tweets on the post) is mostly in favor of this change, but there is some opposition. The main argument against the change is that plenty of "human slop"/bad arguments make it to arXiv, so why discriminate specifically against "AI slop"? One could think that much of what is being submitted as "AI slop" would instead now be submitted as overall worse "human slop."

I don't have firsthand insight into what journal editors are actually facing, but it's certainly a tricky mechanism design problem to solve for.

Conclusion