How AI-native workflows and Git are replacing static handoffs with a continuous, spec-driven product engine
Five months ago, Anthropic’s head of design, Jenny Wen, claims that “the design process is dead” got people arguing for the right reasons. Today, the sharper version of that idea is simpler: the old, sequential design process is no longer enough for how AI-native teams build digital products.
We are not just tweaking the double diamond (4D) model. Engineering, product, design, and data science are increasingly blending into a more fluid workflow, and the boundaries that once defined our jobs are moving.
Which is why the most important shift is that design work is being pulled closer to implementation, iteration, and judgment. If you look at high-velocity teams defining this era, such as the crew behind Claude Code, you do not always see a classic lineup of “PM, designer, and three engineers.” Instead, you see people moving between five distinct archetypes of action, as shared by Boris Cherny, co-founder of Anthropic:
- The Prototyper: Generates a high volume of raw, highly interactive ideas, most of which are thrown away.
- The Builder: Turns a validated prototype into production-grade infrastructure.
- The Sweeper: Cleans up UI, simplifies code, removes bloat, and improves performance.
- The Grower: Takes the product and iterates until product-market fit expands.
- The Maintainer: Secures, stabilizes, and scales mature systems so they stay fast and reliable.
https://medium.com/media/fbfdecca18759cc3bb86d1bc5f357f96/href
That framing matters because it changes how teams think about talent. A strong product team is more than just a set of titles. It is a set of people who can move between creating, refining, shipping, and maintaining. The title matters less than whether someone can help the team make the next useful thing.
The New Medium: Git as a Shared Workspace
Tool fragmentation used to be a normal cost of doing business. We used Miro to think, Figma to draw, Confluence to document, Jira to track, and GitHub to build.
That separation now creates drag. In AI-native teams, product conversations are happening closer to implementation, and Git has become an increasingly central shared workspace for specs, code, and iteration.
[Old World] Miro → Figma → Confluence → Jira → GitHub
[New World] Specs → Interactive Prototypes → Production Code
This changes how ideas get expressed:
- Vibecoding interactivity: Instead of sketching a static flow and asking everyone to imagine the motion, teams can prototype interactions directly and test them quickly.
- Specs over screens: Screens still matter, but specs are becoming highly significant as a source of truth. The future of engineering belongs to Agentic SDD (Spec-driven development), which are precise, human-and-agent-readable descriptions of requirements that can guide code generation.
A useful example is a feature that starts as a vague design deck. In the old model, that deck might bounce between meetings, figma mockups, and handoff docs before any real prototype exists.
In the newer model, the team can move from intent to interactive test much faster, which makes it easier to discover what is actually worth building. That speed is powerful, but only if the team keeps enough discipline to avoid shipping sloppy ideas too early.
What This Means for Designers
Will designers need to become markdown-writing software engineers, by learning Git for its own sake? Not really, but learning how to express intent in a way that survives contact with code will be key.
A spec in this era isn’t dry documentation. It is the concrete articulation of logic, user intent, system state, and design constraints. Rather than spending hours aligning pixels on static screens, designers are increasingly defining the rules and behaviors of the system. In practice, that means shaping how the product responds to different inputs while agents and engineers handle more of the execution.
If a design idea cannot be translated into behavior, constraints, and testable rules, it is still too vague to scale.
Redesigning the System Structure
In his seminal work The Fifth Discipline, Peter Senge wrote:
“The reason that structural explanations are so important is that only they address the underlying causes of behavior at a level at which patterns of behavior can be changed. Structure produces behavior, and changing underlying structures can produce different patterns of behavior. In this sense, structural explanations are inherently generative. Moreover, since structure in human systems includes the ‘operating policies’ of the decision makers in the system, redesigning our own decision making redesigns the system structure.”
In other words, telling teams to work differently doesn’t change anything; changing the system they work in does. If you want different product outcomes, you must redesign your workflows and decision-making rules. Change the mental model, and the behavior will follow.
This is where a lot of teams get stuck. They tell designers to “collaborate more” or engineers to “care more about UX,” but those slogans fail to change the system. The workflow stays the same, the incentives stay the same, and the team keeps producing the same kind of output. If the structure does not change, the behavior usually will not either.
To navigate that shift, Anthropics introduced another framework for human-agent collaboration: The 4D AI Fluency Framework.
- Delegation: Knowing which cognitive tasks belong to the human team and which belong to the agent.
- Description: Expressing intent, rules, and system behavior with absolute clarity.
- Discernment: Critically reviewing, testing, and evaluating AI outputs before approval.
- Diligence: Building governance, guardrails, and quality checks into the workflow.
The New Product Lifecycle
When you combine the 4D Framework with Agentic SDD, a new product lifecycle starts to emerge. It is less a straight line and more an engine that cycles between strategy, experimentation, and hardening.
We call this the SAID framework: a continuous loop of Specifying intent, Agentic delegation, Iterative description and human Discernment and diligence.
The following are steps on how specs become product with AI:
1. Initiate: Set an AI-native approach as a strategic priority so the team builds with agents instead of retrofitting AI into old workflows.
2. Discover: Map current realities and identify the friction points between where the product is today and what it looks like to be truly AI-native.
3. Delegation: Define the team’s operational boundaries. What cognitive work do the humans own? What is delegated to the agents? Who maintains final sign-off authority?
4. Description: Collaboratively author the initial Agentic SDD. This document defines the goals, constraints, and system logic in a format both humans and agents can read.
5. Discernment: Review, debate, and approve the initial specifications through Git before any major implementation begins.
6. Diligence: Institutionalizing governance, guardrails, and quality checks.
7. Loop A (Proposition to Prototype): With the foundation set, spin the 4D loop rapidly:
- Delegate experiment tasks.
- Describe immediate design intents to prototype new possibilities, tweaking design directly with custom workflows and Claude skills.
- Discern via automated evaluation and human “vibe-checks.”
- Diligence by sweeping the master specs to keep code clean and scale features.
8. Loop B (Prototype to Product): Transition the validated prototype into a production system:
- Delegate operational duties to the Builders and Growers.
- Describe requirements with production-grade security and localization in mind.
- Discern performance post-launch through real-world product analytics, feeding discoveries back into Phase 2.
- Diligence by maintaining high reliability, fixing bugs, and keeping the SDD as the absolute source of truth.
The SAID framework is what the complete, modern product pipeline looks like. It begins with raw strategic alignment (Initiate and Discover), launches into structured agentic execution (Delegate, Describe, Discern, Diligence), and tightens through iterative concentric orbits (Specs — Prototype — Product) before finally bridging the gap to our ultimate vision. It is a systematic accelerator with the specs at the core.
A More Useful Mental Map
Early cars were steered with a tiller, a simple lever. Over time, designers realized that a steering wheel was a better mental model for navigating roads.
Product teams are going through a similar change. The pressures of token efficiency are pushing teams toward tighter, more integrated, and more spec-driven workflows.
For designers, the call to action is not to abandon craft. It is to get comfortable in the Git environment and learn how to translate creative ideas into precise intent that humans and AI agents can execute well.
Sketching, wireframing, and conceptualizing will always matter. But the modern product creator is no longer only the person drawing the interface. The stronger skill is shaping behavior, defining constraints, and collaborating effectively with agents.
The old process was built for handoffs. The new one is built for continuous decision-making. That is the real operating change, and it is why teams that adapt quickly will have a clear advantage. The structure is changing, and the operating policies have to change with it.
References
Anthropic. (2025). AI Fluency: Framework & Foundations [Review of AI Fluency: Framework & Foundations]. Anthropic. https://anthropic.skilljar.com/ai-fluency-framework-foundations
Cherny, B. (2026, June 28). As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes: 1. Prototyper: Comes up with brand new ideas; churns out. X (Formerly Twitter); X. https://x.com/bcherny/status/2071379474277613732?lang=en
Senge, P. M. (2006). The fifth discipline: The art and practice of the learning organization. Random House Business.
Thoughtworks. (2025, December 10). Spec-driven development. Medium. https://thoughtworks.medium.com/spec-driven-development-d85995a81387
From vibe to specs: reclaiming the design process with SAID framework was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
