From Prompt Engineering to Loop Engineering: Why /goal Beats Babysitting AI Agents

Most developers chasing a 10x productivity boost with AI optimize the wrong end of the conversation. They spend hours tweaking opening prompts, only to sit at their terminal babysitting the agent turn by turn.

That is Prompt Engineering: crafting the opening sentence and hoping the model lands the change in one pass.

To build JupiterGoals solo, I moved to Loop Engineering: designing the closed-loop environment, automated verification gates, and deterministic exit criteria that keep an AI agent iterating until a specification is proven complete.

Using /goal in both Antigravity CLI and Claude Code, I define the What in a living specification, set a quantifiable exit condition, and step away while the loop plans, implements, self-corrects, and verifies the code.

(Note: “Loop Engineering” refers to outcome-driven /goal loops in Antigravity CLI and Claude Code, not Claude Code’s separate /loop command, which is a recurring clock timer.)

The 5 Stages of AI Engineering

Over the past year, what I delegate to AI has evolved across five distinct stages:

In Stages 1 to 3, the human is the glue: copying snippets, fixing cross-file breakage, or babysitting terminal tool calls turn by turn.

Loop Engineering begins at Stage 4 (Spec-Driven SDLC). Once you have a permanent Living Specification with testable Acceptance Criteria and automated verification gates, you finally have an objective stopping condition for a /goal loop. Instead of babysitting turns, you run one /goal loop until that specification’s acceptance tests pass.

Stage 5 (Multi-Spec Loop Engineering) takes that exact same /goal loop and scales it horizontally: instead of running one spec at a time, multiple parallel clones work through an entire queue of specs concurrently.

The Golden Rule: Quantifiable Exit Criteria

Because an evaluator model decides whether the agent is allowed to stop, vague goals break /goal loops:

The Compaction Trap (And the Final-Turn Proof Rule)

Long /goal sessions inevitably trigger context compaction, compressing earlier turns into a summary. Because the /goal evaluator only reads the active transcript, test output from two hours ago gets lost in compaction.

The fix is one rule in AGENTS.md: name the verification command in the /goal, and rerun it on the final turn.

# 1. Start the loop with a measurable exit condition:
/goal Implement the onboarding spec and check until all spec acceptance criteria pass the test suite and static analysis exits 0.

# 2. On its final turn before stopping, the agent reruns the proof:
$ npm test && ./gradlew check
BUILD SUCCESSFUL - 42 passed, 0 failed (exit code 0)

What the Loop Automates vs. What You Own

Combining Living Specifications, pre-commit gates, and /goal loops leaves a clear boundary between machine execution and human judgment:

The green loop automates spec seam reviews, task breakdown, multi-layer coding, and self-correction against unit tests and static analysis.

As the engineer, you own three high-leverage jobs:

1. Write the Specs (The What and Why): Agents do not know your customers or product vision. You define the rules and testable Acceptance Criteria.
2. Set the Quantifiable /goal (And Maintain Gates): You define binary exit proofs. When an agent makes a class of mistake twice, you add a pre-commit gate so no future loop can repeat it.
3. Read and Verify the Output: When the loop exits, the agent produces a Customer Journey Walkthrough listing autonomous design decisions and a manual test script. You review the decisions and test the real UX in your browser.

How to Start Today

1. Write 3 to 5 testable Acceptance Criteria in your spec and require unit tests to quote them directly.
2. Wrap your next task in /goal in Antigravity CLI or Claude Code with a binary test exit condition.
3. Require a final-turn test run so context compaction never hides the proof.

Once one /goal loop can ship a spec autonomously, the next bottleneck is running one checkout at a time. In Part 2, I break down how I run 8 parallel repository clones on main without git worktree, letting Antigravity CLI, Claude Code, and Codex build multiple specs concurrently using atomic Git push locks.

(If you want to follow the journey of building JupiterGoals, you can claim 1 month free early access and get all future updates.)