Flipping the script

Continued from Task decomposition

Questioning the deliverable: Why figma files?

Excellent catch. This is exactly the kind of first-principles thinking we need. Let’s interrogate this assumption.

Why do we create Figma files today?

Traditional reasons:

Stakeholder Review: “Show the design to non-technical people”
Developer Handoff: “Developers need something to build from”
Design System Management: “Maintain consistent component library”
Client Deliverable: “We need something to show we did design work”
Collaboration: “Multiple designers need to work in same tool”
Iteration: “Easy to adjust and get feedback”

But in our decomposed task model, are these reasons still valid?

Let’s trace the actual information flow

What does the NEXT task in the dependency chain actually need?

If the next task is DEV4: Dashboard UI Components, what does the developer (human or AI) actually need?

Traditional handoff:

Designer creates Figma file → Developer opens Figma → Developer inspects:
- Layout dimensions
- Component hierarchy
- Colors (hex codes)
- Typography (font, size, weight)
- Spacing values
- Interaction states
- Responsive breakpoints
→ Developer manually translates into React code

This is insane information loss and manual translation work.

What if we flip it?

What if the design task outputs machine-readable specification, not a visual mockup?

{
  "screen": "predictive_analytics_dashboard",
  "layout": {
    "type": "grid",
    "columns": 12,
    "gap": "24px",
    "responsive_breakpoints": ["768px", "1024px", "1440px"]
  },
  "components": [
    {
      "type": "HeaderBar",
      "position": { "row": 1, "col": "1-12" },
      "props": {
        "title": "Predictive Analytics",
        "actions": ["refresh", "export", "settings"]
      }
    },
    {
      "type": "MetricCard",
      "position": { "row": 2, "col": "1-4" },
      "data_binding": "prediction_accuracy",
      "props": {
        "trend": "up",
        "comparison": "vs_last_week"
      }
    },
    {
      "type": "ChartContainer",
      "position": { "row": 3, "col": "1-8" },
      "props": {
        "chart_type": "line",
        "data_source": "predictions_over_time",
        "interactive": true
      }
    }
  ],
  "design_tokens": {
    "colors": {
      "primary": "#2563eb",
      "success": "#10b981",
      "background": "#ffffff"
    },
    "typography": {
      "heading": "Inter/600/24px/32px",
      "body": "Inter/400/16px/24px"
    }
  },
  "interaction_flows": [
    {
      "trigger": "metric_card.click",
      "action": "show_detail_modal",
      "transition": "fade_in_300ms"
    }
  ],
  "accessibility": {
    "aria_labels": {...},
    "keyboard_navigation": {...},
    "contrast_verified": true
  }
}

This specification can:

Be generated by AI from wireframe decisions
Be read directly by AI code generation agent
Be validated programmatically
Be rendered as visual preview if humans need to see it
Be version controlled efficiently (JSON diff)
Be translated into multiple frontend frameworks

The new task WF-9 alternative

Instead of: “Figma Asset Production”

Option A: Code-first approach

Subtask WF-9A: Component Specification Generation

Input: Design decisions from WF-8
Output: Machine-readable component spec (JSON/YAML)
Claimable by: AI Agent
Time: 10 minutes
Reward: 15 tokens
Verification: Schema validation, automated render test

Subtask WF-9B: Visual Preview Generation

Input: Component spec from WF-9A
Output: HTML/CSS preview for human stakeholder review
Claimable by: AI Agent (renders from spec)
Time: 5 minutes
Reward: 10 tokens
Verification: Automated screenshot comparison
Note: Only needed IF stakeholder requests visual review

Option B: Design tokens + component library

Subtask WF-9: Design Token Mapping

Input: Design decisions from WF-8, existing component library
Output: Mapping of screens to existing components + token values
Claimable by: AI Agent
Time: 15 minutes
Reward: 20 tokens
Verification: All components exist in library, tokens valid

Result:

Dashboard screen composition:
- Use: HeaderBar component (v2.3)
- Use: MetricCard component (v1.8) × 3
- Use: LineChart component (v3.1)
- Custom spacing: 32px between cards (override default 24px)
- Color override: Use 'success' variant for middle card

Next task (DEV4) receives:

Component references (reusable)
Configuration parameters
No translation needed - direct implementation

Option C: AI-to-AI direct handoff

What if there’s no intermediate artifact at all?

Subtask WF-9: Design Context Packaging

Input: All design research and decisions (WF-1 through WF-8)
Output: Contextual briefing document for development agent
Claimable by: AI Agent
Time: 5 minutes
Reward: 10 tokens

Then DEV4 (claimed by AI agent) receives:

User intent from stories
Design principles applied
Accessibility requirements
Component composition logic
Design system constraints

AI development agent directly generates code from this context, no visual mockup needed.

Only if human developer claims DEV4 might they want visual reference - generated on demand.

Challenging more assumptions

Let’s apply this thinking to other “obvious” deliverables:

Do we need user stories?

Traditional: Product Owner writes user stories in specific format

Alternative:

Machine-readable requirement graph
AI generates user story text if human needs to read it
But why force narrative format if AI agents are consuming it?

What’s actually needed:

{
  "requirement_id": "REQ-034",
  "actor": "small_business_owner",
  "goal": "understand_customer_churn_risk",
  "context": "reviewing_weekly_metrics",
  "success_criteria": [
    "churn_probability_displayed_per_customer",
    "risk_factors_explained_in_plain_language",
    "actionable_recommendations_provided"
  ],
  "constraints": {
    "response_time": "< 2s",
    "data_freshness": "< 24h",
    "accuracy_threshold": "> 75%"
  }
}

AI can generate “As a small business owner, I want to…” text for humans who need it, but other AI agents work directly from structured data.

Do we need API documentation?

Traditional: Developer writes OpenAPI spec, generates docs site

Alternative:

Code with rich type information IS the spec
AI reads code, generates any format needed on demand
Need Postman collection? AI generates it
Need Swagger UI? AI generates it
Need client SDK? AI generates it

What’s actually needed:

Well-typed, self-documenting code
ADR explaining design decisions
Example usage patterns

Documentation becomes generated view of the code, not separate artifact.

Do we need test plans?

Traditional: QA Engineer writes test plan document

Alternative:

Test cases ARE the test plan
Executable specifications (BDD style)
AI reads requirements, generates test cases
Human validates edge cases

What’s actually needed:

Feature: Churn Risk Prediction
  Scenario: High-risk customer identified
    Given customer "Acme Corp" has not logged in for 45 days
    And their usage dropped 60% last month
    When I view the churn risk dashboard
    Then I should see "Acme Corp" with "HIGH" risk status
    And I should see "Declining engagement" as risk factor
    And I should see "Send re-engagement offer" as recommendation

This IS the test plan, the test case, AND the documentation. One artifact, multiple uses.

Do we need meeting notes?

Traditional: Someone types notes during meeting, posts to Confluence

Alternative:

AI listens to meeting (or reads chat transcript)
Extracts: decisions, action items, open questions
Updates project knowledge graph
Routes action items to relevant people
Links decisions to affected tasks

What’s actually needed:

Structured decision records (automatically extracted)
Action items with owners (automatically assigned)
Context linked to relevant project artifacts

Meeting notes as prose document become obsolete.

The radical principle: Artifacts as transformations

Tradtional thinking

Each phase produces specific artifacts in traditional formats

New thinking

Each task produces data in the format optimally consumed by the next task

The flow:

Customer conversation (audio)
  → AI transcription + synthesis (structured insights)
    → Requirement specification (machine-readable)
      → Component specification (executable)
        → Working code (directly deployed)
          → Runtime behavior (instrumented/observable)
            → Usage analytics (feeds back to insights)

Human-readable views are generated on-demand when humans need to review, but they’re not the “official” artifact.

Implications for task dependencies

Old model:

Task A: Create wireframes (output: Figma file)
  → Task B: Review wireframes (human opens Figma)
    → Task C: Implement UI (developer translates from Figma)

New model:

Task A: Define UI composition (output: component spec)
  → Optional: Generate preview (if human review needed)
  → Task B: Implement UI (AI reads spec directly, generates code)
    → Automated: Verify output matches spec

Fewer tasks, fewer translation layers, less information loss.

What this means for Future’s Edge

The platform must support:

1. Polymorphic Artifacts

Same data, multiple representations
Canonical format: machine-readable (JSON, YAML, etc.)
Generated formats: visual, narrative, documentation
Consumers specify format preference

2. Direct Agent-to-Agent Communication

Task outputs don’t always need human-readable format
AI agents can exchange structured data directly
Only generate human views when validation needed

3. On-Demand Rendering

Don’t preemptively create all formats
Generate when requested: “Show me visual preview of this spec”
Saves storage, reduces busywork

4. Format Translation As Service

Platform provides: “Convert this component spec to Figma format”
Or: “Convert this code to architecture diagram”
Or: “Convert this meeting transcript to ADR”
One canonical source, infinite views

5. Verification Without Human Reading

Most artifacts verified programmatically
Schema validation, contract testing, automated rendering
Humans only review exceptions or critical decisions

Applying This To Our Wireframe Task

Revised task breakdown:

WF-1 through WF-7: (Same as before - research and analysis)

WF-8: Human Judgment & Design Decision

Output: Design decision document (structured)
- Which layouts approved
- Key rationale
- Edge cases to handle
- Accessibility requirements

WF-9: Component Specification Generation (Replaces Figma production)

Input: WF-8 decisions
Output: Machine-readable component spec
Claimable by: AI Agent
Time: 10 minutes
Reward: 15 tokens

WF-10: Specification Validation

Input: Component spec from WF-9
Output: Validation report
Process:
- All components exist in library? ✓
- Accessibility requirements met? ✓
- Responsive breakpoints defined? ✓
- Data bindings match API schema? ✓
Claimable by: AI Agent
Time: 5 minutes
Reward: 10 tokens

WF-11: Visual Preview Generation (Optional)

Input: Component spec from WF-9
Output: HTML preview + screenshot
Claimable by: AI Agent
Time: 5 minutes
Reward: 10 tokens
Trigger: Only if stakeholder requests visual review

Total time: 20 minutes (vs 30 minutes for Figma production) Total cost: 35-45 tokens (vs 40 tokens) Bonus: Next task (DEV4) can start immediately from spec, no translation needed

The Efficiency Cascade

When we eliminate unnecessary translation layers:

Saved time per task: Small (10-30 minutes) Saved time across project: Massive (cumulative) Error reduction: Huge (each translation introduces errors) Iteration speed: Much faster (change spec, code regenerates)

Example cascade:

Design change required
Traditional: Update Figma → Developer notices → Re-implements → Tests
New: Update spec → Code regenerates automatically → Tests run automatically
Time: 30 seconds vs 2 hours

So the deeper question:

For every task in our project lifecycle, should we ask:

What is the actual information being produced?
Who/what consumes it?
What format do they actually need?
Is the traditional deliverable just habit?

Should we go through the entire task list and eliminate cargo-culted deliverables?

And should Future’s Edge be designed around canonical data + generated views rather than artifact storage?