No evaluamos a nadie por lo que construyó.

Cuatro dimensiones, cada una puntuada de 1 a 5 contra anclajes de conducta escritos, para que dos revisores viendo el mismo vídeo lleguen al mismo número. El Orchestration Index es la suma, normalizada a 100. Aquí nada premia la velocidad de tecleo, y a nada le importa qué modelo usaste.

Solo se anclan el 1, el 3 y el 5. Anclar los cinco hace que dos revisores coincidan menos, no más, porque les obliga a inventar diferencias que no existen.

Pesos iguales hasta que haya datos suficientes para calibrarlos. Cuando eso cambie, se publicará el cambio y el motivo — una puntuación cuya fórmula se mueve en silencio no vale nada.

01 / 4

Spec

Cómo se descompone el problema antes de escribir una línea.

Minutos hasta el primer prompt · si existen criterios de aceptación por escrito · cuántos supuestos se declaran en voz alta.

1: Sin plan. Primer prompt antes de dos minutos. Criterios de aceptación no escritos en ninguna parte.
2: Punto intermedio
3: Hay plan pero se queda en su cabeza. Los supuestos afloran solo cuando algo se rompe.
4: Punto intermedio
5: Criterios de aceptación escritos antes del primer prompt. Supuestos declarados, y el más arriesgado verificado primero.

02 / 4

Delegation

Qué va al modelo y qué deliberadamente no.

Tamaño de cada cambio pedido · si el reparto sigue el riesgo o las fronteras de fichero · qué decide escribir a mano.

1: Un solo prompt para toda la funcionalidad — o lo contrario, todo tecleado a mano con el modelo parado.
2: Punto intermedio
3: Lotes razonables, pero el reparto sigue las fronteras de fichero en vez de dónde equivocarse sale caro.
4: Punto intermedio
5: Reparto deliberado: el modelo se lleva lo mecánico y bien especificado, la persona se queda las decisiones caras de equivocar.

03 / 4

Review

Qué se rechaza del output del modelo, y cuán pronto.

Outputs descartados antes de ejecutar · errores detectados leyendo y no ejecutando · si el rechazo se explica.

1: Acepta el output y lo ejecuta sin leerlo. Los errores los encuentra el runtime.
2: Punto intermedio
3: Lee el diff y caza lo evidente. El comportamiento incorrecto pero verosímil se cuela.
4: Punto intermedio
5: Rechaza antes de ejecutar. Caza lo verosímil-pero-incorrecto y explica por qué — que es lo que lo hace repetible la próxima vez.

04 / 4

Recovery

Tiempo desde un camino equivocado hasta una solución verde en local.

Minutos entre el primer fallo grave y el verde · si el segundo intento cambia la entrada o solo la redacción.

1: Repite el mismo prompt con otras palabras. No entra información nueva en el bucle.
2: Punto intermedio
3: Cambia de enfoque tras varios intentos. Se recupera, pero sin aislar qué falló de verdad.
4: Punto intermedio
5: Para al segundo fallo, aísla la causa y cambia lo que le da al modelo, no cómo se lo dice. Vuelve a verde rápido, y el arreglo se explica solo.

Qué invalida una sesión

Un corte, una pausa o un hueco en la grabación. Una persona, pantalla completa, sin interrupciones.
Recortar solo la ventana del editor en lugar de compartir pantalla completa (los revisores necesitan evaluar la interacción con el agente de IA, la terminal y el navegador).
Realizar múltiples git pushes de ensayo y error (solo se permite UN ÚNICO git push al repositorio cuando consideres que la solución está lista).
Trabajo commiteado después de que expiren los 45 minutos — lo determinan las marcas de tiempo del repositorio.
Un pull request cuyo check de aceptación se puso en verde editando o debilitando la suite de pruebas del mantenedor.

¿Listo para poner a prueba tu criterio?

Elige un drill de nuestro catálogo semanal, graba tu sesión de pantalla completa y obtén tu Orchestration Index.

Ponlo a prueba