Por qué también contamos los fallos de nuestras pruebas de agentes de IA

Una buena puntuación puede ocultar una función ausente. Dos resultados de nuestras pruebas internas muestran por qué debemos examinar los errores y precisar qué medimos realmente.

Una aplicación de control horario obtuvo 92,5 sobre 100 en nuestra evaluación interna. Una comprobación posterior reveló que no compilaba y borraba su base de datos al arrancar. Ese caso nos obligó a revisar cómo juzgamos un resultado, aunque tenga una nota alta.

La primera derrota trataba una necesidad concreta

En la primera comparación de un seguimiento de hábitos, nuestro método obtuvo 82,1 frente a 90,8 de BMAD-METHOD v6. Era una puntuación de cobertura del diseño: el jurado buscaba si las reglas esperadas aparecían en los documentos. No era un porcentaje de fiabilidad del software.

Los comentarios señalaban fechas, duplicados y reglas olvidadas. Sirvieron para preparar las siguientes pruebas. Conservamos ese resultado en el relato de las campañas, junto con los límites del protocolo.

Una buena nota no significa « utilizable »

El caso del control horario procedía de otra campaña. Sus documentos podían parecer convincentes mientras fallaba el arranque real. Leer las explicaciones y ejecutar el producto responde a preguntas diferentes.

Por eso reforzamos las comprobaciones que pasan por el punto de entrada real de la aplicación. En una reserva, eso significa probar el recorrido desde la pantalla y localizar después el dato guardado, en vez de comprobar solo una función aislada.

Comparar las mismas versiones ante el mismo juez

Una nota también puede cambiar porque el juez sea más exigente. Presentamos dos versiones anónimas del mismo tema al mismo juez de IA, con un orden de presentación aleatorio. La versión más reciente fue preferida en seis de los ocho temas.

El resultado corresponde a una comparación entre dos versiones de nuestro método. No sitúa a Maestro frente a todas las herramientas de creación de aplicaciones ni predice el resultado de tu proyecto.

Qué es público y qué sigue siendo interno

Publicamos resúmenes: resultados, ejemplos de fallos y límites de la medición. Los informes detallados, las copias probadas y los veredictos completos siguen siendo internos. Por tanto, aquí el lector no dispone de todas las piezas necesarias para reproducir estas campañas.

Nuestro equipo produce estas observaciones con jurados de IA. No constituyen una evaluación independiente. Contar una derrota aporta contexto; no convierte automáticamente nuestro protocolo en imparcial o exhaustivo.

Qué puedes pedir para tu proyecto

Pregunta qué se probó, qué falló y qué queda por comprobar. Pide que se aclare si el resultado cubre un primer conjunto de funciones o toda la aplicación. Un informe útil permite localizar un problema y repetirlo.

Nuestra guía para comprobar una aplicación sin saber programar propone un punto de partida. Conserva también los gastos de la prueba junto al resultado: solo tienen sentido en relación con lo que se construyó.