Spec Kit: de intención comprobable a aceptación trazable
Evaluar Spec Kit por comportamiento aceptado y retrabajo, no por páginas
Diseña un piloto justo que incluya aclaración, uso del agente, revisión y convergencia repetida sin inventar ganancias de productividad.
Qué aprenderás
- Contar el ciclo completo
- Cobertura no significa corrección
- Fijar un criterio de parada
Antes de empezar
- Conceptos básicos de requisitos, Git y pruebas
- Distinguir desarrollo local y despliegue de aplicación
Trazar una funcionalidad desde intención hasta evidencia y separar contratos de comportamiento verificado.
Conclusiones clave
- Mide el ciclo completo hasta aceptación.
- Cobertura requisito-tarea no equivale a corrección.
- La convergencia repetida necesita límites de evaluación.
Contar el ciclo completo
La comparación útil incluye aclaración, planificación, tareas, implementación, validación y revisión. La alternativa debe resolver la misma funcionalidad acotada con iguales condiciones de aceptación. Comparar un prototipo estructurado con una respuesta directa sin revisar oculta definiciones diferentes de terminado.
Registra tiempo transcurrido, esfuerzo humano y uso del modelo por separado. Conserva cambios rechazados, requisitos reabiertos e intentos fallidos. Más páginas pueden aportar trazabilidad o ceremonia innecesaria; contar documentos no distingue ambos resultados.
Cobertura no significa corrección
Analyze define cobertura como requisitos asociados con al menos una tarea y limita la tabla a cincuenta hallazgos con resumen del resto. Es un contrato de informe, no un benchmark ni un límite para todas las solicitudes al modelo. Cobertura completa no demuestra tareas correctas o implementadas.
Converge contrasta código actual con artefactos y puede añadir trabajo. Mide escenarios realmente aprobados y causas de hallazgos repetidos. Si cambia la especificación entre ejecuciones, informa del cambio en vez de atribuir toda diferencia al rendimiento del modelo.
Fijar un criterio de parada
Antes del piloto, elige funcionalidad pequeña, presupuesto de revisión y comprobaciones explícitas. Detén y reconsidera cuando se repite la misma brecha, aumenta el alcance sin aprobación o se agota el presupuesto. Que una instrucción sugiera iterar no demuestra que reintentar indefinidamente resulte rentable.
Esta serie no informa aceleración, ahorro de tokens ni precios estimados. La hoja propuesta deja mediciones desconocidas en null. Un ensayo posterior puede comparar resultados aceptados y retrabajo documentando modelo, integración, revisión del proceso y complejidad.
Cómo elegir
| Criterio | Opción A | Opción B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Pasos de implementación
- 1
Fija alcance y aceptación.
- 2
Registra tiempo humano, uso y fallos.
- 3
Sigue comportamiento probado, no solo casillas.
- 4
Revisa las causas de iteraciones improductivas.
Ejemplo para copiar
{
"pilotoPropuesto": true,
"escenariosAceptados": null,
"minutosHumanos": null,
"usoAgente": null,
"hallazgosRepetidos": null,
"requisitosCambiados": false,
"benchmarkEjecutado": false
}Preguntas frecuentes
¿Cobertura del 100% significa que funciona?
No. Significa que los requisitos tienen tareas según la definición del informe.
¿Se midió una mejora de productividad aquí?
No. Se propone un método de medición, no un resultado.
Fuentes
- Spec Kit / templates/commands/analyze.mdFuente verificada 2026-09-14
- Spec Kit / templates/commands/converge.mdFuente verificada 2026-09-14