# Self-driving product: evidencia antes que parche

> PostHog conecta señales de producto con agentes que diagnostican y abren PRs; el valor está en cerrar el loop con evidencia, no en generar más código.

- Author: Viktor Berthelius (BRTHLS)
- Published: 2026-08-14
- Category: automation aiops
- Tags: posthog, self-driving-product, product-analytics, coding-agents
- Language: es
- Canonical: https://www.brthls.com/magazine/posthog-self-driving-product-evidencia-antes-parche-es
- Source: BRTHLS Magazine — https://www.brthls.com

---

## Problema

Un coding agent puede reparar un error descrito con precisión. El cuello de botella es anterior: saber qué ocurrió, a quién afectó, cómo reproducirlo y si el parche mejora el outcome sin crear otra regresión.

Una excepción aislada dice que algo se rompió. Una sesión muestra dónde. El historial del usuario revela qué intentaba conseguir. El segmento afectado indica si estamos ante una rareza o ante una fuga de conversión. Sin esa cadena, el agente solo ve el ruido más cercano al repositorio.

## Tesis

El producto autónomo no empieza en el repositorio. Empieza en una cadena de evidencia que conecta señal, diagnóstico, cambio y verificación.

Llamarlo *self-driving* puede llevar a imaginar un producto que se reescribe solo. La versión útil es menos espectacular y más exigente: un sistema que detecta una desviación, formula una hipótesis, propone un cambio reversible y comprueba si la métrica regresa al rango esperado.

**La medida correcta:** autonomía de producto no es velocidad de parche. Es distancia entre una señal real y una mejora demostrada.

## Framework

PostHog presenta Signals y scouts que inspeccionan errores, logs y session replays, diagnostican problemas y pueden crear pull requests. La arquitectura útil tiene cinco eslabones:

1. **Detectar:** reconocer una desviación con volumen, segmento y momento.
2. **Reconstruir:** unir evento, replay, error, flags y versión desplegada.
3. **Explicar:** formular una causa falsable, no un resumen del stack trace.
4. **Proponer:** abrir un cambio limitado con test y rollback.
5. **Comprobar:** observar después del despliegue si mejoró el comportamiento que originó el trabajo.

Mini-caso: el checkout móvil cae un 4 %. El log muestra un timeout, pero las replays revelan que ocurre tras aplicar un cupón y volver atrás. El parche correcto no es aumentar el timeout; es reparar el estado del carrito. La evidencia impide que el agente optimice el síntoma equivocado.

**Señal medible:** porcentaje de PRs agentivos vinculados a una señal reproducible y a una métrica posterior.

## Por que importa ahora

La generación de código ya no es escasa. La evidencia sí. Sin ella, un agente optimiza el síntoma más visible y el equipo acumula parches rápidos sin aprendizaje de producto.

Esta transición también redefine analytics. Deja de ser un panel que alguien consulta los viernes y se convierte en una capa de control que abre trabajo, aporta contexto y evalúa consecuencias. Eso exige disciplina: una métrica mal definida ahora no solo confunde una reunión; puede disparar código.

El equipo debe distinguir incidente, oportunidad y experimento. Un error reproducible pide reparación. Una caída de conversión pide investigación. Una hipótesis de crecimiento pide asignación y control. Si todo se convierte en PR, el sistema sustituye criterio por actividad.

## Anti-ejemplo

"El agente vio una excepción y abrió un PR." Una excepción no demuestra causa, impacto ni que el cambio arregle la experiencia.

El segundo anti-ejemplo es validar el cambio solo con tests del repositorio. Los tests prueban que el código hace lo especificado. La señal de producto prueba si especificamos la intervención correcta.

## Protocolo (3 pasos)

1. **Une la señal.** Adjunta error, replay, logs y segmento afectado.
2. **Exige hipótesis.** El PR debe explicar causa y mecanismo de mejora.
3. **Cierra el loop.** Verifica tests y comportamiento tras desplegar.

Conserva un recibo por intervención: señal original, hipótesis, diff, gate de despliegue, ventana de observación y resultado. Si el agente no puede producirlo, todavía genera parches; no conduce producto.

| Eslabón | Artefacto | Gate |
| --- | --- | --- |
| señal | evidencia reproducible | impacto real |
| cambio | hipótesis y diff | revisión |
| resultado | métrica posterior | mejora demostrada |

## Relacionado

- [Coding agents: limitar WIP para proteger la revisión](/magazine/coding-agents-limite-wip-capacidad-revision-es)
- [Output Verification Layer: el seguro invisible de los agentes](/magazine/output-verification-layer-seguro-invisible-agentes-produccion-es)

## Fuentes consultadas

- [PostHog: What if your product built itself?](https://posthog.com/blog/what-if-your-product-built-itself)
- [PostHog product platform](https://posthog.com/)

## Proximo paso

Toma el próximo PR generado por un agente y exige tres enlaces: evidencia original, reproducción y métrica que observarás después del despliegue.

---

_Cite as: Berthelius, V. (2026). "Self-driving product: evidencia antes que parche". BRTHLS Magazine. https://www.brthls.com/magazine/posthog-self-driving-product-evidencia-antes-parche-es_