Puedes delegar el trabajo y buena parte de la revisión, pero no la responsabilidad.
Así cierra Addy Osmani un artículo sobre pensar críticamente cuando los agentes hacen el trabajo. Lo leí a principios de noviembre y me quedé pensando en cómo trabajo yo.
Addy describe tres escalones. Arriba está delegar: el agente hace el trabajo y el resultado sigue siendo tuyo. En el medio está lo que él llama deferral: lo que dice el agente se vuelve tu punto de partida y deja de ser una hipótesis. Abajo está lo que Steven Shaw y Gideon Nave, de Wharton, llaman rendición cognitiva (cognitive surrender): lo que dice el agente pasa a ser tuyo y ya no sientes la necesidad de revisarlo.
Lo que más me hizo ruido es que se baja de a poco. Revisaste bien la última respuesta, así que la siguiente la lees por encima. Cada paso parece razonable.
Yo trato de quedarme arriba. Esto es lo que hago para lograrlo, antes y después de pedirle algo a un agente.
Antes de pedir#
Es lo de siempre: garbage in, garbage out. Depende de la configuración, del prompt y de entender el problema. O sea, de saber qué pedir. Addy lo pone así: tu prompt refleja cuánto entiendes el problema, y si no lo puedes explicar claro, a lo mejor tampoco lo tienes claro tú.
Por eso, cuando un agente me da un mal resultado, ya no me paso a otro modelo. Primero reviso qué le pedí. Charlie L (@charliesbot) lo dijo hace poco en un tweet: hoy Codex, Claude y Gemini son tan buenos que, si un proyecto da malos resultados, la razón principal va a ser una mala configuración, no el modelo.
Antes usaba ChatGPT y Codex. Me pasé a Claude sobre todo por el plan mode: que el agente planee antes de tocar nada tenía sentido para mí. De ahí fui aprendiendo spec-driven development: primero se escribe qué se va a hacer, después se hace. Creo que fue en febrero cuando empecé a pagar el plan de 20 dólares. En abril ya iba en el de 100.
Addy recomienda escribir con tus palabras, antes de pedir ayuda, para quién es, qué queda fuera y cuándo está terminado. En este blog eso ya es regla: ningún post se escribe sin antes tener la lista de hechos, cada uno con su fuente, y para quién es. Este post tuvo la suya.
Las reglas que no estaban escritas#
Addy cuenta que antes, si pedías algo vago, alguien te lo cuestionaba, y ahí te dabas cuenta de que no lo tenías pensado. Un agente muchas veces no te frena: llena lo que faltó y te entrega algo que parece terminado.
Para eso tengo mis reglas: no tocar más de la cuenta, no mergear a main, avisarme de los cambios, no asumir y preguntarme siempre.
Y funcionan. Hace unas semanas le contesté "yes" a un agente sin decir a qué. Tenía dos cosas pendientes: mergear dos PRs o abrir otro en el repo de mi juego. En lugar de elegir, me frenó y me preguntó. Le contesté, y después mergeé los dos PRs.
Pero no estaban escritas en ningún lado. Se las repetía al agente cada vez que empezaba un proyecto. Me di cuenta mientras armaba la lista de hechos de este post, cuando el agente me preguntó dónde las tenía. Una regla que tengo que repetir en cada proyecto es costumbre, y una costumbre se olvida. Así que las puse en un archivo que aplica en todos mis proyectos. Una de ellas ahora dice que un "sí" de antes no cuenta para la próxima vez.
Después: lo que reviso yo#
En esa misma tanda de trabajo, el agente escribió en la descripción de un PR que una de mis revisiones automáticas se trababa "también en main". Lo dijo con toda seguridad. Otro agente, el que revisa antes de mergear, la corrió completa: 211 checks, todos pasaron, y no se trabó. Se corrigió antes del merge.
Ahí el dato ya había dejado de ser una hipótesis. Ese es el escalón del medio, y el segundo revisor me paró antes de bajar al de abajo.
Addy dice que un check en verde prueba una sola cosa, y que hay que preguntarse qué no probó. Por eso el diff lo sigo leyendo yo. Veo qué módulos toca y si tiene sentido que los toque. Y reviso que los unit tests prueben algo, que no estén ahí solo para pasar.
Lo que aprendo, lo anoto#
Otra idea de Addy: cuando algo no pasa tu estándar, anota por qué en la configuración, en un hook o en un test, para que no se repita.
Eso sí lo hago. Este blog tiene su configuración desde el 12 de septiembre: cuatro agentes que editan, traducen y revisan, tres skills y un hook que revisa cada post al guardarlo. No la armé en un fin de semana. La voy arreglando en el día a día, cuando algo sale mal. La skill que define cómo escribo salió de mis propios chats, y ahí quedaron las palabras que fui tachando porque nadie las dice en voz alta, como "costura" o "la frescura". En el trabajo es parecido: el equipo comparte un CLAUDE.md con ciertas reglas.
La configuración es donde guardo lo que aprendí revisando. Pero revisar lo sigo haciendo yo.