Simon Willison, creador de Datasette, contó en su blog el 9 de noviembre que hoy la mayoría de los cambios en sus proyectos llegan como pull requests (PR) que le abren Claude Code o Codex. El PR es su unidad de trabajo. Lo usa para agrupar commits, iterar hasta que una función está terminada, documentar decisiones y después fusionar el resultado final. Según Willison, los agentes de programación actuales escriben muy bien las descripciones de PR.

Describen demasiado bien el trabajo

El problema, escribe, es que son demasiado buenos. La descripción de un PR escrita por un agente es precisa y completa. Explica el problema, la solución en detalle y los pasos que se siguieron para verificarla. Es mucha información para absorber.

"No es necesariamente basura, pero se lee como basura", resume Willison, que usa la palabra slop, el término en inglés para el contenido de relleno generado por IA.

Un PR escrito por IA se reconoce muy fácil, y como con otras formas de escritura de IA, su reacción inmediata se resume en "no voy a leer todo eso". Da lo mismo qué tan precisa o útil sea la información. Lo desanima la idea de que le tomará más tiempo leerla que lo que le tomó escribirla al autor que dirigió el trabajo, aunque ese autor sea él mismo.

Willison quiere criterio editorial humano. Quiere que alguien haya pensado en el PR lo justo para darle una introducción aprobada por una persona, que le explique a grandes rasgos para qué sirve el cambio y si merece más atención.

Dice haber encontrado una forma de hacerlo que cuesta poco esfuerzo y que le parece la correcta.

¿Cómo funciona el truco de details y summary?

Las etiquetas HTML <details><summary> se muestran como un encabezado plegado (el summary) que se puede desplegar para ver el texto más largo. El código se ve así:

HTML
<details>
  <summary>Claude Opus 5.5</summary>
  <h2>The hook</h2>
  Plugins implement <code>register_agent_reference_types(datasette)</code>...
</details>

Una vez renderizado, queda como en este PR de datasette-agent.

Lo importante es que <details><summary> funciona en el Markdown de GitHub. Las etiquetas se pueden pegar directo en un comentario de issue o en la descripción de un PR, y GitHub esconde el detalle y muestra solo el resumen con una flecha para desplegarlo.

Willison empezó a usar esto en sus PR generados con IA, con este orden:

  • El párrafo de apertura lo elige con cuidado para que explique a grandes rasgos qué está pasando. Es el texto más corto que una persona puede leer para ponerse al día.
  • A veces agrega una captura de pantalla, porque una imagen suele ser la forma más rápida de mostrar una función nueva.
  • El ensayo completo del agente va después, dentro de un <details><summary>. Como resumen usa el nombre del modelo y muchas veces el nivel de esfuerzo, por ejemplo "Claude Opus 5.5 Medium", para dejar claro qué es ese bloque.

Según Willison, sus PR ya no parecen tan descuidados. Toda la información sigue ahí, pero quien lee puede mirar por encima y quedarse con lo de arriba, curado por una persona, sin que se le nublen los ojos frente a varios párrafos de detalle escritos por el agente.

No siempre escribe él la introducción. A veces el agente ya le dio lo que necesitaba, escondido en la avalancha de texto. Lo que le promete al lector es que esa apertura corta representa su criterio humano sobre lo que de verdad vale su tiempo.

Cómo no olvidar el orden de las etiquetas

Willison reconoce que le costaba recordar el orden. ¿Es <details><summary> o <summary><details>? Propone dos trucos.

El primero y más obvio es que <summary> es la parte donde se resume el detalle. Es la etiqueta de la línea de texto en la que se hace clic para desplegar, y <details> tiene que envolver todo lo demás.

El segundo, que considera mejor, es llamar siempre a las dos etiquetas "details-summary". En inglés son dos sílabas seguidas de tres, y eso sale más fluido que el golpe de tres y dos de "summary-details". Basta con decirlo en voz alta unas cuantas veces para no olvidar nunca más el orden.

Willison igual quisiera que GitHub agregara un botón para esto en su editor de Markdown. En parte para no tener que escribirlo a mano en el teclado del celular, y en parte para que más usuarios de GitHub se enteren de que la función existe.