There are countless reasons why AI-assisted coding tools like Claude Code, Codex, Cursor, Windsurf, etc. are amazing. They’ve virtually removed the barrier that once existed to starting coding and turned what used to be hours of reviewing documentation into a conversation. Now you can go from a chaotic idea spinning in your head to a fully functional prototype in a matter of seconds, and a non-technical person no longer needs to enroll in a months-long course just to build what they have in mind.
These tools also have eliminated much of the hard work that developers never particularly enjoyed first of all. So while I’m a big fan of these tools (even though they literally jeopardize my future career), they’re also what turned me into something I never signed up for: a babysitter. That was until I started giving Claude Code a persistent goal instead of step-by-step directions, and I was finally able to stop babysitting.
Do you want to stay up to date with the latest in AI? The XDA AI Insider newsletter is published weekly with deep dives, tool recommendations, and practical coverage you won’t find anywhere else on the site. Subscribe by Modifying your newsletter preferences.!
This is what an average coding session turns you into
I was the loop
If you’ve been keeping up with the memes and TikToks that have been popping up lately, you’ve probably seen at least one post about someone walking around with their laptop open just so they can keep an eye on what their coding agent is doing. Many times, it’s to prevent the screen from closing and Claude Code (or whatever agent they’re running) stopping mid-task, waiting for a permission message that no one is there to approve.
Other times, though, it’s to catch the agent the moment he starts heading in the wrong direction, before he burns through twenty minutes and a stack of chips confidently builds the wrong thing. And while I haven’t gotten to the point where I’m walking around with my laptop open in my hand, I’ve found myself course-correcting one too many times.
For every assignment I turned in, I’d hover over the terminal, watch it work, catch it the moment it went off track, and type some version of “no, not like that” until I got there. Other times, I would sit there waiting for a pass to finish so I could run the tests myself, read what failed, paste in the errors, and send it off for another round. Given how terrible usage limits are nowadays, this back and forth would end up significantly eating into my session limits (despite being on the Max plan).
Believe me, I tried everything. I made sure each message was as detailed as possible, anticipating every constraint and edge case I could think of so it wouldn’t go off track in the first place. One of the biggest pieces of advice from Anthropic engineers has been to consistently give Claude a way to check his own work, whether through the Claude extension in Chrome or a suite of tests he can run against himself, so he can catch his own mistakes instead of waiting for me to catch them. Despite trying that, Claude Code checking his own work and me checking the result would always get different results and eventually I would find myself in exactly the same situation as before.
The /goal command was the only thing that finally closed that gap
Runs the loop so you don’t have to
Anthropic released the /goal command in May, and if you weren’t paying close attention, you may have simply ignored it by labeling it as “just another slash command,” just like I did. However, it turned out to be the only thing that really got me out of the cycle I was stuck in.
This is what it does. Typically, Claude Code performs one pass, stops, and returns control to you. With /goal, you set a condition and Claude continues working until that condition is met or until you manually stop him. However, the model that performs the work does not verify the condition. A smaller, independent model reads the session transcript after each pass and decides one thing: whether the condition has been met. If not, the cycle continues. (I went into the full mechanics of how that evaluator works in a separate piece if you want more details).
That verification step is exactly what I’ve been doing manually all along. I was the one who read each result, decided if it was good enough, and wrote “keep going” or “no, not like that” until I got there. The /goal command took that away from me completely. I set the condition once and Claude took care of the back and forth on his own instead of stopping to serve me each round.
So what does this actually look like in practice? anthropic lists a handful of use cases in its support documentationand they all share one trait: a goal line that a second model can really mark. Migrate a module to a new API until each calling site builds and passes tests. Split a large file into smaller modules until each one is under the budget size. Work on a backlog of tagged issues until the queue is empty.
What they all have in common is a real, measurable end state, which is exactly what the condition needs. Anthropic recommends building yours around three things: a measurable final state (a test result, a build exit code, an empty queue), an established check for how Claude should test it (“the npm test exits from 0”), and any constraints that it shouldn’t change along the way (“no other test files are modified”).
Using the /target command is as simple as typing /target followed by the condition you want to meet. There’s no separate message to send afterwards, and setting the objective starts the first turn on its own. A small indicator shows you how long it has been running while it works.
I’m sorry I ignored the /goal command for so long.
Given how quickly Anthropic (and all the other AI labs) have been removing features lately, it’s incredibly easy to glance at a release post and assume it’s just another minor update. That’s exactly the trap I fell into with /goal, only for it to turn out to be the only feature that really changed the way I work.
