Beyond Multiple Chats: Real Role Division in AI-Assisted Development

Introduction

The author previously proposed a working method where architecture, development, and testing operate in relatively independent threads with distinct responsibilities. When development discovers design gaps, it does not guess answers but returns to the architecture role to complete the design baseline. This article demonstrates how that method runs in an actual small project, focusing on collaboration between architecture and development roles.

Core Insight: Role Division Is Not Just Running Multiple Agents

Simply naming two threads "Architect" and "Developer" and letting both freely pursue a vague goal does not constitute role division; it merely duplicates uncertainty. True role division requires at least four elements:

What each role is responsible for

What each role must not decide

What deliverables the roles use to collaborate

Which responsibility boundary to return to when problems arise

Role Boundaries in This Case

The two core roles have the following boundaries:

Architecture Role

Main Responsibilities: Requirements analysis, boundary design, system design, development readiness, running or demonstrating development outcomes, implementation consistency checks

Core Deliverables: Requirements, design, interfaces, data models, decisions, technical validations, acceptance baselines, implementation deviation lists

Must Not Handle: Changing requirements for implementation convenience; directly modifying business code when implementation deviations are found — instead, feedback to development role

Development Role

Main Responsibilities: Reading design, splitting implementation, frontend/backend development, building and testing

Core Deliverables: Code, migrations, test results, runtime evidence, design gaps

Must Not Handle: Adding unconfirmed business rules in code; directly modifying requirements and design documents (may propose changes)

Boundaries are not mechanically split by file type. The architecture role performed a limited backend skeleton and dependency baseline validation to confirm the technical approach could run, explicitly excluding business interfaces, business tables, and collection logic. The key isolation is decision responsibility, not an absolute ban on architecture writing verification code.

The author acts as the Human-in-the-Loop decision maker and coordinator, providing business facts, confirming trade-offs, deciding on scope changes, and routing development-discovered issues to the appropriate role.

Project Context

The project extends an existing data statistics function. Goal: unify aggregation of data from databases, object storage, search engines, Linux directories, and external system reports; compute counts and capacities per multi-level directory; provide backend configuration, periodic collection, and page display. Though functionally small, it covers the full chain from requirements through design to development verification.

Step 1: Understand the Legacy System First

Because the project builds on existing functionality, the architecture role first read relevant controllers, services, configurations, and data access code to answer specific questions:

What data is currently being counted?

Sources: database, object storage, or search engine?

How does each source calculate count and capacity?

Relationship between scheduled tasks and query interfaces?

Which capabilities can be reused, which implementations only suit the old system?

This step establishes facts before designing new solutions. Skipping it risks reinventing existing capabilities or mistaking old limitations for new requirements.

Requirements Converge Through Continuous Questioning

Initial requirements only stated the goal and rough scope. Through ongoing discussion, additional items emerged: Linux directory collection, external system active reporting, directory sorting, homepage display positions, tag control, scheduling strategy, and database snapshots. Several rules surfaced only during review:

Can a parent directory directly bind a statistic item?

When homepage shows only some directories, should totals cover displayed range or all data?

When a source collection fails, should parent aggregation use zero, exclude failed items, or use last successful value?

Can database records, object counts, search documents, and file counts share a single "resource count" metric?

Does page query access external systems in real time or read published aggregation snapshots?

Each undecided point could cause divergent understanding in data models, interfaces, and pages. The architecture role wrote conclusions back into the requirements document after each round, then re-checked for omissions and conflicts. The requirements document thus became a progressively converged baseline through multiple cycles of "raise question → confirm rule → update baseline → re-review," not a one-shot generation. This embodies the author's view of SDD: the focus is not writing many documents upfront, but giving confirmed requirements and boundaries a more stable carrier than chat logs.

Design Completion ≠ Ready for Development

After requirements stabilized, the architecture role produced module design, data model, API draft, page states, database schema, migration strategy, and acceptance criteria. However, the author did not let development start full implementation immediately. Instead, he asked: "Are we ready to enter development?" The first answer was No-Go . Reasons:

API still a draft, not frozen

Database tables, indexes, and migration plan lacked an executable baseline

Page fields, states, and interactions insufficiently detailed

Development execution scope and non-goals not explicit

Some environment, security, and deployment decisions still affecting implementation

This judgment is critical: many AI programming projects mistake "already discussed" for "ready for development." After completing limited technical validation, the author continued supplementing design, repeatedly asking the architecture role to do only completeness checks without expanding implementation scope. The architecture role's responsibility is to advance the system to a state where development can proceed with less guessing and rework, not to write code for development.

Development Role Also Does Not Start Coding Immediately

Upon entering, the development role's first task was to read requirements, design, API, and current codebase, distinguishing three categories of facts:

What the documents have defined

What the current code has implemented

What is missing between the two

When design documents changed, the development role re-read and re-checked rather than relying on old conversation memory. Only after confirming the current module met entry conditions did implementation begin.

Implementation proceeded in small increments: first aligning and completing frontend/backend project scaffolding, then database migrations, domain objects, admin interfaces, pages, collection capabilities, and verification. Each task carried its own scope, non-goals, checklist, and done criteria.

Development must leave objective evidence: backend tests, frontend builds, database migration verification, interface contract checks, and runtime results. A demonstrable feature does not equal design compliance; passing tests does not equal production release gates being satisfied.

When Development Finds Design Gaps, It Must Not Invent Answers

The most critical collaboration occurs when development cannot proceed. Issues fall into four categories with distinct handling paths:

Implementation error → Fixed within development role, re-test

Design missing or conflicting → Return to architecture role to supplement design baseline

Environment unavailable → Mark as environment block, do not disguise as code complete

High-risk decision unconfirmed → Wait for human confirmation before continuing

Current tools cannot automatically hand off between roles; the author manually routes design issues to architecture, which updates documents, then notifies development to re-read and resume. This path ensures development does not bake temporary judgments into permanent design, and architecture does not carry long-term coding tasks, staying focused on overall design consistency.

Mid-Project Scope Change Exposes Baseline Drift

Midway, the author handed part of the project to others and added features. Original baseline: 3 top-level menus, 9 pages, 41 API operations. New scope: 4 top-level menus, 10 pages, 46 API operations. The numbers themselves don't conflict — they belong to different phases. The real problem: new features only updated some requirements, design, or interface materials without a full baseline upgrade. Result: some documents described v2, while implementations and machine-readable contracts (OpenAPI) remained at v1.

Architecture's final consistency check revealed missing pages and interfaces, API draft vs OpenAPI operation count mismatch, a delete interface's HTTP method and path deviating from frozen contract, and debug interfaces not promoted to formal contract. This exposed not unclear role responsibilities, but lack of a unified entry point for baseline changes. External contributors' deliverables cannot become global facts directly; they must be reviewed and merged by architecture before a new design baseline is published.

Role Handoffs Cannot Rely on Chat Logs Alone

When one role hands work to another, at least six items must be clear:

Design Baseline — Which version of requirements and design is the current basis?

Scope & Non-Goals — What is being done this round, and explicitly what is not?

Inputs & Outputs — What materials are depended on, what deliverables are expected?

Done Criteria & Evidence — What state counts as done, where is the evidence?

Design Gaps — Which issues must be decided by the upstream role?

Impact Scope — Which code, documents, and tests may become invalid after the change?

For mid-project additions, a change package is needed: what was added, which old design it replaces, affected pages, interfaces, tables, tests, and which completed results need re-verification. Without these, multi-role collaboration devolves into parallel evolution of multiple contexts — each role locally consistent but globally conflicting.

If later upgrading this manual collaboration to an executable task graph, these handoff items can be structured as fields like baselineVersion, scope, doneWhen, designGaps, and affectedArtifacts. But in the manual phase, ensuring someone answers these questions matters more than designing a complex protocol.

What This Case Shows and Does Not Show

It shows:

Independent roles reduce cross-context contamination. Architecture focuses on goals, boundaries, design consistency; development focuses on implementation, build, test. Neither must carry all information simultaneously.

Design baselines reduce free guessing during development. Development can stop and feed back when decisions are missing, rather than picking a seemingly reasonable implementation to "complete the task."

Development readiness checks and final consistency checks are valuable. The former prevents immature designs from entering full implementation; the latter catches "lots of code, lots of tests, but still not meeting current design."

It does not cover: full automated multi-agent collaboration. Issue routing and baseline notifications remain manual; testing not fully assigned to an independent test role; some threads ran long, causing context compression and inconsistency between old context and latest baseline. Thus it primarily demonstrates architecture-development collaboration, not a complete closed loop of architecture, development, testing, etc.

More accurately: "I used manual orchestration to run a small task graph containing architecture, development, external collaboration, and verification nodes."

Where SDD, Harness, Loop, and Graph Land in This Case

SDD — Provides stable R&D basis via requirements and design documents

Harness — Constrains context, responsibilities, tools, modification scope, and verification methods for each role

Loop — Lets each role complete its tasks through execute-check-correct-reverify cycles

Graph — Organizes dependencies and issue dispatch among architecture, development, external collaboration, and verification

Summary

This case further illustrates that different roles bearing different responsibilities is an effective AI programming approach. Its value is not spawning more threads or having multiple agents generate more code, but letting requirements, design, implementation, and verification each return to the correct responsibility boundary and pass results through stable deliverables.

The more roles, the more design baselines, change merging, and impact analysis are needed. Otherwise, multiple roles do not naturally yield collaboration; they only produce multiple locally consistent but globally conflicting facts.

Therefore, what multi-role AI programming truly needs to design is not just role prompts, but the responsibilities, deliverables, states, feedback paths, and completion evidence between roles.