Ten AI coworkers, four departments, one human. A practical tour of who does what — and what each one needs, does, and hands on.
In the introduction to SDAIS I argued for an inversion: humans author requirements, AI synthesises everything else, and the specification can never fall behind the code because the code is always derived from it. That post named a team of specialists but moved on quickly. This one slows down and introduces the team properly.
The most useful way to think about SDAIS day to day is not “I am prompting a model.” It is “I work with a team.” You are the one human in the room — the Requirements Engineer. Everyone else AI coworkers with a desk, an in-tray, a job, and an out-tray. You hand work to them, they hand work to each other, and eventually annotated, reviewed, verified code lands back with you. Nobody on the team writes implementation code except the coworkers; nobody writes requirements except you.
A coworker is easiest to understand through three questions. What lands in their in-tray (the input)? What is their job? What goes into their out-tray, and whose desk does it land on next (the output)? I’ll describe every role and how they’ll do their work below .
The Team at a Glance
Ten AI coworkers across four departments. And you sit at the top as the only human; the Requirements Specification Files (RSF) are the single source of truth everyone works from.
The team is organised into four departments that map onto the phases of the work. The Specification Office turns your raw requirements into a cleared, audited specification. The Synthesis Floor turns that specification into reviewed, verified code through a tight loop. Quality Assurance adds optional security and test coverage at any point after generation. And the Re-Engineering Wing is an alternative entrance for projects that begin with an existing codebase rather than a blank page.
Work flows downhill from your desk, but findings flow back uphill to you constantly. That return path is the point: when a coworker cannot proceed honestly, they do not improvise — they raise a finding and wait.
This is still a weakness in the current version, v0.9.0. It is easy to see that the current version follows a waterfall model, even if the implementation is then iterative and incremental. However, this does not apply to the continuous addition of new features; it serves only to fulfil the requirements that have already been defined to a high standard. Subsequent versions are intended for the continuous extension, modification or removal of requirements. Accordingly, the prompts still need to be modified so that they create a modular system in the architecture and generation, regardless of size.
The Specification Office
This department never sees code. Its entire job is to make sure the specification is sound before a single line is synthesised, because everything downstream inherits its quality.
SemanticAuditor
The SemanticAuditor is the coworker who reads your requirements with deliberate suspicion. Input: the authored RSF items for a version — Functional and Non-Functional Requirements, Constraints, Environment items, and Acceptance Criteria. Task: read them as a whole and surface every defect before code exists, flagging items that are AMBIGUOUS, INCOMPLETE, CONTRADICTORY, INFEASIBLE, UNTESTABLE, or UNQUANTIFIED — the last of which catches the classic “the system must be fast” with no number attached. Output: Requirements Audit Report (RAR) findings, one file per finding, each pointing at the item it concerns. The specification is only Cleared once every finding is resolved or consciously waived. Because the work is detecting subtle contradictions in natural language, this is a role for a model strong in reasoning.
Grounder
The Grounder is the coworker who checks that the world the specification assumes actually exists. Input: the Environment (E-) items of the RSF, plus read access to the real target infrastructure. Task: confirm that every environment fact the specification relies on is real — the database connection, the runtime target, the infrastructure assumption. It verifies; it does not invent. Output: a RAR finding for each element it cannot confirm, so you can correct either the specification or the environment before generation begins. The Grounder is modest in cognitive demand but distinguished by something the others lack: access to the actual deployment environment.
Designer
The Designer is an optional but valuable coworker who sketches the building before anyone pours concrete. Input: all cleared RSF items. Task: bridge specification and implementation by producing a module decomposition, the API surface, the data flows, and the explicit design decisions — each one traceable back to the RSF item IDs that justify it. Output: the Architecture Definition File (ADF), which you review and approve before code is written. The ADF guides the shape of the implementation, but it is not authoritative: if the ADF and the RSF ever disagree, the RSF wins.
The Synthesis Floor
This is where code is born and made correct. The three coworkers here run the loop that the introduction called quality as an emergent property: no first pass is perfect, so quality is iterated into existence rather than assumed.
Generator
The Generator is the coworker who writes the first complete draft. Input: the cleared RSF, plus the ADF as structural context when one exists. Task: synthesise a complete, idiomatic implementation from the requirements, choosing data structures and strategy freely within the stated constraints — and wrap every unit in an [ANN] block carrying its (ANN-ID), (ORIGIN), (TASK), (PRE)/(POST), (AGENT), (ROUND 0), and (VERIFIED false). Output: annotated source code — round 0 of the implementation — handed straight to the Reviewer. Producing correct, structurally sound code at scale is a job for a strong coding model.
Reviewer
The Reviewer is the coworker who reads the code against the contract. Input: the annotated code together with the RSF and the ADF. Task: check every [ANN] block against both the requirements and the actual code — is the (TASK) really implemented, are the (PRE)/(POST) conditions honoured, is every constraint respected, is every active RSF item covered, is every Acceptance Criterion confirmed? It also runs the (DEPENDS-ON) cascade so that a unit found broken automatically flags its dependents before the error can propagate silently. Output: findings written directly into each block as co-indexed (FINDING:n), (SEVERITY:n), and (HINT:n) labels, with the (VERIFIED) flag set per block. One discipline matters more than the tier here: the same Reviewer model should review every round, so findings are interpreted against a constant baseline.
Refiner
The Refiner is the coworker who acts on the Reviewer’s notes. Input: the annotated code carrying the Reviewer’s findings and hints. Task: resolve each violation guided by its (HINT) — and, crucially, where a finding genuinely cannot be fixed without changing the requirements, mark it Waived — requires RSF amendment rather than forcing a workaround that would quietly break the audit trail. Output: refined code with each (FINDING:n:STATUS) recorded; once a block has no open findings, its (VERIFIED) becomes true. Control then returns to the Reviewer, and the loop repeats until the Reviewer has nothing left to raise.
Quality Assurance
Two coworkers you can call on at any point after generation. Neither is mandatory; both feed their findings back into the same refinement loop.
SecurityAuditor
Input: the generated and refined annotated code. Task: audit the implementation for security weaknesses — unsafe input handling, secret exposure, missing authorisation, and similar classes — reading each [ANN] block to understand what the unit was meant to do, not just what it does. Output: security findings for you and the refinement loop to act on. Like the SemanticAuditor, this is reasoning-heavy work.
TestGenerator
Input: the cleared RSF — the Acceptance Criteria above all — and the generated code. Task: author an executable test suite that exercises each Acceptance Criterion’s inputs, expected outputs, and observable side effects, linking every test back to the requirement it verifies. Output: a test suite traceable to the ACs and RSF items it covers. Because the AC already specifies what verifiable means, the TestGenerator’s job is largely one of faithful, idiomatic translation into tests.
The Re-Engineering Wing
SDAIS is not only for greenfield work. The SDAIS-RE extension addresses the far more common case: an existing system, built without a formal specification, that needs to migrate, modularise, or simply acquire a specification at all. The inversion still holds — you just start from code instead of from a blank page.
Analyzer
The Analyzer is the coworker who reverse-engineers intent without touching behaviour. Input: an existing codebase, plus rough RES hypothesis files in which you record what you believe the system does, each carrying a Confidence level. Task: read the legacy code and — without changing a line of its logic — add [ANN] blocks additively, derive formal RSF items from observed behaviour, and open findings for anything that cannot be cleanly mapped to a requirement. It assigns the permanent (ANN-ID) that each unit will keep for the rest of its life. Output: three artefacts at once — an annotated codebase, a derived RSF, and RAR findings — which then flow into the standard semantic audit loop.
Re-engineering
The Re-engineering coworker performs the transformation itself. Input: the annotated codebase with a now-cleared RSF, plus one or more Change Definition Files (CDFs) — orthogonal transformation axes such as lang-, ui-, pers-, mod-, plat-, api-, obs-, and i18n-, several of which can apply in a single pass. Task: apply those CDFs — a language migration, a modularisation, a new persistence layer — while preserving every (ANN-ID), so the audit trail survives even a complete rewrite. A unit that began life as a Java method annotated ANN-c9e05a31 carries that same identifier into the Go function that replaces it. Output: a transformed, still-annotated codebase, ready to enter the Review → Refine → Approve loop exactly as a greenfield project would.
How the Work Travels
A team of stateless coworkers has an obvious problem: the Reviewer in round four has no memory of what the Generator intended in round zero. SDAIS solves this without shared memory by letting the work carry its own history. The [ANN] block is the shared note that travels with the code from desk to desk, and every coworker writes on it.
One annotated unit at three moments: the Generator creates the block, the Reviewer appends a finding, the Refiner resolves it and flips (VERIFIED) to true.
This is the inter-agent protocol in action. The Generator records the unit’s identity and intent. The Reviewer appends a co-indexed finding, its severity, and a hint. The Refiner records the resolution and, when nothing is left open, sets (VERIFIED) true — after which the unit is left untouched in later rounds unless one of its dependencies changes. No coworker needs to remember the conversation, because the conversation is written into the code.
Why a Team, and Not One Model
It would be simpler to point a single capable model at the whole pipeline. SDAIS deliberately does not, because the phases reward different cognitive strengths. Finding a hidden contradiction between two requirements is a different task from generating idiomatic code at scale, which is different again from translating an Acceptance Criterion into a test. Assigning a recommended capability tier to each role — reasoning-strong for the auditors and the Designer, coding-strong for the Generator, Refiner, and TestGenerator, a deliberately constant model for the Reviewer — is what makes the review loop converge reliably rather than producing inconsistent findings from round to round. The tiers on each card above are recommendations, not rules; the principle is to match the coworker to the work.
The Same Idea, From the Other Side
The introduction made the case structurally: the specification is the source of truth because the process makes it impossible for it not to be. The roles are the other half of that same idea. Each coworker is narrow on purpose, hands off explicitly, and refuses to paper over a conflict — it raises a finding and waits for you. The specification stays authoritative not because the team is disciplined, but because no coworker is permitted to quietly work around it.
That is what the team is for. You specify; they synthesise, review, refine, and remember. And the chain from intent to artefact is documented at every desk it passes.
The methodology is developing in the open. The current version is v0.9.0 on Codeberg — codeberg.org/tideland/sdais — where the full normative specification, the greenfield and re-engineering workflows, and the prompt files for every role described here are available to read and use.
