AI Agent Software Factory: Multi-Role Collaboration in Software Delivery

1. The Real Variable Is the Measurement, Not “Who Writes the Code”

When a senior practitioner maintains a full-time management role while also producing at high intensity, the industry’s first reaction is usually to question the numbers. The more useful question is different: what exactly is the measurement basis behind a claim like “several times the efficiency”?

Measuring generative coding output in raw lines of code is almost guaranteed to distort. Large models have a stable redundancy bias on the generation side: they tend to add defensive branches, expand simple flows into multiple layers of abstraction, and pre-provision code paths for rare scenarios that are never called. The result is that line counts balloon quickly, while the semantic changes that are actually validated, merged, and shipped to production grow slowly. This kind of “paper capacity” cannot be converted into value, and it raises the downstream cost of reading, review, and maintenance.

A more robust approach swaps the unit of measurement from “characters” to “semantic units” — what the industry usually calls logical lines of change:

• Change-point count: the number of semantically independent behavior changes in a merge request, not the number of lines added to new files. Under a single requirement, “add an endpoint + fix one validation + add a set of tests” counts as 3 change points, regardless of implementation length.
• Behavior diff: input/output changes covered by executable tests. Changes that cannot be observed by a test count as zero output.
• Defect density: defects introduced per unit of logical change, used to offset the hidden cost of “writing fast but reworking more.”
• Review and regression time: agent-generated portions are often heavily rewritten during review, and this cost has to be counted in the numerator.

Equal honesty is required here: any multiplier conclusion spanning more than a decade has a numerator and a denominator shaped by measurement definitions, task difficulty distribution, and survivorship bias. Such a number can serve as a trend judgment, not as a performance metric. What engineering teams should actually watch are reproducible local measurements — delivery cycle time for comparable tasks, first-pass review acceptance rate, and post-release rollback rate.

2. From an Autocomplete Tool to a Software Factory: Making Implicit Judgment Explicit

Single-model, single-session coding assistants share one failure mode: all quality responsibility is packed into one context. The same context has to understand the requirement, design the structure, and self-check for defects, which typically yields “acceptable implementation, rough details, uncontrolled edge cases.” A workflow built from multiple role-specific agents is, in essence, a way of decomposing the implicit judgment that individuals normally carry through experience into responsibilities that are describable, verifiable, and independently assessable.

A workable role breakdown looks like this. Every role needs explicit inputs, deliverables, and acceptance criteria:

Role	Input	Deliverable	Acceptance criteria
Product owner	User requests, constraint list	Requirement spec and acceptance conditions	Every requirement maps to one executable assertion
Architecture review	Current architecture, dependency topology	Design notes and trade-off record	Rejected alternatives and reasons listed explicitly
Implementer	Design notes, interface contract	Small, independently revertible change set	One responsibility per change point, tests included
Design review	UI changes, interaction flows	Defect list (consistency, readability)	Reproducible steps given for each item
Code review	Change set, coding standards	Review comments and blocking items	“Must fix” separated from “suggested”
QA	Acceptance conditions, runtime environment	End-to-end test results	Main paths and key exception paths covered
Security audit	Data flows, permission boundaries	Risk list with remediation advice	Input validation, credentials, privilege escalation covered
Release engineering	Reviewed and approved changes	Merge request and release record	Rollback plan and observability metrics in place

The value of these roles is not the titles but context isolation: a reviewer should not be influenced by the fact that “I wrote this code,” and a security auditor should not reuse the implementer’s optimistic assumptions. Letting each role see only the material it needs, in an independent context, is the key mechanism for suppressing homogenized bias.

3. Workflow Orchestration: Human Gates That Bound Autonomy

The higher the autonomy, the wider the blast radius of a single mistake. For that reason, the more reliable engineering shape is a “staged pipeline plus human decision gates” rather than a fully automatic closed loop. A sketch of the orchestration configuration:

pipeline:
  - stage: spec
    owner: product_owner
    output: [requirements.md, acceptance.md]
    gate: human_approval        # requirements and acceptance conditions must be confirmed by a human
  - stage: design
    owner: architect_reviewer
    output: [design.md, rejected_alternatives.md]
    gate: human_approval
  - stage: implement
    owner: implementer
    constraints:
      max_change_points_per_step: 3
      require_test_with_change: true
  - stage: review
    parallel: [code_reviewer, design_reviewer, security_auditor]
    blocking_severity: [critical, high]
  - stage: verify
    owner: qa
    actions: [unit_tests, contract_tests, browser_e2e]
    environment: ephemeral_container
  - stage: release
    owner: release_engineer
    require: [all_blocking_cleared, rollback_plan_present]
    post_checks: [error_rate, latency_p95, business_metric]

A few practices go with it:

1. Spec first. Requirements must be translated into executable acceptance conditions; otherwise every downstream role is guessing at the same vague goal.
2. Bounded change granularity. Limiting the number of change points per step measurably reduces review fatigue and error propagation, and makes bisection for regression sources practical.
3. Verification before generation. Generation is the cheap stage; verification is the expensive one. The pipeline’s time budget should lean toward testing and review.
4. Failures are revertible. Each stage’s output should be independently discardable, so reworking one design does not contaminate the whole chain.

4. Context Engineering and Contract Constraints: The Two Variables That Set the Ceiling

The quality ceiling of agent output is often determined by what the agent “can see” and “what it is permitted to do,” not by model capability alone.

Layered context. Treat the repository as a knowledge base: the top layer holds non-negotiable engineering principles (coding standards, logging standards, error-handling strategy, prohibited practices), the middle layer holds module-level design notes and interface contracts, and only the bottom layer holds concrete implementation code. Retrieval should be trimmed to the task’s scope — filling the context window with irrelevant code is itself a quality killer, because noise degrades output.

Contract constraints. Fix interface signatures, data structure definitions, and error code semantics before implementation, so the implementing role can only fill in blanks within the established contract. This yields two direct benefits: changes become automatically verifiable (a contract test alone can flag a violation), and multiple roles working in parallel cannot break each other’s assumptions.

# Contract excerpt (illustrative)
endpoint: POST /orders
request:  { userId: string, items: [{ sku: string, qty: int>0 }] }
response: { orderId: string, status: enum(CREATED,PAID,CANCELLED) }
errors:   { 400: INVALID_ITEM, 409: STOCK_CONFLICT, 422: QUOTA_EXCEEDED }
invariant: order amount = Σ(item.price * item.qty), computed server-side as the source of truth

An invariant like “computed server-side as the source of truth” is exactly the input the security audit role depends on most. Many high-severity defects introduced by agents come down to placing the trust boundary on the client, or getting the order of validation wrong.

5. Verifying in a Real Environment: From “Looks Right” to “Is Right”

The thing generative implementations fool people with is that they look entirely reasonable. Verification therefore has to come as close to real runtime conditions as possible:

• Run end-to-end flows in a disposable, isolated environment. Never verify on a developer machine or a long-lived shared environment.
• The QA role should be able to actually drive a browser or an API, complete main paths such as registration, ordering, and failure retry, and produce screenshots, logs, and failing assertions.
• Security audit needs to cover two categories. One is the input side (injection, privilege escalation, bulk enumeration); the other is the process side (payment confirmation ordering, idempotency, concurrency races). A widely used web risk checklist and the six categories of threat modeling (spoofing, tampering, repudiation, information disclosure, denial of service, privilege elevation) make good checklists to work through item by item.
• All verification results should be persisted as structured reports that serve as the decision basis for the release gate, rather than living only in a session transcript.

6. Supporting Infrastructure and Security Boundaries

Running this pipeline stably requires not one point tool but a combination of general infrastructure capabilities: a container platform to provide isolated runtime environments, a code hosting and pipeline service to handle change integration, a logging service and monitoring/alerting to supply post-release observability feedback, a key management service to consolidate credentials, and an artifact repository to keep dependencies traceable. On Baidu AI Cloud, these capabilities can be combined as standard categories, with teams selecting what they need rather than binding to a specific implementation.

At the same time, the higher the autonomy, the further forward the security boundary must sit:

• Least privilege. The credentials an agent uses should reach only the resources the current task needs, with write access and production access separated by default.
• Human approval gates. Keep human confirmation for requirement sign-off, production release, permission changes, and deletion-type operations.
• Supply chain audit. New dependencies should be checked for source credibility, maintenance activity, and license terms; watch out for look-alike packages with confusingly similar names.
• Prompt injection defense. External content (web pages, documents, tickets, dependency READMEs) should be treated as untrusted data and never executed as instructions.
• Audit trail. Every automated change should be linked to a requirement ID, a review record, and a verification report for traceability and compliance checks.
• IP and data compliance. Generated content should go through licensing and similarity checks, and sensitive data must not enter uncontrolled external contexts.

7. Rollout Path

A three-phase approach is preferable to rebuilding the process in one shot:

• Phase one (about two weeks): change only the measurement basis. Stop reporting output in lines of code and switch to logical change points, review pass rate, and cycle time to establish a baseline.
• Phase two (about one month): introduce a two-role pipeline — an implementer plus an independent reviewer. The goal here is not speed but getting the “generate — review — fix” loop working smoothly and accumulating repository-level engineering standards documents.
• Phase three (ongoing): gradually add design review, end-to-end verification, and security audit roles. Grant high autonomy only to modules that already have automated tests, and keep human gates elsewhere.

8. Conclusion

What agents change is not that code becomes easier to write. They move the bottleneck of software engineering downstream as a whole: from “can it be implemented” to “can it be verified, maintained, and released safely.” Correspondingly, an individual’s core competitiveness shifts from hand-written implementation speed to requirement decomposition, contract design, verification system building, and quality judgment. What is worth copying is not a particular tool or a particular multiplier claim, but the methodology of making work explicit, automating verification, and narrowing permissions to what is strictly necessary — a methodology that applies to any team and does not depend on any specific product.