La precisión del vibe coding es una medición, no una propiedad del modelo
Dos equipos que usan el mismo modelo obtienen resultados muy distintos, porque la precisión al nivel que te importa la determina lo que ocurre después de la generación. ¿Alguien lo comprobó? ¿Contra qué? ¿Cuánto tardó en volver un resultado incorrecto para poder corregirlo?
Planteado así, la pregunta deja de ser «qué modelo es más preciso» y pasa a ser «cómo es mi ciclo de retroalimentación», que es algo que tú controlas.
Qué vale la pena medir
¿Ocurre el comportamiento descrito?
La única definición de «correcto» que sobrevive al contacto con un usuario.
Se mide ejercitando el flujo, no leyendo el código.
¿Sigue funcionando lo de ayer?
La tasa de regresión importa más que la precisión al primer intento en cuanto pasas la primera semana.
Aproximadamente uno de cada cinco cambios de funcionalidad rompe algo que antes funcionaba.
Cuánto se tarda en llegar a un resultado correcto
Los intentos hasta llegar a verde son más útiles que si pasa o falla al primer intento.
Capta lo que de verdad se siente: cuánto dura el ciclo.
La trampa: pruebas escritas por el mismo autor
La forma obvia de medir la precisión es pedirle al agente que escriba pruebas y ver si pasan. Eso produce un número que casi siempre es alto y significa muy poco. Una prueba generada a partir de las mismas suposiciones que la implementación coincide con ella por construcción, incluso allí donde ambas se equivocan.
Una medición de precisión necesita una verificación independiente. Algo que ejercite el producto contra el comportamiento esperado y no contra la idea que el código tiene de sí mismo.
Cómo montar la medición
Describe en lenguaje natural los flujos que definen qué es correcto en tu producto, antes de la siguiente ronda de cambios. Ejecútalos contra la aplicación desplegada. La primera ejecución te da una línea base y cada ejecución posterior te da una señal de regresión.
Nada de esto necesita una terminal. Crea un proyecto en el panel de TestSprite, describe la verificación en lenguaje natural y apúntala a tu aplicación. Quienes prefieran la línea de comandos en tu equipo pueden hacer lo mismo desde ahí, disponible en el repositorio de la CLI.
Un dato que vale la pena conocer
En una tabla de clasificación pública donde varios agentes de programación construyeron la misma aplicación, el modelo más barato del conjunto produjo la aplicación más correcta cuando había un ciclo de verificación en marcha, a la mitad del costo de la opción más cara. Lo interesante no es el puesto en la tabla. Es que el ciclo importó más que el modelo, justo lo contrario de hacia dónde suele ir la conversación sobre la precisión.
Para qué sirve realmente el número
Las cifras de precisión suelen recopilarse para responder a una pregunta que nadie hizo, como si el modelo es bueno. La pregunta útil es más acotada: ¿puedo hacer merge de esto?
Eso replantea la medición. No necesitas una puntuación de todo tu producto: necesitas saber si este cambio rompió algo que funcionaba antes. Un puñado de verificaciones sobre los flujos que importan, ejecutadas contra la versión desplegada, responde eso en minutos. Un benchmark exhaustivo responde otra pregunta distinta y tarda una semana.
También cambia lo que significa un mal número. Que la precisión caiga en un benchmark es interesante. Que un flujo concreto funcionara ayer y hoy no, es accionable, y es lo segundo lo que evita que las cosas lleguen a los usuarios.
Haz que la medición sea continua
Una medición puntual te habla de un solo momento. La precisión es una propiedad de un proceso continuo, así que las verificaciones corresponden a cada cambio.
Dos caminos, y la elección depende en realidad de quién es dueño del pipeline. Conectar la GitHub App desde el panel no requiere ningún cambio en tu repositorio, porque reacciona al despliegue que tu compilación ya emite. Añadir un paso de GitHub Actions pone la verificación en el repositorio, donde se revisa igual que el resto de la compilación.
Convertir la precisión en algo que puedes medir
TestSprite es la verificación independiente que la medición necesita. Ejercita tu producto desplegado contra el comportamiento que describiste, no contra la idea que el código tiene de sí mismo, y eso es lo que hace que el número signifique algo cuando tanto la implementación como sus pruebas salieron del mismo agente.
En la práctica describes una sola vez los flujos que definen qué es correcto en tu producto, y se ejecutan en cada cambio. La primera ejecución es tu línea base. Cada ejecución posterior responde la pregunta que de verdad tienes: si este cambio rompió algo que ayer funcionaba.
Eso te da los dos números que vale la pena seguir: la tasa de regresión por cambio y cuántos intentos hacen falta para volver a verde. Ambos se mueven cuando el ciclo se acorta, y ninguno se puede inflar escribiendo más pruebas.
¿Qué modelo es más preciso para el vibe coding?
Es la pregunta equivocada para la mayoría de los equipos. La varianza que introduce el hecho de verificar o no es mayor que la varianza entre los modelos de frontera actuales.
¿Puedo medir la precisión sin escribir pruebas?
Sí. Describe los flujos en lenguaje natural y haz que se ejecuten contra la aplicación. Estás midiendo comportamiento, y observar el comportamiento no requiere código de prueba.
¿Qué es un buen número de precisión?
No existe una referencia útil que sirva para todos los productos. Sigue tu propia tendencia: tasa de regresión por cambio e intentos hasta llegar a un resultado correcto. Ambos deberían bajar a medida que el ciclo se acorta.
¿Más cobertura significa más precisión?
No de forma fiable. La cobertura cuenta qué se ejercitó, no si las expectativas eran correctas. Una suite grande de pruebas generadas puede reportar mucha cobertura sobre suposiciones equivocadas.
¿Cada cuánto debo volver a medir?
En cada cambio, de forma automática. La precisión medida según un calendario te habla del calendario, no del cambio que rompió algo.
La precisión es tu ciclo, no tu modelo.
La precisión del vibe coding es algo que mides en tu propio producto: si ocurre el comportamiento descrito, si lo de ayer sigue funcionando y cuánto se tarda en llegar a un resultado correcto. Usa una verificación independiente en lugar de pruebas escritas por el mismo autor, y mide en cada cambio.