Stop Giving AI Goals Like Build Me an App

When I use Codex or Claude Code for a while, I eventually catch myself repeating the same things.

“Keep going.” “Fix this too.” “Run the tests again.” “Update the docs as well.”

This is not happening because AI is slow. AI is already fast enough. The problem is that the human still has to keep deciding the next step.

I think I have handed the work to AI, but in practice I am still standing next to it. I check how far it got, notice what is missing, and give the next instruction.

The bottleneck has quietly moved back to me.

Delegating work to AI is not just handing over a task list. It is designing the condition for stopping.

That is where /goal becomes useful.

It is not just another prompt. It is closer to telling AI what state it should reach, so it can check, fix, and continue until the work matches that state.

The point of /goal is not to make AI do more work. It is to transfer part of the judgment about whether the work is actually done.

---

A Good Goal Describes the Finished State

People often write something like this:

/goal Build me an app.

This is a weak goal because no one can tell what finished means.

What is an app? Is it done when a screen loads? Does it need login? Should data be saved? Should there be no errors? Should tests pass?

When the goal is vague, AI usually does one of two things.

It stops too early, or it keeps circling around the work.

A better /goal looks like this:

/goal Fix the login flow until all login-related tests pass, lint succeeds, and the build completes successfully.

This is much stronger because the finished state is visible.

AI can check:

• Did the login tests pass?

• Did lint pass?

• Did the build succeed?

When the standard can be checked, AI can judge completion more reliably.

If I want AI to work for longer without constant supervision, I should not only tell it what to do. I should tell it when to stop.

---

What a Good /goal Needs

A useful /goal usually includes three things:

• What must be true when the work is done

• What must not be changed

• Which commands prove that the work is done

For example:

/goal Migrate the old writing flow to the new flow while preserving existing behavior. Do not delete or skip tests. Continue until pnpm test, pnpm lint, and pnpm build all pass.

With this level of detail, AI does not stop after changing code.

It checks the result. If something fails, it fixes it. If something is missing, it continues.

A good goal is less about what to do and more about what state counts as done.

The real skill is not writing a clever prompt. It is creating an environment where AI can tell whether it is finished.

---

/goal Is a Work Method, Not a Prompt Trick

The strength of /goal is not that one answer becomes better.

The strength is that after each step, AI looks at the current state again.

• Did a test fail?

• Did lint find a problem?

• Did the build fail?

• Is documentation missing?

• Is there still unfinished work?

If something is incomplete, it can move to the next step without the person typing “next” again.

For example, “refactor this” is unstable. AI does not know how far to go.

This is steadier:

/goal Merge the duplicated save logic into one path without changing user-visible behavior. Add tests so the same issue does not return, and continue until existing tests and lint all pass.

This goal has a finish line. It has boundaries. It has a way to verify the result.

AI needs those boundaries if we want it to act with any useful autonomy.

---

Bad Goals and Good Goals

A bad goal usually looks like this:

/goal Make the app better.

The problem is obvious.

There is no standard for better. There is no finish line. There is no way to verify the result.

That makes it easy for AI to widen the scope on its own. It may change the screen, change the structure, and touch unrelated files. The result may look more complete, but it is hard to know whether it actually became better.

A good goal looks more like this:

/goal Fix the settings page so users can see an error when saving fails. Add a test so the issue does not return, and continue until pnpm test and pnpm lint both pass. Do not change the page URL or server command structure.

This goal gives AI something it can judge:

• What problem to fix

• What test to add

• Which commands to run

• What must not change

The more work we delegate to AI, the more these standards matter.

---

The Method I Recommend Most

The method I recommend most is simple.

Do not write the /goal yourself first.

That may sound strange, but in practice it works better. People tend to write goals too loosely. AI, on the other hand, can read the project and often propose better goals for that specific codebase.

I usually start with something like this:

First inspect this project structure. Suggest three tasks that would work well as /goal assignments. For each one, explain why it is a good goal, what the finished state should be, what constraints should be kept, and which commands should verify it. End with a ready-to-paste /goal sentence.

This lets AI generate goal candidates that fit the project.

For a frontend app, that may include screen tests, lint, and build checks. For a Rust or Tauri app, it may include Rust tests and type checks.

The important point is not that I memorize every command.

The important point is that I make AI read the project first, then ask it to shape a good goal.

More important than writing a good /goal is knowing how to make AI produce one.

---

Where /goal Works Especially Well

/goal is not needed for every task. For a small change, a direct instruction is often faster.

But it works well when the task requires repeated checking.

For a larger cleanup:

/goal Replace all usage of the old helper function with the new helper function. Do not change user-visible behavior, and continue until all tests and lint checks pass.

For broken tests:

/goal Fix all currently failing tests. If there was a real bug, add coverage so it does not return. Do not delete or skip tests.

For documentation:

/goal Add examples to the public usage docs and remove outdated explanations. Also check that links inside the docs are not broken.

For repetitive editorial work:

/goal Add two relevant internal links to each of the 30 most recent posts. Do not add links that feel awkward in context.

These are the kinds of tasks where it is better to give AI the finish line than to keep typing “continue.”

---

Without Constraints, AI Finds the Easy Path

The riskiest part of long AI work is that the result can look complete without being correct.

If I only say “make the tests pass,” AI may remove a failing test.

If I only say “make lint pass,” it may weaken types.

If I only say “make the build pass,” it may route around the actual problem.

So a /goal should include constraints.

Useful constraints include:

• Do not delete or skip tests

• Do not change user-visible behavior

• Do not add new libraries

• Do not modify unrelated files

• Do not reduce type safety

• Do not hide a real issue with fake data

If we give AI autonomy, we also need to give it boundaries.

This is not about distrusting AI. It is about how delegation works. When we delegate work to a person, we also say what should not be touched and which standards should remain intact. AI needs the same kind of boundary.

---

Long Runs Need a Stop Condition

/goal can run for a long time. For larger work, I prefer to add a stop condition.

For example:

If this is not complete after 20 attempts, stop and summarize what remains and why it is blocked.

Even if the goal is not reached, AI has to organize the current state at a certain point.

This reduces the chance of repeating the same failure again and again. It does not remove failure, but it prevents failure from becoming an endless loop.

Good delegation needs both a completion condition and a stop condition.

---

Claude Code and Codex Feel Different

Claude Code and Codex can both work toward a goal over a longer session. The feeling is slightly different.

Claude Code often feels like it continues along a fixed goal. When used with an auto-approval mode, it can reduce mid-task confirmations and feel closer to handing off a block of work.

Codex often feels more like a cycle of planning, execution, and review. It reads the codebase, checks what remains, and moves into the next useful step.

But the important question is not which one is better.

Both are weak with vague instructions. Both are much stronger with goals that can be checked.

The quality of the goal matters more than the difference between the tools. If the goal is vague, even a strong tool moves vaguely. If the goal is clear, the tool becomes much more stable.

---

A Practical Template

The form I use most often is simple:

/goal [desired final state]. Done means: [condition 1], [condition 2], [condition 3]. Constraints: [things not to do]. Verify with: [command 1], [command 2], [command 3]. If blocked, stop and explain the exact reason.

For example:

/goal Stabilize the save experience on the publishing settings screen. Done means: success and failure states are clearly visible, repeated clicks on the save button do not create duplicate saves, and existing settings are preserved. Constraints: do not add new dependencies and do not change the server command structure. Verify with pnpm lint, pnpm test, and cargo test. If blocked, stop and explain the exact reason.

This is not beautiful prose.

But it is useful.

It gives AI a destination, a boundary, and a measuring tool.

The important thing is not making the sentence longer. The important thing is giving AI evidence it can use to judge its own work.

---

The Real Shift

/goal is not a magic button.

A sloppy goal still produces sloppy work. But if the goal includes a definition of done, verification commands, and clear constraints, AI becomes a much more practical working partner.

The core idea is simple.

• Do not explain the task endlessly.

• Define the state that counts as done.

• Reduce language that cannot be checked.

• Add constraints so AI cannot take the easy way out.

• When useful, ask AI to write the /goal first.

The reason humans still become the bottleneck in the AI era is that we often keep the judgment criteria in our own hands.

We think we delegated the work, but AI still has to come back so we can say “keep going,” “check this too,” or “not yet.”

A good /goal reduces that loop. Not because AI suddenly becomes smarter, but because the work has been reshaped into something that can actually be delegated.

In the end, /goal is not about writing a longer instruction.

It is about handing over part of the judgment about whether the work is done.

A good /goal is closer to a delegation skill than a prompting trick.

It defines what should exist, what should not be touched, and what evidence must be present before the work can be called finished.

That is when Codex and Claude Code stop feeling like code generators and start feeling more like working partners that can keep moving toward a goal.