Una estrategia de modelos fase por fase para GitHub Spec Kit en 2026

Mi artículo anterior sobre Spec Kit respondía una pregunta sobre proyectos brownfield:

¿Cómo aplico ingeniería inversa a una funcionalidad existente para convertirla en artefactos utilizables de Spec Kit?

La siguiente pregunta es la que seguí escuchando inmediatamente después:

¿Todas las fases de Spec Kit deberían usar el mismo modelo?

Mi hipótesis de trabajo era:

• usar un modelo rápido para constitution, specify y clarify
• usar un modelo con mayor capacidad de razonamiento para plan, tasks y analyze
• usar un modelo más potente para programar en implement

Esa parte sigue siendo válida.

Pero cuando volví a revisar la documentación vigente de los proveedores el April 14, 2026, la combinación exacta que tenía en mente necesitaba nombres más claros y una mejor separación de funciones:

• La línea actual de Google hace más clara la división: Gemini 3 Flash Preview para la opción rápida más reciente y Gemini 3.1 Pro Preview para el trabajo más exigente de la clase Pro de Google
• La denominación pública actual de OpenAI es GPT-5.4 o GPT-5.4 pro con un nivel de esfuerzo de razonamiento como xhigh, no un modelo llamado literalmente gpt-5.4-xhigh
• La documentación actual de Anthropic describe Claude Opus 4.6 y Claude Sonnet 4.6, y Claude Code documenta un modo opusplan que usa Opus para planificar y Sonnet para ejecutar

Así que este artículo no dice: «Demostré que mi hipótesis original exacta era perfectamente correcta».

Es una continuación más útil:

la idea de separar las fases es sólida, pero la combinación concreta de modelos debe actualizarse para 2026.

TL;DR

• Sí, sigo pensando que seleccionar modelos según la fase es el modelo mental correcto para GitHub Spec Kit.
• No, ya no creo que el mejor artículo sea simplemente «un modelo rápido aquí, uno inteligente allá y uno para programar en otra parte».
• La pregunta más útil es: ¿qué falla primero cuando realmente ejecutas este flujo de trabajo?
• Las quejas habituales son sorprendentemente consistentes:
  • Gemini puede parecer demasiado creativo si no lo fundamentas de forma rigurosa
  • GPT-5.4 puede volverse demasiado lento si permites que razone en profundidad en cada ciclo
  • Claude Opus es potente, pero suele ser demasiado lento para ser el ejecutor predeterminado
• La variable nueva más interesante es Composer 2 Fast dentro de Cursor:
  • Cursor dice que Composer 2 tiene un rendimiento de programación de nivel de frontera
  • Cursor dice que la variante más rápida tiene la misma inteligencia, cuesta menos que otros modelos rápidos y ahora es la opción rápida predeterminada
• Mi combinación práctica predeterminada actual es:
  1. constitution, specify, clarify con Composer 2 Fast dentro de Cursor
  2. plan, tasks, analyze con GPT-5.4 en medium o high, no en xhigh de forma predeterminada
  3. implement con Claude Sonnet 4.6 de forma predeterminada, escalando a Claude Opus 4.6 solo cuando la ruta de código es especialmente difícil
• Sigo pensando que Gemini 3 Flash Preview y Gemini 3.1 Pro Preview son útiles, pero ahora los veo como opciones de Google con grounding, no como mi respuesta predeterminada para cada ciclo rápido

Para quién es este artículo

Este artículo es para equipos que:

• ya usan, o quieren usar, GitHub Spec Kit como un flujo de trabajo real en lugar de un prompt aislado
• se sienten cómodos trabajando en Cursor o en otro entorno que permita cambiar de modelo
• valoran lo suficiente la calidad de la planificación como para tolerar cierta complejidad operativa
• quieren una respuesta mejor que «simplemente usa el mismo modelo para todo»

Este artículo probablemente no es para equipos que:

• quieren la menor cantidad posible de componentes
• no quieren gestionar varios proveedores, sistemas de facturación o comportamientos específicos de cada modelo
• están en una etapa de adopción lo bastante temprana como para que sea más fácil promover el uso de un único modelo predeterminado potente

Si esa es tu situación, pasa directamente a Alternativa 4: Máxima simplicidad.

Qué sigue fallando en la práctica

Esta es la sección que, en mi opinión, la versión anterior no enfatizaba lo suficiente.

Las fortalezas teóricas importan, pero los modos de falla recurrentes importan más.

1. Gemini puede desviarse si no lo fundamentas de forma rigurosa

Esta es la queja que escucho con más frecuencia sobre Gemini en flujos de trabajo que parten de una especificación.

No es que «Gemini no sirva».

Es más bien que:

• el borrador es rápido
• la redacción suena bien
• pero algunas afirmaciones son demasiado categóricas para la evidencia disponible en el repositorio

La documentación de la API de Gemini de Google ofrece un recordatorio útil. Sus recomendaciones de seguridad dicen explícitamente que los modelos de lenguaje grandes pueden generar texto incorrecto desde el punto de vista factual. Su documentación sobre grounding dice que el grounding con Google Search puede reducir las alucinaciones y mejorar la precisión factual. Su documentación sobre salidas estructuradas también advierte que incluso una salida válida según el esquema puede no superar las validaciones de lógica de negocio.

Así que mi interpretación actualizada es:

• Gemini sigue siendo atractivo por su velocidad
• pero es más seguro cuando exiges grounding, prompts basados en evidencia y validación después de la generación

Esto significa que ya no me convence tanto Gemini como opción predeterminada sin controles para redactar artefactos finales.

2. GPT-5.4 puede razonar demasiado para los ciclos de iteración

Me sigue gustando mucho GPT-5.4 para planificar.

Pero la queja habitual también es real:

• si usas GPT-5.4 en cada ciclo de redacción
• o si recurres directamente a high/xhigh con demasiada frecuencia
• el flujo de trabajo puede volverse notablemente más lento de lo necesario

La documentación actual de OpenAI respalda esa disyuntiva. Presenta GPT-5.4 como el modelo insignia para razonamiento complejo y programación, al tiempo que recomienda explícitamente GPT-5.4 mini y GPT-5.4 nano para cargas de trabajo de menor latencia y costo. También señala que GPT-5.4 pro puede tardar varios minutos en solicitudes más difíciles.

Así que el problema no es que «GPT-5.4 sea malo».

El problema es que:

• es excelente para los puntos de control
• suele ser excesivo para el ciclo de iteración

3. Claude Opus es demasiado lento para ser el ejecutor predeterminado

La documentación de Anthropic coincide casi perfectamente con esta queja.

Describe:

• Claude Opus 4.6 como el modelo más inteligente para agentes y programación
• Claude Sonnet 4.6 como la mejor combinación de velocidad e inteligencia

Claude Code también documenta:

• opusplan, que usa Opus para planificar y Sonnet para ejecutar
• el modo rápido para Opus 4.6

Eso es una señal importante.

Si la propia Anthropic ofrece:

• Opus para los momentos de razonamiento más difíciles
• Sonnet para la ejecución diaria

entonces ya no creo que Opus deba ser el modelo de implementación predeterminado en este artículo.

4. Composer 2 Fast ya debe formar parte de esta conversación

Esta es la incorporación más importante al artículo.

Los materiales actuales de Cursor sobre Composer 2 dicen que:

• Composer 2 tiene un rendimiento de programación de nivel de frontera
• Composer 2 obtuvo 61.3 en CursorBench, 61.7 en Terminal-Bench 2.0 y 73.7 en SWE-bench Multilingual
• la variante más rápida tiene la misma inteligencia
• tiene un costo menor que otros modelos rápidos
• Cursor está convirtiendo la variante rápida en la opción predeterminada

Eso no convierte automáticamente a Composer 2 Fast en el mejor modelo para cada fase de Spec Kit.

Pero sin duda hace que valga la pena analizarlo como:

• el ciclo más rápido diseñado para programar dentro de Cursor
• una opción predeterminada sólida para la redacción iterativa
• una alternativa seria cuando GPT-5.4 y Opus se sienten demasiado lentos

La recomendación de un vistazo

Si solo quieres la respuesta antes de revisar la evidencia, esta es la versión que hoy le entregaría a un equipo de ingeniería:

Qué puedo demostrar realmente aquí

Quiero ser cuidadoso con la palabra «demostrar».

Lo que puedo demostrar a partir de la documentación actual es:

• Las fases de Spec Kit son lo bastante distintas como para que asignarles modelos diferentes sea razonable desde el punto de vista operativo
• Google documenta el riesgo de inexactitudes factuales, así como las medidas de mitigación mediante grounding y salidas estructuradas
• OpenAI distingue el razonamiento profundo de su modelo insignia de las variantes más pequeñas y de menor latencia
• Anthropic distingue los papeles de Opus y Sonnet según su velocidad e inteligencia
• Claude Code convierte la separación entre planificación y ejecución en una función del producto
• Cursor ahora ofrece una opción propia de modelo rápido para programar que vale la pena tomar en serio

Lo que no hice aquí fue ejecutar un benchmark controlado con prompts idénticos, repositorios idénticos y resultados evaluados para todos los proveedores.

Así que considera este artículo como investigación de flujos de trabajo respaldada por fuentes, junto con análisis práctico de ingeniería, no como un estudio de benchmark con rigor de laboratorio.

Por qué el mapeo simplista de fases deja de ser útil

La versión anterior del artículo preguntaba principalmente:

• ¿qué modelo es más potente para esta fase?

La versión más útil pregunta:

• ¿qué modo de falla perjudica más a esta fase?

Por ejemplo:

• constitution, specify, clarify sufren más por la iteración lenta y la redacción excesivamente segura
• plan, tasks, analyze sufren más por el razonamiento superficial y la incoherencia entre artefactos
• implement sufre más por la latencia durante los ciclos de corrección

Una vez que ves el flujo de trabajo de esa manera, la combinación cambia.

Qué respalda la documentación oficial

1. Spec Kit sigue dándonos los límites de fase adecuados

El README actual de Spec Kit documenta el flujo principal como:

• /speckit.constitution
• /speckit.specify
• /speckit.plan
• /speckit.tasks
• /speckit.implement

También documenta comandos opcionales como:

• /speckit.clarify
• /speckit.analyze
• /speckit.checklist

Eso sigue siendo importante. Las fases son reales. La pregunta es cuánto quieres optimizar cada una.

2. La documentación de Google respalda tanto la preocupación sobre Gemini como su mitigación

La documentación de la API de Gemini de Google no dice que «Gemini alucine demasiado».

Pero sí dice lo suficiente para que la preocupación sea real:

• la salida de Gemini puede ser incorrecta desde el punto de vista factual
• el grounding con Google Search puede reducir las alucinaciones
• la salida estructurada mejora el formato, pero no garantiza que el resultado sea correcto desde el punto de vista del negocio

Esto lleva a una recomendación más cautelosa para Google:

• usa Gemini 3 Flash Preview cuando quieras la opción rápida de Google
• usa Gemini 3.1 Pro Preview cuando quieras la opción de Google más exigente y orientada a ingeniería
• pero considera que Gemini es mucho más seguro cuando el prompt está rigurosamente fundamentado en evidencia del repositorio, salida estructurada o grounding con búsquedas

3. La documentación de OpenAI respalda el uso de GPT-5.4 como modelo para puntos de control, no para todo

La documentación actual de OpenAI dice que:

• GPT-5.4 es el modelo insignia para razonamiento complejo y programación
• GPT-5.4 mini es un modelo más rápido y eficiente para cargas de trabajo de alto volumen
• GPT-5.4 pro puede tardar varios minutos en solicitudes difíciles

Esto encaja bien con lo siguiente:

• usa GPT-5.4 para los puntos de control de planificación importantes
• no des por hecho que GPT-5.4 en xhigh debe usarse en cada ciclo

Este es el cambio del artículo con el que me siento más satisfecho.

El problema nunca fue que GPT-5.4 fuera débil.

El problema fue que implícitamente estaba tratando un modelo para puntos de control como si fuera un modelo para iterar.

4. La documentación de Anthropic respalda mucho más a Sonnet que a Opus como ejecutor predeterminado

La documentación actual de Anthropic dice que:

• Claude Sonnet 4.6 es la mejor combinación de velocidad e inteligencia
• Claude Opus 4.6 es el modelo más inteligente para agentes y programación
• el modo rápido hace que Opus 4.6 sea hasta 2.5x más rápido

Claude Code añade dos señales prácticas para el flujo de trabajo:

• opusplan = Opus para planificar, Sonnet para ejecutar
• los alias de modelos posicionan explícitamente a Sonnet para las tareas diarias de programación

Así que, si la queja es que «Claude Opus simplemente es demasiado lento», la documentación apunta básicamente a la misma respuesta:

• sí, conserva Opus
• no, no lo conviertas en el modelo predeterminado del ciclo de ejecución

5. Composer 2 Fast de Cursor es la incorporación nueva más importante

La mayor ausencia en la versión anterior de este artículo era la opción de modelo rápido del propio Cursor.

Cursor ahora dice que:

• Composer 2 tiene un rendimiento de programación de nivel de frontera
• Composer 2 obtiene buenos resultados en CursorBench y otros benchmarks de programación
• la variante más rápida tiene la misma inteligencia
• la variante rápida tiene un costo menor que otros modelos rápidos
• Cursor está convirtiendo la variante rápida en la opción predeterminada

Como este flujo de trabajo ya asume el uso de Cursor para buena parte del trabajo con Spec Kit, Composer 2 Fast merece un papel de primer nivel en el artículo.

No es automáticamente mejor que GPT-5.4 para la planificación profunda.

Pero es sumamente relevante para:

• la redacción rápida de constitution y especificaciones
• los ciclos rápidos de aclaración
• los ciclos rápidos de edición de código cuando Sonnet u Opus se sienten demasiado lentos

El costo operativo de hacerlo

Esta sigue siendo la parte que puede pasar desapercibida si el artículo solo habla de la calidad de los modelos.

Distribuir las fases entre proveedores no es gratis. Añade:

• más configuración de claves de API y proveedores
• más sistemas de facturación que monitorear
• más transferencia de contexto entre fases
• más disciplina en el flujo de trabajo para que los ingenieros sepan cuándo cambiar de modelo
• más trabajo de depuración cuando los resultados son malos y el equipo debe preguntarse si el problema fue el prompt, la fase, el modelo o la transferencia de contexto

Eso significa que solo recomendaría una combinación entre proveedores como esta cuando se cumpla al menos una de estas condiciones:

• equivocarse en la planificación tiene un costo elevado
• el equipo ya usa varios proveedores
• la velocidad en las fases iniciales importa lo suficiente como para justificar la configuración adicional

Si ninguna de esas condiciones se cumple, un flujo de trabajo más simple con un solo proveedor suele superar en la práctica a uno ingenioso con varios modelos.

Mi recomendación actualizada

Si hoy estuviera estandarizando esto para un equipo, actualizaría la hipótesis original de esta manera:

Etapa 1: Constitution, Specify, Clarify

Opción predeterminada:

• Composer 2 Fast

Por qué:

• ahora es el ciclo rápido más convincente disponible directamente dentro de Cursor
• Cursor lo presenta como un modelo de programación de nivel de frontera con una variante predeterminada más rápida
• la redacción rápida importa mucho más en estas fases iniciales que la máxima profundidad de razonamiento

Cuándo usaría Google en su lugar:

• usa Gemini 3 Flash Preview cuando quieras la opción rápida de Google
• usa Gemini 3.1 Pro Preview cuando quieras la opción de Google más exigente y orientada a ingeniería
• en ambos casos, añade grounding y validación más rigurosos que antes

Etapa 2: Plan, Tasks, Analyze

Opción predeterminada:

• GPT-5.4 con medium o high

Escalamiento:

• usa xhigh solo cuando el plan siga siendo débil después de una revisión normal
• usa GPT-5.4 pro solo cuando equivocarse en la arquitectura tenga un costo especialmente alto y la latencia adicional sea aceptable

Por qué:

• estas son las fases en las que un razonamiento más profundo suele compensar su costo
• aquí es donde más importa la coherencia entre artefactos
• aquí es donde un razonamiento débil se manifiesta después como retrabajo, dependencias omitidas o lógica de aceptación defectuosa

Una corrección sutil pero importante:

• describiría esta configuración como GPT-5.4 en medium/high de forma predeterminada
• no recurriría directamente a xhigh a menos que la tarea realmente lo necesite

Etapa 3: Implement

Opción predeterminada:

• Claude Sonnet 4.6

Ciclo rápido secundario:

• Composer 2 Fast cuando quiero un ciclo de iteración local rápido dentro de Cursor

Escalamiento:

• Claude Opus 4.6 cuando el cambio es especialmente riesgoso, exige mucho trabajo de arquitectura o probablemente requiera más ciclos de corrección autónoma

Por qué:

• Sonnet es ahora el modelo de implementación más claramente indicado para el uso diario en la documentación oficial
• Opus es valioso, pero demasiado lento para ser mi opción predeterminada en el ciclo de ejecución
• Composer 2 Fast ahora es lo suficientemente bueno como para formar parte también de la conversación práctica sobre implementación

Cómo lo ejecutaría en la práctica

Dentro de Cursor, dejaría de pensar en términos de «un modelo por artículo» y empezaría a pensar en términos de ciclos de iteración y ciclos de control.

Aquí tienes un ejemplo concreto.

Imagina que trabajo en un repositorio brownfield de SaaS y quiero documentar y luego ampliar un flujo existente de exportación de facturas:

1. Usaría Composer 2 Fast para constitution, specify y clarify, con el fin de iterar rápidamente y mantener ágil el ciclo de redacción.
2. Si el borrador empieza a parecer demasiado impreciso o a asumir demasiado sobre el código, probaría Gemini 3 Flash Preview o Gemini 3.1 Pro Preview, pero solo con grounding más riguroso y restricciones basadas en evidencia.
3. Cambiaría a GPT-5.4 en medium o high para plan, tasks y analyze, de modo que la arquitectura y las verificaciones de coherencia entre artefactos sean más sólidas.
4. Le asignaría implement a Claude Sonnet 4.6 para la ronda de programación predeterminada.
5. Escalaría solo cuando fuera necesario:
   • GPT-5.4 xhigh/pro para desbloquear problemas difíciles de planificación
   • Claude Opus 4.6 para resolver problemas difíciles de implementación
   • Composer 2 Fast cuando quiera un ciclo local rápido de programación sin pagar el costo de latencia de Opus

A ese tipo de flujo de trabajo me refiero en todo el artículo: no cambiar de modelo por cambiar, sino hacerlo deliberadamente porque el modo de falla cambia.

1. Redacción rápida

Usar para:

• /speckit.constitution
• /speckit.specify
• /speckit.clarify

Opción predeterminada:

• Composer 2 Fast

Enfoque de las instrucciones:

• mantente fundamentado en la evidencia del repositorio
• optimiza la claridad y la fluidez
• no compliques la solución de más

2. Punto de control profundo

Usar para:

• /speckit.plan
• /speckit.tasks
• /speckit.analyze

Opción predeterminada:

• GPT-5.4 medium/high

Enfoque de las instrucciones:

• optimiza la coherencia interna
• conserva los requisitos exactamente
• expón los riesgos y las dependencias de forma explícita

3. Ejecución diaria

Usar para:

• /speckit.implement
• ciclos de corrección después de fallas en las pruebas o en tiempo de ejecución

Opción predeterminada:

• Claude Sonnet 4.6

Enfoque de las instrucciones:

• haz cambios de código mínimos y verificables
• mantén la implementación alineada con spec.md, plan.md y tasks.md
• prioriza que las pruebas pasen y que los diffs sean pequeños por encima de soluciones ingeniosas

Alternativas que consideraría seriamente

El objetivo no es imponer una combinación exacta. El objetivo es elegir una combinación que coincida con las prioridades de tu equipo.

Si tuviera que reducir la decisión a una guía rápida, sería esta:

Alternativa 1: Opción de velocidad integrada en Cursor

• constitution, specify, clarify con Composer 2 Fast
• plan, tasks, analyze con GPT-5.4 medium/high
• implement con Claude Sonnet 4.6

Ideal cuando:

• ya trabajas principalmente en Cursor
• tu mayor problema es la iteración lenta
• quieres el ciclo práctico más ágil sin recurrir a GPT-5.4 u Opus para todo de forma predeterminada

Alternativa 2: Opción de puntos de control con OpenAI

• redacción rápida con Composer 2 Fast
• puntos de control de planificación con GPT-5.4
• los casos de planificación más difíciles con GPT-5.4 pro
• implementación con Claude Sonnet 4.6

Ideal cuando:

• tu mayor problema es la calidad de la planificación, no la velocidad pura de implementación
• te parece bien asumir la latencia solo en los puntos de control

Alternativa 3: Opción con Gemini y grounding

• constitution, specify, clarify con Gemini 3 Flash Preview
• rondas de aclaración o síntesis más exigentes con Gemini 3.1 Pro Preview
• puntos de control de planificación con GPT-5.4
• implementación con Claude Sonnet 4.6

Ideal cuando:

• quieres mantenerte más cerca de la familia actual de modelos de Google
• estás dispuesto a añadir controles de grounding y validación
• sigues valorando la velocidad de Gemini para redactar

Alternativa 4: Máxima simplicidad

• un modelo general potente para cada fase

Ideal cuando:

• tu equipo no va a mantener realmente un flujo de trabajo con varios modelos
• la simplicidad operativa importa más que exprimir mejoras fase por fase

Esta sigue siendo la alternativa que elegiría para la mayoría de los equipos antes que una orquestación ingeniosa pero frágil.

Qué me hizo cambiar más de opinión

Tres cosas:

1. La pregunta correcta ahora es cómo asignar modelos según el modo de falla, no solo según la fase

El artículo anterior iba en la dirección correcta, pero era demasiado simplificado.

La pregunta práctica no es solo:

• ¿qué modelo es más potente para esta fase?

También es:

• ¿qué modelo falla de la manera más perjudicial para esta fase?

2. GPT-5.4 y Opus son mejores para puntos de control que como opciones predeterminadas

Esta fue la lección más clara sobre el flujo de trabajo.

• GPT-5.4 sigue siendo excelente, pero lo quiero para puntos de control profundos, no para cada ciclo de redacción
• Opus sigue siendo excelente, pero lo quiero para resolver problemas difíciles, no para cada ciclo de ejecución

Ese es un modelo operativo mucho más sano.

3. Composer 2 Fast ya debe formar parte de este artículo

Este es el cambio más importante de la nueva versión.

Los propios materiales de Cursor ahora hacen que Composer 2 Fast sea demasiado relevante como para ignorarlo:

• buenos benchmarks de programación
• variante predeterminada más rápida
• afirmación de que la opción rápida tiene la misma inteligencia
• costo menor que otros modelos rápidos

Para un flujo de trabajo de Spec Kit que ya depende en gran medida de Cursor, eso cambia la recomendación práctica.

Mi conclusión final

Si quieres la respuesta más breve posible, es esta:

• la idea detrás de la hipótesis original sigue siendo correcta
• pero la mejor combinación en la práctica cambia cuando tomas en cuenta los modos de falla reales

Así que la versión que hoy le entregaría a un equipo de ingeniería es:

1. Composer 2 Fast para constitution, specify y clarify
2. GPT-5.4 en medium o high para plan, tasks y analyze
3. Claude Sonnet 4.6 para implement de forma predeterminada
4. Gemini 3 Flash Preview o Gemini 3.1 Pro Preview solo cuando quieras una opción de Google con grounding
5. GPT-5.4 xhigh/pro y Claude Opus 4.6 solo como herramientas de escalamiento

Esa es probablemente la lección más importante de esta investigación:

la estrategia ganadora no es un modelo mágico. Es elegir el modelo según el modo de falla.

Lista de fuentes

• README de GitHub Spec Kit
• Documentación de Cursor: Modos
• Documentación de Cursor: Selección de modelos
• Documentación de Cursor: Claves de API
• Cursor: Presentación de Composer 2
• Cursor: Informe técnico de Composer 2
• Documentación de Google AI: Modelos
• Documentación de Google AI: Gemini 3
• Documentación de Google AI: Gemini 3 Flash Preview
• Documentación de Google AI: Gemini 3.1 Pro Preview
• Documentación de Google AI: Grounding con Google Search
• Documentación de Google AI: Salidas estructuradas
• Documentación de Google AI: Recomendaciones de seguridad
• Descripción general de los modelos de OpenAI
• Comparación de modelos de OpenAI
• OpenAI GPT-5.4 pro
• Documentación de Claude Code: Configuración de modelos
• Documentación de Claude Code: Modo rápido
• Documentación de la API de Claude: Novedades de Claude 4.6
• Documentación de Claude Code: Registro de cambios