From Serial Approval to Parallel Collaboration: Router + Worker Development Workflow

The previous article "Design of AI Programming Workflow: Serial Verification Design" introduced the dev-workflow used in the project: first restore the background, then formulate a plan, code after manual confirmation, and finally have an independent Agent review and deliver based on actual evidence.

This process helped me connect requirements, plans, implementation, and verification, and also gave each step of AI a basis to check. After using it for a while, another problem gradually became obvious: when the model can already handle most routine requirements, the strictly serial phase arrangement makes both humans and AI spend a lot of time waiting.

So I started designing a new workflow: dev-workflow-router. The Router uniformly receives requirements and feedback, and then hands them to three Workers to complete background and plan, coding, review and verification separately. While retaining human decision-making power, it allows work that can be done ahead of time to start earlier to improve efficiency.

Below I record the starting point, implementation method, and remaining shortcomings of this design.

1. Problems with the existing workflow

1. With quality constraints in place, we also need to pay attention to delivery efficiency

The original dev-workflow roughly proceeds in the following order:

Each step in this chain has a role. Background analysis helps confirm the real goal to be achieved; the plan makes state ownership, module boundaries, and compatibility strategies visible before coding; independent review provides another perspective; verification requires that conclusions are supported by evidence.

These constraints increase the probability that requirements are implemented correctly and make it easier to discover and track deviations.

The efficiency problem mainly comes from waiting between stages: the background has not been confirmed, the plan cannot be formally unfolded; the plan has not been confirmed, coding cannot start. Even if the current analysis will likely be accepted later, the executor must stop and wait for an interaction.

When the requirement involves a new state model, complex business trade-offs, or cross-module adjustments, such waiting is valuable. But for tasks with clear goals and stable existing structure, some implementation and preparation work can already begin.

2. Most confirmations don't change direction; running ahead is worth trying

Based on my rough estimation from usage in the project, tasks that actually require me to make adjustments in background analysis or technical planning account for about 10%-20%; more often, after reading the AI's analysis, I just say "confirm" and let the AI continue.

This observation is enough to raise a hypothesis worth verifying: in tasks where the goal and boundaries are already relatively clear, allowing the Coder to do a part of the implementation early may reduce overall waiting time.

As model capabilities improve, familiarizing with project encapsulation, reading relevant code, and completing routine implementation is work that can be handed to AI. Pre-analysis is still important, but we can further distinguish which conclusions must be confirmed before action, and which work can be done first under explicit assumptions.

3. The main Agent takes on too many responsibilities and easily becomes a waiting point

In the original process, the main Agent usually continuously handles background analysis, plan design, coding, verification, and summarization, with an independent Reviewer intervening during the review stage.

This arrangement is convenient for maintaining context continuity, but the main Agent also gradually accumulates a lot of implementation details. If it is executing time-consuming tool calls or digging into a certain call chain, handling new user feedback may be affected.

At the same time, the Reviewer often starts building context only when formal review begins. Preparation work such as requirements, project specifications, and relevant module relationships is concentrated in the second half.

These tasks can be reassigned: the main session maintains external communication and scheduling, execution details go to their respective Workers, and the Reviewer prepares stable information in advance.

4. The cost of small feedback should be proportional to its impact scope

During development, feedback like this often appears:

Change the earlier 3 minutes to 5 minutes.

If each message triggers a full round of background analysis and plan design, the process cost exceeds the modification itself.

The original dev-workflow already requires that feedback on the current task continues the current stage without reinitializing the process. The new design further refines the dispatch method: the Router judges what this feedback changes and directly hands it to the role that needs to handle it.

Clear local adjustments are implemented directly; adjustments with unclear impact first do a local analysis; adjustments that change goals or architecture are submitted for manual confirmation of the corresponding trade-offs.

2. Structure and inspiration of the Super-agent

This design was inspired by DeepSeek's article "Exploration of Super-agent Design: Toward a More Autonomous Agent System". The original text discusses Router and Worker layering, event-driven, asynchronous interaction, context organization, and state and environment management required for persistent operation.

Among them, the Router maintains global interaction and task coordination, while Workers execute specific work in isolated contexts; time-consuming tasks are advanced asynchronously, and related information enters the context as needed. These designs hand some session management and task tracking work back to the system, and also treat human attention as a resource to save. link

1. Separate external interaction from concrete execution

The most direct inspiration to me is separating "communicating with people, knowing where the work is" from "diving into code to complete tasks".

A human engineer only needs to continuously face the Router: raise requirements, supplement background, modify requirements, confirm trade-offs, and provide test results. Which specific Worker investigates, implements, or reviews is organized by the Router.

This reduces the burden of human memory and switching execution context, and also gives new feedback a unified entry point.

2. Allow bounded ahead-of-time actions

The original text discusses speculative execution that tries ahead based on environmental signals: first invest computation, and adopt the result if it has value. This provides a perspective for the Coder to run ahead. section 3.4 of the original

In my development scenario, the user has already explicitly proposed the task, and the scope of ahead-of-time actions can also be limited to the current project and candidate files. The Coder can first form its own judgment and do limited implementation, then accept the constraints of the confirmed plan.

The prerequisite is that this portion of work can be adjusted or discarded, and it does not cross unclear technical routes, external contracts, or authorization boundaries.

3. Distinguish multi-task scheduling from single-task internal collaboration

The Super-agent article focuses on cross-session, multi-task, and continuous operation; this implementation mainly handles role collaboration within a development task.

The two are at different levels. In the future, a higher-level task Router can schedule multiple development tasks, and each task internally runs its own analysis, coding, and review processes. There is no need to implement all levels at once; first verify whether the division of labor and handoff within a single task is effective, and that already involves a lot of work.

3. Implementation of dev-workflow-router

1. One Router, three Workers with clear responsibilities

The overall division of labor is as follows:

Role	Core responsibility	Main product
Router	Receive messages, judge task ownership, dispatch work, maintain stages and approvals, aggregate delivery	Task state, handoff info, final report
Worker 1: Coder	Five-line skeleton, limited ahead run, implementation, local adjustments, all rework, final doc maintenance	Actual diff, static checks, implementation notes
Worker 2: Reviewer	Prepare context early, independent review, incremental recheck, acceptance and evidence checking	Review report, verification report, manual checklist
Worker 3: Analyst / Planner	Background analysis, technical plan, acceptance criteria, local impact analysis	Background info, plan, verification contract

The Router still needs to do lightweight judgment, such as which task a message belongs to, whether it changes current requirements, and who to wake up. But full call chain investigation, technical plan design, and business implementation are handed to the corresponding Workers.

Background analysis and Planner are placed in the same Worker because they are closely related. After the background is confirmed, it can continue to use existing facts to formulate the plan, reducing the cost of rebuilding context.

The Coder retains its own implementation context and is responsible for all rework. The Reviewer focuses on judgment and rechecking, and does not directly take over source code modification. All human interaction is presented uniformly by the Router; Workers do not each open approvals to the user.

2. After receiving the first requirement, start three types of work as early as possible

When the goal is clear, the Router starts the three Workers as early as possible:

• Analyst begins restoring background, checking goals and preservation rules.
• Coder reads the original requirement and necessary code, writes a five-line skeleton, and does limited implementation.
• Reviewer reads stable specifications, existing requirements, and related module relationships, preparing for later review.

The "parallel" here has clear boundaries. The Planner still waits for the background gate; the Reviewer's formal review still waits for the implementation gate. What starts early is work that can be independently advanced.

After the Reviewer completes preparation, it can return to a waiting state and continue when new contracts or review tasks appear, without repeatedly reading the same content just to keep three roles "busy".

For tasks that have already chosen the experimental process but where key structures are not yet determined, the plan-first mode can be used: the Coder does read-only preparation first, and implements after the plan is confirmed.

3. Five-line skeleton: leaving the Coder's initial judgment

If the Coder also fully repeats background investigation and plan design, the benefit of parallelism will be eaten by duplicate work. Therefore, its pre-work output adopts a "five-line skeleton":

1. State ownership.
2. Level of retry or exception handling.
3. Candidate files to change.
4. Error semantics.
5. Observable acceptance phenomena.

For example, when adding an idle reminder to an existing device page, you can record it like this. The following file names are for illustration only:

1. State ownership: Continue using the page's existing ViewModel reminder event; UI only handles display.
2. Exception level: The timer task continues with the page session; stop when leaving the page.
3. Files to change: DeviceViewModel.kt, DeviceRoute.kt.
4. Error semantics: After restarting the timer or exiting the page, the old task no longer triggers reminders.
5. Acceptance criteria: When continuous inactivity reaches 3 minutes, a reminder appears on the current page.

If these judgments are not yet verified, mark them as assumptions; items not involved can be stated as not involved.

The five lines limit the output length and the pre-decision surface. The interfaces, lifecycle, and shared constraints that implementation depends on must still be verified. You cannot skip key facts that would change the approach just to write quickly.

The value of the skeleton is that the Coder leaves its own structural judgment before diving into implementation, which can later be compared with the Planner's plan. Whether it can reduce rework needs to be verified by actual tasks; no fixed return rate is assumed.

The smaller the divergence between Coder and Planner, the greater the benefit?

Under the premise that task scale, implementation difficulty, and tool environment are similar, and there is enough overlapping work, the smaller the divergence in key technical decisions between the two, the easier it is to preserve the benefits of running ahead.

The reason is direct: if the state ownership, module boundaries, and error semantics implemented early by the Coder are basically consistent with the finally confirmed plan, that part of the code can continue to be used. The less work there is to reinterpret, wait for adjudication, overturn implementations, and recheck, the easier it is for the time saved by early start to translate into final delivery benefits.

A rough cost relationship to help understand:

Net time benefit relative to serial process
≈ time saved by overlapping analysis and coding
− added startup and coordination overhead of parallelism
− extra alignment and rework time from diverging decisions

What is more worth recording here is the impact of divergence. A few differences in function naming may be quickly unified; a single divergence in state ownership can change the entire implementation path. The same divergence discovered early in the work versus after a large amount of code is written has different rework costs.

Therefore, tasks with clear goals, stable project encapsulation, and easy convergence of key decisions are more suitable for trying to run ahead. The five-line skeleton and timely synchronization of #0/#1 are to expose and handle these differences as early as possible.

However, consistency between the two still requires evidence of correctness. Two Agents may ignore the same constraint together, or make the same wrong judgment. You cannot reduce the "divergence count" by having the Coder copy the plan or suppress factual objections; independent review and operational verification continue to be retained.

4. Three gates retained, confirmation results synced in batches

I retained the three main human approval points from the original process:

Gate	Confirmation target	Actions after passing
#0 Background confirmation	Scenario, goal, current behavior basis, boundaries that must be preserved	Sync goals and boundaries immediately; Analyst continues to formulate plan
#1 Plan confirmation	Technical decisions, implementation scope, acceptance criteria, verification method, skeleton divergence	Coder aligns with confirmed plan; Reviewer updates preparation materials
#2 Implementation verification	Current version's implementation, static results, manual tests and pending items	After human approval, enter formal independent review

There are two important timings.

First, after background confirmation, immediately sync goals and boundaries. This way, the Coder can correct deviations in "misunderstanding the goal" as early as possible.

Second, the divergence between the skeleton and the plan must be formed before #1. When the human sees the plan, they should also see the Coder's different judgments and factual basis to make a ruling. If differences are compared only after plan approval, this gate is missing part of its input.

During the wait for the first two gates, the Coder can continue to advance approved work within tentative boundaries. The user choosing this experimental process authorizes this adjustable early implementation; background and technical plan still need to be confirmed separately.

5. After implementation is complete, test first, then formal review

After the Coder completes this round of implementation, it first delivers the necessary static check results and a manual verification checklist that can be directly operated:

Prerequisite	Operation	Expected outcome	Corresponding AC	Why manual verification is needed
Enter device page and keep foreground	Continue inactivity, wait for reminder time	Reminder appears only once	AC1	Need to observe real timing and page behavior
During reminder timing	Leave device page	No further reminder appears on that page	AC2	Need to verify real page lifecycle

A human engineer can build, run, and complete real-device verification at #2, then hand over for formal review by the Reviewer. This continues the implementation release order from the original process.

If the human explicitly requests to enter review first without completing real-device testing, the release can be recorded, but the runtime item must remain marked as untested. Entering the next stage does not itself constitute evidence of passing runtime.

When the Reviewer later requests rework, existing human results are only valid for the implementation at that time. Reverify whichever behaviors changed; for unaffected results, reuse after explaining the basis, avoiding re-testing all paths each time.

6. "Change 3 minutes to 5 minutes" goes directly to Coder

Subsequent feedback should not by default go through a full analysis. The Router first judges the intent and impact of this message:

Feedback type	Handling method
Ask about progress or explain implementation	Router answers based on existing facts, fetching info from corresponding Worker if necessary
Clear local modification	Directly to Coder; update affected implementation and acceptance expectations
Unclear impact scope	Analyst analyzes only that point's impact and necessary trade-offs
Changes goal, state ownership, or module boundaries	Submit local plan difference; human confirms the changed part
Current implementation fails tests or has omissions	Rework within this task; hand to Reviewer for recheck by stage

For example, if the currently discussed topic is clearly the idle reminder duration, and the user says:

Change 3 minutes to 5 minutes.

This instruction itself confirms that local adjustment. The Router can directly tell the Coder: modify the reminder duration, check related display and units, sync the affected ACs, and preserve other confirmed rules.

No need to refill the five-line skeleton, nor to have the Analyst rewrite the entire plan.

If the Coder finds this value also participates in other timeout constraints, it reports the extra impact back and does targeted analysis. The dispatch depth is determined by actual impact; you cannot judge risk just by "changing a number".

Small feedback enters the incremental record of the same task. The base plan and current valid increment together form the latest contract; the Analyst can merge relevant items the next time it needs to work or when wrapping up, avoiding waking it to re-investigate for every parameter change.

7. Reuse context while preserving independent judgment

The Reviewer can reuse already verified requirements, interface facts, call relationships, and engineering norms; re-finding that information usually has no added value.

What needs to be avoided is directly importing the implementer's exploration process and successful self-assessment into the review context. The Reviewer should make its own judgment based on the confirmed contract, actual diff, and necessary call context.

Therefore, the handoff focuses on passing goals, facts, sources, constraints, file locations, and current version; the full exploration history stays in each context and can be referenced on demand.

The shared workspace also brings a practical problem: while the Analyst is investigating original behavior, the Coder may have already started modifying the same files.

For this reason, before the Coder edits a target file for the first time, it needs to save the pre-modification content or a "does not exist" marker. When the Analyst analyzes original behavior, it should prioritize these contents to avoid mistaking post-race implementations for original facts. This capture only covers relevant files, not the entire repository.

8. Ownership and version must be explicit

If three Workers simultaneously modify one ledger, even if each is responsible for only certain columns, overwrites can occur. Therefore, task products are split by owner:

.workflow-router/<task-id>/
├── task.json          Router: state, version, approvals, increments, count
├── background.md      Analyst: background and evidence
├── plan.md            Analyst: plan, decisions, and ACs
├── coder.md           Coder: skeleton, differences, implementation, and static checks
├── review.md          Reviewer: independent review and recheck
├── verification.md    Reviewer: acceptance and evidence
├── delivery.md        Router: final delivery report
├── baseline/          pre-modification content for relevant files
└── snapshots/         content snapshot records

Source code, resources, project config, and formal documentation are written by Coder uniformly. Other roles raise problems or change requests through the Router, not directly modifying each other's files.

When effective requirements change, the Router increments the version number and notifies only affected Workers. If old-version products arrive, first judge their applicability; they cannot directly overwrite the latest requirements.

Implementation snapshots compute content digests based on declared written files and related inputs, distinguishing different local implementations after the same branch or commit, and covering added, deleted files and related external inputs. Scope declarations and actual diffs still need to be checked; snapshots don't automatically know all business dependencies.

During formal review, Coder's source writes are paused. If adjustments are truly needed, first coordinate the affected review, then fix a new snapshot, and hand to the original Reviewer for incremental recheck.

9. Review, verification, and wrap-up remain complete

The Reviewer checks two directions simultaneously: whether requirements are correctly implemented, and whether the engineering implementation is reliable. Problems are divided into three categories:

• ① Requirements or ACs not met: hand to Coder to fix.
• ② Engineering defects, such as races, resource leaks, incomplete error semantics: hand to Coder to fix.
• ③ Factual structural divergence between implementation and plan: hand to human for decision via Router.

Problem category and severity are recorded separately. The Reviewer can question the plan but cannot rewrite it; the Coder also cannot modify acceptance criteria to fit existing code. Finding no new problems can be a legitimate result; there is no metric like "must find a few per round".

After review, the verification report retains four layers: static checks, itemized ACs, manual verification checklist, and edge case analysis. Static reading, existing logs, and manual real-device results each note their source; untested items remain pending.

In my Android project, AI by default does not actively compile the project or add test cases; it uses static checks, existing evidence, and manual verification checklists. It only executes builds or tests when explicitly authorized. This is the project's execution constraint; other projects can arrange their own verification contract.

Review and verification each accumulate failure counts; pause after reaching three. The human can give guidance and retry, explicitly accept known risks and skip, or terminate. Rework and worker replacement cannot reset the count, and skip cannot be written as pass.

Once code and related verification stabilize, then centrally maintain requirement HTML, related topic docs, screenshots, change records, and navigation. Finally, the Router aggregates review, verification, documentation results and pending items to deliver a status that can be tracked.

4. Outlook

1. Workers can gradually decouple from specific Harness

The current three Workers are all dispatched by a single Harness (e.g., Codex). The next step worth experimenting with is: retaining the Router and role contracts, handing some Workers to other Harnesses or models to improve efficiency.

For example, can the Coder be handed to DSH? For tasks with clear implementation paths, can a faster-responding Harness or model be used? Should Analyst and Reviewer stay in the current environment?

This requires first defining stable handoff content: task ID, current version, goals and boundaries, files allowed to modify, necessary sources, acceptance criteria, returned diff, static checks, and unverified items.

If the target Harness provides reliable start, resume, interruption, and result return capabilities, this combination can be further verified. Different environments also need to address workspace access, baseline consistency, permission boundaries, and handling of late results; you can't just copy the same prompt.

Whether a faster model is worth it also depends on end-to-end results: the first round of coding may be faster, but if it adds more rework and human explanation, the overall benefit may be worse, so a faster model must also be smarter.

2. Re-evaluate roles and gates as model capabilities change

Responsibilities that currently need explicit splitting may be completed by one model more stably in the future; parts that require human intervention today may gradually have more reliable check evidence.

The number of roles and stage arrangements can all be adjusted. What deserves to be kept are goals, modification scope, major trade-offs, and evidence boundaries, so that time saved as model capabilities improve truly reflects in delivery.

Any compression or automation of gates should have actual usage evidence and clear authorization; you cannot assume omission just because the model has been updated.

3. Move from chat feedback to task events

Currently the process is primarily driven by user messages. In the future, events such as build results, review completion, test feedback, and external dependency recovery could be connected, with the Router judging who should receive the next step.

This requires additional adaptation and runtime mechanisms, which are not currently considered or implemented. Even if available later, notification frequency should be controlled: only notify the user when there is a result, a decision is needed, or takeover is needed, avoiding turning every background step into a new attention burden.

5. Shortcomings of dev-workflow-router

1. Abstract problems are still better with plan-first

If the requirement itself is still exploratory, or if state model, module boundaries, and data ownership must be decided first, the Coder's initial skeleton can easily diverge significantly from the Planner.

For such tasks, the reusable portion of early implementation may be very small, while alignment costs are high. When these conditions are known before starting, the original dev-workflow should be preferred, confirming background and plan first.

2. Token consumption usually increases

Multiple Workers need to build their own contexts, plus dispatching, handoff, status updates, and recheck overhead. Even if facts can be reused, you cannot assume that repeated reading has no cost.

The actual increase depends on task size, context trimming, tool calls, and the billing method of the environment. There is currently not enough data to give a fixed multiple.

Therefore, whether investing more computation can buy less human waiting needs to be measured per task type. For very small changes, the overhead of starting multiple roles may already exceed the implementation itself.

3. A few large reworks can offset gains from most tasks

The 10%-20% human adjustment ratio only indicates how frequently adjustments occur, not the cost of each. Human approval of the Planner's plan does not directly imply the Coder's speculative implementation matches that plan; the two differences must be observed separately.

If the intervention needed happens to be a structural decision, the Coder may have completed a large amount of implementation that no longer applies. The five-line skeleton provides a comparison baseline but cannot guarantee the initial judgment is correct.

This requires us to continuously narrow the ahead-of-run boundary and observe which tasks suit early execution and which should wait, rather than deciding strategy solely based on average confirmation rate.

4. Concurrent collaboration adds consistency costs

Source code may change, old version results may arrive late, and message delivery does not mean the executor has stopped. File ownership, pre-modification baselines, and version snapshots all incur additional management costs.

The current "read-only Reviewer" and "sole source writer" are first role constraints; they do not mean the operating system has provided independent sandboxes. Actual permissions and isolation capabilities still depend on the host environment.

Similarly, independent contexts can reduce the impact of following the author's reasoning, but the same model may still share blind spots. Critical paths need to be checked against code, objective checks, and real runtime evidence.

5. Manual-first testing order may cause repeated verification

This implementation retains the order of #2: manual verification first, then formal review. This lets the Reviewer get human feedback, but if it later requests behavior changes, re-testing may be needed.

Snapshots and focusing on affected scope can reduce repeated tests, but cannot entirely eliminate this cost. Whether to adjust the order in the future must be judged based on the project's review finding rate, build cost, and device verification cost.

6. Summary

The original dev-workflow established a responsibility chain among background, plan, implementation, review, and verification. This experiment retains those responsibilities, hands independently advanceable work to different Workers, and lets the Router uniformly handle human interaction and subsequent feedback.

The Coder can implement ahead within a limited scope, the Analyst continuously converges goals and technical plans, and the Reviewer prepares early and independently checks results. Clear small adjustments go directly into implementation; new facts and major trade-offs are handed to appropriate roles.

This design aims to reduce two costs: AI waiting due to serial stages, and the ongoing human attention needed to push the process. Whether the extra computation and consistency management are ultimately worth it needs to be answered by real tasks.

The current new workflow skill is in the experimental stage, but the direction should not have major problems.

Note: This article was compiled with AI assistance combined with my project practice, thinking, and experience. I was responsible for checking and revising. If there are errors, please criticize and correct.

Engineering design articles:

AI Programming Workflow Design: Serial Verification Design

AI Programming Workflow Design: Parallel Collaboration Design