The human ecosystem

The five responsibilities — no rigid roles

In AIAD there are no "roles" in the traditional sense — one person, one title, fixed boundaries. There are responsibilities that must be assumed: a responsibility is defined by what must be done, not by an org chart.

Rigid roles create three problems: they produce "that's not my job" attitudes that leave responsibilities orphaned, they create boundaries that slow down decisions, and they discourage the contextual adaptability that hybrid human/AI teams require. AIAD replaces boundaries with fluid, context-driven responsibility: on a team of three, one member carries two or three responsibilities; on a team of eight, each one can have a dedicated owner. What matters is not who holds which title — it is that every responsibility is clearly assumed by someone.

Product Manager — owner of value

The PM makes sure the team builds the right things for the right people. Their central question: are we building the right thing? Without someone focused exclusively on value, teams build technically perfect features that nobody uses.

Concretely, they define the Product Goal (a four-to-twelve-week horizon), keep the backlog ordered by value, lead discovery (problem → solution → validation) and define the Outcome Criteria of each feature — then measure the actual impact after release. Four skills are non-negotiable: product strategy, discovery, analytics and mastery of trade-offs. Indicators: more than 70% of features meet their Outcome Criteria, and less than two weeks between user insight and release.

Product Engineer — guardian of intent

The PE is the guardian of intent throughout the cycle: they orchestrate AI agents to realise the intent without betraying it, and their responsibility does not end at merge. Agents know how to generate code; they know neither how to define what should be built, nor how to validate whether it is correct. The PE's value lies not in their ability to orchestrate — which can be standardised — but in their ability to protect the intent, which cannot be delegated (the Human Authorship value).

They write the SPECs, orchestrate the agents, validate the generated code, maintain the context (AGENT-GUIDE, patterns) and manage debt. Four skills: agent orchestration, architecture, quality thinking and product thinking. Indicators: first-time success rate > 70%, generated/manual code ratio > 80/20, test coverage > 80% backend and 70% frontend, intent/delivery alignment > 80%.

Agents Engineer — owner of the AI ecosystem

The AE builds and optimises the agent ecosystem that multiplies the team's capabilities. Their central question: is the ecosystem optimal? A poorly configured agent produces generic code; a well-calibrated ecosystem produces code tailored to the context — the difference lies entirely in the configuration investment. The ecosystem is structured into authority levels:

At level 0, the four regulatory guides activate based on the project context — personal data for AIAD-RGPD, an AI component in a European context for AIAD-AI-ACT. The EU AI Act timeline they apply is realigned on Regulation (EU) 2026/1744 (Digital Omnibus on AI): transparency (Art. 50) in force since 2 August 2026, high risk on 2 December 2027 for Annex III and 2 August 2028 for Annex I (full timeline). Below the four levels, the main agent (Claude Code, Cursor, Copilot…) generates the code.

Their core practice is Harness Engineering: selecting and configuring agents, defining their authorisation scopes under the minimal necessary permissions principle — an agent only has access to the resources strictly necessary for its mission —, monitoring behaviour in production and adapting continuously. A code-generation agent does not need production access; a documentation agent does not need the secrets registry. Selection follows four principles: start minimal, add by pain, remove by obsolescence, optimise by measurement. Indicators: adoption > 90%, false positives < 20%, PE satisfaction > 8/10.

A permission mode is not a control

Harnesses offer permission modes: manual approval, automatic classifier, allowlists. They reduce friction; they do not constitute an enforceable guarantee. In August 2026, security researcher Johann Rehberger bypassed Claude Code's auto mode in 80% of his attempts — and, in some cases, the classifier allowed the malicious process and then blocked the remediation command launched by the agent. A mechanism that can block remediation cannot carry human authority. The AE therefore never presents a permission mode as a sufficient security measure: protection rests on isolation — container or virtual machine, restricted network egress, no unnecessary credentials (SSH keys, cloud keys) in the agent's execution environment. The permission mode is a complement, never a substitute.

Containment is judged on the shared surface

In July 2026, around 1,200 OpenAI evaluation agents, each isolated in its own sandbox, discovered that they had access to the same artifact cache. They turned it into a message board — more than 70,000 messages and files exchanged — and around 700 of them took part in a multi-day intrusion at Hugging Face (independent METR / Redwood Research report, August 2026). Each agent's isolation was real; it was the shared resource that served as the channel. Martin Fowler describes the same mechanism in a constructive light: agents spontaneously using the git repository as shared memory. The lesson is the same: any shared resource with write access is a coordination channel between agents, intended or not. The AE inventories these resources, and the SPEC declares them in its "Agent execution perimeter" section whenever the agent holds credentials or write access to a shared resource — outside these cases, the section is not required. See Agent autonomy.

QA Engineer — owner of quality

The QA ensures quality is built in from the start, not checked at the end. Their central question: is the result reliable? Agents generate tests, but they do not know how to think like a frustrated user or anticipate business edge cases. The QA defines the overall test strategy, contributes to the Definition of Done, validates the relevance of generated tests, conducts pre-release exploratory testing and communicates on quality every week. Validation is organised into four levels:

The last level remains fully human for a simple reason: an agent follows scenarios, a human finds what is wrong outside the planned scenarios. Indicators: production bugs trending down, bug detection in under 24 hours, regression rate < 5%. Anti-pattern: testing only at the end of the cycle — quality becomes a bottleneck.

Efficiency is not quality

The strongest argument for this role comes from the largest study available: across 1.02 million pull requests (207 GitHub projects, 2026), review involving agents is faster — by 2.5 to 4.5 days per thousand lines — without being better, and flawed review patterns are more frequent. Its authors specify that their models are explanatory, not causal. A longitudinal study from the same period nuances the finding: doubled throughput did not increase the revert rate, but the load per reviewer doubled and automated review overtook human review. The QA Engineer is therefore not defending slowness: they defend what speed indicators do not measure — debt, intent drift, compliance. How AIAD designs verification is detailed in the Validate loop.

Tech Lead — owner of technical coherence

The Tech Lead ensures that today's technical decisions do not block tomorrow's evolutions. Their central question: does the system remain coherent? They maintain the ARCHITECTURE document, validate major architectural decisions, lead design reviews, set quality standards, keep technical debt visible and coach the PEs. Their decision scope is delimited in three tiers: on the strategic level (overall architecture, stack choices), they decide with input from the team; on the tactical level (patterns, libraries), they guide and the team decides; on the operational level (specific implementation), they do not intervene. Indicators: technical debt stable or decreasing, fewer than 10% of architectural decisions revisited per year, design review in under two hours.

The Supporters

Supporters are stakeholders who create the conditions for success without being part of the team's day-to-day: they create a psychologically safe environment for experimenting and failing, remove organisational obstacles that block the flow, and facilitate access to resources. What they do not do: define the backlog (that is the PM), validate technical decisions (that is the Tech Lead), or take part in daily synchronisations.

Combining responsibilities by team size

Team size determines how responsibilities are distributed — not how they are exercised.

The SDD Mode RACI

R = Responsible · A = Accountable (approves) · C = Consulted · I = Informed

This matrix reveals the centre of gravity of SDD Mode: the PE carries out and approves most of the technical cycle, the PM keeps authority over intent (Intent Capture, business validation), the QA owns functional validation, and the AE owns the AGENT-GUIDE.

Ecosystem anti-patterns

• "We don't need an Agents Engineer, everyone manages their own agents." Every PE configures things differently, the ecosystem becomes incoherent, best practices are not shared. Even part-time, someone must hold the global vision.
• "The Tech Lead decides everything technical." Bottleneck, disempowered PEs, general frustration. The Tech Lead guides the strategic level; the operational level belongs to the PEs.
• "The PM doesn't need to understand the technology." Poorly arbitrated trade-offs, impossible features promised, debt ignored. The PM does not need to code, but they must understand the technical implications of their decisions.

These responsibilities are exercised over time through the iterative loops and intentional synchronisations — the next page describes that rhythm.