Separate Human Planning from AFK Implementation

The workflow has a deliberate handoff point. Alignment, research, prototyping, destination definition, and issue decomposition remain human-reviewed. Once a clear backlog of bounded AFK tasks exists, implementation can move to an autonomous loop. This creates a "day shift" for human judgment and a "night shift" for repeatable agent execution.

A minimal implementation runner performs one iteration of the loop. It collects the information the coding agent needs and starts a fresh session. The demonstrated runner supplies:

• The local issue files from the backlog.
• A small amount of recent commit history.
• A focused implementation prompt.
• Repository access under a controlled permission mode.

The prompt tells the agent to work only on AFK issues. It also defines a stop signal to emit when no eligible tasks remain. Within a single iteration, the agent:

1. Reads the backlog.
2. Selects the next valid task according to the stated priorities and blockers.
3. Explores the relevant repository area.
4. Implements the task using test-driven development.
5. Runs the required feedback loops.
6. Creates a commit.
7. Reports what was completed.

The one-iteration script is important because it exposes the agent's behavior. Before running an unattended loop, execute the single iteration repeatedly and inspect task selection, exploration, edits, tests, and summaries. Adjust the prompt when the agent chooses the wrong work, skips a feedback loop, or interprets issue metadata incorrectly.

The AFK version repeats the same fresh-session pattern. Each iteration starts from external state rather than accumulated conversation. Issues, code, tests, and commits carry the project forward. The agent does not need a single long context containing the full history.

The autonomous version also runs inside an isolated environment. The unattended version uses a sandboxed environment, while a branch or worktree preserves the resulting changes for later review and merge.

Autonomy is safest after the uncertain decisions have been converted into bounded work. Sending an agent away with only a vague idea creates uncontrolled interpretation. Sending it away with a dependency-aware backlog, a task-selection rule, a test discipline, and a stop condition creates a constrained execution system.

The fresh-session loop also aligns with context management. Each issue can be completed in the smart zone, committed, and followed by a clean restart. The backlog provides continuity without relying on compaction.

Build the AFK workflow in stages:

1. Maintain backlog items as local markdown files or work-tracking issues with clear scope

and dependencies.

1. Write a runner that injects the backlog and a concise implementation prompt into a new

coding-agent session.

1. Define how the agent identifies eligible work and what it outputs when no work remains.
2. Require repository exploration before editing.
3. Require TDD and named feedback loops.
4. Require a commit and completion summary for each successful task.
5. Run the process once with a human watching.
6. Tune the prompt until one iteration behaves predictably.
7. Only then place it inside an unattended loop and sandbox it.

Task prioritization can be explicit. A queue may prefer critical bug fixes, development infrastructure, tracer-bullet issues, polishing work, quick wins, and refactors in a defined order. The exact priority is less important than making the selection rule visible and controllable.

Implementation is not the end of the workflow. Autonomous coding increases the amount of output that must be reviewed and manually tested. It can move the bottleneck from writing code to validating code.

Long loops also conflict with the desire for small, self-contained pull requests. One loop that completes many issues can create a large review burden. The process may need shorter loops, smaller tasks, or separate branches to preserve reviewability.

Sandboxing and permission design reduce risk but do not establish correctness. The agent can still implement the wrong behavior or create changes that pass automated checks while failing in real use.

Do not automate ambiguity. Automate a curated backlog. Validate one iteration under human observation, then run the same bounded, fresh-context implementation cycle unattended inside an isolated environment.