Multi-Agent Collaborative Programming: A Complete Workflow from Requirements Analysis to Testing

I. Introduction: The Value and Limitations of AI Coding Tools

As Large Language Model (LLM) technology matures, AI-assisted programming has evolved from simple code autocomplete to full-chain support encompassing “requirement understanding, code generation, and test validation.” However, single-agent tools often suffer from “memory drift,” “hallucinated code,” and “context window limitations,” leading to frequent errors in complex projects. Maximizing the complementary advantages of multiple AI assistants to form a systematic collaboration mechanism has become a core issue for developers, especially non-professional programmers.

Based on practical project experience, this article proposes a “dual-agent adversarial and collaborative” development model. This model does not rely on any vendor-specific product. Instead, it abstracts general role assignment, workflow orchestration, and quality gate methods, making it adaptable to mainstream AI coding tools (such as general LLM chat interfaces or CLI-based coding assistants). All terms used are general concepts that readers can map to their own preferred tools.

II. Core Concept: From “Lone Ranger” to “Multi-Role Game”

In traditional AI-assisted programming, developers typically use a single tool for all tasks. However, differences in training data, reasoning preferences, and interface styles among tools can lead to the following issues:

• Single-perspective blind spots: The same model tends to repeat the same types of errors and lacks self-review capabilities.
• Requirement misunderstanding: Orally described requirements are unstructured, preventing the model from accurately breaking them down.
• Insufficient test coverage: Test cases generated by a model often share the same source as the code being tested, making it difficult to discover boundary conditions.

The “dual-agent collaboration” model proposed in this article borrows the “Red Team/Blue Team” concept from software engineering: one agent is responsible for “constructive output” (e.g., requirement refinement, code implementation), while the other handles “critical review” (e.g., logic checks, security audits). Through multi-round interactions, the two agents converge their differences into consensus, ultimately producing high-quality deliverables. This model is particularly suitable for individual developers or small teams without dedicated QA personnel.

III. Complete Workflow Design

3.1 Phase 1: Requirement Discussion and Harness Document Generation

Objective: Transform vague ideas into verifiable, structured requirement specifications (Harness documents).

Steps:

1. Initial Conversation: Use Agent A (referred to as the “Executor”) for a free-form discussion, stating business goals, user scenarios, and constraints (e.g., performance, compliance, deployment environment). Do not rush to write code; let the AI guide the breakdown of functional points.
2. Generate Harness: Ask the Executor to output a document containing:
   • Functional module division (including dependencies)
   • Input/output definitions for each module
   • Exception handling and boundary conditions
   • Non-functional requirements (response time, security level)
   • Acceptance criteria (testable behavior descriptions)
3. Manual Review: Non-programmers can check whether the requirements cover daily usage logic, focusing on scenarios like “What happens if the user inputs illegal characters?”

Example Harness snippet (using generic descriptions):

Module: User Login
- Input: Username (string, length 6-20), Password (8+ chars containing numbers and letters)
- Output: Session token (valid for 24 hours)
- Exception: Account locked after 5 consecutive errors, requires manual unlock
- Acceptance: Returns token for correct credentials, returns clear error code for incorrect credentials

3.2 Phase 2: Solution Review and Rebuttal Loop

Objective: Ensure the technical implementation path of the Harness document is reasonable and eliminate logical flaws.

Implementation:

1. Submit the Harness document to Agent B (referred to as the “Reviewer”), asking it to propose optimization suggestions, potential risks, or rebuttals from an independent perspective.
2. Return the review comments to the Executor, asking it to respond with “accept/reject” and provide reasons. For example:
   • Reviewer: “The login module should add a CAPTCHA mechanism to prevent brute-force attacks.”
   • Executor: “Accepted, but the impact on user experience needs to be evaluated. I suggest using a slider verification instead of a graphic CAPTCHA.”
3. Conduct multiple rounds (usually 3 to 5) until consensus is reached. Record a changelog for each iteration for traceability.

Key Tip: Explicitly state in the prompt, “Please review with critical thinking, do not just affirm,” and set a constraint like “must find at least 3 issues” to prevent the AI from being perfunctory.

3.3 Phase 3: Code Implementation and CLAUDE.md Constraints

Objective: Perform modular coding based on the finalized Harness document, ensuring consistent code style and standards.

Practices:

• Create a project-level specification file (e.g., PROJECT_GUIDE.md or AGENTS.md) containing:
  • Programming language versions and framework conventions
  • Naming conventions, comment requirements
  • Error handling patterns (e.g., unified exception classes)
  • Forbidden dangerous functions (e.g., eval)
  • Test frameworks and coverage thresholds
• Modular development: Generate code for each module independently and place it in the corresponding directory immediately to avoid context confusion from generating the entire project at once.
• Incremental feedback: After completing a module, paste the code to the Executor, ask it to self-check against the Harness item by item, and output a “satisfied/not satisfied” checklist.

Example Prompt Template:

You are the backend developer for this project. Please implement the [Module Name] function strictly according to the project specifications. Requirements:
1. Every function must have a docstring and type annotations.
2. All external inputs must be validated.
3. Do not use dynamic execution functions.
4. Output a self-check checklist upon completion.

3.4 Phase 4: Code Audit and Multi-Round Confrontation

Objective: Discover logical defects, security vulnerabilities, and dead code in the implementation.

Process:

1. Submit the generated module code to Agent B for an audit, requiring it to output:
   • Code quality score (quantifiable dimensions: readability, performance, security)
   • Specific issue list (including code line numbers, severity levels, modification suggestions)
2. Hand the audit results to Agent A (Executor), asking it to respond item by item: fix plan, whether to reject and why.
3. For disputed items (e.g., “Is this exception catch necessary?”), human judgment can be introduced. However, in most cases, an agreement can be reached after two rounds of confrontation.

Important Principle: The audit should not only look for “bugs” but also check whether the code meets the “acceptance criteria” defined in the Harness. For example, if the Harness requires “throw an error when input string length exceeds 20,” and the code does not actually enforce this limit, it must be fixed.

3.5 Phase 5: Automated Test Plan Design and Execution

Objective: Generate test cases covering core paths and boundary conditions, and run them automatically.

Recommendations:

1. Test plan design: Have Agent B (Reviewer) design a test plan based on the Harness document, including:
   • Unit tests (normal/abnormal inputs for each function)
   • Integration tests (inter-module interactions)
   • End-to-end tests (key user flows)
2. Test code generation: Give the test plan to Agent A to generate executable test code (e.g., using general frameworks like pytest or JUnit).
3. Run and debug: Run the tests locally or in a CI environment. If a test fails, provide the error logs to both agents simultaneously, let them analyze the root cause and suggest fixes respectively, and choose the better one after comparison.

Note: AI-generated test cases may be “self-referential”—designing tests based on the implementation of the code under test rather than the requirements. Therefore, the test plan must precede the test code, and the Harness must be the sole basis.

3.6 Phase 6: Manual Supplementary Testing and UI Fixes

Objective: Cover interactive experiences and visual details that AI struggles to simulate.

Manual Testing Focus:

• Page layout: element alignment, font display, responsive adaptation
• Interaction flow: click sequence, keyboard navigation, loading state prompts
• Compatibility: different browsers, different OS versions
• Perceived performance: large file uploads, list scrolling, animation smoothness

Fix Strategy: When a UI bug is found, paste the screenshot or description to the Executor, asking it to locate the potentially related code module and propose a fix. If it involves pure frontend styling issues, you can manually adjust using developer tools and then ask the AI to generate a patch.

IV. Collaboration Tips and Prompt Design

4.1 Role Setting Templates

• Executor: You are a rigorous software engineer skilled at translating requirements into high-quality code. Your responsibility is to ensure the correctness and maintainability of the functionality.
• Reviewer: You are a senior QA engineer who reviews design documents and code with a critical eye. You must point out any potential risks, even if they seem unlikely to occur.

4.2 Iterative Convergence Strategy

• Set a maximum number of interaction rounds (e.g., 5 rounds) to prevent endless debate.
• After each round, manually write the mutually agreed conclusions into a “decision log” to avoid repetitive arguments.
• For issues where consensus cannot be reached, pause and switch to human decision-making or break them down into smaller sub-problems.

4.3 Context Management

• Due to limited conversation window lengths, it is recommended to reference the Harness document, specification files, and current code snippets as separate files rather than pasting them directly into the prompt.
• Use “summarize previous conclusions” to compress context, e.g., “Last time we agreed that the login module should use JWT tokens. Now please implement this module.”

V. Case Study: A Non-Programmer Developing a To-Do List Application

Suppose we need to develop a Web application with the following features: user registration/login, task creation, marking tasks complete, and filtering by priority. Here is a simplified workflow demonstration:

1. Requirement Discussion: Chat with the Executor to list features and generate a Harness document (including database table structures, API definitions).
2. Review and Rebuttal: The Reviewer suggests “task deletion requires secondary confirmation” and “password storage must be salted.” The Executor accepts and updates the document.
3. Code Implementation: Generate backend (e.g., Python Flask) and frontend (e.g., HTML/CSS/JS) code according to the Harness. Paste each generated file back into the chat for self-checking.
4. Audit Confrontation: The Reviewer discovers “no type check on task ID, which may cause SQL injection.” The Executor fixes it and adds parameterized queries.
5. Test Plan: The Reviewer designs test cases: registering a duplicate username, deleting a non-existent task, filtering an empty list. The Executor generates the test code, and all tests pass.
6. Manual Supplementary Testing: Testing the registration form in a browser reveals that the “show/hide” button for the password field doesn’t work. The issue is fed back to the Executor, fixed, and completed.

The entire project took about 6 hours (including AI response waiting time), whereas traditional manual coding might take 2 to 3 days. More importantly, the readability and standardization of the final code far exceed individual writing levels.

VI. Common Issues and Solutions

• Issue 1: The two agents are overly polite to each other with no substantive confrontation.
  Solution: In the prompt, require “must point out at least 1 fatal flaw” and “only use factual evidence, no vague expressions.”
• Issue 2: Generated code relies on specific third-party libraries without declaring them.
  Solution: Explicitly state in the specification file that “dependency declarations must be written to requirements.txt or package.json,” and require checking dependency legality during the audit phase.
• Issue 3: Test coverage is artificially high, but key paths are untested.
  Solution: Require the test plan to include “negative testing” (incorrect input, illegal operations) and “extreme value testing” (extra-long strings, concurrent requests).
• Issue 4: AI introduces new issues when fixing bugs.
  Solution: After each fix, immediately run the existing test suite and have the Reviewer compare the output differences before and after the fix.

VII. Conclusion: From Tool User to Process Designer

The essence of multi-agent collaborative programming is upgrading AI from a “code generator” to a “team member.” By assigning different roles, designing interaction protocols, and establishing quality gates, even those without top-tier coding skills can deliver production-grade software. The value of this model lies not only in efficiency improvements but also in cultivating systematic thinking—before writing the first line of code, you have already completed requirement convergence, solution validation, and test planning. This is exactly what modern software engineering emphasizes as “built-in quality.”

Finally, remember: AI is an amplifier, not a replacement. Your domain knowledge, product intuition, and judgment are the core of the process. Make good use of the dual-agent model, let them challenge and refine each other, and you will find yourself getting closer to the goal of being a “one-person army.”