Mejora tu producto en piloto automático usando Posthog
PostHog acaba de mostrar cómo se ve la automatización de producto cuando se hace sin trampa: agentes que observan el comportamiento real, proponen cambios concretos en forma de pull requests, y miden si el cambio funcionó después de mergearlo. Si no funcionó, el sistema genera nuevas señales y evalúa un rollback. Nadie toca producción sin que un humano presione "merge". El nombre que le dieron es "self-driving mode", y vale la pena tomarse el tiempo de entender por qué esa arquitectura importa más allá del mundo de producto.
La diferencia entre un agente que propone y uno que actúa
La mayoría de las conversaciones sobre automatización con IA colapsan en uno de dos extremos: el asistente que necesita que le des instrucciones manuales para cada tarea, o el agente "autónomo" que hace cambios sin supervisión y nadie termina de saber qué tocó. PostHog construyó algo en el medio, y la estructura del medio es lo que lo hace interesante.
El sistema arranca con lo que llaman Signals: observaciones crudas sobre el comportamiento del producto. Pueden venir de error tracking (excepciones con sus stack traces), de session replay (clics muertos, sesiones estancadas), o de herramientas externas como Zendesk, Linear o GitHub. No es el agente inventando un problema: es el agente leyendo lo que ya está pasando. Desde esas señales, Scouts programados con memoria persistente las convierten en reportes que aterrizan en un Inbox, ya deduplicados y agrupados. De ahí, el agente propone un PR. El PR llega al humano. El humano decide.
Lo que hace el loop completo, y no solo la mitad costosa, es la etapa post-merge: cada cambio que entra a producción lleva instrumentación propia; PostHog mide si la métrica que se buscaba mover efectivamente se movió; y si no se movió, eso genera nuevas señales. El sistema cierra el ciclo sobre sus propios resultados. Esa disciplina de medir-y-considerar-rollback es lo que separa un flujo de trabajo honesto de uno donde los agentes "hacen cosas" y el equipo nunca sabe bien si funcionaron.
Por qué la arquitectura importa más que el nombre
"Self-driving" es un nombre de marketing, pero el diseño subyacente tiene tres principios que merecen atención: observación basada en datos reales (no en suposiciones del agente), propuesta en lugar de acción (PRs en vez de cambios directos), y validación post-hoc con posibilidad de reversión. Los tres juntos forman una postura epistemológica: el agente no sabe si su propuesta es buena, y el sistema está diseñado para descubrirlo empíricamente en vez de asumir que sí.
En materia de seguridad y privacidad, PostHog tomó decisiones razonables para la etapa beta: los entornos de ejecución están aislados, el código y los datos de clientes no se usan para entrenar modelos, y los agentes respetan las branch protections y las reglas de CI que el equipo ya tiene. El proof point más elocuente es que PostHog mismo usa el sistema en su propio repositorio: hay PRs mergeados sobre caché, web analytics, cohorts e infraestructura de feature flags. No es una demo controlada; es el producto aplicándose a sí mismo.
La lectura para growth, paid media y martech
La propuesta de PostHog es específicamente sobre código de producto. No corre sobre cuentas de Google Ads, no toca Meta Business Manager, no mueve presupuestos ni creativos. Ese detalle importa: el lector de paid media o de growth que lea esto como "ya hay agentes que manejan mis campañas solos" está leyendo algo que la página no dice.
Lo que sí dice, y eso es lo relevante para el ecosistema más amplio, es que la arquitectura de la loop existe y funciona. Observe-propose-gate-measure-rollback es un patrón reproducible. Ya hay señales de que algo equivalente está llegando al mundo de ads y martech: plataformas que generan variantes de creativos, herramientas que sugieren ajustes de puja, o los servidores MCP de ads que permiten que un agente lea y escriba en cuentas publicitarias a través de instrucciones en lenguaje natural (ver nuestra nota sobre los servidores MCP de ads). La pregunta no es si ese loop llegará a las cuentas de clientes; es qué versión del loop va a ser la duradera.
La versión duradera se parece a lo que PostHog construyó: un humano informado que aprueba, y una medición objetiva que juzga si el cambio valió la pena. La versión que va a generar titulares de "el agente arruinó la campaña" es la que saltea uno de los dos.
La pregunta de gobernanza que la página no responde
El sistema es beta y el modelo de precios por pull request completado es inusual. No está claro todavía cómo escala cuando los PRs son complejos o cuando el Inbox se llena de señales contradictorias. Tampoco se sabe cuánto peso tiene el agente para priorizar qué Signals merecen un Scout y cuáles son ruido: si esa priorización es opaca, el humano en el gate está aprobando o rechazando propuestas sin saber por qué el agente eligió ese problema y no otro.
La pregunta más abierta es de gobernanza: quién en el equipo tiene acceso al Inbox, y cómo se auditará, en seis meses, qué PRs abrió el agente, cuáles se mergearon, y qué cambió en la métrica. El loop de medición existe, pero la trazabilidad histórica de las decisiones humanas dentro de ese loop no está documentada en lo que muestra la página hoy. Eso es algo que cualquier organización que adopte esta clase de herramienta va a tener que resolver por su cuenta, con independencia de lo que la plataforma ofrezca por defecto.
Fuentes
Este contenido fue desarrollado con asistencia de IA y revisado por el equipo de Zenda. Las malas ideas son 100% nuestras.