Empieza por la tarea, no por la marca
No es lo mismo explicar un error, escribir una prueba, refactorizar un módulo o resolver una incidencia con varias herramientas. Conviene separar estos trabajos antes de comparar modelos.
Una prueba útil define archivos disponibles, restricciones, formato de salida y una condición de éxito: por ejemplo, que compile, que pase una suite o que respete una interfaz.
Qué comparar además de la calidad
El contexto disponible, el soporte de herramientas, el coste de entrada y salida, la latencia y la estabilidad cambian el coste real por tarea. Un modelo más barato por token puede salir caro si obliga a repetir más trabajo.
La ficha técnica debe indicar versión, endpoint y fecha. Comparar nombres de producto sin estos datos mezcla capacidades diferentes.
Cómo decidir con menos riesgo
Prueba dos o tres modelos con los mismos casos de tu stack. Guarda el prompt, la configuración, el coste y el resultado de la validación. Después decide por el trabajo que realmente se resuelve, no por una puntuación aislada.
Siguiente paso