Model Fusion
Effort: heavy — un panel completo redactando en paralelo más un juez independiente (y un escritor opcional); gástalo en builds y arreglos difíciles que van a entregarse, nunca en cambios de una línea. Elimina: apostar el cambio al borrador de un solo modelo, y el retrabajo cuando ese único borrador está mal.
Muchas voces independientes ganan a una sola. Un panel de modelos redacta la
misma tarea en paralelo. Un juez — un modelo que no escribió ninguno de los
borradores — elige o fusiona al mejor. Al ganador después se le compara con lo
que de verdad se pidió.
Cuándo correrla
- Cualquier build, fix o mejora sustancial donde la calidad importa más que la velocidad.
- Cuando quieres un par concreto de evaluadores independientes, no fe ciega en un modelo.
- NO para cambios triviales de una línea. Haz el cambio directo y verifícalo.
Las tres etapas
1. Panel — borradores en paralelo
- Manda la misma tarea, con el mismo contexto, a todos los modelos del panel a la vez.
- Cada redactor trabaja solo. Ningún redactor ve el trabajo de otro.
- Un redactor que falla, se queda sin tiempo o devuelve vacío se registra y se
descarta. Nunca mata la ronda. Registra el descarte en voz alta — jamás lo
tragues en silencio.
- Recoge todos los candidatos no vacíos.
2. Juez — un externo elige y fusiona
- Antes de juzgar, corre una compuerta mecánica barata sobre cada candidato:
¿aplica limpio? ¿parsea? Corre la prueba sobre una copia desechable, nunca
sobre el árbol vivo. Los candidatos que fallan la compuerta quedan fuera antes
de que el juez los vea.
- Dos formas de juez — elige una por config:
- Síntesis: el juez analiza cada candidato (fortalezas, defectos,
conflictos), y luego un modelo escritor aparte compone la respuesta final a
partir de ese análisis. Escritor y juez son roles distintos; mantenlos en
modelos distintos cuando puedas.
- Selección: el juez elige el mejor candidato único que pasó la compuerta.
Más barato. Úsalo cuando fusionar no aporta nada.
- Si el juez o el escritor no está disponible, degrada EN VOZ ALTA a selección
sobre los mismos candidatos. Nunca desperdicies el panel en silencio; nunca
finjas que hubo síntesis.
- Si ningún candidato sobrevive la compuerta, añade el mejor error al prompt y
vuelve a correr el panel — acotado, máximo 2 rondas de reparación. Al
agotarse, devuelve fallo con la lista completa de errores. Nunca devuelvas un
resultado vacío o sin efecto como éxito.
3. Validar — comparar al ganador con la intención
- Relee la petición original. ¿El ganador hace lo que se pidió — todo, y nada
que no se le pidió hacer?
- Revisa la corrección semántica, el encaje de estilo con el código de alrededor,
y que siga aplicando limpio.
- La confianza baja se muestra como bandera de escalado, no se esconde. Luego
pruébalo por la vía normal: test en rojo primero, verde, comportamiento vivo.
Un borrador fusionado que nunca corrió es una suposición.
La escalera
- La forma de peldaños de la fusión: un panel amplio de modelos baratos abajo,
paneles más apretados y presupuestos de salida más cortos subiendo — un peldaño
mal configurado falla en voz alta al cargarse.
- El formato de config, los roles-no-nombres y la resolución por sondeo vivo
pertenecen a fleet-ladder.
Reglas duras — rompes una y la skill falló
- El que construye nunca juzga. El juez no escribió ningún candidato. El
evaluador final es un modelo distinto (idealmente de otra familia) del que
construyó al ganador.
- Nada de nombres de modelos en duro en ningún punto de llamada. Roles en el
código, modelos en la config.
- Nada de degradación silenciosa. Redactores descartados, el fallback del
juez, fallos de compuerta y agotamiento suenan todos en voz alta. Un resultado
imposible de calificar nunca pasa por defecto.
- Reparación acotada. Las repeticiones del panel tienen tope duro. El
agotamiento es un fallo en voz alta, no un loop infinito.
- Tests en verde por sí solos no es terminado. El ganador se prueba en
comportamiento vivo.
Combina bien con
- fleet-ladder — resuelve qué modelos están arriba antes de disparar el panel.
- blind-tribunal — la corte de calificación que falla-cerrado cuando el evaluador primario muere.
- red-first — el test en rojo que el borrador ganador debe poner en verde.
- blind-eval — la compuerta de gusto conservar-o-revertir cuando ningún test puede decidir.
1---2name: model-fusion-33description: Úsala cuando la respuesta de un solo modelo no da suficiente confianza — un build, fix o diseño difícil donde quieres que varios modelos compitan y un juez independiente elija. Un panel redacta en paralelo, un juez fusiona al ganador, y el resultado se valida contra la intención original. Trigger words: fusion, panel, judge, multi-model, ensemble, draft and merge, builder not grader, fusión, panel de modelos, juez, multimodelo, borradores en paralelo, el que construye no califica.4license: MIT5---67# Model Fusion8**Effort:** heavy — un panel completo redactando en paralelo más un juez independiente (y un escritor opcional); gástalo en builds y arreglos difíciles que van a entregarse, nunca en cambios de una línea. Elimina: apostar el cambio al borrador de un solo modelo, y el retrabajo cuando ese único borrador está mal.910Muchas voces independientes ganan a una sola. Un panel de modelos redacta la11misma tarea en paralelo. Un juez — un modelo que no escribió ninguno de los12borradores — elige o fusiona al mejor. Al ganador después se le compara con lo13que de verdad se pidió.1415## Cuándo correrla1617- Cualquier build, fix o mejora sustancial donde la calidad importa más que la velocidad.18- Cuando quieres un par concreto de evaluadores independientes, no fe ciega en un modelo.19- NO para cambios triviales de una línea. Haz el cambio directo y verifícalo.2021## Las tres etapas2223### 1. Panel — borradores en paralelo24251. Manda la misma tarea, con el mismo contexto, a todos los modelos del panel a la vez.262. Cada redactor trabaja solo. Ningún redactor ve el trabajo de otro.273. Un redactor que falla, se queda sin tiempo o devuelve vacío se registra y se28 descarta. Nunca mata la ronda. Registra el descarte en voz alta — jamás lo29 tragues en silencio.304. Recoge todos los candidatos no vacíos.3132### 2. Juez — un externo elige y fusiona33341. Antes de juzgar, corre una compuerta mecánica barata sobre cada candidato:35 ¿aplica limpio? ¿parsea? Corre la prueba sobre una copia desechable, nunca36 sobre el árbol vivo. Los candidatos que fallan la compuerta quedan fuera antes37 de que el juez los vea.382. Dos formas de juez — elige una por config:39 - **Síntesis:** el juez analiza cada candidato (fortalezas, defectos,40 conflictos), y luego un modelo escritor aparte compone la respuesta final a41 partir de ese análisis. Escritor y juez son roles distintos; mantenlos en42 modelos distintos cuando puedas.43 - **Selección:** el juez elige el mejor candidato único que pasó la compuerta.44 Más barato. Úsalo cuando fusionar no aporta nada.453. Si el juez o el escritor no está disponible, degrada EN VOZ ALTA a selección46 sobre los mismos candidatos. Nunca desperdicies el panel en silencio; nunca47 finjas que hubo síntesis.484. Si ningún candidato sobrevive la compuerta, añade el mejor error al prompt y49 vuelve a correr el panel — acotado, máximo 2 rondas de reparación. Al50 agotarse, devuelve fallo con la lista completa de errores. Nunca devuelvas un51 resultado vacío o sin efecto como éxito.5253### 3. Validar — comparar al ganador con la intención54551. Relee la petición original. ¿El ganador hace lo que se pidió — todo, y nada56 que no se le pidió hacer?572. Revisa la corrección semántica, el encaje de estilo con el código de alrededor,58 y que siga aplicando limpio.593. La confianza baja se muestra como bandera de escalado, no se esconde. Luego60 pruébalo por la vía normal: test en rojo primero, verde, comportamiento vivo.61 Un borrador fusionado que nunca corrió es una suposición.6263## La escalera6465- La forma de peldaños de la fusión: un panel amplio de modelos baratos abajo,66 paneles más apretados y presupuestos de salida más cortos subiendo — un peldaño67 mal configurado falla en voz alta al cargarse.68- El formato de config, los roles-no-nombres y la resolución por sondeo vivo69 pertenecen a [fleet-ladder](../fleet-ladder/SKILL.md).7071## Reglas duras — rompes una y la skill falló7273- **El que construye nunca juzga.** El juez no escribió ningún candidato. El74 evaluador final es un modelo distinto (idealmente de otra familia) del que75 construyó al ganador.76- **Nada de nombres de modelos en duro** en ningún punto de llamada. Roles en el77 código, modelos en la config.78- **Nada de degradación silenciosa.** Redactores descartados, el fallback del79 juez, fallos de compuerta y agotamiento suenan todos en voz alta. Un resultado80 imposible de calificar nunca pasa por defecto.81- **Reparación acotada.** Las repeticiones del panel tienen tope duro. El82 agotamiento es un fallo en voz alta, no un loop infinito.83- **Tests en verde por sí solos no es terminado.** El ganador se prueba en84 comportamiento vivo.8586## Combina bien con8788- [fleet-ladder](../fleet-ladder/SKILL.md) — resuelve qué modelos están arriba antes de disparar el panel.89- [blind-tribunal](../blind-tribunal/SKILL.md) — la corte de calificación que falla-cerrado cuando el evaluador primario muere.90- [red-first](../red-first/SKILL.md) — el test en rojo que el borrador ganador debe poner en verde.91- [blind-eval](../blind-eval/SKILL.md) — la compuerta de gusto conservar-o-revertir cuando ningún test puede decidir.