4 Collaborating Across Product, Architecture, and Engineering
Spec-driven development is presented as a team practice for humans and AI agents alike, where specifications become the durable source of intent that replaces tribal knowledge. Because agents arrive with no memory from one session to the next, the team’s responsibility is to create a working environment that lets each new session onboard quickly and contribute value without constant hand-holding. The chapter argues that productivity gains only become real when the roles that already exist on a team help author the specification itself, so the agent can use shared context to understand what to build, why it matters, and how success will be judged.
The chapter examines several collaboration patterns and shows their tradeoffs. Having engineers act as scribes for product and architecture input is simple, but it creates translation bottlenecks and filters intent through one person’s understanding. Sequential handoffs let each role contribute directly, yet they introduce review queues and mini-waterfalls as features pile up. Mob authoring removes handoffs entirely by bringing everyone into the same session, but it depends on simultaneous availability. The preferred alternative is asynchronous collaboration through standing context: recurring business rules, architectural constraints, and engineering practices are encoded once so they can guide future specification work without requiring every specialist to be present each time.
The team then applies this model while building a URL shortener with SpecKit, using the Product Specialist, Architect, and Engineer roles to grow context just in time. Product decisions become standing context when they recur, architecture defines stable boundaries and constraints, and engineering captures task-generation rules, quality gates, and evidence of completion. Feature-specific conversations remain focused on what changes from case to case, while the durable context handles what should stay constant. The exercise shows that this approach makes later features easier, shorter, and more precise, with more of the team’s effort shifting from repeated explanation to higher-value judgment and refinement.
A mental model of participation of key stakeholders in authoring specification as part of Intent Harness.
An engineer acts as a scribe for the product specialist and architect during spec authoring because the spec and code are co-located in most SDD frameworks. When the agent requests clarifications, the engineer must either answer based on their second-hand understanding or escalate the question to the appropriate SME, introducing delays and risking intent loss in translation.
Coding agents speed up the contribution by each role to the spec, however every handoff creates a human review queue that negates this advantage. Coding agents also implement specified features much faster, causing implementation reviews to accumulate quickly further increasing the review burden on every role.
All stakeholders collectively authoring the specification in a single agent session, and a single machine
Mapping SpecKit commands to the SDD mental model. The Discover (What), Design (How), and Tasks phases author the specification, which is then handed over to the agent for autonomous execution.
Summary
- Each role adopting agents individually only makes each of us faster. Individual speedups do not compose into a team speedup until we organize how contributions reach the specification.
- The collaboration patterns we observed while specifying features as a team were engineer as scribe, passing the baton from one role to the next, mob authoring the specification, and finally each role contributing standing context so the agent can participate on their behalf in drafting the specification even when they are not present. Each pattern addresses a different aspect of the bottleneck created by human availability during specification authoring, specification review, and review of the resulting implementation.
- The product specialist, architect, and engineer each contribute standing context that are invariant across features as well as feature specific live judgement.
- To keep the standing context lean, it should contain only project-specific knowledge. Knowledge that is shared across multiple projects belongs in reusable skills so it can be loaded on demand when needed. The architect’s construction constraints is one example.
- Standing context is grown, not installed. As we come across patterns in questions and review findings, we capture these learning as standing context and as this standing context matures, our involvement shifts from effort to judgement.
- An implementation built against every role's standing context arrives more aligned, so review is reduced rather than abandoned, and we can focus on decisions that genuinely need us.
- Using SDD frameworks as they are is a good way to learn the fundamentals and explore collaboration patterns. In practice, however, we should customize the framework to fit our existing tools and workflows rather than forcing ourselves to adapt to it.
FAQ
What is the main goal of collaborating across product, architecture, and engineering in Spec-Driven Development?
The goal is to combine each role’s expertise directly into the specification so AI agents can onboard quickly and produce implementations that reflect the team’s shared intent, rather than relying on ad hoc conversations or tribal knowledge.
Why does the chapter say AI agents should be treated like “perpetual new joiners”?
Because each agent session starts with no memory of previous sessions, so the team must provide durable context through specifications instead of depending on human onboarding or repeated explanations.
What are the three roles that contribute to the specification surface?
The three roles are product specialists, architects, and engineers. In SDD, they correspond to the Discover, Design, and Tasks phases respectively.
Why is the “engineer as scribe” pattern considered a bottleneck?
It puts translation burden on one engineer, delays clarification, and risks intent loss because product and architecture knowledge is filtered through someone else instead of being contributed first-hand.
What is “passing the baton” in specification authoring?
It is a sequential collaboration pattern where each role contributes to the spec in turn, often through pull requests or feature branches, with the specification handed from one role to the next.
What is the downside of sequential handoffs between roles?
Sequential handoffs create review queues, waiting, and context switching. Each feature can become a miniature waterfall, which slows collaboration and increases overhead as more work accumulates.
What is mob authoring and when is it useful?
Mob authoring is when all roles collaborate live in a single session on one machine to author the specification together. It removes handoffs and clarifications, but it depends on everyone being available at the same time.
What is standing context and why is it important?
Standing context is recurring business, architectural, and engineering guidance that lives in the harness and is reused across features. It helps agents author better specs with less human intervention and reduces repeated review work.
How does each role contribute to standing context?
Product specialists contribute business rules, vocabulary, and required questions; architects contribute constraints, boundaries, and interfaces; engineers contribute testing practices, completion checks, and quality expectations.
Why should standing context be grown gradually instead of installed all at once?
Because standing context should be based on repeated real experience, not assumptions. The team should start with what they already know and let the context expand naturally as recurring patterns prove useful.
Spec-Driven Development ebook for free
