Un revisor de código con personalidad (Claude Code) Agentes

Cambiar el tono de un revisor de código no solo cambia cómo te habla — puede cambiar cuánto te ayuda de verdad. Eso es lo que salió al pedirle a la IA dos revisiones del mismo archivo Python, en paralelo: un subagente con tono de profesor exigente y otro con tono de profesor amigable, los dos con el mismo criterio de fondo, revisando el mismo código a la vez. Los dos coincidieron en lo que estaba mal. Pero solo uno de los dos terminó proponiendo cómo arreglarlo.

El problema que resuelve

Un ejercicio de Python “funciona” —da el resultado correcto— y aun así puede estar mal escrito: sin comentarios, con variables que no dicen nada, sin la información mínima para saber de qué asignatura o curso es. Casi nunca hay tiempo de revisar eso a mano, uno por uno. Pedirle a la IA que lo revise resuelve la falta de tiempo, y crear dos revisores con tonos distintos —uno estricto, otro amigable— añade algo más: comprobar si el tono cambia solo la forma o también el fondo de la ayuda.

El código de partida

El archivo que se revisó, notas.py, calcula la nota media de una clase con un patrón acumulador (un bucle que va sumando nota a nota) y cuenta cuántos alumnos aprueban. Da el resultado correcto, pero la lista de notas está metida directamente en el código en vez de pedirse como dato, no tiene ninguna cabecera que diga de qué asignatura o curso es, y usa variables de una sola letra sin explicar qué guardan.

Paso 1 — Crear el subagente estricto

Con Claude Code, se pide crear un agente que revise archivos Python y diga qué está bien, qué está mal y qué mejorar, con un tono muy estricto, como un profesor exigente. Claude Code crea el archivo del subagente y pide permiso para guardarlo en su carpeta correspondiente.

Paso 2 — Crear el subagente amigable, con el mismo criterio de fondo

A continuación se pide el segundo agente: el mismo encargo, pero con el tono exactamente contrario — un profesor con un tono natural y amigable, que anime a corregir los errores en vez de señalarlos como una falta. La instrucción explícita fue mantener el mismo criterio técnico de revisión entre los dos; lo único que cambia es cómo se presenta cada corrección, planteándola como el siguiente paso a resolver, no como un fallo.

Paso 3 — Pedir las dos revisiones en paralelo, sobre el mismo archivo

Con los dos subagentes ya creados, se adjunta el archivo notas.py y se pide una sola cosa: que ambos lo revisen a la vez, en paralelo. Claude Code lanza las dos revisiones en segundo plano — con un pequeño tropiezo real en la demo, porque el registro de la sesión no cargaba bien al principio y solo mostraba una de las dos—, y avisa cuando las dos han terminado.

Paso 4 — Comparar las dos respuestas

El profesor amigable señaló lo que estaba bien (el patrón acumulador para sumar las notas) y, sobre lo que faltaba —la cabecera con el nombre del curso, las variables de una sola letra sin explicar, la lista de notas metida a mano en vez de pedida como dato—, no se quedó solo en decirlo: propuso directamente cómo quedaría la cabecera corregida.

El profesor estricto llegó a los mismos fallos de fondo —cabecera inexistente, cero comentarios en las 15 líneas del archivo, variables de una sola letra, un problema con cómo está organizada la lista de notas, y una salida por print que considera insuficiente—, pero se quedó ahí, en el diagnóstico, sin proponer la corrección.

Mismo criterio, mismo código, mismo momento — y solo uno de los dos hizo el trabajo completo de proponer la solución, no solo señalar el problema.

Adaptación por nivel

Para PYC (2º Bach) el proceso completo tiene sentido tal cual: crear los dos subagentes de verdad y compararlos en paralelo. Para CDYPC (1º Bach), sin montar nada técnico, se puede simular la misma comparación con dos prompts seguidos en el chat normal: “revisa este código como un profesor muy estricto” y “revisa este mismo código como un profesor muy amigable” — y fijarse en si, además del tono, cambia cuánta ayuda concreta da cada uno.

Avisos

Un pequeño tropiezo al cargar el registro de una sesión con dos agentes en paralelo no es un fallo grave — es la clase de fricción real que conviene mostrar en vez de esconder. Y el hallazgo de fondo del vídeo no es “el tono no importa”: es que, aunque el criterio técnico sea el mismo, conviene fijarse en si el tono que se elige también está recortando la utilidad de la respuesta, no solo su forma.

Idea para llevarse a casa

La próxima vez que le pidas a la IA que revise tu código, prueba a pedirle dos tonos distintos a la vez y compara no solo cómo lo dicen, sino si los dos te dan realmente algo que puedas usar para corregirlo.