Ajusta el motor a la faena, y que otros ojos lo aprueben
Lo habitual es usar un único modelo para todo, y el mismo que cambia el nombre de una variable acaba diseñando el esquema de la base de datos y peleando con un fallo que lleva una semana abierto. Es cómodo, pero pone el esfuerzo donde sobra y lo escatima donde hace falta.
Repartir las tareas lo arregla: trocear el trabajo en encargos pequeños, dar cada uno al que mejor lo resuelve y dejar que compruebe el resultado alguien que no sea su autor.
Para perfiles técnicos
~8 min de lectura
Un solo modelo para todo falla por los dos extremos
Hay modelos de varios niveles. Los pesados van despacio y razonan a fondo; los ligeros son rápidos y cumplen de sobra con el trabajo repetitivo y bien acotado. Usarlos como si fueran intercambiables sale mal por ambos lados.
Con trabajo pesado, un modelo ligero falla sin avisar. Te devuelve algo que parece correcto y está mal de un modo que solo ves más adelante, cuando deshacer una decisión de diseño tomada con prisas ya sale caro.
Con trabajo ligero, un modelo pesado se desperdicia. Renombrar archivos, ajustar formatos o escribir la décima prueba casi igual a las nueve anteriores bloquea el nivel más lento y caro con tareas que uno rápido despacha sin problema.
La salida es elegir modelo para cada tarea, siempre.
La idea: encargos cortos, el nivel adecuado y una revisión aparte
Tres pasos Cada uno, de sentido común
-
Trocea el trabajo en encargos cortos
Cada uno es una sola tarea, con un resultado y unos límites claros: qué hay que cambiar, dónde y cómo sabrás que está terminado. Las piezas pequeñas se pasan, se comprueban y se repiten sin esfuerzo.
-
Dale cada encargo al nivel que le toca
Lo difícil y lo incierto va a un modelo pesado, sin prisa y con margen para pensar; lo sencillo y bien definido, a uno rápido. Esa elección se hace de nuevo cada vez.
-
Que lo revise un juez que no lo escribió
El modelo que hizo el trabajo no debería darlo por bueno. Otro lee el resultado, lo compara con el encargo y lo aprueba o lo devuelve para otra ronda.
Es lo que casi todo el mundo se salta, y lo que da fiabilidad a los otros dos.
Por qué la revisión tiene que ser independiente
Un modelo que revisa su propia obra suele darse la razón: las decisiones son suyas y le parecen sensatas. Un lector nuevo, con otro encargo y una única pregunta, la de si el trabajo cumple lo que se pidió, mira sin ese apego.
Esa independencia cuesta poco: una lectura más de algo que ya está escrito. Y altera lo que puedes afirmar después. Que el modelo diga que ha terminado es solo su palabra; que un juez distinto lo haya comprobado contra el encargo y aprobado ya es un resultado.
Y lo que no supera la revisión tiene adónde ir: vuelve para otra ronda con el motivo del juez por escrito, en lugar de llegarte a medias.
Qué cambia en la práctica
Con el reparto en marcha se notan tres cosas.
Dejas de estar encima. Con encargos cortos y una revisión en cada entrega, tú miras los resultados al final.
El esfuerzo caro va donde cuenta. El nivel lento y cuidadoso dedica su tiempo a las decisiones que lo merecen, y el rápido se encarga de la rutina.
Los fallos se quedan en su sitio. Una entrega mala se para en el juez, frente a un encargo pequeño, antes de que nada se construya encima.
Para todo esto basta con la disciplina de los tres pasos y unas herramientas que la sostengan, de modo que se cumpla siempre.
Las herramientas que usamos, en código abierto
De las tres herramientas de nuestra página de código abierto, dos tienen que ver con este trabajo.
Router trocea el trabajo de programación con IA en encargos cortos, manda cada uno al nivel de modelo que le corresponde y deja que un juez independiente revise cada entrega. Lo que no pasa el filtro va a una segunda ronda.
Harness es una configuración de Claude Code lista para instalar, con acciones que se disparan en cada paso, habilidades que puede cargar y agentes en los que delegar tareas, todo preparado para funcionar junto. Router decide adónde va cada encargo, y este es el entorno donde se ejecuta.
La página de código abierto describe las dos: qué hace cada una y para quién es.
Cómo empezar con lo que ya tienes
Puedes probar la idea esta misma semana con lo que ya usas.
- Escribe como encargos los tres próximos trabajos. Cada uno con un solo resultado y con cómo sabrás que está hecho.
- Elige el nivel antes de arrancar. Difícil e incierto, o rutinario y definido.
- Revisa cada entrega con una lectura limpia. Otro modelo, que solo vea el encargo y el resultado.
- Apunta lo que pilla la revisión. Con dos semanas de notas sabrás si compensa.
Si la revisión no detecta nada, seguramente los encargos son demasiado fáciles y el nivel, excesivo; si caza mucho, has dado con el trabajo que siempre pidió una segunda mirada.
Si vives de programar con IA
Las herramientas son públicas para que las leas y saques tus conclusiones. Encajar el reparto y la revisión en la rutina de tu equipo es parte de lo que hacemos.
Sigue leyendo
- Código abierto, donde están Router y Harness, junto a Motion.
- Antes de ceder la jornada a un sistema que trabaja solo, la misma disciplina aplicada a un negocio entero.
- Volver al blog, con el resto de artículos.