Most conversations about autonomous software development start with agents writing code. An agent picks up an issue, implements a feature, opens a pull request. The demo works. People get excited.
Before any autonomous delivery can work reliably, someone has to design the engineering system that the autonomy will operate inside. The project structure, the technology choices, the architectural boundaries, the design direction, the engineering conventions, the validation mechanisms, the specialist roles, the approval boundaries. None of that should emerge from a collection of independent agents guessing in parallel.
My approach starts with a different division of responsibilities. Humans design the engineering system. Specialized agents execute the work. Asynchronous loops orchestrate when that work happens and what comes next.
The objective is not to remove humans from software development. It is to concentrate human involvement on the decisions that require judgment, context, and product understanding, while building an environment where more of the execution can continue on its own.
These are the six steps I follow every time I start a project that is meant to eventually run without me watching it.
Step 1: the human designs the engineering system
When I begin a project, I do not ask an autonomous agent to invent its foundations.
I decide the important parts first: how the repository should be organized, which technologies to use, how the main architectural boundaries work, what the design direction is, which engineering conventions must be followed, and where autonomy should stop. These decisions become the foundation of everything that comes after.
Then I use opencode-onboard to encode them into the repository.
/make-engineer creates the specialist AI engineers the project needs. Frontend, backend, infrastructure, testing, security, data, mobile, whatever the product demands. These are not generic agents with different labels. Each one has a defined specialization, a set of abilities, and a clear place within the engineering workflow.
/make-architecture captures the technical structure and boundaries in ARCHITECTURE.md. /make-design captures the visual language, design tokens, and component patterns in DESIGN.md. /make-guardrails converts all of those decisions into concrete rules that every agent must respect. Architectural boundaries, naming conventions, testing expectations, code style, security constraints, Git practices. They stop being knowledge held only by the original developer and become part of the operating environment.
The repository ends up containing more than documentation. It contains an encoded engineering organization and a shared source of truth for every agent that will work inside it.
The human defines the system first. Only then does autonomous execution become useful.
Step 2: the interactive foundation comes before autonomy
Once the engineering system is defined, I build the initial project foundation interactively.
I normally use /plan-quick and /plan-apply at this point. /plan-quick analyzes a focused objective and turns it into a concrete, ordered sequence of tasks. It is intentionally lighter than a complete specification workflow. I use it when the work is clear and I want to move quickly without losing visibility or control. /plan-apply implements those tasks and verifies the result.
This is how I establish the basic infrastructure of the project. Repository structure, application skeleton, database setup, authentication foundations, design system, testing infrastructure, CI/CD configuration, deployment foundations.
The early stages of a project contain decisions that affect everything built afterward. A weak abstraction, an inconsistent folder structure, an unclear testing strategy. Any of those can be reproduced hundreds of times once autonomous agents begin working. I have seen it happen. It is not pretty.
For that reason, this phase stays fast and AI-assisted, but supervised.
The purpose is not to maximize autonomy as early as possible. The purpose is to make the project stable, understandable, and predictable enough that autonomy can later operate safely inside it.
Step 3: human involvement becomes a project policy
After the foundations are ready, I decide how much autonomy the delivery system should have.
This is not a binary choice between manual development and full automation. Human involvement can exist at different points in the lifecycle, and the right configuration depends on the project.
A fully supervised project might require a human to refine the issue, approve the implementation plan, review the pull request, approve the merge, and authorize deployment.
A partially autonomous project might let AI refine and implement, while humans answer unresolved questions, review important pull requests, or retain control over the final merge.
A highly autonomous project might let the system refine, implement, review, and merge changes automatically when the required guardrails, tests, and quality checks pass.
A new product with unstable requirements needs more human participation than a mature internal tool. A regulated system requires explicit approval gates that would be unnecessary for a small experiment. And the same project can become more autonomous over time as its architecture, tests, and delivery mechanisms mature.
The important point is that autonomy is defined intentionally. Issue refinement, question resolution, plan approval, pull request review, merge approval, deployment approval. These are not accidental interruptions. They are configurable gates in the engineering system.
Every project chooses a different level of autonomy, and those boundaries evolve with it.
Step 4: ideas become durable backlog items
The interactive console is still the place where I investigate ideas.
When an idea is incomplete, I use /plan-explore. This is not an implementation command. It is a collaborative exploration process. The agent examines the repository, maps relevant components, identifies existing patterns, challenges assumptions, traces dependencies, considers risks, and helps determine what should actually be built.
Many development problems initially look like coding tasks but are really understanding problems. Sending an unclear idea directly into an autonomous implementation workflow usually produces an unclear implementation. Exploration gives the idea enough structure to become actionable without prematurely committing to a solution.
Once the direction is clear, I use /ops-backlog to create a structured work item in GitHub, Azure DevOps, or Jira. The work item becomes the durable handoff between interactive thinking and asynchronous execution. It can contain the context, scope, acceptance criteria, risks, unresolved questions, and dependencies needed by the next stages of the workflow.
At this point the backlog is no longer just a place where tasks are stored. It becomes the shared coordination layer between humans, agents, and loops.
Humans create ideas, answer questions, and make decisions. Loops observe issue states and select eligible work. Agents receive focused tasks with the context needed to execute them.
The backlog transforms an interactive conversation into durable work that continues after that conversation ends.
Step 5: loop-task orchestrates asynchronous work
Once the project, engineers, guardrails, backlog, and approval policy are ready, I configure loop-task inside a local machine or VM.
loop-task runs the outer orchestration loops. These loops continuously inspect the backlog, identify eligible work, invoke the appropriate engineering workflow, and update the state of each issue.
A refinement loop can select a new issue, investigate it, improve its specification, and add questions when information is missing. When a human decision is required, the issue moves into a waiting state. A person answers when available, and the loop resumes when the information appears.
Once the issue is clear enough, it moves into a ready-to-implement state. The implementation loop picks it up and invokes the autonomous engineering workflow.
A review loop can inspect pull request feedback, coordinate corrections, rerun the necessary workflow, and move the change back toward acceptance. A completion loop can merge accepted work, close the related issue, and allow the next eligible item to enter the system.
The loops do not need to communicate with one another directly. They coordinate through durable backlog states. A typical issue moves through a lifecycle like this:
New, Refining, Waiting for answers, Ready to implement, Implementing, Pull request, Reviewing, Done.
Humans can enter the process whenever the project policy requires them, but the system does not depend on someone continuously watching a terminal. Even when the developer is offline, the VM keeps checking the backlog and moving eligible work forward.
This is the distinction at the center of loop engineering:
Agents execute the work. Loops decide when work exists, when it should start, which workflow should execute it, and what happens next.
Step 6: /plan-goal executes one issue from end to end
When the implementation loop finds an issue that is ready, it invokes /plan-goal.
This command is not responsible for deciding the product direction or inventing the project architecture. Those decisions have already been made and encoded into the repository. Its responsibility is to execute one sufficiently refined work item within the existing engineering system.
/plan-goal reads the issue, explores the relevant parts of the codebase, creates an OpenSpec proposal, generates structured tasks, identifies specification or testing gaps, selects the appropriate specialist engineers, assigns model tiers, calculates dependencies, and organizes implementation work into parallel execution waves.
Tasks that are independent and modify separate areas of the repository can be assigned to different engineers simultaneously. Tasks that depend on previous work or touch the same files are executed in the required order.
The lead agent coordinates the work, collects each result, creates focused commits, runs tests, linting, type checks, and builds. It stops rather than shipping the change when verification cannot be completed successfully.
When the implementation is valid, the branch is pushed and a pull request is created with the necessary context and evidence.
The configured project policy then determines what happens next. A human may review the pull request. Another AI system may perform the review. A highly autonomous project may merge automatically when every required check passes. In other projects, the final decision remains explicitly human.
This reveals the two orchestration layers in the system. loop-task is the outer orchestration layer. It manages the backlog lifecycle and decides when refinement, implementation, review, or completion should occur. /plan-goal and the other opencode-onboard commands form the inner engineering workflow. They understand how to explore, plan, assign, implement, verify, and deliver one specific change.
A system that survives the conversation
One of the limitations of prompt-based development is that too much state lives inside a temporary conversation.
The architecture has to be explained again. Previous decisions get forgotten. An interrupted implementation is difficult to resume. A developer must remain present to decide what the agent should do after every step.
This workflow moves that state into durable systems. The repository contains the architecture, design rules, engineers, and guardrails. OpenSpec contains the planned change and its tasks. Git contains the implementation history and recovery points. The backlog contains the delivery state and human decisions. The local machine or VM provides the persistent environment where the loops continue running.
The result is not a single autonomous agent attempting to behave like an entire software organization. It is a coordinated system in which different components have different responsibilities.
Humans define direction, constraints, and responsibility boundaries. Specialized agents execute focused engineering work. Loops coordinate the lifecycle asynchronously. The backlog connects them.
The most important change is not that agents can generate more code. The larger shift is from isolated AI interactions toward persistent engineering systems.
Instead of explaining the repository before every task, the project carries its own architecture and guardrails. Instead of asking a generic agent to implement everything, work is assigned to specialists. Instead of manually deciding what should happen after every step, loops react to durable workflow states. Instead of keeping the entire process inside a conversation, progress survives in issues, specifications, commits, pull requests, and local state.
The human role does not disappear. It moves toward designing the environment in which autonomous execution is allowed to operate.
That is the model I am currently building: a human-designed AI SDLC where the developer establishes the engineering environment and autonomy boundaries first, then asynchronous loops coordinate specialized agents through a backlog-driven delivery lifecycle.
From zero to loops running on their own. Six steps, each one building on the previous one, each one moving a little more state out of the conversation and into systems that do not forget.
PS: You can find loop-task, opencode-onboard and the rest of these tools at ckgrafico.com
