LLM-Orchestrated Coding Workflow

A practical, engineering-first approach for using role-based LLM support in real software work.

Spec

Start with a clear problem statement and acceptance criteria. Keep it focused on the outcome, scope, and why the change matters.

Plan

Choose the tools or models by role: planning, implementation, review, verification. Define dependencies, files, and commands for the task.

Task Packet

Package each step as a small, reversible task with objective, scope, constraints, commands, and evidence requirements. If a step cannot be reviewed quickly or reverted cleanly, it is too large and should be split.

Implement

Send the task packet to the implementing tool. Expect code plus a precise summary of files changed, a minimal diff summary, commands run, command results, unresolved risks, and acceptance criteria status.

Review

The review role checks correctness, regressions, edge cases, project rules, and whether the evidence is sufficient.

Verify

A change is not accepted until the required lint, typecheck, tests, and project-specific verification commands have actually been run and reported.

Manual Validate

Execute targeted runtime checks and scenario testing for behavior that automated verification does not cover.

Commit

Keep commits tied to completed task packets. Record the verification commands and results in the change note.

Note: This is still one tool critiquing another. The difference is that planning, implementation, review, and verification are explicit roles, which makes the process easier to audit and repeat.

What belongs in repo-level instructions?

Keep durable rules in project guidance files, not in every prompt. Use a repo-level document such as AGENTS.md, REVIEW.md, or CLAUDE.md for long-lived conventions.

Project conventions and coding standards
Model roles and review expectations
Required verification commands
Release and commit formatting rules

Keep the prompt focused on the specific task, scope, and acceptance criteria.

Example task packet

Objective: Add a new endpoint for exporting user settings as JSON.
Scope: backend route only, app/server/users.js and tests/server/users.test.js.
Constraints: preserve current auth flow, do not change UI.
Commands:
  npm test -- users.test.js
  npm run lint -- app/server/users.js
Acceptance criteria:
  - endpoint returns 200 and valid JSON
  - unauthorized requests return 401
  - unit tests cover error paths
Required output:
  - route implementation diff
  - test results
  - verification commands run

Review loop checklist

Correctness
Does the change solve the stated objective?

Regressions
Did review role search for backward-impact risk?

Evidence
Is the output supported by actual commands or diffs?

Validation and evidence

Run lint and typecheck before approval.
Run the smallest focused test set that exercises the change.
Confirm the implementation output includes files changed, a diff summary, commands run, command results, unresolved risks, and acceptance criteria status.
When needed, validate runtime behavior in a representative environment.

Common failure modes

Prompt is too vague: no objective or acceptance criteria.
Step is too large: hard to verify or revert.
No reproducible command: you cannot confirm the change.
No scope boundary: the agent edits unrelated files or drifts beyond the task packet.
Trusting "done" without evidence.
Repeating persistent instructions in every prompt instead of using repo guidance.