Dual-Assistant Collaboration: A Practical Software Development Workflow

In the context of software engineering increasingly relying on intelligent programming tools, a single assistant often struggles to balance “thinking clearly” and “implementing robustly.” One type of tool excels at long-context planning, requirement breakdown, and document constraints; the other is better at implementing code based on established specifications, static checks, and drafting test plans. Combining them into a repeatable workflow, rather than competing over which is “stronger,” is key for many non-professional developers to achieve stable delivery.

1. Why Dual Assistants Instead of Single-Point Dependency

The capabilities of intelligent programming tools are unevenly distributed. Planning assistants are sensitive to ambiguous requirements, capable of translating verbal goals into module boundaries, interface agreements, and acceptance criteria; execution assistants are better suited for batch generating code, filling in error handling, and logs once constraints are clear. Using only a planning assistant often leads to solutions that merely “look reasonable.” Relying solely on an execution assistant might result in hard-to-rollback implementations when requirements haven’t converged. The essence of cross-usage is introducing adversarial validation: one proposes an opinion, the other must refute or absorb it based on documents, until their expressions converge, before entering the coding phase.

This adversarial approach isn’t about creating conflict but replacing personal guesswork with structured debate. The more detailed the requirement document (which can be called a harness or constraint specification), the less likely the subsequent implementation will derail. The document should cover: business goals, non-goals, data flow, module division, error code conventions, log fields, configuration items, and test entry points. Without these, audits devolve into style disputes.

2. Phase 1: Writing Requirements into Executable Constraints Using Planning Mode

First, discuss requirements with the execution assistant to produce an initial harness. Recommended content includes:

1. Problem statement and success criteria: Describe “what counts as done” using verifiable statements, avoiding adjective stacking.
2. Module list and dependency direction: Indicate which modules can be parallelized and which must be sequential.
3. Interface sketches: Inputs, outputs, idempotency, timeout, and retry strategies.
4. Risk list: Data loss, privilege escalation, UI state inconsistency, etc.

Next, hand this document to the planning assistant for review: point out missing boundary conditions, inconsistent naming, and untestable clauses. Then, return the review comments to the execution assistant, requiring point-by-point responses—accept, reject, or compromise—with stated reasons. After two or three such rounds, the document transitions from an “idea” to a “contract.” Maintain planning mode throughout, forbidding premature writing of business code to prevent implementation from hijacking design.

For the planning assistant, maintain a separate constraint file (similar to a project-level README) clarifying: language and framework versions, directory structure, prohibited dependency categories, logging standards, and commit granularity. The constraint file should be as short as possible but strictly checkable. It acts as the “constitution” for the assistants, while the harness serves as the “law” for the current iteration.

3. Phase 2: Modular Implementation and Immediate Auditing

Break down development by modules according to the harness. Immediately enter cross-auditing after each module is finished, rather than waiting until everything is written. Recommended fixed audit checklist:

• Whether it deviates from interface and error handling conventions in the harness.
• Whether it introduces undeclared side effects (global state, implicit caching).
• Whether logs are sufficient to reproduce issues.
• Whether there are obvious resource leaks or blocking calls.
• Whether UI-related modules cover empty, loading, and failure states.

The execution assistant is responsible for providing audit opinions against the harness; the planning assistant refutes or supplements these opinions. Both parties must cite document clauses rather than relying on “feelings.” Only after reaching consensus can they proceed to the next module. This limits rework to the module level rather than the system level.

Another benefit of modularization is context control. Only input the current module’s harness fragment, related code, and audit records into the conversation to reduce noise. Timely commit completed modules to the repository to prevent assistants from rewriting already accepted parts in subsequent rounds.

4. Phase 3: Testing Plans Also Need “Adversarial Finalization”

Once features are complete, the execution assistant drafts an automated test plan: test case layering (unit, API, critical paths), data fixtures, failure criteria, and regression scope. The planning assistant reviews coverage gaps, such as permission combinations, concurrent writes, and UI state machines. The two communicate for several rounds to finalize the test plan before writing the scripts.

Parts not covered by automation, especially UI layout, animations, focus order, and overflow at different resolutions, require manual testing. In practice, defects encountered by non-professional developers mostly center on UI states and copy, not algorithms. Create a separate defect queue for such issues, and write the minimal reproduction steps back into the “Known Limitations” section of the harness to prevent the next round of assistants from “kindly” breaking already-tuned interactions.

5. Document Granularity and Convergence Criteria

The harness isn’t better the longer it is; clauses must be verifiable. Use three criteria to decide when to end the discussion:

1. No new unverifiable clauses: Every clause corresponds to a test or check item.
2. No substantive objections: Neither party raises substantive objections for a consecutive round.
3. Stable dependency graph: The module dependency graph is stable, with no temporary “utility module” bloating.

If the discussion diverges, return to the success criteria and delete features that don’t serve them. For non-programmers, exercising restraint on scope is more important than pursuing architectural elegance.

6. Human Role: Judge, Not Coder

The human’s responsibilities in the process are: finalizing scope, confirming business semantics, supplementing UI tests, and choosing the simpler solution when assistants are deadlocked. Do not let assistants endlessly debate style issues. When audit opinions conflict with the harness, the harness prevails and the document is updated, rather than tacitly allowing code exceptions, otherwise constraints will quickly become invalid.

7. Reusable Minimal Toolchain (Neutral Capabilities)

There is no need to bind to a specific vendor. A general capability combination can support this process: code repository with branch protection, continuous integration running tests, object storage for build artifacts, logging service and monitoring alerts for runtime observation, and documents stored in the same repo directory for assistant retrieval. Cloud container platforms can be used for isolated staging environments to avoid “the assistant says it runs, but the machine fails” scenarios caused by local environment differences.

8. Conclusion

The core of dual-assistant collaboration is not stacking models, but using documents to string planning, implementation, auditing, and testing into an auditable closed loop: first converge the harness, then develop modularly, cross-audit each module, finalize test plans through adversarial debate, and finally have humans supplement UI and business judgment. For non-professional developers, this rhythm turns “one-off generation” into “iterative delivery,” transforming intelligent programming tools from chat partners into constrained production line components.