Chapter 5: The Execution Loop: Review Discipline + Commit Discipline

Series: LLM Development Guide

Chapter 5 of 15

Previous: Chapter 4: Work Notes: External Memory + Running Log

Next: Chapter 6: Scaling the Workflow: Phases, Parallelism, Hygiene

What you’ll be able to do

You’ll be able to run an LLM through implementation work in a way that stays reviewable:

• One logical unit at a time.
• Verification before claiming “done”.
• Atomic commits with clear intent.
• Notes updated as part of the loop.

TL;DR

• Never skip: update notes, verify, propose commit, review.
• A “logical unit” is the smallest change that is independently reviewable.
• Treat LLM output like junior output: it needs review.
• Keep commits small to make rollback cheap.

Table of contents

• The execution loop
• What counts as a logical unit
• Commit discipline
• Verification
• Failure modes

The execution loop

This loop is intentionally repetitive:

Load prompt + work-notes
-> implement one logical unit
-> update work-notes
-> verify
-> propose commit
-> you review
-> commit
-> repeat

If you skip the middle steps, your “agent” becomes a vibes-based code generator.

What counts as a logical unit

A logical unit is a change that:

• Has a clear purpose.
• Can be verified.
• Can be reviewed in isolation.
• Does not leave the repo in a half-broken state.

Examples:

• Add one Kubernetes template file.
• Add one Go type + its tests.
• Add one API endpoint handler.

Non-examples:

• “Implement everything for phase 2”.
• “Half a refactor”.
• “Quick fixes”.

Commit discipline

Use a consistent commit format so you can scan history later.

Example commit message:

feat(helm): add service template for metrics-gateway

- Exposes port 9090 as ClusterIP
- Follows event-processor naming and labels
- No ingress in this commit

Refs: work-notes/phase-2b-core-resources.md

In prompts, require the model to:

• Summarize what changed.
• Explain why.
• Propose a message.
• Wait for approval.

Verification

Verification is context-specific, but the shape is consistent:

• Build.
• Test.
• Lint.
• Render config.

Generic verification commands you can adapt:

# Make sure you know what is staged and what is not.
git status --porcelain

git diff

# Run the repo's verification gates.
# Replace these with your actual commands.
go test ./...

# After the commit, ensure you're clean.
git status --porcelain

Expected results:

• Before committing, git diff matches the logical unit scope.
• After committing, git status --porcelain is empty.
• Tests and other gates exit 0.

Failure modes

• The model keeps “just one more change”-ing.
  • Fix: put explicit stop points in the prompt.
• You don’t verify.
  • Fix: add verification commands to plan and prompt docs.
• Commits include unrelated changes.
  • Fix: shrink the logical unit and split the work.
• You approve output you can’t review.
  • Fix: stop and do it manually or bring in a reviewer.

Continue -> Chapter 6: Scaling the Workflow: Phases, Parallelism, Hygiene