Vibe Coding: cuando lo difícil es elegir qué construir

El cuello de botella se movió—esto es lo que cambia

La primera vez que ves a una IA generar una pantalla, una llamada a una API o una automatización funcionando en minutos, se siente como un atajo. Lo que antes requería días de tickets, esperas e idas y venidas aparece de repente: “Aquí está la funcionalidad”.

Y entonces aparece otro tipo de silencio.

¿Es esta la funcionalidad correcta? ¿Debería existir? ¿Qué significa que esté “funcionando” para tus usuarios, tus datos, tus políticas y tu negocio?

El cambio central: de tipear a decidir

Vibe coding no elimina el esfuerzo: lo redistribuye. Cuando producir código se vuelve rápido y barato, la limitación ya no es la capacidad del equipo para implementar. La limitación es tu capacidad para tomar buenas decisiones:

• ¿Qué problema estamos resolviendo y para quién?
• ¿Qué estamos dispuestos a sacrificar (precisión, tiempo, seguridad, alcance)?
• ¿Qué debe cumplirse para considerar esto “terminado”?

Cuando esas respuestas son poco claras, la velocidad genera ruido: más prototipos, más medias-funciones, más resultados “casi correctos”.

Para qué sirve este artículo (y para quién)

Esta es una guía práctica para quienes necesitan convertir salidas rápidas en resultados reales: product managers, fundadores, diseñadores, líderes de equipo y stakeholders no técnicos que ahora se encuentran “construyendo” mediante prompts.

Aprenderás a pasar de vibras vagas a requisitos claros, priorizar cuando todo parece fácil de enviar, decidir qué pasa de prototipo a producto y establecer bucles de feedback para que la programación asistida por IA produzca valor medible—no solo más código.

Qué significa “vibe coding” en la práctica

“Vibe coding” es un nombre coloquial para construir software dirigiendo una IA en lugar de escribir cada línea manualmente. Describes lo que quieres en lenguaje natural, la IA propone código y se itera en conjunto—como pair programming donde tu “pareja” puede esbozar rápido, refactorizar bajo demanda y explicar opciones.

En plataformas como Koder.ai, este flujo de chat-a-construcción es el producto: describes la app que quieres, el sistema genera una implementación web/servidor/móvil funcional y iteras conversando—sin tener que ensamblar cinco herramientas distintas solo para lanzar un prototipo.

Cómo se ve en el día a día

La mayoría de ciclos de vibe coding siguen el mismo ritmo:

1. Prompt: indicas el objetivo, las restricciones y el contexto (“Añade un formulario de pago con validación, conserva el diseño actual, usa Stripe”).
2. Generar: la IA produce código, tests o un plan.
3. Revisar: lo lees como revisor de código—comprobando corrección, casos límite, seguridad y encaje con el producto.
4. Iterar: afinás el prompt (“No almacenés datos de tarjeta; manejá pagos fallidos; agregá nombres de eventos de analytics”).

Qué no es

No es magia y no es “construir cualquier cosa al instante”. La IA puede equivocarse con confianza, malinterpretar tu dominio o introducir errores sutiles. El juicio, las pruebas y la responsabilidad siguen siendo humanas. Vibe coding cambia cómo se produce el código, no la necesidad de asegurar que sea seguro, mantenible y alineado con el negocio.

Flujos comunes que vas a ver

• Chat-a-código: describir funcionalidades en un chat y luego pegar o aplicar los cambios sugeridos.
• Generación de código en el IDE: sugerencias inline, refactors, generación de tests y ediciones tipo “haz esta función más limpia”.
• Tareas estilo agente: dar un objetivo (“agrega exportación a CSV”) y dejar que la herramienta haga cambios multietapa en varios archivos, luego revisar un diff propuesto.

El nuevo factor limitante: claridad de intención

Cuando generar código es barato, el recurso escaso son las decisiones claras: qué debe existir, qué significa “hecho”, qué excluir y qué riesgos son aceptables. Mejor intención = mejor salida = menos sorpresas caras después.

Por qué escribir menos código aumenta la necesidad de mejores decisiones

Hace unos años, la principal limitación en software era el tiempo de desarrollador: sintaxis, boilerplate, conectar servicios y “simplemente hacerlo funcionar”. Esas fricciones obligaban a los equipos a ser selectivos. Si una funcionalidad tomaba tres semanas, se discutía mucho si valía la pena.

Con la programación asistida por IA, gran parte de esa fricción disminuye. Podés generar variantes de UI, probar distintos modelos de datos o levantar un proof-of-concept en horas. Como resultado, la limitación pasa de producción a dirección: gusto, trade-offs y decidir qué es realmente valioso.

Explorar más barato implica más decisiones

Cuando las opciones son caras de construir, las limitás naturalmente. Cuando son baratas, generás más—a propósito o no. Cada “experimento rápido” suma elecciones:

• ¿Qué versión coincide con el objetivo?
• ¿Qué hay que mantener, eliminar o fusionar?
• ¿Qué casos límite son aceptables ahora?

Así que mientras aumenta la salida de código, el volumen de decisiones crece aún más rápido.

Deuda de decisión: el nuevo desperdicio

La “deuda de decisión” se acumula cuando evitás elecciones difíciles: criterios de éxito poco claros, propiedad difusa u opciones no resueltas (velocidad vs calidad, flexibilidad vs simplicidad). El código puede generarse fácil, pero el producto se vuelve más difícil de dirigir.

Signos comunes incluyen múltiples implementaciones a medio terminar, funciones solapadas y reescrituras repetidas porque “no se sintió bien”.

Objetivos poco claros siguen causando churn

Si la meta es vaga (“mejorar la incorporación”), la IA puede ayudarte a construir algo, pero no puede decir si mejoró la activación, redujo tickets de soporte o acortó el time-to-value. Sin un objetivo claro, los equipos iteran en ciclos que parecen productivos—hasta que se dan cuenta de que enviaron movimiento, no progreso.

El nuevo cuello de botella: decidir qué debe existir

Cuando el código es barato de producir, el recurso escaso es la claridad. “Construime una función” deja de ser una petición de implementación y se vuelve una petición de juicio: qué construir, para quién y con qué estándar.

Decisiones clave que no podés tercerizar

Antes de pedirle a una IA (o a un compañero), tomá un pequeño conjunto de decisiones de producto que definan la tarea:

• Problema: ¿Qué dolor resolvemos y qué desencadenó esta petición?
• Usuario: ¿Para quién es (usuario primario) y quién se ve afectado indirectamente?
• Resultado: ¿Qué debe ser verdad después del lanzamiento (cambio de comportamiento, tiempo ahorrado, menos errores)?
• Restricciones: tiempo, presupuesto, legal/compliance, plataformas, integraciones, accesibilidad.
• Métricas de éxito: cómo sabrás que funcionó (adopción, conversión, retención, tickets de soporte, latencia).

Sin esto, obtendrás “una solución”—pero no sabrás si es la correcta.

Separá el “qué” del “cómo”

Una regla útil: decidí el “qué” en términos humanos; dejá que la IA proponga el “cómo”.

• Decisiones de qué: flujo de usuario, permisos, datos requeridos, criterios de aceptación, estados de error.
• Decisiones de cómo: frameworks, estructura del código, detalles de implementación, refactors.

Si los mezclás demasiado pronto (“Construilo en React con la librería X”), podés bloquear sin querer un comportamiento de producto equivocado.

Decisiones ocultas que complican después

Vibe coding suele desplegar valores por defecto que no elegiste conscientemente. Señalalos explícitamente:

• Valores por defecto: configuraciones iniciales, estados vacíos, campos pre-rellenados.
• Casos límite: duplicados, reintentos, fallos parciales, comportamiento offline.
• Manejo de datos: qué se guarda, por cuánto tiempo, necesidades de exportación/eliminación.
• Permisos: quién puede ver/editar/eliminar, logs de auditoría, overrides de admin.

Lista rápida previa al prompt

Antes de escribir un prompt, respondé:

1. ¿Quién es el usuario y qué tarea intenta realizar?
2. ¿Cuál es el resultado mínimo aceptable?
3. ¿Qué no debe ocurrir (riesgos, cumplimiento, seguridad)?
4. ¿Qué entradas/salidas existen (datos, sistemas, roles)?
5. ¿Cuáles son 3 tests de aceptación que prueban que funciona?

Estas decisiones convierten “generar código” en “entregar un resultado”.

De vibras vagas a requisitos claros

La IA puede convertir una idea difusa en código funcional rápido—pero no puede adivinar qué significa “bueno” para tu negocio. Prompts como “mejoralo” fallan porque no especifican un resultado objetivo: mejor para quién, en qué escenario, medido cómo y con qué trade-offs.

Empezá por el resultado, no por la implementación

Antes de pedir cambios, escribí el resultado observable que querés. “Los usuarios completan el checkout más rápido” es accionable. “Mejorar el checkout” no lo es. Un resultado claro le da dirección al modelo (y al equipo): qué mantener, qué quitar y qué medir.

Usá artefactos ligeros (no burocracia pesada)

No necesitás una spec de 30 páginas. Elegí uno de estos formatos cortos y mantenelo en una sola página:

• PRD de una página: problema, objetivo, no-objetivos, métrica de éxito, restricciones, preguntas abiertas.
• Historia de usuario: “Como ___, quiero ___, para ___”.
• Criterios de aceptación: condiciones concretas que deben cumplirse para dar por “hecho”.

Si usás un builder centrado en chat como Koder.ai, estos artefactos se mapean bien a prompts—especialmente con una plantilla consistente como “contexto → objetivo → restricciones → criterios de aceptación → no-objetivos.” Esa estructura suele marcar la diferencia entre una demo llamativa y algo que realmente puedas enviar.

Requisitos nítidos vs vagos (ejemplos)

• Vago: “Hacer más fluido el onboarding.”

• Nítido: “Reducir el abandono en onboarding del 45% al 30% eliminando el paso ‘tamaño de empresa’; los usuarios pueden saltarlo y aún llegar al dashboard.”

• Vago: “Agregar un mejor buscador.”

• Nítido: “La búsqueda devuelve resultados en <300ms para el 95% de las consultas y soporta coincidencia exacta + tolerancia a errores tipográficos para nombres de producto.”

• Vago: “Mejorar la seguridad.”

• Nítido: “Requerir MFA para roles admin; registrar todos los cambios de permisos; retener logs de auditoría por 365 días.”

Escribí las restricciones explícitamente

La velocidad aumenta el riesgo de romper límites silenciosamente. Poné restricciones en el prompt y en la spec:

• Tiempo/presupuesto: “Debe lanzarse en 2 días; no usar servicios pagados nuevos.”
• Límites técnicos: “Solo PostgreSQL; no introducir Kafka.”
• Cumplimiento: “No PII en logs; eliminación GDPR en 30 días.”

Requisitos claros convierten el vibe coding de “generar cosas” a “construir lo correcto”.

Priorización cuando todo parece barato de construir

La programación asistida por IA hace que el “esfuerzo” parezca colapsado. Eso es bueno para el impulso—pero también facilita enviar lo incorrecto más rápido.

Usá un método de puntuación ligero

Una matriz impacto/esfuerzo simple sigue funcionando, pero obtendrás más claridad con RICE:

• Reach (Alcance): cuántas personas lo usarán en un periodo dado.
• Impact (Impacto): cuánto mueve la métrica clave (pequeño/medio/grande).
• Confidence (Confianza): cuán seguro estás acerca del alcance e impacto.
• Effort (Esfuerzo): tiempo desde la idea hasta hecho (no “primer demo”).

Aunque la IA reduzca el tiempo de codificación, el esfuerzo aún incluye pensamiento de producto, QA, docs, soporte y mantenimiento futuro. Ahí es donde “barato de construir” deja de ser barato.

La velocidad puede ocultar costo de oportunidad

Cuando todo parece construible, el verdadero costo es lo que no construiste: el bug que no arreglaste, el flujo de onboarding que no mejoraste, la petición del cliente que ignoraste.

Una regla práctica: mantené una lista corta “Ahora / Siguiente / Después” y limitá Ahora a 1–2 apuestas a la vez. Si llega una nueva idea, debe reemplazar algo—no sumarse.

Limitá el WIP y definí “hecho” antes de empezar

Establecé una definición de hecho que incluya: métrica de éxito, verificaciones básicas de QA, evento de analytics y una nota interna que explique la decisión. Si no puede cumplir la definición rápido, es un prototipo—no una función.

Cómo decir no (y qué recortar primero)

Al priorizar, recortá en este orden:

1. Casos límite (mantené el happy path)
2. Extras agradables (mantené la promesa principal)
3. Personalización (lanzá una configuración por defecto opinionada)
4. Pulido (solo después de que el uso pruebe valor)

Vibe coding funciona mejor cuando cada “sí” es un compromiso con resultados, no con output.

Prototipado vs producto: elegir qué gradúa a “real”

La programación asistida por IA hace que los prototipos aparezcan rápido—y eso es tanto regalo como trampa. Cuando un equipo puede generar tres variantes de una función en un día, esos prototipos compiten por atención. La gente recuerda la demo que se veía más cool, no la que resolvía el problema correcto. Pronto mantenés “cosas temporales” que se convierten en dependencias.

Por qué los prototipos se multiplican (y confunden)

Los prototipos son fáciles de crear pero difíciles de interpretar. Difuminan líneas importantes:

• ¿Es esto un concepto o un compromiso?
• ¿Es seguro, cumplible y soportable?
• ¿Mide algo real o solo muestra algo posible?

Sin etiquetas claras, los equipos debaten detalles de implementación de algo que solo buscaba responder una pregunta.

Usá una escalera de prototipos

Tratá los prototipos como peldaños con distintos objetivos y expectativas:

1. Boceto: aclarar la idea y el flujo de usuario.
2. Clicable: probar comprensión y deseo.
3. Funcional: probar factibilidad y casos límite con rutas de datos reales.
4. Producción: construir para fiabilidad, seguridad, monitoreo y soporte.

Cada peldaño debe tener una pregunta explícita que responde.

Decidí con señales de validación

Un prototipo “gradúa” por evidencia, no por entusiasmo. Buscá señales como:

• Entrevistas con usuarios que confirmen el problema y el flujo propuesto.
• Pilotos pequeños con una audiencia definida y criterios de éxito.
• Patrones de retención/uso (uso repetido, time-to-value, completitud de tareas).

La regla que evita productos accidentales

No escales un prototipo—a más usuarios, más datos, más integraciones—sin una decisión documentada de comprometerse. Esa decisión debe nombrar al responsable, la métrica de éxito y qué dejarás de construir para financiarlo.

Si iterás rápido, hacé de la “reversibilidad” un requisito de primera clase. Por ejemplo, Koder.ai soporta snapshots and rollback, que es una forma práctica de experimentar agresivamente y poder volver a un estado conocido cuando un prototipo se descontrola.

Calidad y riesgo: la velocidad no elimina la responsabilidad

Vibe coding puede dar la sensación de “simplemente enviarlo” porque el código aparece rápido. Pero el perfil de riesgo no disminuye—se desplaza. Cuando la salida es barata, decisiones de baja calidad y salvaguardas débiles se amplifican más rápido.

Qué suele salir mal

Los modos de fallo comunes no son exóticos—son errores corrientes producidos a mayor volumen:

• Huecos de seguridad: cheques de auth inseguros, riesgos de inyección, endpoints expuestos, CORS permisivo.
• Flujos rotos: casos límite omitidos, estados UX confusos, manejo parcial de errores.
• Propiedad de datos poco clara: dónde viven los datos, quién puede acceder, reglas de retención y auditabilidad.

El código generado por IA aún necesita escrutinio

El código asistido por IA debe tratarse como código escrito por un nuevo compañero que trabaja extremadamente rápido: útil, pero no automáticamente correcto. La revisión es innegociable—especialmente en autenticación, pagos, permisos y cualquier cosa que toque datos de clientes.

Guardarraíles que mantienen la velocidad segura

Algunas prácticas ligeras preservan la velocidad y reducen sorpresas:

• Revisión de código como puerta (incluso para cambios “pequeños”).
• Tests automatizados para rutas críticas: login, compra, CRUD básico y permisos.
• Modelado de amenazas para nuevas funciones: “¿qué podría salir mal y cómo lo detectaríamos?”.
• Logging + monitoreo: logs estructurados, tracking de errores y alertas para flujos clave.

Una lista simple de “no ir”

Hacé estas reglas estrictas desde el principio y repetilas con frecuencia:

• No secretos en prompts (API keys, tokens, datos de clientes).
• No dependencias sin revisar añadidas “porque la IA lo sugirió”.
• No librerías con licencias poco claras o ausentes.
• No mergear funciones con tests faltantes en rutas críticas.

La velocidad es una ventaja solo cuando podés confiar en lo que enviás—y detectar problemas rápido cuando no podés.

Bucles de feedback que convierten salida en resultados

Construir rápido solo importa si cada iteración te enseña algo real. El objetivo no es “más output”. Es convertir lo que enviaste (o mockeaste) en evidencia que guíe la siguiente decisión.

El bucle que debés correr siempre

Un bucle simple mantiene el vibe coding con los pies en la tierra:

prompt → construir → testear → observar → decidir

• Prompt: indicá el problema de usuario, el comportamiento previsto y lo que intentás aprender.
• Construir: generá la versión más pequeña que responda la pregunta.
• Testear: probalo con uso real, no solo “funciona en mi máquina”.
• Observar: capturá qué hacen y dicen las personas.
• Decidir: parar, seguir o cambiar dirección—basado en evidencia.

Recopilá feedback rápido (sin procesos pesados)

No necesitás un departamento de research para obtener señal pronto:

• Prompts in-app: una encuesta de una pregunta tras una acción clave (“¿Esto te ayudó a terminar más rápido? Sí/No”).
• Notas de sesión: pedí a 3–5 usuarios que lo prueben; anotá citas textuales y dónde dudaron.
• Analytics ligero: trackeá pocos eventos ligados al resultado (start → complete, time-to-complete, drop-off).
• Escaneo de canales de soporte: etiquetá mensajes que mencionen la función; contá repeticiones.

Puntos de control y límites de tiempo

Después de cada iteración, hacé un checkpoint:

• Seguir: la evidencia dice que es útil y seguro—mejoralo.
• Cambiar: hay algo de valor, pero el enfoque es erróneo—revisá la hipótesis.
• Parar: poco valor o alto riesgo—archivalo.

Para evitar iteraciones infinitas, poné timeboxes a experimentos (por ejemplo, “dos días o 20 sesiones de usuario”). Cuando el timebox termine, hay que decidir—aunque la decisión sea “pausar hasta poder medir X”.

Roles del equipo: quién decide, quién revisa, quién es dueño de los resultados

Cuando la IA puede producir código bajo demanda, “quién puede implementarlo” deja de ser la limitación principal. Los equipos que funcionan bien con vibe coding no eliminan roles—los reequilibran alrededor de decisiones, revisión y responsabilidad.

El decisor: una garganta que toser (en buen sentido)

Necesitás un decisor claro por iniciativa: un PM, fundador o líder de dominio. Esta persona responde:

• ¿Qué problema resolvemos, para quién y por qué ahora?
• ¿Qué significa “hecho” (métrica de éxito + criterios de aceptación)?
• ¿Qué no construiremos explícitamente?

Sin un decisor nombrado, la salida de la IA puede convertirse en un montón de features a medio terminar que nadie pidió y que nadie puede liberar con confianza.

Los desarrolladores pasan de mecanógrafos a revisores, arquitectos y coaches

Los desarrolladores siguen construyendo—pero gran parte de su valor se desplaza a:

• Revisar código generado por IA por corrección, seguridad, rendimiento y mantenibilidad.
• Decisiones de arquitectura: límites, modelos de datos, patrones de integración y “cómo encaja esto en el sistema”.
• Entrenar a otros en prompts, restricciones y cómo traducir la intención de producto en tareas implementables.

Pensá en los ingenieros como editores y pensadores de sistemas, no solo productores de líneas de código.

Contribuyentes no técnicos: redactores de specs y evaluadores

Diseñadores, líderes de soporte, ops y ventas pueden contribuir directamente—si se enfocan en claridad en lugar de detalles de implementación.

Entradas útiles que pueden liderar:

• Una spec de una página: historia de usuario, restricciones, casos límite, ejemplos y qué medir.
• Un script de prueba: “clic acá, ingresá esto, esperá eso.”
• Un chequeo de realidad: ¿el prototipo realmente resuelve el problema del cliente?

El objetivo no es “hacer mejores prompts”, sino definir cómo se ve el éxito para que el equipo juzgue las salidas.

Rituales de colaboración que impiden que la velocidad derive en caos

Unos rituales ligeros hacen explícitos los roles:

• Revisiones de prompt (10 minutos): compartí el prompt + restricciones antes de generar mucho código.
• Demo Fridays: mostrá qué cambió, qué sigue y qué se canceló.
• Registros de decisiones: un registro corto de lo decidido, por quién y por qué (linkealo en tu tracker o al template /blog/decision-log).

Ser dueño de resultados (no solo de envío)

Asigná un “owner de resultados” por función—a menudo el mismo que el decisor—que monitoree adopción, carga de soporte y si la función mueve la métrica. Vibe coding abarata construir; debería acelerar el aprendizaje, no volver la rendición de cuentas difusa.

Un flujo práctico para vibe coding sin caos

La velocidad solo es útil cuando se apunta al blanco correcto. Un flujo ligero mantiene la programación asistida por IA productiva sin convertir tu repo en un archivo de experimentos.

Un flujo simple de punta a punta

Empezá con un embudo claro de idea a resultado medible:

1. Backlog: registrá las peticiones como una línea + el “porqué” (quién se beneficia, qué problema resuelve).
2. Spec: convertí el ítem elegido en una descripción pequeña y testeable (entradas, salidas, casos límite y qué significa “hecho”).
3. Generar: usá IA para redactar código, tests y docs a partir de la spec—no desde un chat vago.
4. Revisar: humanos verifican comportamiento, implicaciones de seguridad/privacidad y consistencia con estándares.
5. Merge: lanzar detrás de un feature flag cuando sea posible.
6. Medir: confirmar el resultado (activación, tiempo ahorrado, tasa de error, tickets de soporte).

Si evaluás cómo encaja esto en tu equipo, mantené la barra simple: ¿podés ir de “idea” a “cambio medido” repetidamente? (/pricing)

Artefactos útiles que mantienen alta la calidad

Algunos “predeterminados” pequeños previenen la mayor parte del caos:

• Plantillas de prompt: “contexto → objetivo → restricciones → criterios de aceptación → no-objetivos.”
• Estándares de codificación: nombrado, logging, manejo de errores y reglas de dependencias.
• Tests de aceptación: escenarios en lenguaje llano más cheques automatizados (unit/integración).

Documentá decisiones, no solo código

Tratá la documentación como un registro de decisiones:

• Qué suposiciones se hicieron (y qué las falsaría)
• Qué alternativas se rechazaron (y por qué)
• Riesgos conocidos y seguimientos

Un consejo práctico si estás en un entorno gestionado: hacé explícita la “exitabilidad”. Herramientas como Koder.ai soportan source code export, lo que ayuda a tratar la aceleración por IA como palanca—no como lock-in—cuando un prototipo se vuelve producto duradero.

Si necesitás ayuda para montar este flujo o calibrar responsabilidades de revisión, encomendalo a un único responsable y buscá asesoría externa si hace falta. (/contact)

Ejemplo: convertir “construime una función” en una decisión clara

Un PM deja un mensaje: “¿Podemos agregar una función ‘Smart Follow‑Up’ que recuerde a los usuarios escribirles a los leads que no contactaron?” Con codificación asistida por IA, el equipo genera tres versiones en dos días:

• un modal de recordatorio programado
• una pestaña tipo bandeja “Follow‑Ups”
• un correo borrador automático

Entonces todo se detiene. Ventas quiere más automatización (“que lo redacte por ellos”), Soporte teme usuarios enviando mails equivocados y Diseño dice que la UI se está saturando. Nadie puede ponerse de acuerdo en cuál versión es “mejor” porque la petición original nunca dijo qué aspecto medir.

Dónde se trabó el equipo

Tenían:

• Objetivos en conflicto: ahorrar tiempo vs evitar errores vs mantener la app simple
• Usuario poco claro: ¿SDRs? ¿fundadores? ¿agencias?
• Sin métrica: ¿menos follow-ups perdidos, mayor tasa de respuesta o menos churn?

Así que el equipo siguió construyendo alternativas en vez de decidir.

La solución: convertirlo en una decisión, no en una vibra

Reescribieron la petición en un resultado medible:

Resultado objetivo: “Reducir el % de leads sin follow-up en 7 días de 32% → 20% para equipos SDR.”

Alcance limitado (v1): recordatorios solo para leads marcados ‘Hot’.

Criterios de aceptación:

• el usuario puede establecer una fecha de follow-up en la vista del lead
• el recordatorio aparece in-app (no por email) una vez al día
• el usuario puede posponer o marcar como hecho con un clic
• evento de tracking: followup_reminder_completed

Ahora el equipo puede elegir la implementación más simple que pruebe el resultado.

Lista de verificación reutilizable

• ¿Quién es el usuario primario?
• ¿Qué cambia el resultado y en cuánto?
• ¿Qué incluye v1 (y qué queda explícitamente afuera)?
• ¿Qué lo haría un “no”? (riesgo, cumplimiento, carga de soporte)
• ¿Cuáles son los criterios de aceptación y la métrica principal a vigilar?