Agentic AI Software Engineering Part 2: Design Shifts Left

In our previous post, we explored how AI is changing the engineering delivery model from months to days. We looked at the compression of traditional SDLC phases and the emergence of prompt-based development. Now we turn to what this means for design — and why the classic research-diverge-converge-handoff model is becoming a liability.

The traditional design process assumes time is abundant. Research for weeks. Diverge and converge. Polish mocks until they’re pixel-perfect. Then throw them over the wall to engineering. But when engineers can spin up a working React prototype in an afternoon using Claude Code and GitHub Copilot, the value of static mocks collapses. The design function doesn’t disappear — it shifts. From authoring artefacts to guiding execution.

In this post we explore what “design shifting left” looks like in practice, using a recent client engagement where we moved from Figma to deployed React components in hours, not weeks. If you’re in a hurry, here are the key takeaways:

  • Static mocks are becoming technical debt — working code is the new design spec
  • The designer’s role is shifting from “pixel author” to “execution guide” and “system connector”
  • Prompt-based UI generation (VS Code + Copilot + Claude) compresses the design-to-code gap to near-zero
  • Rapid feedback loops trump perfect upfront vision — especially for AI products with non-deterministic behaviour
  • The iceberg model: visible UI above water, connected APIs and domain logic below

Observation

Working with enterprise product teams over the past year, we’ve seen a clear pattern emerge. The teams shipping fastest aren’t the ones with the most detailed Figma libraries. They’re the ones where designers and engineers are co-creating in code from day one.

A recent engagement illustrates this shift perfectly. A client needed a customer-facing dashboard for an internal tool — something they’d previously estimated at 6-8 weeks using their standard process (design brief → research → mocks → review → handoff → development → QA). We approached it differently.

Day 1: Designer and engineer pair in VS Code. Designer describes the layout in natural language. Engineer prompts GitHub Copilot: “Create a responsive sidebar navigation with collapse behaviour, using our design tokens.” Copilot generates the component. Designer tweaks CSS values directly in the IDE. By end of day: a working navigation shell.

Day 2-3: Same pattern. “Create a data table with sorting and filtering.” “Add a modal for record editing.” Each prompt generates 70-80% of what’s needed. The remaining 20% is collaborative refinement — designer guiding spacing, interaction states, responsive breakpoints. Not in Figma. In code. The gap between “looks right” and “works right” collapses.

Day 4: We have something shippable. Not polished — but real. Usable. Testable. We deploy to a preview URL and put it in front of actual users. The feedback is immediate and concrete: “The filters are confusing” — so we iterate. “We need export” — so we add it. This is the shift: from guessing upfront to learning in production.

The traditionalists in the room were uncomfortable. Where were the comprehensive user flows? The detailed annotation? The “finish line” of design sign-off? But here’s what they missed: we got to validated learning in a week. The old model would still be in the research phase.

Key Concepts

1. The Design-to-Code Compression

The classic handoff model assumed design and engineering were sequential. Design finishes, then engineering starts. But modern AI coding assistants break this sequence. A designer with basic React knowledge can now generate working UI using natural language prompts. An engineer with taste can refine visual details without waiting for design sign-off.

The result: the “design phase” and “frontend development phase” merge into a single, fluid activity. The question isn’t “is the design approved?” — it’s “does this code match the user’s mental model?”

Traditional waterfall – User defines requirements and waits months to see and test the product
Agile or Wagile (waterfall + agile) – User defines requirements and waits weeks to see demo (no touching) and months to test the product
Agile or Wagile + AI led prototyping – User defines requirements and waits days to see and test the product, tighter feedback loop
This loop tightens from months to days. And each iteration produces working code, not static mocks that simulate working code.

2. The Iceberg: UI design is only the surface

Shifting of software design with UI prototypes is enabling users to see and test the product early but this is just the tip of an iceberg. Enterprise software goes deeper than this and for products that require UI and backend there are layers below the UI including experience api (UI API), domain service with the core business logic, domain API contracts (how to serve/integrate the domain logic), data models, integrations, platform etc. The early clarity with business users enables us to chip away at this iceberg layers faster because the dependency chain starts with what the user wants then towards the core business logic in the domain services layer and to the integrations and finally to the platform

The UI prototypes help us write better Experience API contracts and design the boundaries around our domain services and service/event contracts faster. Compare this to the most agile project where we do these in parts across multiple sprints and you realise that the upfront validation and design helps with alignment early in cross functional teams leading to a better quality and better wanted product

In our client engagement, as we built the UI, we were simultaneously discovering what the APIs needed to do. The table component needed sorting? That implies backend support. The modal needed to fetch related records? That shapes endpoint design. The UI becomes API spec — not in a document, but in running code.

This forces a new discipline: the “working prototype” isn’t throwaway code. It becomes the foundation. Which means you need architectural patterns that let you refactor from scrappy to production without full rewrite. Component boundaries. API versioning. Domain-driven design at the micro level.

3. What Remains Human

With all this acceleration, what do designers actually do? Three things that resist full automation:

Judgment about what matters. AI can generate infinite variants. Someone has to decide which path to pursue. This requires taste, product sense, and understanding user context that’s hard to compress into a prompt.

Connecting the experience. Individual components are easy to generate. A coherent user journey across many components? That requires systems thinking. Designers become the connective tissue, ensuring the whole holds together.

Accountability for outcomes. Someone has to own whether the thing actually helps users. AI can advise. It can’t settle disputes about priorities or take responsibility for shipped decisions.

The designer’s toolkit expands. They still need Figma — for the rapid exploration, the “what if?” phase where you need to see 10 variants in minutes. But they also need enough code literacy to guide implementation. Enough system thinking to connect components into journeys. Enough product sense to know what to ship and when.

Summary

  • Working code is the new design spec. Static mocks become outdated the moment engineers can generate working UI from prompts. The design function shifts from authoring to guiding.
  • The design-engineering divide collapses. When prompts generate 70-80% of UI code, the distinction between “design phase” and “build phase” dissolves. Co-creation in code becomes the default.
  • Speed enables learning. Rapid deployment and iteration beats perfect upfront planning — especially for AI products where behaviour is non-deterministic and can’t be fully mocked.
  • Architecture matters more, not less. The iceberg beneath the UI — APIs, domain logic, data models — needs careful design. But you discover those needs through building, not before.
  • Trust requires labelling and iteration. Ship early, but be clear about what users are getting. Then prove the “we’ll iterate” promise with rapid, visible improvements.
  • Human judgment amplifies. AI generates options. Humans decide which paths to pursue, connect disparate parts into coherent experiences, and own the outcomes.

Next post: We’ll look at the technical specification layer — how to capture the API contracts and domain logic that emerge from rapid UI prototyping, and how to publish these as living documents that keep pace with code.

Part 2 of the AI-Led Engineering series. Previous: Part 1: The Compression of SDLC. Next: Part 3 — Technical Specifications from Running Code.

Unknown's avatar

Published by alokmishra

Alok brings experience in engineering and architecting distributed software systems from over 20 years across industry and consulting. His posts focus on Systems Integration, API design, Microservices and Event driven systems, Modern Enterprise Architecture and other related topics