Most coding-agent workflows still follow a relatively manual interaction pattern:

1. Describe a task.
2. Let the agent investigate and implement it.
3. Review the result.
4. Identify what is missing.
5. Send another prompt.

This works well for interactive development, but it introduces a coordination bottleneck for larger tasks. The agent can execute commands, modify files, run tests, and inspect results, but the developer still has to drive the process forward.

Claude Code's /goal introduces a different execution model: goal-driven iteration.

Instead of treating each model response as the end of a task, you define a completion condition. Claude continues working across multiple turns until the condition is satisfied, judged impossible, or the workflow encounters an error that requires intervention.

The important shift is from specifying the next action to defining the expected end state.

What Claude Code /goal actually does

The /goal command establishes a completion condition for the current Claude Code session.

When you activate it, Claude starts working on the goal immediately. At the end of each turn, a separate evaluator model assesses whether the stated condition has been satisfied.

The evaluator can return three outcomes:

• Not yet met: Claude continues working and uses the evaluator's feedback to guide the next turn.
• Met: The goal is considered achieved and the loop terminates.
• Impossible: The evaluator determines that the condition cannot be satisfied, and Claude clears the goal.

Certain unrecoverable errors also require the goal to be cleared so the developer can address the underlying problem.

Conceptually, the execution loop looks like this:

Goal → Execute → Evaluate → Continue or Stop

This is more than a longer conversation. The completion condition becomes part of the session's execution lifecycle.

An important implementation detail is that the evaluator is not an independent test runner. It evaluates the condition against the conversation and the evidence Claude has surfaced. It does not independently execute commands or inspect repository files.

That distinction matters. Claude still needs to run the relevant tests, inspect the output, and report the results. The evaluator judges whether the available evidence demonstrates completion.

The quality of the loop therefore depends heavily on the quality of the verification process.

The difference between a task and a goal

A conventional prompt usually describes an activity:

"Refactor the billing service."

That leaves several questions unanswered:

• What exactly should change?
• Which interfaces must remain compatible?
• Which tests must pass?
• What constitutes complete coverage?
• When should the agent stop?

A goal should describe an observable end state.

For example, a billing-service migration could have these completion criteria:

• All relevant modules have been migrated.
• Existing public interfaces remain compatible.
• The unit and integration test suites pass.
• Type checking and linting complete successfully.
• No legacy implementation remains in the target scope.
• No unrelated modules have been modified.

This gives the agent a concrete target and a way to demonstrate progress. You should structure most engineering goals around three elements:

1. Expected outcome - Describe what should exist or be true when the work is finished.
2. Verification - Specify which commands, tests, or checks establish that the expected outcome has been reached.
3. Constraints - Define what must not change, which areas are in scope, and what limitations apply to the execution.

This is particularly important for tasks that span multiple modules or require several implementation and verification cycles.

The control loop is more important than the prompt

There is an interesting distinction between autonomous execution and reliable autonomous execution.

An agent can continue making changes without human intervention and still produce an incorrect result.

For example, a successful build does not establish that business behavior has been preserved. A passing unit test suite does not establish that integration behavior is correct. A clean linter does not establish that an implementation meets the original requirements.

The control loop needs feedback that is relevant to the actual task. For software development, this usually means combining:

• Unit and integration tests.
• Static analysis and type checking.
• Build and compilation results.
• API or contract validation.
• Regression tests.
• Git-based checks to identify unintended changes.
• Browser or end-to-end verification for user-facing features.

The more observable the result, the easier it is for the agent to evaluate its own progress.

For deterministic requirements, I would go a step further and use scripts, CI checks, or Claude Code Stop hooks. These can enforce conditions that should not depend solely on a model's interpretation of terminal output. This leads to an important engineering principle:

Use the model to make decisions and deterministic checks to enforce requirements wherever possible.

The evaluator helps manage continuation. It should not replace a proper test and validation strategy.

/goal does not automatically mean unrestricted autonomy

Another important distinction is between the execution loop and tool permissions.

Claude Code's /goal controls whether the agent continues working across turns. It does not automatically grant permission to execute every command or modify every file.

For unattended execution, /goal can be combined with Claude Code's Auto mode, which handles tool approvals within the configured permission model.

These are separate concerns:

• /goal determines whether more work is required.
• Auto mode determines how tool approvals are handled.
• Skills and hooks provide reusable workflows and lifecycle controls.
• Scripts and CI provide deterministic validation.

Combining these primitives is considerably more useful than relying on a single large prompt.

There is also a practical cost consideration. Every additional turn involves more model activity, and the evaluator introduces additional usage. Claude Code exposes goal status, evaluated turns, token consumption, and the evaluator's latest reasoning through /goal without arguments.

Goals should therefore have explicit time or turn boundaries. A condition can include a stopping clause, such as stopping after a specified number of turns.

This prevents an agent from spending an unreasonable amount of time attempting to satisfy an ambiguous or fundamentally unachievable condition.

The GitHub Copilot alternative: Autopilot

GitHub Copilot offers a closely related workflow through Autopilot mode, available in GitHub Copilot CLI and the Copilot app. In Copilot CLI, you can activate it through the /autopilot command or switch modes using Shift+Tab.

Autopilot allows Copilot to work through successive model interactions without waiting for another prompt after every step. It can:

• Implement changes across multiple files.
• Execute commands and run tests.
• Evaluate the results.
• Modify its implementation based on failures.
• Continue iterating until it determines the task is complete or reaches an execution limit.

For complex tasks, GitHub also supports a plan-first workflow. You can begin in Plan mode, review the proposed implementation, and then move into Autopilot execution.

This is a useful pattern because it separates two different engineering activities: deciding how the change should be implemented and allowing the agent to execute that plan.

How does it compare with Claude Code?

The two approaches solve a similar orchestration problem, but they should not be treated as identical implementations.

Claude Code /goal

• Establishes an explicit completion condition.
• Uses a separate evaluator model after each turn.
• Provides feedback when the condition is not yet met.
• Supports explicit turn or time boundaries.
• Evaluates completion based on evidence surfaced in the conversation.

GitHub Copilot Autopilot

• Enables autonomous continuation through successive model interactions.
• Supports implementation, testing, and iterative correction.
• Can be combined with Plan mode.
• Provides configurable continuation and AI-credit limits.
• Separates autonomy from tool permissions.

One additional feature is worth distinguishing: Copilot's /delegate sends work to the Copilot cloud agent. Unlike local CLI Autopilot, the task runs remotely, creates a branch, and can produce a draft pull request while you continue working elsewhere.

That is a different form of delegation, rather than a direct equivalent of Claude's /goal evaluation loop.

The practical comparison is therefore:

• Claude /goal is particularly interesting when the completion condition itself is central to the workflow.
• Copilot Autopilot provides a comparable iterative execution experience within the GitHub Copilot ecosystem.
• Copilot /delegate is useful when the work should move into a remote background workflow.

When should you use these workflows?

Not every coding task benefits from autonomous execution. For short, well-understood changes, an interactive session is usually more efficient. There is little value in introducing additional evaluation cycles when the task can be completed and reviewed in one turn.

Goal-driven execution becomes more useful when:

• The implementation spans multiple files or components.
• The task requires several rounds of testing and correction.
• There is a clear acceptance criteria set.
• Progress can be measured through executable checks.
• The work can continue without frequent architectural decisions from a developer.

It is less appropriate for open-ended exploration, ambiguous requirements, or tasks where important decisions require human judgment throughout the process.

In those cases, a better workflow is to use the agent interactively to clarify the problem, develop a plan, and establish acceptance criteria before enabling autonomous execution.

Human review remains necessary regardless of which tool performs the work. The final diff, test results, and unintended side effects still need engineering review.

The engineering takeaway

The evolution of coding agents is not simply about making models better at writing code. It is also about improving the systems that orchestrate them. A useful autonomous workflow needs a clearly defined target, reliable feedback, bounded execution, and an explicit stopping condition.

Claude Code /goal makes this control-loop approach available directly within a coding session. GitHub Copilot Autopilot offers a comparable way to reduce manual orchestration during multi-step development tasks.

Both are useful steps toward a more autonomous development workflow, but autonomy alone is not the measure of success.

The real objective is to reduce manual coordination without reducing engineering confidence in the result.

References and further reading

1. Anthropic – Keep Claude working toward a goal
2. Anthropic – Loop engineering: Getting started with loops
3. GitHub – Using Autopilot mode in GitHub Copilot CLI
4. GitHub – Allowing Copilot to work autonomously
5. GitHub – Delegating tasks to Copilot
6. Using goal in Claude Code for autonomous workflows

Since I’m currently working on equipping my home with solar panels, I found the lack of a proper calculator quite strange. There are a few calculators developed and owned by companies selling solar panels and systems, but they tend to be overly optimistic in their calculations. Also, when you start looking at more complex systems with an EV charger, batteries, and a heat pump, I found that even the sellers struggle to provide proper answers.

So, as a side project, I decided to vibe code an application to help others. For now, it only works for Croatia: Solar Web

How

I started coding with Google Gemini models using a prepaid plan. There is no subscription; instead, you add money, get an API key, and use it from VS Code. This is also the most expensive way to do it, since there are no included tokens and you are charged directly as you use them. I also had quite a few issues with the availability of the Gemini 3.1 Pro model, and most of the time I ran into availability errors.

I also found the Gemini models not to be particularly good for coding, so I switched to GitHub Copilot. I needed a subscription anyway for other things, so I decided to try it on this project as well. At that point, the project was not quite finished: the UI was there, but the calculations were only around 50% implemented or correct.

It took quite a few iterations. At the moment, my repository has 56 commits, which roughly means 56 iterations with the model to fix something, since each iteration I completed ended up as a PR. The project is still very much a work in progress.

To be honest, most of those iterations went into a strange bug where my Azure Function was not being deployed to Azure. In the end, it was fixed by completely excluding tests from the Function App build. It took quite a bit of time before any of the models could figure it out. In the end, it was GPT 5.6 Luna - the cheapest of all the models I tried that found the solution.

Something else also changed during the process. I started with VS Code, my dev container, and all the tools I usually have when developing at work. But with each iteration, I started using the GitHub Copilot App more and more, and by now I barely look at the code at all. I rely on tests written based on my requests, the CI/CD pipeline, and visual testing of the deployed application.

There are also two additional reasons why the Copilot App works particularly well for me:

1. Mobile app – Since I do most of my hobby projects in the evening, when I also have other family obligations, the ability to steer Copilot from my mobile phone is extremely convenient.
2. Agent merge – With this functionality, you can hand over the full PR lifecycle to your agent. It can check build failures, fix them, and even approve the PR once everything is green.

Of course, this can work well for a hobby or demo application, but the more critical the application, the more important human review, local validation, security review, observability, and operational knowledge become.

The first problem is that I now have very little idea about the quality of the code itself. My frontend development days ended a long time ago, around the time of jQuery and HTML 4, so I do not have much expertise in the modern frontend stack anyway. My own code review would therefore not add much value.

There are, of course, tools on the GitHub platform that can help with this, such as Code Quality and Copilot code review. However, since this is a hobby repository on a free tier, these features are not available to me out of the box. They would probably help me get more confidence in the code quality, but I have not used them yet.

The second problem is that my Copilot App environment does not have all the tools needed to build or validate the code locally. This means that some build issues are only discovered after I push the code and the pipeline runs. This way of working is slower and consumes more tokens, but I did not have the time to improve the setup - maybe that will be the topic of the next blog post.

Lessons learned

So, can you really vibe code an app? My answer is yes, but with an important qualification.

I was able to build a working application without manually writing most of the code, and for a hobby project, this approach can be surprisingly effective. But I did not eliminate the engineering work; I moved it somewhere else. Instead of spending my time implementing the UI and business logic, I spent it describing requirements, reviewing results through tests and deployed builds, investigating failures, and deciding whether the application was actually doing what I expected.

The biggest lesson for me is that the better your validation loop is, the further vibe coding can take you. Tests, CI/CD, visual validation, and a production environment effectively became my code review process.

At the same time, I am much less confident about the quality of the underlying code than I would be with a traditional development workflow. For a hobby application, that is a trade-off I am happy to make. For something where correctness, security, maintainability, or reliability really matter, I would not trust the same process without much stronger human review and validation.

In other words, vibe coding did not make software engineering disappear. It changed the part of engineering I spend my time on - from writing code to defining what the code should do and proving that it actually does it.