# A Practical AI Agent Workflow for Solo Developers
AI coding agents can inspect a repository, change multiple files, run tests, and deploy a release. That power is useful only when the work stays connected to the product outcome.
For a solo developer, the best workflow is not a longer prompt. It is a short operating loop that makes direction, evidence, and continuity explicit.
Start with the user action
Before asking an agent to write code, finish this sentence:
After this work, the user can…
If the answer describes a file, service, table, or refactor, keep going. Those are implementation choices, not the result.
Examples of useful outcomes:
- After this work, a visitor can compare the plans and start checkout.
- After this work, a user can return tomorrow and continue the same project.
- After this work, a failed import can be retried without creating duplicate data.
This sentence becomes the test for every proposed change.
Give the agent four boundaries
A capable agent will fill gaps with reasonable assumptions. Some assumptions are helpful; others silently change the product. Give it four boundaries before execution.
1. The current authority
State where the truth lives now: a database, a local file, an external service, a generated artifact, or user input.
Without this, an agent may create a second source of truth because it looks convenient.
2. The invariants
List what must remain unchanged. Common invariants include public URLs, data ownership, privacy expectations, existing user actions, deployment paths, and product naming.
3. The authorized surface
Name the repository, service, or environment the work may change. A diagnosis in one system should not automatically become permission to patch another.
4. The completion evidence
Say what must be observed before the task is complete: a test, a rendered page, a runtime status, a production event, or a full user action.
Use a six-step execution loop
Step 1: Anchor in current reality
Ask the agent to read the smallest relevant set of code, configuration, tests, and current runtime evidence. Old plans and chat summaries are useful pointers, but current behavior wins when they disagree.
The output of this step should separate observation from inference.
Step 2: Find the first broken link
Do not begin with a broad redesign. Trace the user action from entry to result and find the first point where reality diverges from the intended outcome.
Fixing that link is usually more valuable than improving the entire architecture.
Step 3: Define the smallest complete change
“Small” does not mean incomplete. The change must include every layer required for the user result: registration, state updates, error behavior, generated output, and verification.
It should exclude unrelated cleanup and speculative improvements.
Step 4: Execute with stable identities
When work crosses sessions or external systems, record stable identifiers: task IDs, versions, commits, deployment IDs, or idempotency keys.
Names such as “latest,” “the new one,” or “the draft” become ambiguous quickly. Stable identities make retries and handoffs safe.
Step 5: Verify the final consumer
Test what the user actually receives, not only the source that produced it.
If a template creates JavaScript, parse the generated JavaScript. If a worker serves HTML, inspect the response HTML and status. If a lifecycle event updates a page, verify the page, metadata, and sitemap together.
A narrow unit test is the first check, not always the final one.
Step 6: Leave a factual handoff
Record:
- the goal;
- verified current state;
- exact changes;
- test and runtime evidence;
- remaining work;
- the next safe action.
A handoff should let a fresh session continue without repeating discovery or guessing which object was changed.
Separate planning from execution without disconnecting them
A roadmap answers “what outcome matters next?” An execution session answers “what must change now?”
Keep both visible. When execution discovers a new problem, decide whether it blocks the current outcome. If it does, update the current plan with evidence. If it does not, capture it for later and keep shipping.
This prevents two common failures:
- following an outdated plan despite new facts;
- abandoning the roadmap whenever a new technical idea appears.
How much autonomy should an agent have?
Give broad autonomy inside a narrow outcome.
The agent should be free to inspect code, choose a focused implementation, run relevant tests, and repair mistakes within the authorized surface. It should stop when a decision would change the product boundary, delete existing assets, spend money, alter production data beyond the stated action, or choose between materially different user outcomes.
This balance keeps work fast without turning product decisions into accidental implementation details.
A reusable prompt structure
You can brief an agent with six short fields:
1. Outcome: What the user can do afterward. 2. Current evidence: What is known from code or runtime. 3. Invariants: What must not change. 4. Scope: What may be modified. 5. Verification: What proves completion. 6. Stop conditions: What requires a pause.
The prompt can be brief because the structure carries the important context.
Warning signs that the workflow is drifting
Pause and re-anchor when you see these patterns:
- the diff grows faster than the evidence;
- the agent explains architecture instead of completing the user action;
- a workaround creates a second source of truth;
- production is being used to discover basic behavior;
- “done” depends on the user performing unlisted cleanup;
- the next session would need to infer which version or object matters.
Drift is not solved by a more forceful “continue.” It is solved by restoring the outcome, boundaries, and evidence chain.
The operating loop in one line
Choose one user outcome, anchor in reality, preserve the boundaries, repair the first broken link, verify the final consumer, and leave a factual handoff.
That loop is small enough for a solo developer and rigorous enough for agents working across code, services, and production.