# Shared design concept A durable, explicit understanding of the problem, domain language, boundaries, constraints, and acceptance conditions shared by humans and coding agents before implementation expands. technical-term · Foundations · practitioner · Reviewed 2026-08-09 ## Definition A shared design concept is the common model that lets people and coding agents reason about the same system: why it exists, what outcome matters, which domain terms mean what, where responsibilities belong, which constraints bind, and how success will be tested. It is an alignment artifact that can evolve with evidence—not a promise that ambiguity disappears or a license for unattended execution. Shared mental models and domain language are established software practices; this explicit agent-facing framing remains practitioner-led and implementation-specific. ## Why it matters Coding agents amplify whatever conceptual structure they receive. A shared concept gives subsequent specifications, tasks, interfaces, and tests a coherent vocabulary. The concept should be inspectable and revisable. Interviews, examples, diagrams, and existing system evidence can expose disagreements before they become parallel implementations. ## System anatomy - **Purpose:** The user or business outcome and the reason it matters. - **Domain language:** Stable terms for entities, rules, states, and exceptions. - **Boundaries:** Responsibilities, interfaces, exclusions, and ownership. - **Acceptance:** Observable conditions that would show the concept works. ## Important distinctions - **A single prompt:** A prompt is one instruction event; a shared concept is durable, reviewable project knowledge used across many decisions. - **Detailed implementation:** The concept aligns meaning and boundaries without prescribing every code-level choice. ## Implementation signals - Interview accountable stakeholders before decomposing ambiguous work - Record contested terms, decisions, and open questions - Test the concept with examples and a thin implementation slice ## Failure modes - Humans and agents use the same word for different ideas - A polished specification hides unresolved product or domain decisions ## Related knowledge - [Intent engineering](https://aisdlc.ai/agentic-engineering/intent-engineering) — The practice of turning goals into versioned specifications, constraints, interfaces, invariants, decision rights, acceptance criteria, and testable outcomes before agents implement them. - [Spec-to-code](https://aisdlc.ai/agentic-engineering/spec-to-code) — A controlled transformation from durable intent and acceptance criteria through a technical plan and bounded tasks into implemented, tested, and reviewable software. - [Context engineering](https://aisdlc.ai/agentic-engineering/context-engineering) — The deliberate selection and maintenance of instructions, knowledge, tools, state, examples, and artifacts within a finite model attention budget. - [Tracer-bullet development](https://aisdlc.ai/agentic-engineering/tracer-bullet-development) — A deliberately thin, end-to-end implementation slice used to expose architecture, integration, feedback, and deployment assumptions before scaling the full build. ## Sources and further study - [AI Engineer — "Software Fundamentals Matter More Than Ever" — Matt Pocock](https://www.youtube.com/watch?v=v4F1gFy-hqg) — A conference talk arguing that shared language, deliberate software design, deep modules, and fast test feedback become more important as coding agents increase implementation throughput. **Use:** Practitioner perspective. **Limitation:** This is an attributed practitioner argument illustrated with examples, not a controlled study showing that the proposed practices produce universal outcomes. - [Matt Pocock — Skills for Real Engineers](https://github.com/mattpocock/skills) — An open repository of composable, user-invoked agent skills covering discovery, specifications, tickets, implementation, review, testing, debugging, teaching, and codebase design. **Use:** Practitioner perspective. **Limitation:** The repository documents one evolving workflow. Its MIT license covers repository materials, not separate videos, course branding, or an assurance claim for downstream use. - [GitHub — GitHub Spec Kit](https://github.github.com/spec-kit/) — Documents an intent-driven workflow that turns a specification into a plan, tasks, and implementation artifacts while supporting multiple coding agents and replaceable process extensions. **Use:** Official guidance. **Limitation:** This is official project documentation, not causal evidence that spec-driven development improves every project; its artifact flow is one configurable process model. - [Anthropic — Agentic coding and persistent returns to expertise](https://www.anthropic.com/research/claude-code-expertise) — Reports a privacy-preserving observational analysis of roughly 400,000 Claude Code sessions, including task composition, planning-versus-execution decisions, domain expertise, and operationalized success. **Use:** Empirical evidence. **Limitation:** The analysis is observational and vendor-specific, so it does not establish causality or generalize automatically to other tools, teams, tasks, or definitions of success. --- This library synthesizes cited research, standards, official documentation, and clearly attributed practitioner perspectives. Maturity describes the state of a concept—not vendor endorsement, production readiness, or permission to deploy. Benchmarks and demonstrations do not replace use-case evaluation, governed controls, independent verification, or named human release authority.