News & Insights

Beyond the Translation Stack: Rethinking Design and Delivery in the Age of AI

Written by Andy Pimlett | Jul 1, 2025 4:18:24 PM

Introduction: A Theory of Translation and Compression

Over years in digital delivery, a persistent trend has emerged: the expansion of siloed disciplines alongside increasing depth in each. What began as simple collaboration between designers and developers has evolved into a complex chain of highly specialised roles.
While each contributes valuable expertise, they are, fundamentally, all engaged in the same overarching task: translating human intention into digital output.

In practice, this manifests as a cascade of translations: from vision to wireframe, wireframe to design, design to code, code to test, and so on. This system, though optimised for risk reduction, is inefficient, slow, and fundamentally fragile. It also disguises the fact that much of the work being done is not actually core to design or engineering, but rather necessary overhead: artefact creation, translation, and interpretation for consumption by both humans and machines.

This guide explores a theory: that artificial intelligence is not merely a force of automation or disruption - it is a compression layer, one that collapses these translations and exposes a new, more fluid paradigm. It is a shift not just in toolset, but in structure, mindset, and ultimately the model of value creation itself.

1. The Translation Stack: Why We Work This Way

The current delivery process is inherently layered:

1. Vision → Design
2. Design → Frontend Code
3. Frontend → Backend & Integration
4. Build → QA & Test
5. Test → Approval

Each handoff introduces latency, risk, and cost. The stack exists not because it is optimal—but because of human limitations:

  • Certainty is required before commitment, thus forcing up-front design and gating processes
  • No one person can master all disciplines
  • Human work is slow, expensive, and difficult to scale.

At its core, however, the stack serves a singular purpose: to tell a computer what to do. Every artefact - be it a Figma frame or a React component - is just a means to convey that “we want a blue box here.”

2. AI as Compression, Not Displacement

The popular narrative pits AI as either:

→ A threat that replaces humans.
→ A tool that assists existing human processes.

But there is a third, more compelling possibility: AI as a compression layer that removes friction between silos, allowing human creativity to flow more directly into working solutions.

This view reframes the purpose of AI:

→ Not to replace specialists, but to remove the grunt work that requires specialist mediation.
→ Not to accelerate artefact creation, but to reduce the need for artefacts entirely.

In this framing, designers aren't just freed from drawing rectangles. They're liberated to manifest ideas in partially working software, rapidly testable and refinable.

3. The Rise of the T-Shaped Creative Technologist  

In this AI-compressed world, a new archetype emerges: theT-shaped creative technologist.

These individuals:

  • Have strong foundational skills in either design or code.
  • Are capable of navigating adjacent disciplines with confidence.
  • Use AI tools to extend their reach and compress iteration time.

This doesn’t imply everyone must become a full-stack expert. It means that the barrier to experimentation is lowered. Instead of passing work through multiple hands for translation, the creative technologist can explore solutions directly in the browser or code editor.

Implications:

  • Prototypes can be partially built and tested by design-led teams.
  • Engineers step in later to refine, harden, and scale.
  • Clients engage earlier with *real experiences*, not abstract proposals.

4. From Artefact to Outcome: A Paradigm Shift

Let’s contrast paradigms:

Feature
Classical
Assistive AI
Compressed AI Paradigm
Discipline
Siloed
Specialised, AI-boosted
Blended, fluid roles
Process
Linear, artefact-driven
Faster artefact creation
Outcome-first, real-time iteration
Value
Predictability & control
Cost & speed gains
Continuous, tested solutioning
Role of AI
Optional productivity tool
Embedded assistant
Translation eliminator


In the compressed paradigm, the emphasis shifts:

  • From process adherence → to problem solving
  • From design sign-off → to design in use
  • From upfront certainty → to live experimentation

This isn’t Agile as ceremony - it’s agility as an operating system.

5. Risks, Considerations & Enterprise Realities

This paradigm remains unproven at enterprise scale. There are challenges:

→ Governance, security, and code quality
→ Design system integrity under distributed control
→ Accountability and traceability of decisions

However, the direction is clear. Even if classical engineers remain necessary for refinement, the inputs they receive will change:

  • Less static comps
  • More semi-functional code
  • Greater fidelity to the client’s original need

It’s not just the labour that changes - it’s the interface between people, tools, and outcomes.

6. The Future of Delivery: Value at the Centre

Ultimately, this is not about replacing roles. It’s about removing constraints:

  • Enabling more iteration within the same budget
  • Allowing design decisions to emerge from reality, not abstraction
  • Elevating the collaborative process over the artefact creation treadmill

Clients aren’t buying rectangles or commits. They’re buying tested answers to business problems. This new delivery model aligns better with that reality.

Even if job counts shift, value creation increases.

And where value increases, demand follows - albeit possibly consolidated in fewer, more adaptive organisations.

Conclusion: Beyond One-Shot AI or Status Quo

This theory rejects the binary of “AI does it all” versus “AI changes nothing.” It suggests a different path:

  • One where AI collapses friction between disciplines
  • Where humans stay at the centre, focused on intent and iteration
  • And where the final product is not just faster - but better

In this world, design becomes a live, evolving act, not a static document. And the best way to tell a computer what to do… may be to show it.