--- title: "Reunión de tres horas para elegir modelo. Al final eligieron el que yo había sugerido al principio" url: "https://www.mikefluff.com/es/blog/model-choice-2026" locale: "es" author: "Mike Fluff" updated: "2026-07-08" description: "Sobre un proyecto que se retrasó siete semanas porque el equipo no conseguía decidir entre Claude, ChatGPT, Gemini o uno local. Y cómo suele curarse." tags: - "ai" - "tools" - "strategy" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/model-choice-2026" markdown: "https://www.mikefluff.com/en/blog/model-choice-2026.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/model-choice-2026" markdown: "https://www.mikefluff.com/ru/blog/model-choice-2026.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/model-choice-2026" markdown: "https://www.mikefluff.com/pt/blog/model-choice-2026.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/model-choice-2026" markdown: "https://www.mikefluff.com/es/blog/model-choice-2026.md" --- # Reunión de tres horas para elegir modelo. Al final eligieron el que yo había sugerido al principio > **En resumen:** El equipo pasó siete semanas debatiendo entre Claude, ChatGPT, Gemini y un modelo local, con un coste de alrededor de un millón de rublos, y luego un prototipo de tres días con veinte ejemplos reales lo decidió. Si los datos no pueden salir, local. Con más de 100 000 peticiones al día, local o la API más barata. En el resto, Claude o ChatGPT probados con veinte ejemplos. La reunión fue un martes. En Zoom — seis personas: CTO, dos backends, producto, seguridad y yo. Una sola pregunta en el orden del día: "¿qué modelo cogemos para la feature X?". Tres horas después la reunión acabó sin decisión. Se adoptó el formato "pensemos hasta el viernes". El viernes nadie pensó, porque hubo un incidente en producción y ya nadie se acordaba de qué modelo. En las seis semanas siguientes volvimos a reunirnos cuatro veces. Cada vez se sumaba un argumento nuevo — "acaba de salir el nuevo Sonnet", "Gemini ya tiene dos millones de contexto", "Llama 3.3 está un poquito mejor en un benchmark que, por cierto, no nos aplica". La feature X no se movió en esas siete semanas. En la séptima semana perdí la paciencia. Dije: "coged Claude Sonnet, montad un prototipo en tres días con veinte ejemplos reales, y veis". Lo montaron. El prototipo funcionó. Se quedaron con Claude Sonnet. Sigue funcionando. La feature X salió. Esas siete semanas le costaron al cliente alrededor de un millón de rublos en tiempo ocioso de cuatro personas. Más la desmoralización — cosa que no sé cuantificar, pero creo que del mismo orden. --- Es una historia típica, que se me repite dos o tres veces al año. **Elegir modelo** es una tarea en la que es muy fácil ahogarse, porque: — salen modelos nuevos cada tres o cuatro meses, — los benchmarks se dan la vuelta, — cada desarrollador tiene su opinión ("probé Gemini, me gustó"), — los blogs del sector publican "por qué GPT-4o superó a Claude en X" (y, como no, "por qué Claude superó a GPT-4o en Y"), — nadie en el equipo quiere ser el primero en decir "da igual, coged este", porque suena poco profesional. Resultado: en lugar de trabajar, el equipo **debate herramientas**. Estaría bien si el debate tuviera sentido. Normalmente no lo tiene. --- Por qué no lo tiene. Los benchmarks con los que discutís — **MMLU, GPQA, HumanEval** y el resto del sintético — miden cómo le va a un modelo en **tareas abstractas estándar**. Eso probablemente no os aplica. Necesitáis saber si **este modelo concreto maneja vuestra tarea concreta a un coste razonable**. Y eso se comprueba **en media jornada** con vuestros datos, no en siete semanas de debate. > **No repitáis a mis clientes** > > No paséis una semana comparando modelos "en general". Coged vuestra tarea, > veinte ejemplos reales, pasadlos por dos o tres. El ganador a producción. > Lo demás es teoría. --- Cuando aun así tengo que fundamentar la decisión — porque el cliente quiere "decisión razonada", no "lo digo yo" — separo los modelos así. **Claude (Sonnet / Opus)** — contextos largos, tareas con instrucción matizada, refactor, trabajo fino con texto. Lo uso en la mayoría de mis escenarios reales porque, primero, es disciplinado (sigue instrucciones), y segundo, rara vez alucina en hechos que no conoce (suele decirlo honestamente). Contra — más caro por token. Proyecto mediano: $50–200/mes a carga normal. **ChatGPT (GPT-4o / serie o)** — multimodal, tiempo real, interfaces de chat para usuario final. Enorme ecosistema de plugins. Contra — las alucinaciones en nichos se notan **más** que en Claude. Pocos lo escriben, pero me he convencido de ello varias veces en un año, incluyendo una con coste reputacional para un cliente que casi envía un email citando un estudio inventado. **Gemini (2.x)** — si toda la empresa vive en Google Workspace, este es el camino más corto. Contextos largos (en 2026 ya no únicos). Fuerte en multimodal con gráficos. Contra — **el ecosistema**. Fuera de Google parece cocina ajena. **Locales (Llama 3.x, Mistral, Qwen)** — privacidad, coste a escala, escenarios edge. Si guardas datos que **no pueden salir a ninguna nube** — decisión cerrada, local. Contra — **necesitas ingeniero**, servidor, GPU. Y la diferencia de calidad en tareas duras con flagships en 2026 sigue siendo real. --- Reduzco la elección a tres preguntas en este orden: **Primera — privacidad.** ¿No puede salir? Local. No sigas leyendo. **Segunda — volumen.** ¿Más de 100 000 peticiones al día? Local o API más barata. Calcula sobre carga real. **Tercera — todo lo demás** — Claude o ChatGPT, 20 ejemplos, gana uno. Tres horas. No tres semanas. > **Un truco que ahorra dinero** > > Si tu carga es mixta — parte compleja, parte rutinaria — usa **dos modelos**. > Flagship (Opus/GPT-4o) para lo complejo. Barato (Haiku/mini) para rutina. > El routing son veinte líneas de código. Ahorro real: 3–5×. --- Algo que le digo mucho a los clientes como externo: No migres entre modelos cada tres meses "porque ha salido uno nuevo". **La estabilidad** cuesta más que un 2% de benchmark. Cada migración es reescribir prompts, reconfigurar, retestear. Trabajo que no aporta valor al cliente final — a él le da igual si estás en Sonnet 3.5 o Sonnet 4. Un cliente este año se pasó dos semanas migrando de Sonnet a Opus porque "ahora Opus es más listo". Un mes después vimos que, para su tarea, Opus no era notablemente más listo, solo tres veces más caro. Volvieron. Otra semana. Menos tres semanas de trabajo real. (Menos mal que volvieron. Peor habría sido quedarse.) --- Un modelo **no es religión**. Es herramienta para una tarea. En 2026 las herramientas son abundantes y comparables; la elección se hace en media jornada con tus datos, no en tres horas de Zoom con seis personas. Si tu reunión "a ver qué modelo cogemos" dura más de una hora, no estáis debatiendo modelos. Estáis debatiendo el **miedo** a elegir mal. Es otro problema, y no se resuelve comparando benchmarks. **[Curso de vibe coding](https://www.mikefluff.com/es/vibe-coding-course)** — Incluye cómo rutear peticiones entre modelos, cuándo flagship, cuándo barato. 6 módulos, $19.