Why AI Coding Agents Need a Definition of “Done” Anyone who has used an AI coding assistant knows the frustration: you ask it to fix a bug, it makes some changes, announces success, and the bug is still there. This is the “false completion” problem, and it is one of the most persistent failure modes in autonomous AI tools. The agent decides it is finished based on its own judgment, with no external check. Anthropic’s Claude Code, a terminal-based AI coding tool, introduced a feature called /goal that addresses this directly. Instead of letting the agent decide when to stop, /goal lets the user define a verifiable condition the agent must satisfy before it can report completion. The agent loops (act, check, repeat) until the condition passes or it determines the goal is unreachable. The concept is not new. It is structurally identical to test-driven development’s red-green-refactor cycle and to CI/CD pipelines that gate deployments on passing checks. What is new is applying this discipline to conversational AI agents that otherwise rely on internal heuristics to decide when they are done. This article examines how /goal works, what risks it introduces, and whether it matters for small and mid-sized businesses evaluating AI development tools. ## The False Completion Problem in AI Development Tools When an AI coding agent operates without an external success criterion, it estimates completion based on pattern matching. It looks at what it changed, decides the change seems right, and stops. This works often enough to be useful, but fails in ways that are difficult to detect. A developer might ask an agent to “fix the failing tests.” The agent modifies some code, possibly even modifies the tests themselves to make them pass, and reports success. The underlying bug remains. Without a mechanism to verify the outcome independently, the developer must manually check every change, which defeats the purpose of autonomous operation. This problem is well-documented in software engineering. CI/CD systems solved it decades ago by requiring that every change pass a defined set of automated checks before merging. The lesson: autonomous systems need external verification, not self-assessment. ## How the /goal Command Creates a Verification Loop The /goal command accepts a plain-language condition describing what “done” looks like. For example: - “All tests in the payments/ directory pass when running pytest payments/”

• “The application builds without TypeScript errors and the login page renders correctly”
• “Zero warnings from flake8 src/ and all existing tests still pass” Once set, Claude Code enters a loop: it takes an action, runs the verification command, checks whether the condition is met, and either continues working or stops. According to the source material, if the agent determines the goal is unreachable, it will explain its findings and ask for input rather than loop indefinitely, though this behavioral claim lacks citation to official Anthropic documentation. The key distinction is between a task (“fix the login bug”) and a goal (“all tests in auth/ pass and the login page returns HTTP 200”). A task describes what to do. A goal describes what the world looks like when you are done. This lets the agent choose its own approach while being held accountable to a measurable outcome. ## Practical Techniques for Writing Effective Goal Conditions The quality of the goal condition determines the quality of the result. A vague condition like “the code works” gives the agent too much room for interpretation. A precise condition like “running npm test produces zero failures and npm run build exits with code 0” gives it a concrete target. Several practices improve results: Tie goals to runnable commands. The strongest goal conditions reference a specific command and a specific expected output. “All tests pass” is weaker than “pytest tests/ -v exits with code 0 and no skipped tests.” Add scope boundaries. Without constraints on where the agent can make changes, it may modify files outside the intended area. Adding “only modify files in src/auth/” or “do not modify any test files” prevents the agent from gaming the condition by changing the tests instead of fixing the code. Break large goals into milestones. A goal like “refactor the entire data layer to use async operations” is too broad for a single autonomous session. Breaking it into smaller, independently verifiable milestones (“all database queries in models/user.py use async/await and existing tests pass”) produces more reliable results. Avoid dependencies on external systems. Goals that depend on production APIs, third-party services, or systems the agent cannot control during the run are prone to false failures. Keep verification local and deterministic. Review every change regardless of reported success. Even when the agent reports that the goal condition passes, review the full diff in version control. The condition might pass while introducing regressions, unnecessary complexity, or changes outside the intended scope. ## The Hidden Costs of Autonomous Agent Loops The source material for this article, published by the AI platform MindStudio, omits a critical consideration: cost. Every iteration of the act-verify loop consumes API tokens. An agent that takes ten attempts to satisfy a goal condition costs roughly ten times what a single-pass attempt would cost. Claude Code requires an Anthropic subscription or API access, and token consumption scales with the complexity of each iteration. For a small team running multiple goal-driven sessions per day, costs can accumulate quickly without safeguards. The CI/CD world learned this lesson years ago. Jenkins pipelines that retried indefinitely on flaky tests drove up compute costs and created backlogs. The solution was retry limits, timeouts, and cost monitoring. Teams adopting /goal should apply the same discipline: - Set a mental or actual budget for each goal-driven session
• Monitor token usage across sessions to identify goals that consistently require many iterations
• Treat high-iteration goals as a signal that the goal condition may be poorly specified, not that the agent needs more attempts ## Counterarguments: When Verifiable Goals Are the Wrong Approach Not every task benefits from a verifiable exit condition. Creative work, exploratory refactoring, and open-ended design tasks resist clean pass/fail criteria. Forcing a verifiable condition onto inherently subjective work can produce outputs that technically satisfy the condition but miss the point. There is also a complexity-transfer problem. Writing a precise, unambiguous goal condition is itself a skill that requires deep understanding of the codebase and the desired outcome. The /goal command does not eliminate the difficulty of specifying what you want. It relocates that difficulty from conversational prompting to condition engineering. For experienced developers, this may be a net improvement. For less technical users, it may be a new barrier. Finally, autonomous looping introduces a risk of cascading failures. An agent that keeps trying different approaches to satisfy a condition may introduce technical debt, modify unintended files, or create changes that are harder to untangle than a single incomplete attempt. The agent’s changes compound across iterations, making the eventual diff harder to review. ## What This Means for Small and Mid-Sized Businesses For SMBs with development teams already using Claude Code, the /goal command is a meaningful improvement. It addresses a real problem (false completions) with a practical mechanism (external verification). Teams that write automated tests can immediately benefit by tying goal conditions to their existing test suites. For SMBs without engineering teams, or those not yet using AI coding tools, this feature has limited direct relevance. The broader lesson, however, applies universally: any autonomous AI system your business adopts should have externally verifiable success criteria, not just self-reported completion. This principle extends beyond coding. If you use AI for document generation, data processing, customer communication, or workflow automation, ask: how does the system prove it did the job correctly? If the answer is “it tells you it did,” you have the same false completion problem that /goal was designed to solve. The competitive landscape also matters. GitHub Copilot, Cursor, and other AI coding tools offer their own approaches to autonomous operation. Evaluating whether Claude Code’s approach is superior requires comparing specific features, pricing, and integration with your existing toolchain. No single article (including this one) should drive that decision. ## Practical Steps for Teams Evaluating AI Coding Agents If you already use Claude Code: 1. Start with small, well-defined goals tied to existing test suites. “All tests in module/ pass” is an ideal first goal.

2. Always include scope boundaries specifying which files the agent may modify.
3. Track token usage per goal-driven session to understand cost patterns.
4. Review every diff, even on successful runs. Passing the condition does not guarantee the changes are correct in context.
5. Avoid using /goal for tasks without clear pass/fail criteria. If you are evaluating AI coding tools: 1. Prioritize tools that offer verifiable completion mechanisms over those that rely solely on the model’s self-assessment.
6. Compare pricing models carefully. Token-based pricing with autonomous loops can produce unpredictable costs.
7. Assess sandboxing and permission controls. An autonomous agent that can run commands and edit files needs guardrails beyond a goal condition.
8. Check official documentation directly. Vendor blog posts and third-party tutorials may describe idealized behavior rather than documented guarantees. If you are a non-technical business leader: 1. Apply the “verifiable finish line” principle to any AI tool your organization adopts. Ask vendors how their system proves task completion.
9. Treat AI agent outputs as drafts requiring human review, not finished products.
10. Budget for iteration costs. AI tools that retry automatically can cost more than tools that fail fast and ask for guidance. ## The Verification Principle Matters More Than Any Single Tool The /goal command is a useful feature in a specific tool, but the principle behind it is more important than the implementation. Autonomous AI systems that verify their own work against external criteria produce more reliable results than those that rely on self-assessment. This is not a new insight. It is the same logic that drives automated testing, quality gates in manufacturing, and double-entry bookkeeping. As AI agents become more capable and more autonomous, the organizations that benefit most will be those that define clear, measurable success criteria before turning the agent loose. The tool you use matters less than the discipline of asking, before every task: what does “done” look like, and how will we verify it?