Agent IDE Workflows
Using Cursor, Windsurf, Bolt, and other AI-powered tools to build functional prototypes rapidly.
Back to EEM Overview
03 Execute stage
The Execute Stage
Make to learn. Direct agents. Let stakeholders judge working software, not slides.
Why Execute is the Heart of EEM
In traditional workflows, execution was treated as downstream work—something that happened after the "real" thinking was done. Discovery, research, and planning were where value was created. Execution was just implementation.
That assumption made sense when execution was slow, expensive, and risky. But AI-driven tools have fundamentally changed the economics of making. Now execution can happen in hours instead of weeks. The cost of building a functional prototype has collapsed.
"When making is faster than planning, execution becomes the primary learning engine."
This is why Execute sits at the heart of EEM. It's where ideas become real. Where assumptions get tested. Where stakeholders see working software instead of static mocks. Where uncertainty actually collapses.
What Happens in Execute
Designers Direct, AI Builds
Designers articulate what's needed and evaluate what agents produce—they don't write code.
Multiple Solution Variants
Explore 2-5 different approaches simultaneously instead of betting on a single solution.
Stakeholder Engagement
Review working prototypes, not mocks. Click through actual flows. Test on real devices.
Designer as Director
The most important shift in EEM is understanding what designers actually do in the Execute stage. They don't write code—they direct AI agents and evaluate outputs.
Traditional Model
Designer as Pixel Perfectionist
- Creates pixel-perfect static mockups in Figma
- Hands off designs to engineering
- Waits for implementation to see real behavior
- Disconnected from implementation reality
EEM Model
Designer as Experience Director
- Articulates what's needed to AI agents
- Evaluates what agents produce for quality
- Judges brand/UX quality in working software
- Decides when solution is ready for governance
Critical Clarification: Designers Don't Need to Be Expert Coders
This is the most misunderstood aspect of AI-enabled design. Designers don't need to become software engineers. They need comfort with code and the ability to evaluate working software. The Agent IDE does the coding. The designer does the directing and evaluating.
What Designers DO Need
- Comfort evaluating functional prototypes (not Figma mocks)
- Ability to articulate what's wrong and prompt adjustments
- Understanding of component thinking (props, states, variants)
- Judgment about brand/UX quality in working software
- Design system fluency
What Designers DON'T Need
- Expert-level coding ability
- Ability to write every line of code themselves
- Deep knowledge of framework internals
- Traditional software engineering background
- CS degree or bootcamp certification
The Agent IDE Workflow
Agent IDEs like Cursor, Windsurf, and Bolt have fundamentally changed what's possible in the Execute stage. Here's how the workflow actually operates.
Frame the Intent
Start with a clear articulation of what you're trying to build. This isn't a detailed spec—it's a direction. "Build a dashboard that shows real-time portfolio performance with the ability to drill into individual holdings."
Provide Context
Give the agent your design system reference (Storybook link, component library docs), brand guidelines, and any specific constraints. The more context, the better the initial output.
Generate Initial Build
The agent produces a working prototype. Not a wireframe, not a mockup—actual functional code that renders in a browser. This might take minutes, not days.
Evaluate & Direct
Review what the agent built. Does it match your intent? Does it feel right in the browser? Is the brand expression correct? Articulate what needs to change: "The spacing feels cramped—increase padding between cards. The hover states need to be more subtle."
Iterate Rapidly
The agent adjusts based on your direction. You evaluate again. This cycle happens in minutes, not sprints. Multiple variants can emerge from different approaches to the same problem.
Stakeholder Review
Show stakeholders working software, not slides. Let them click through actual flows. Capture feedback on real behavior. This builds confidence in ways mockups never could.
Primary Agent IDE Tools
Cursor
AI-first code editor with deep codebase understanding and multi-file editing capabilities.
Windsurf
Agentic IDE designed for flow state coding with AI that understands your entire project.
Bolt
Browser-based development environment for rapid prototyping with instant preview.
Replit
Collaborative browser IDE with AI assistance and instant deployment capabilities.
v0 (Vercel)
Generative UI tool that creates React components from natural language descriptions.
Claude Code
Command-line agentic coding tool for terminal-based workflows and automation.
When Do You Need Figma?
Your design system maturity determines whether you can execute directly in Agent IDEs or need preparation in traditional design tools first.
Immature Design System
Figma Needed
When your design system isn't mature enough to constrain AI execution effectively, use Figma for preparation:
- Design system components don't exist yet
- Brand patterns not yet codified
- Complex component interactions need visual thinking first
- Team is still learning the EEM workflow
Mature Design System
Execute Directly
When your design system is mature and well-documented, skip Figma and execute directly:
- Component library is comprehensive and documented
- Brand constraints are clear in the system
- System can effectively constrain AI output
- Team is comfortable directing agents
Key Principle: Code (Storybook, component libraries) is the source of truth. Figma is a preparation tool when the system is immature, and an optional visualization layer when mature. The design system lives in code, not in design files.
The Multiple Solutions Strategy
Traditional workflows optimize for finding "the right answer." You research, analyze, ideate, and converge on a single solution. Then you bet everything on that solution being correct.
EEM takes a different approach. When execution is cheap and fast, you can explore multiple solution variants simultaneously. Instead of one big bet, you make several smaller bets and let real feedback determine which approach wins.
"Two to five working prototypes beat one perfect mockup."
This isn't about being indecisive. It's about recognizing that you learn more from comparing working alternatives than from debating hypotheticals. Stakeholders can actually feel the difference between approaches instead of imagining it.
Why Multiple Solutions Work
De-risk Decisions
Instead of betting everything on one approach, spread risk across multiple viable options.
Better Stakeholder Conversations
"Which of these three approaches resonates?" is more productive than "Does this single solution work?"
Surface Trade-offs
Different approaches reveal different trade-offs. Seeing them side-by-side clarifies what you're actually choosing.
Faster Learning
You learn more from comparing working alternatives than from debating abstract options.
Stakeholders Want the Real Thing
Here's a truth that EEM makes explicit: stakeholders have always wanted to see working software. They accepted mockups because that's all we could produce quickly. Now we can give them what they actually wanted all along.
Click Through Actual Flows
No more "imagine this transition" or "pretend this button works." Stakeholders interact with real navigation, real forms, real state changes.
Test on Real Devices
Pull out your phone and try it. Feel how the touch targets work. See how it responds. This is feedback you can't get from a Figma prototype.
Feedback on Real Behavior
"This loading state feels slow" is actionable feedback. "I think this transition might feel slow" is speculation. Working software enables real feedback.
"Stakeholders don't want mockups. They want confidence. Working software provides confidence in ways that design artifacts never could."
Example: Building a Portfolio Dashboard
Here's what the Execute stage looks like in practice, using a real example from a fintech prototype.
Input Received
Product strategist provides the input: "We need a portfolio dashboard that shows real-time performance, allows users to drill into individual holdings, and surfaces relevant market news."
Design system context: Existing component library in Storybook with charts, cards, and data tables. Brand tokens defined.
Initial Direction to Agent
The Execution Designer opens Cursor with the design system context and provides initial direction:
"Build a portfolio dashboard using our design system components. Include a performance chart at the top, a sortable holdings table below, and a sidebar for market news. Use the existing Card, Chart, and DataTable components from our library."
Evaluate & Direct Adjustments
Agent produces initial build in 15 minutes. Designer reviews in browser and provides direction:
- "The chart needs more vertical space—it feels cramped."
- "Add a hover state to table rows that shows a quick preview."
- "The news sidebar should collapse on mobile into a bottom sheet."
Create Variant Approaches
Designer decides to explore two different approaches to the holdings interaction:
Variant A
Click to expand row with full details inline
Variant B
Click to open slide-over panel with detailed view
Stakeholder Review
Both variants deployed to preview URLs. Stakeholders click through real flows on their own devices. Feedback captured:
"Variant B feels better—the slide-over doesn't lose context of the overall portfolio. But can we add a quick-glance summary that appears on hover before clicking?"
Total time: Input to stakeholder-reviewed prototypes in 4 hours, not 4 weeks.
When is Execute Complete?
Execute isn't done when you've built something. It's done when you've built something ready for governance judgment.
Solutions Are Functional
Working prototypes that run in a browser, not static mockups. Real interactions, real state, real behavior.
Multiple Variants Exist
Two to five different approaches that took different strategic paths. Options for governance to compare.
Stakeholders Have Engaged
Real people have clicked through real prototypes and provided feedback on actual behavior.
Learning Captured
What worked, what didn't, what surprised you. Documented so governance has context for decisions.
When these criteria are met, solutions move to Governance Gate for judgment.
Ready to Transform How Your Team Executes?
Execute is the heart of EEM—the stage where uncertainty collapses through making. Let's discuss how your team can start building functional prototypes instead of static mockups.
Continue exploring the framework: