Claude Code's output got dramatically better when I stopped letting it decide when it was done

Published Sep 21, 2026, 6:00 AM EDT Mahnoor Faisal is a tech journalist covering AI and productivity tools with bylines at XDA, SlashGear, MakeUseOf, Laptop Mag, and Android Police. She's been writing professionally since she was sixteen, and has since penned hundreds of articles. This includes in-depth coverage of AI tools like NotebookLM to breaking news across the AI space. Her passion for technology started when she received her first iPod Touch (4th generation) on her 8th birthday, and she's been deep in the tech world ever since. Currently pursuing a degree in computer science, Mahnoor brings both a journalist's eye and a technical foundation to her coverage of how AI is reshaping the way we work and learn. The days of being impressed when an AI spits out lines and lines of code that actually run are pretty much over. At this point, an AI being able to take a prompt, dig through a project, make the changes I asked for, and leave me with something that at least works is the bare minimum. However, something working and something actually being finished are two very different things. Claude Code can get surprisingly far on its own, but I’ve found that it’s often a little too eager to decide whether a task is done the second the main functionality works. This is why I’ve stopped letting Claude Code decide for itself when it’s finished. Instead, I’ve started giving it a much clearer finish line and making it prove it’s actually crossed it before calling a task done! I now give Claude a checklist it has to clear first Claude has to earn the green light Let's say you have an exam coming up that you've been cramming for. The best way to judge whether you're actually ready probably isn't to look at your notes, decide they seem familiar enough, and call it a day. You'd want some sort of concrete way to tell whether you've actually covered everything you need to. That's basically why we make checklists in the first place. Whenever I have a bunch of little things to get through, I'll usually write them down and tick them off one by one, because otherwise it's ridiculously easy to forget something and convince myself I'm done before I actually am. I've started treating Claude Code the same way! Instead of letting it decide that a task is finished simply because the main feature works, I now give it a checklist of things that need to be true before it can call the job done. Depending on what I'm building, that might mean making sure the project still builds successfully, running the relevant tests, checking for console errors, verifying the actual user flow, and going back through my original prompt to make sure nothing was unknowingly skipped. Rather than being extra instructions that Claude needs to follow while it's working, the checklist is essentially meant to be conditions it has to satisfy before it gets to stop. So, for example, I might end a prompt with something along the lines of: Make sure the project builds successfully. Run all relevant tests and fix anything that fails. Verify the feature actually works from start to finish. Check for any console errors or obvious regressions. Re-read my original request and make sure every requirement has been addressed. If any of these checks fail, fix the issue and run through the checklist again before calling the task complete. It's an incredibly simple addition, but it changes Claude Code's behavior more than I expected. Instead of reaching the point where the feature technically works and immediately handing control back to me, it has a reason to keep looking for the little things it would otherwise have left behind! I use /goal when a checklist isn't enough /goal gives Claude a finish line Sometimes, giving Claude a checklist doesn't quite do the trick, or is simply too much for the task at hand. Not every job needs a long list of conditions to clear before Claude can stop, especially when what I really care about is one very specific end result. That's where Claude Code's built-in /goal command comes in. I've written about /goal a few times now, and the biggest thing I've learned from using it is that it works much better when I stop treating it like another way to give Claude instructions. Instead, I use it to define the condition that needs to be true before Claude is allowed to call the task finished. So rather than giving Claude a sequence of steps and hoping it decides at the right point that everything is done, I can give it a goal like making sure a particular feature works from start to finish, or that a project reaches a certain state without any failing tests. Claude can then keep working toward that condition instead of handing control back to me the second it thinks it has done enough. It's also especially handy for the kinds of tasks where I don't necessarily know every step Claude will need to take beforehand. A checklist works well when I know exactly what I want verified. A goal works better when I know what the end result should look like, but I'm happy to let Claude figure out how to get there. Asking Claude to verify its own work does wonders Trust, but make Claude verify A tip I've been religiously following is one from Claude Code creator Boris Cherny: give Claude a way to verify its own output. The idea is if Claude can actually see whether what it just built works, rather than writing the code and assuming everything went according to plan, it has a chance to catch its own mistakes and fix them before handing the task back to you. This can look different depending on what I'm working on. If there are tests available, I'll ask Claude to run them once it's done and fix anything that fails. If I'm building something with a UI, I'll have it actually open the app in a browser and interact with what it just created instead of assuming that because the code looks right, the end result does too. I've found this makes a surprisingly big difference. There have been plenty of times where Claude has confidently told me something is finished, only for me to open it myself and immediately spot something that doesn't work quite the way I asked. Giving Claude that same feedback loop means it can catch a lot of those issues before I ever see them. I've also started explicitly asking Claude to go back through my original prompt once it's finished and compare what it built against what I actually asked for. It sounds almost too obvious to matter, but longer prompts are exactly where I've noticed little requirements have a habit of quietly disappearing along the way. Ultimately, verification is another way of taking the decision of when a task is finished out of Claude's hands! Whether I'm using a checklist, /goal, or simply asking Claude to double-check its own work, I'm the one deciding what "done" actually looks like now. That tiny change in how I work with Claude Code has made its output dramatically better. It still makes mistakes, of course, but far fewer of them make it all the way back to me.