Cómo uso Linear, Codex, Claude Code y GitHub para lanzar experimentos de growth

Un experimento de growth suele morir en el espacio entre una buena idea y un handoff limpio.

La idea empieza afilada: cambiar la pregunta de onboarding, probar una nueva promesa en la landing page, agregar un nudge de ciclo de vida, apretar el flujo de la demo. Después se copia en un doc, se resume en Slack, se traduce en tareas, se reparte entre diseño, data, ingeniería y marketing, y poco a poco pierde su forma. Para cuando el experimento se lanza, nadie está del todo seguro de cuál era la hipótesis original.

Aquí es donde uso Linear, Codex, Claude Code y GitHub juntos.

Linear no es donde los agentes hacen el trabajo. Linear es donde el trabajo se mantiene organizado. Lo uso para la gestión de tareas y proyectos: intake, alcance, ownership, dependencias, criterios de aceptación y estatus.

Los agentes hacen la ejecución. Codex y Claude Code ayudan a programar, revisar, testear y preparar cambios. GitHub es donde esos cambios se vuelven concretos: branches, pull requests, CI, revisión e historial de merges.

La idea no es "los agentes de Linear corren el experimento." La idea es que Linear mantiene el experimento legible mientras los agentes mueven la implementación a través de GitHub.

El ciclo

Mi workflow tiene seis etapas:

1. Intake
2. Brief del experimento
3. Grafo de tareas
4. Instrumentación
5. QA de lanzamiento
6. Postmortem

El trabajo de Linear no es tomar la decisión. Mantiene visible el razonamiento, expone las piezas faltantes y mantiene cada artefacto conectado a la misma hipótesis. Los agentes de código trabajan desde esa estructura en lugar de desde prompts sueltos.

Etapa 1: Intake

El ciclo arranca con un solo issue de Linear:

Probar si agregar una pregunta de "meta de sueño" antes del screener aumenta la tasa de finalización.

Un sistema débil convierte eso en una tarea y pierde el contexto.

Un issue útil de Linear lo convierte en preguntas:

• ¿Para qué segmento es esto?
• ¿Qué métrica define el éxito?
• ¿Es un test de conversión, de calificación o de aprendizaje?
• ¿Cuál es el efecto mínimo detectable?
• ¿Qué métrica downstream podría empeorar?
• ¿Quién necesita aprobar el copy, el tracking de eventos y el lanzamiento?

El primer output no es una lista de tareas. Es un planteamiento del problema más afilado.

Hypothesis:
If we ask users to choose their sleep goal before the screener, completion rate will increase because the flow starts with user motivation instead of clinical qualification.

Primary metric:
Screener completion rate

Guardrail:
Qualified lead rate should not decrease by more than 5%

Decision rule:
Ship if completion improves by 10%+ and guardrail holds.

Esto ya cambia la calidad del trabajo. El equipo no está debatiendo un botón o un campo. Está debatiendo un mecanismo.

Etapa 2: Brief del experimento

Creo el brief dentro de Linear y lo enlazo al issue original.

Mantengo el brief aburrido:

• Contexto
• Hipótesis
• Audiencia
• Métrica primaria
• Métricas guardrail
• Eventos requeridos
• Variantes
• Owner
• Reviewers
• Checklist de lanzamiento
• Regla de decisión

Aburrido es bueno. Aburrido significa reutilizable.

El truco es que el brief se mantiene vivo. Si la variante cambia, quiero que el issue haga visible el tradeoff: ¿cambió la hipótesis, o solo la implementación? Si se agrega una métrica, ¿es primaria o es un guardrail? Si el copy cambia, ¿el mensaje sigue mapeando al mecanismo?

El brief se vuelve la columna vertebral del experimento.

Etapa 3: Grafo de tareas

La mayoría del seguimiento de experimentos se rompe porque el trabajo se representa como un checklist plano.

Los experimentos no son planos. Son grafos de dependencias.

Para este test, creo issues enlazados como:

• Escribir el copy de la variante
• Diseñar el paso de onboarding
• Implementar la variante de frontend
• Agregar los eventos de analítica
• Configurar el experimento en Statsig
• Hacer QA del disparo de eventos
• Redactar la nota de lanzamiento
• Monitorear las primeras 24 horas
• Readout tras alcanzar el umbral de muestra

Cada issue carga la parte del brief de la que depende.

El issue de analítica tiene los nombres de eventos. El issue de diseño tiene la audiencia y la hipótesis. El issue de QA tiene las métricas guardrail. El issue de readout tiene la regla de decisión.

Esa es la diferencia entre gestión de proyectos y memoria de workflow.

Cómo encajan Codex, Claude Code y GitHub

Linear es el sistema de proyecto. Codex, Claude Code y GitHub son el ciclo de ejecución a su alrededor.

Uso Linear para definir el trabajo: la hipótesis, los criterios de aceptación, las dependencias, el plan de eventos, el checklist de QA y la regla de decisión. Eso les da a los agentes de código un objeto estable contra el cual trabajar en lugar de un prompt vago.

Codex es donde corro los carriles de implementación. Para un experimento más grande, divido el grafo de tareas en issues estrechos de Linear y dejo que cada carril trabaje en su propio branch o worktree. Un carril puede conectar la variante de frontend. Otro puede agregar el tracking de eventos. Otro puede apretar el copy, los tests o la documentación. Lo importante es que cada carril reporta de regreso a la misma estructura de issues de Linear: qué cambió, qué se validó, qué está bloqueado y qué evidencia existe.

Claude Code es útil cuando quiero una segunda superficie de código en la terminal: revisar la forma de una implementación, explorar un repo, redactar un plan de migración o poner a prueba si el código todavía coincide con el brief del experimento. No lo trato como una fuente de verdad aparte. Es otra superficie de ejecución apuntando de regreso al mismo issue de Linear.

GitHub es donde el trabajo se vuelve revisable y lanzable. Los pull requests adjuntan el diff del código, el estatus de CI, los screenshots y la discusión de la implementación. Linear guarda el porqué. GitHub guarda el cambio exacto. El ciclo funciona cuando el PR enlaza de regreso al issue de Linear y la evidencia de validación regresa a Linear.

El workflow se ve así:

Linear issue -> Codex / Claude Code implementation -> GitHub PR -> review + CI -> Linear readout

Esa es la parte que hace durable al sistema. Linear no reemplaza a GitHub. GitHub no reemplaza a Linear. Codex y Claude Code no reemplazan al juicio. Cada herramienta es dueña de una parte distinta del ciclo.

Etapa 4: Instrumentación

La instrumentación es donde los buenos experimentos fallan en silencio.

El issue de Linear carga el plan de eventos antes de la implementación:

Events:
- sleep_goal_step_viewed
- sleep_goal_selected
- screener_started
- screener_completed
- lead_qualified

Properties:
- variant_id
- sleep_goal
- traffic_source
- device_type
- market

Después cada tarea de implementación se puede revisar contra el plan:

• ¿Se agregó el evento?
• ¿El naming es consistente?
• ¿Las propiedades están disponibles en el punto donde se dispara?
• ¿El analista puede segmentar por variante, mercado y dispositivo?
• ¿El dashboard coincide con la regla de decisión?

Esto no tiene glamour. Es exactamente el tipo de detalle que determina si el experimento crea conocimiento o solo actividad.

Etapa 5: QA de lanzamiento

Antes del lanzamiento, mantengo un checklist de QA específico del experimento, no genérico del producto.

Para este test:

• La variante renderiza en móvil y desktop
• La selección de meta se persiste a lo largo del screener
• El camino existente del screener sigue funcionando
• Los eventos se disparan en el orden correcto
• El bucketing de Statsig es estable
• El dashboard tiene las métricas primaria y guardrail
• Hay un owner de rollback asignado
• La nota de soporte está lista por si los usuarios preguntan sobre el nuevo paso

La decisión de lanzamiento pasa en el mismo lugar que el trabajo. No en la nota de una reunión. No en un hilo de Slack que después será imposible de encontrar.

Linear se vuelve la fuente de verdad del estado del experimento.

Etapa 6: Postmortem

El postmortem es donde el ciclo completo se vuelve más útil.

La mayoría de los equipos escriben los readouts como resúmenes de una sola vez:

La variante B mejoró la finalización en un 8%, no es estadísticamente significativo. No se lanza.

Eso no es suficiente.

Un postmortem útil responde:

• ¿Qué creíamos?
• ¿Qué pasó?
• ¿Qué cambió en nuestro entendimiento del usuario?
• ¿Qué deberíamos probar después?
• ¿Qué issues, docs, eventos, screenshots y dashboards respaldan esa conclusión?

El output se vuelve memoria reutilizable:

Learning:
Motivation-first onboarding increased early engagement but did not improve qualified completions. Users selected goals, but the added step created drop-off before clinical questions.

Next test:
Move goal selection after screener completion and use it to personalize follow-up copy.

Ese aprendizaje no desaparece en un deck. Se enlaza al siguiente ítem del backlog.

En qué es bueno este stack

El mejor uso de este stack no es "haz mi trabajo."

Es:

• Mantener el contexto atado a las tareas
• Convertir ideas vagas en briefs estructurados
• Identificar instrumentación faltante
• Crear el grafo de dependencias correcto
• Preservar las reglas de decisión
• Hacer reutilizables los postmortems
• Mantener el siguiente experimento conectado al último aprendizaje
• Dejar que los agentes programen, revisen y validen contra un issue claro
• Dejar que GitHub cargue el diff exacto, la revisión, el CI y el historial de merges

Por eso Linear es interesante en un workflow de desarrollo de producto AI-native. Ya está donde se negocia el trabajo. El issue es donde producto, ingeniería, diseño, soporte, ventas y marketing tocan todos el mismo objeto.

Si Codex y Claude Code trabajan desde ese objeto, pueden hacer más que generar código. Pueden ayudar a mantener la implementación alineada con la razón por la que existe el trabajo.

El punto de fondo

Los equipos de growth no necesitan más ideas de experimentos. Necesitan mejor memoria de experimentos.

Necesitan que la hipótesis, las tareas, los eventos, el QA, la decisión y el aprendizaje sobrevivan el viaje de la idea al trabajo lanzado.

Ese es el ciclo que corro con Linear, agentes de código y GitHub.

No un checklist más rápido.

Una mejor memoria de cómo aprende el equipo.