La IA ha reducido casi a cero el coste de generar variantes creíbles de cualquier pieza de producto: una página de inicio, un email, un onboarding, una pantalla vacía. Ruby on Rails hace trivial desplegar esas variantes detrás de un control de funcionalidad y retirarlas en segundos. Son dos avances grandes, y llevan al menos un año disponibles.
Y aun así, casi ningún equipo está experimentando como podría.
La mayoría usa la IA para generar código o redactar textos. Pocos la están usando para lo que, en nuestra experiencia, genera más retorno por hora invertida: producir varias alternativas viables y dejar que la realidad decida cuál funciona.
Experimentar solía ser caro
Los tests A/B siempre tuvieron un problema: el valor estaba claro, pero el coste de montarlos también. Para lanzar un solo experimento hacía falta:
- Redactar varias versiones de los textos.
- Diseñar variantes de la interfaz.
- Implementar el branching en el código, con controles de funcionalidad o con herramientas externas.
- Definir métricas con producto.
- Esperar dos semanas para tener resultados.
Con ese coste, solo se probaban las decisiones grandes: el precio, la página de inicio, quizá el onboarding. Lo demás —microtextos, el orden de una lista, el tono de un estado inicial— lo decidía quien tuviese la opinión más fuerte en la sala. Se decidía a ojo porque el coste de no hacerlo era demasiado alto.
La IA ha eliminado el cuello de botella
El cuello de botella siempre fue producir alternativas plausibles. Eso ya no existe.
Un solo prompt genera cinco versiones distintas. Por ejemplo:
Dame cinco variantes para la sección principal de esta página. Una centrada en ahorrar tiempo, otra en reducir coste, otra en fiabilidad, otra con tono agresivo y otra minimalista. Para cada una dame textos y dirección visual.
Y lo mismo sirve para secuencias de onboarding, estados vacíos, diálogos de confirmación, tablas de precios, asuntos de email o mensajes de error. Lo que antes ocupaba un sprint entero ahora se resuelve en minutos.
No es que la IA vaya a acertar siempre con la mejor variante. Es que ya no hace falta que acierte. Solo hace falta que produzca opciones razonables; el resto lo hace el tráfico real.
Rails ya trae casi todo lo que necesitas
Rails soporta template variants desde hace años, y se combinan perfectamente con un sistema de control de funcionalidad como Flipper. El patrón es corto:
# app/controllers/pages_controller.rb
def home
request.variant = :b if Flipper.enabled?(:new_hero, current_user)
end
# app/views/pages/
# home.html.erb <- versión control
# home.html+b.erb <- variante B
Rails elige la plantilla correcta sola. El control de funcionalidad decide quién ve cada variante: por plan, por país, por cohorte o al azar. Si algo sale mal, se desactiva el control y la variante desaparece, sin desplegar nada.
Esa última parte es la importante. Lo que hace segura la experimentación no es el A/B en sí, sino la capacidad de retirar una variante en segundos.
Medir con lo mínimo
Para medir, basta con una librería de seguimiento de eventos sencilla. Ahoy funciona bien en Rails:
ahoy.track "viewed_hero", variant: request.variant
ahoy.track "clicked_cta", variant: request.variant
Con eso se consultan resultados desde una rake task, un dashboard o la propia consola. Se elige la variante ganadora, se retira el control, y el ciclo vuelve a empezar con ideas nuevas.
Una nota importante: si vas a lanzar experimentos cada semana, lee antes How Not To Run An A/B Test, de Evan Miller. La significancia estadística es real, y parar un test en cuanto ves el resultado que querías es una forma muy popular de engañarse a uno mismo.
Qué pasa cuando tu plataforma te lo pone difícil
WordPress fue durante mucho tiempo una respuesta razonable a "quiero un sitio sin montar un stack entero". Y sigue siéndolo para muchos casos.
Pero el momento en que quieres experimentar en serio, aparece la fricción. Probar una tabla de precios distinta, un checkout rediseñado o un onboarding alternativo termina casi siempre en la misma historia: buscar un plugin, pagar una herramienta SaaS extra o meter JavaScript a mano en el head. Cada experimento deja deuda técnica.
En una aplicación Rails, esa misma variante se sube detrás de un control de funcionalidad el mismo día, sin plugins, sin SaaS externo y sin deuda. No es una crítica a WordPress: es simplemente una propiedad distinta del stack. Si la experimentación va a ser parte central de cómo tomas decisiones en los próximos años, merece la pena elegir herramientas que la abaraten en lugar de encarecerla.
La ventaja que se está quedando sobre la mesa
Durante años, la ventaja competitiva en experimentación la tenían las empresas con la infraestructura para hacerla: redactores, diseñadores, ingenieros, analítica y un sistema de controles decente.
La IA se ha cargado el coste de producir variantes. Rails —y otras plataformas modernas— se han cargado el coste de desplegarlas y retirarlas. Lo que queda es la cultura: ¿vas a decidir basándote en la opinión de la persona que más alto habla, o vas a dejar que el producto hable por sí solo?
En Laboratorio Web trabajamos así con TalentoHQ, HorarioWeb y HMS porque es la forma más barata que conocemos de equivocarnos poco y aprender rápido.
Si tu producto sigue tomando decisiones a ojo en 2026, no es por falta de herramientas. Es crecimiento compuesto que se está quedando sin recoger.
