How to incorporate PBX into your organization in 2026

This interview is part of Kameleoon's Expert FAQs series, where we interview leaders in data-driven CX optimization and experimentation. Alexandre Suon is a Head of Experimentation from Paris, and the co-author of an independent Henkan & Partners study into the efficacy of PBX: "Why Prompt-Based Experimentation Belongs on the C-Level Agenda."

How have you used PBX within your regular day-to-day experimentation? How has it changed your day-to-day work?

Because we’re a large organization, fully integrating PBX into our experimentation workflow will take time. Today, we run hundreds of tests per year, and our setups still rely mainly on injected JavaScript. So for now, PBX hasn’t drastically changed our daily operations—not because it lacks value, but because adoption at scale requires adjustments across processes, governance, and roles.

Right now, we’re in a transformation phase:

• identifying the fastest and most impactful PBX use cases,
  
  
• adapting our internal workflows to incorporate PBX,
  
  
• and rethinking the skill sets we will need next year and in two years.
  

We’re moving toward more “Swiss-knife” or jack-of-all-trades profiles who can bridge experimentation, QA, prompting, and product logic. PBX is not just a tool — it’s a shift in how teams will operate.

Can you tell me more about specification-mediated automation? What does it mean, and how should experimenters approach this new challenge?

Specification-mediated automation is the shift from code-based implementation to intent-based implementation. Instead of writing JavaScript, CSS, or using visual editors, experimenters now describe what they want, and AI translates that description into a full A/B test: experience, targeting, tracking, and logic.

In other words, the specification (your natural-language prompt) becomes the true source of truth—not the code.

This changes everything about how experiments are designed, built, and governed.

This concept showed up repeatedly in our PBX evaluation work: AI performs extremely well when intent is clear and structured, but breaks down when human intent isn’t expressed with enough precision (or when the task requires interpretation that goes beyond the specification).  

AKA : Prompt engineering is going to become a key function

PBX and vibe experimentation are continually challenging our concept of experimentation. What do you think will be the role of the experimenter as these processes evolve and improve?

I’ve always split experimentation roles into two archetypes: enablers and doers—and PBX affects them very differently.

Enablers

Enablers grow experimentation culture, enforce the framework, align stakeholders, and ensure decisions stay rigorous. Their role is deeply human. Even with automation, you still need people who:

• ask the right questions,
  
  
• challenge assumptions,
  
  
• keep teams aligned,
  
  
• and maintain the scientific method.
  

PBX won’t replace this role. If anything, it increases its importance.

Doers

For doers, PBX is transformative. Tasks that used to take days or weeks can now be executed in hours. Both analytics and experimentation workflows can scale dramatically.

This shift will allow companies to operate at a completely new pace—and those who don’t adopt these capabilities will fall behind.

The doer role becomes less about manual execution and more about validation, orchestration, and scaling initiatives.

What is the role of the developer in an organization that uses Prompt-Based Experimentation?

We don’t yet have developers fully dedicated to PBX—we’re still testing what the optimal setup looks like.

But PBX definitely introduces a new class of requirement. Even if PBX can generate high-quality code, someone must validate that it works exactly as intended.

As Lenny’s newsletter noted, this shift actually increases the need for strong QA.

I foresee a hybrid role emerging:

a jack-of-all-trades QA who can both prompt experiments and ensure the output meets the required standards.

This empowers QAs to build experiments while guaranteeing quality before launch.

So instead of removing developers, PBX reshapes the workflow:

• developers focus on system-level foundations,
  
  
• QAs evolve into experiment builders and validators,
  
  
• and experimenters orchestrate the entire process.
  

What guardrails do you use alongside PBX to catch off-brand or unexpected outputs?

Our approach is closely aligned with the shift described in Question 4—we rely heavily on empowered QA.

PBX can generate variations quickly, but that makes human validation even more important. Our guardrails include:

• ensuring QAs can detect off-brand UI,
  
  
• validating UX coherence,
  
  
• identifying unintended behaviors or side effects,
  
  
• and confirming that the generated experience aligns with business and brand rules.
  

In other words:

PBX accelerates creation, but human QA maintains quality and protects the brand.