How I Actually Run /goal Mode

First, what “goal mode” even is. Instead of walking the AI through a task one step at a time, you set a goal — a completion condition — and the model keeps working toward it on its own, checking its own results and continuing until the condition is met. Claude Code’s /goal documentation lays out the mechanics, and Codex has its own version. You set the destination; the model figures out the route.

Until recently, working with an AI meant a conversation — you ask, it answers, you ask again, and nothing happens while you’re not typing. Now I can hand off a goal and the model keeps working for a long stretch: pulling what it needs, building, testing, fixing, iterating across dozens of steps without me sitting there. The interaction stopped being a chat and became something closer to a job you submit and check on later. That shift is what puts “tell it what you want and step away” on the table at all — and it’s exactly why being deliberate about how you run it matters more now, not less. The more the AI can do unattended, the more it matters what you pointed it at.

There are two ways to get this wrong. One is to hand it all off and walk away. The other is the opposite — never letting go, correcting every line the model writes, babysitting every output until you’re moving slower than if you’d just done it yourself. I’ve been on both ends. The system I’m about to describe is what sits between them: I stay in control without being the bottleneck. It’s more work up front than typing one sentence, and that’s the entire point. Here’s how it actually runs.

The work moved earlier

The instinct with these tools is to start by talking to the model. The shift that changed how I work was starting somewhere else — with a specification the model works against, instead of a prompt it has to guess at.

I wrote about the mechanics of building those specs in Spec-Driven Development, so I won’t repeat the whole thing here. The short version: instead of describing what you want in a conversation, you build a small hierarchy of documents that define the project at multiple levels, and the AI references them — and evaluates its own output against them — as it works.

The raw material for my specs comes out of conversations. Working through a design, talking through reviews, going back and forth on what a feature actually needs to do. Those conversations get captured automatically into my note-taking system, and that captured material becomes the starting point for the specs. The talking is not separate from the building. The talking is the early part of the building.

From there, I end up with two layers. A master spec that tracks how the whole project is progressing — I read from it and write back to it as work gets done, so it’s a living map of where things stand. And individual feature specs that get into the details of each piece. You need both. The master spec keeps you oriented; the feature specs keep the model precise.

I spend real time here. Reading the specs, critiquing them, going back and forth until they actually say what I mean. It’s slow and it feels unproductive in the moment. Then I pin them off and let the model build against them — and that’s the fun part.

The tools keep getting better. The thinking doesn’t go away.

It’s worth saying that this gets easier every month. The tools that help you build specs and turn them into working software are improving fast. The Figma integration is a good example — I can click on a component, send it to whatever I’m building in, and the model will read that component and build out the pieces it needs in the app. A year ago that was a manual translation job. Now it’s close to a handoff.

But — and this is the part the demos skip — none of that removes the pre-work. The thinking that happens before any of this runs is still yours to do. The tools get faster at executing intent; they don’t supply the intent. If anything, the better the tools get at building, the more it matters that you’ve actually decided what you want.

Specs become issues

The first thing I do with a finished spec is turn it into GitHub issues.

This sounds like a small bureaucratic detail and it isn’t. Writing the work as issues — grouped into Epics — gives me trackability and an audit trail. I can see what was asked for, what got built, and what’s still open. When I tell the AI “go complete all of these issues,” there’s a record of every unit of work, not a vague conversation I have to reconstruct later. The issues are the contract between what I specified and what got shipped.

Here’s what one of those issues actually looks like, condensed:

Epic: Checkout

Issue #44 — Implement order creation on payment webhook

Tasks:

• Verify webhook signature; reject unsigned/replayed events.
• Dedup by event ID before processing.
• Create the order in one transaction; safe to run twice.

Acceptance criteria (from the spec):

• Two deliveries of the same event produce exactly one order.
• Unsigned request → rejected, nothing written.

Definition of done: tests pass, PR reviewed, merged.

Notice that the acceptance criteria came straight from the feature spec. That matters in a minute, because those same criteria are what the second model checks the work against.

The loop

Here’s the part that runs while I’m doing other things.

I give the goal to Opus 4.8 in goal mode: take these issues, use the spec, build it out. It grabs what it needs, works back and forth, and keeps going until the goal is met. Then Claude Code evaluates the work — fixes what’s broken, submits a PR, and keeps at it until it’s all done. That gets merged to main.

Then a second model gets involved. Every night, I have Codex look at the newly merged work and review all of it again — through its automations, on a schedule, without me. The next morning I come in to a fresh PR that addresses whatever the first pass with Claude missed.

So the shape of it is: one model builds, another model tears into the result. Two top-tier models, working against each other, on a loop. I’m not the bottleneck in the middle of it — I’m the one who set the specs and who reviews what comes out the other end.

None of this is free. As it stands, the setup runs me about $320 a month — $200 for Claude, $100 for Codex, $20 for Cursor. For that, I get a build-and-review loop that never sleeps and never complains. Set against the cost of shipping one insecure feature, it’s the cheapest part of the operation.

Why two models against each other

This is the piece I’d most want someone to copy, because it’s where the quality actually comes from.

A single model doing a single pass is one perspective. It’s confident whether or not it’s right. When you put a second model on the job specifically to critique and improve the first one’s work, you get something closer to an argument than an answer — and arguments surface problems that agreement hides.

This isn’t just my hunch. Researchers have found that when multiple model instances debate their answers across several rounds, the result “improves the factual validity of generated content, reducing fallacious answers and hallucinations.” And a separate line of work on using one strong model to judge another’s output found that these judges agree with human preferences over 80% of the time — about the same rate that humans agree with each other. A second model reviewing the first isn’t a rubber stamp. It’s a credible reviewer.

And it earns its keep. The morning PR caught security issues and general clutter — cleaning up the code and hardening the app before any of it went further. That’s not a cosmetic pass. That’s a second set of judgment finding the things the first pass was confident it had handled.

Why I don’t just say “build me an app”

I know the louder pitch right now is “describe it and ship it.” Build me an app, here’s what I want, off you go. I have yet to see that work in production.

For prototyping, it’s great. First passes, throwaway demos, proving out an idea — the one-sentence approach is genuinely useful. But the stuff I’ve seen built that way falls flat the moment you try to scale it or make it secure. And security is where this gets serious, because the failure is invisible. A large study of developers using an AI assistant found that they wrote significantly less secure code — and were more confident it was secure than the people working without one. That combination is the trap: the shortcut doesn’t just produce weaker code, it produces weaker code you feel great about. You don’t go looking for the hole because you don’t believe it’s there.

That’s why I stay with test-driven, spec-driven development. I want to know that what comes out works, that it’s safe, and that it isn’t quietly carrying a handful of vulnerabilities I’ll meet later. The system is how I keep that knowledge instead of outsourcing it.

The part I didn’t expect

You’d think that handing more of the building to the models would mean I understand my own work less. The opposite happened. I know more about what I’m doing now than I ever have — because to run this system, I have to think everything through in finite detail. I can’t approve what I can’t follow. To know it’s working, to know it’s safe, to know it’s the best it can be, I have to actually understand it.

The lazy path would have hidden all of that from me. “Off you go, AI” feels like getting ahead, but it’s really just not looking. The system makes me look. It requires planning and thinking through, in detail, what I’m actually asking for. Skip that step and your results will show it — every time.

So no, I’m not telling the AI what I want and walking away. I could. I just know what that costs. I’d rather keep the control, do the front-loading, and let two models fight it out over the details while I stay the person who understands the whole thing.

That’s the trade I’d make every time. Not because the shortcut isn’t real — because I’ve seen what’s on the other side of it.