El instinto es que más modelos significa mejores respuestas. Una pestaña más, una perspectiva más, triangula tu camino hacia la verdad. Funciona hasta alrededor de tres modelos y luego se invierte drásticamente. Pasado eso, cada modelo que agregues cuesta más en reconciliación de lo que aporta en insight, y lo primero que se degrada no es tu velocidad. Es tu criterio sobre cuál respuesta fue correcta.
Lo clave: Un modelo te fuerza a pensar con claridad. Dos o tres te compran una segunda opinión genuina. Pasado eso, no estás orquestando modelos, estás presidiendo un comité que no recuerda en qué estuvo de acuerdo hace diez minutos.
Dibujé esta curva después de un mes donde tenía seis modelos abiertos más o menos permanentemente, me sentía extremadamente productivo, y envié trabajo notoriamente peor.
Tener seis modelos abiertos me costó un día en un mapa de redirección
En mi peor momento tenía Opus 5 en un problema de arquitectura, Codex a mitad de la implementación, Composer activo en el editor, Grok abierto para una segunda lectura, y Qwen y Kimi estacionados en dos pestañas más porque alguien en X dijo que eran buenos en esto. Se sentía como una cabina. Era un chat grupal donde nadie había leído el brief.
El costo apareció en un mapa de redirecciones. Estaba consolidando algunos cientos de URLs antiguas en un sitio programático grande, el tipo de trabajo donde estar 95 por ciento correcto es un desastre porque el 5 por ciento silenciosamente está haciendo 301 hacia el revenue hacia una pared. Le pregunté a tres modelos y obtuve tres respuestas defensibles sobre la cadena de barras diagonales finales. En lugar de elegir una y razonarla, las mezclé. La mezcla fue peor que cualquiera de las tres solas, porque cada una era internamente consistente y la mezcla no. Un día para deshacer, enteramente culpa mía.
Un modelo te obliga a pensar con claridad
La propiedad subestimada de un solo modelo es que te devuelve la especificación a ti. Con exactamente una cosa para preguntar, tienes que escribir un brief real: la entrada, qué debe satisfacer la salida, qué está fuera de alcance, qué significa "listo". Ese acto de escribir es la mayor parte de la ingeniería. He atrapado más errores de diseño escribiendo un prompt que en cualquier revisión de código.
Con seis modelos abiertos, esa disciplina se evapora silenciosamente. Dejas de escribir briefs y empiezas a hacer encuestas, y una pregunta vaga lanzada a seis modelos devuelve seis respuestas confiadas. La confianza no es evidencia, es solo cómo suenan estos sistemas. Casi todo el valor en mi flujo de trabajo con Claude Code está aguas arriba del modelo.
Dos o tres modelos es el punto dulce real
La razón por la que tres funciona es que los modelos están haciendo trabajos diferentes en lugar del mismo trabajo en paralelo. La división del trabajo es aditiva. La duplicación no. Un modelo sostiene el plan, uno escribe el código, uno te lo lee de vuelta con frialdad. Nadie está votando.
En el momento en que dos modelos están haciendo el mismo trabajo, no has comprado redundancia. Has comprado un desempate que solo tú puedes resolver, y eres el participante menos descansado en la conversación.
Cuando un modelo especializado realmente se gana su pestaña
Los especialistas valen la pena cuando son estructuralmente diferentes, no solo con marca diferente. Mi prueba es simple: ¿discrepa con los otros de una manera de la que puedo aprender? Un modelo que está de acuerdo con todo es un asistente muy costoso.
Codex se gana su pestaña en la implementación, especialmente cambios mecánicos largos en muchos archivos donde quiero un diff en lugar de una conversación. Composer 2.5 se la gana dentro del editor, donde el valor es la latencia, no la profundidad. Grok se la gana en preguntas de producto y posicionamiento, porque felizmente me dirá que la idea es aburrida. Qwen y Kimi se la ganan cuando quiero una distribución de entrenamiento diferente en lugar de otro voto del mismo vecindario. Tengo Kimi integrado en un script de auditoría de UI precisamente porque nota lo que los otros han aprendido a ser educados al respecto.
Esa última distinción es lo fundamental del asunto. La mayoría de las veces que la gente agrega un quinto modelo no busca otra opinión, busca otra confirmación. Se sienten idénticas en el momento y son opuestas.
El costo oculto es la reconciliación, no el cambio
El context switching es el costo que todos mencionan, y es real: relees el mismo archivo por cuarta vez porque no recuerdas en cuál pestaña mencionaste la restricción. Pero no es el que cuesta más.
El costoso es que te conviertes en el conflicto de merge. Dos modelos te dan un desacuerdo para arbitrar. Tres te dan tres. Seis te dan quince desacuerdos pareados, y cada uno quiere una decisión de la misma persona cansada. Nada en tu stack hace esa reconciliación por ti. Eres la capa de integración, funcionando al final del día, en un problema del que ya leíste seis reformulaciones ligeramente diferentes.
Y los modelos no pueden ayudarte aquí, porque ninguno sabe qué dijeron los otros. Eres el único que sostiene el contexto completo, que es exactamente la posición de la que intentabas delegar.
La orquestación de IA es generalmente un problema humano
Cuando la gente dice que necesita mejor orquestación, generalmente significa que necesita un brief más claro. Si tres modelos te dan tres respuestas genuinamente diferentes, rara vez es una brecha de capacidad. Casi siempre es ambigüedad en la pregunta, y ninguna cantidad de lógica de enrutamiento soluciona un problema subespecificado. Solo lo distribuye.
El diagnóstico que uso ahora: si no puedo escribir, en dos oraciones, qué tendría que satisfacer una respuesta correcta, abrir otro modelo es procrastinación con barra de progreso. Escribe primero las dos oraciones. A veces las dos oraciones son la respuesta y cierro todas las pestañas.
El flujo de trabajo que realmente ejecuto hoy
Opus 5 para pensar. Arquitectura, tradeoffs, la incómoda pregunta de si la cosa debería construirse en absoluto. Es aquí donde invierto esfuerzo en prompts, porque una mala decisión acá no es recuperable con mejor código después.
Código para implementación. Una vez que la forma esté decidida, dale la especificación y déjalo trabajar. Reviso el diff, no el razonamiento.
Composer 2.5 para asistencia en codificación. Dentro del editor, rápido, alcance reducido. Es un autocompletado mejor, no un colega, y tratarlo como colega es cómo terminas con 400 líneas que no pediste.
Grok para perspectivas alternativas. Deliberadamente fuera de la ruta crítica. Voy allí cuando sospecho que me he convencido a mí mismo de algo.
Qwen o Kimi cuando quiero otra opinión en lugar de otra confirmación. Raramente. A propósito.
Lo que importa no es la lista. Es que estos casi nunca están abiertos al mismo tiempo. Una secuencia, no una cabina: pensar, luego implementar, luego revisar, un modelo sosteniendo la pluma en cada etapa. El gráfico tiene tres picos porque tres es cuántas etapas están genuinamente activas en un buen día. Comparé dos de estos en Claude Code vs Cursor.
Los prompts mejores le ganan a más pestañas.
Un problema bien especificado dado a un modelo bueno le gana a un problema vago dado a seis, y no es cerrado. Más modelos se siente mejor porque abrir una pestaña es instantáneo y escribir una especificación es trabajo. El FOMO de IA es la creencia de que el próximo modelo hará el pensamiento que has estado evitando. No lo hará. Será más articulado sobre el problema equivocado.
La disciplina no es glamorosa y se compone. Las personas que conozco entregando el mejor trabajo con estas herramientas no están corriendo los más modelos. Están corriendo dos o tres, a propósito, con una clara división del trabajo y una especificación escrita, y están aburridos del discurso del modelo de la semana.
Una cosa para hacer hoy.
Cierra cada pestaña de IA excepto una. Toma la tarea en la que realmente estás y escribe dos oraciones: cuál es la entrada y qué tendría que satisfacer una salida correcta. Dale esas dos oraciones al único modelo que dejaste abierto. Si la respuesta es buena, tu cuello de botella nunca fue capacidad del modelo. Si es mala, ahora sabes cuál de las dos oraciones estaba mal, algo que seis modelos no podrían haberte dicho.
FAQ
¿Cuántos modelos de IA debo usar a la vez?
Dos o tres, haciendo trabajos diferentes: uno para pensar el problema, uno para implementar, y opcionalmente uno para revisar u ofrecer una lectura contraria. Pasado los tres, el costo de reconciliar respuestas conflictivas crece más rápido que el valor de la perspectiva adicional, porque eres el único participante que sabe qué dijeron todos.
¿Es malo usar múltiples modelos de IA para la misma tarea?
Ejecutar dos modelos en la tarea idéntica es generalmente un desperdicio. No te compra redundancia, te compra un desempate que solo tú puedes resolver. Los múltiples modelos ayudan cuando tienen roles diferentes, como planificación versus implementación, y dañan cuando se duplican entre sí.
¿Cuál es el costo real de cambiar entre modelos de IA?
El costo obvio es reestablecer contexto y releer los mismos archivos. El mayor es la reconciliación: con seis modelos tienes quince desacuerdos por pares que arbitrar, y nada en tu stack lo hace por ti. Te conviertes en la capa de integración.
¿Los modelos especialistas como Codex, Grok, Qwen o Kimi realmente ayudan?
Sí, cuando son estructuralmente diferentes en lugar de simplemente nombrados diferente, y cuando tienen un trabajo definido. La prueba es si el modelo está en desacuerdo con los otros de una manera de la que puedas aprender. Si mayormente está de acuerdo, estás pagando por confirmación, no por perspectiva.
Relacionado: mi flujo de trabajo Claude Code para la disciplina de modelo único que esto arguye, y contratar un desarrollador Claude Code si preferirías que esto fuera el problema de alguien más.