Simon Willison: oculta las descripciones de PR con IA

Por qué las descripciones de PR escritas por IA se volvieron un problema

Simon Willison, creador de Datasette, publicó el 9 de noviembre de 2026 una nota que describe un cambio de hábito. La mayoría de los cambios que hace hoy en sus proyectos llegan como pull requests que le abren Claude Code o Codex. Usa el PR como unidad de trabajo: agrupa commits, itera hasta cerrar una función, documenta decisiones y fusiona el resultado.

El problema no es la calidad. Los agentes escriben descripciones precisas y exhaustivas: describen el problema, la solución detallada y los pasos de verificación. Es demasiada información para absorber de una sola vez. Willison lo dice sin vueltas: no es necesariamente contenido de relleno, pero se lee como tal, y su reacción instintiva es «no voy a leer todo eso».

Ahí está el punto que le sirve a cualquier equipo: el costo de leer no lo paga quien escribe. Un agente produce tres párrafos en segundos; un revisor humano los procesa en minutos. Cuando el volumen de PRs sube, esa asimetría se convierte en el cuello de botella real.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Y el volumen subió. Según el informe Octoverse 2026 de GitHub, recogido por Developer Tech News, más del 40% de los pull requests de la plataforma arrancaron en septiembre de 2026 con un borrador generado por un agente, frente al 17% de marzo. Solo en septiembre, los agentes iniciaron 110 millones de PRs, unas seis veces el volumen de marzo.

Qué es `details`/`summary` y por qué funciona en GitHub

La solución que propone Willison es de bajo esfuerzo y se apoya en una etiqueta HTML que GitHub ya soporta dentro de su Markdown.

<details><summary> renderiza un encabezado plegable: se ve el texto del summary y una flecha para expandir el resto. En GitHub funciona directamente en la descripción de un PR o en un comentario de un issue, sin plugins ni configuración.

El patrón que adoptó tiene cuatro piezas:

El primer párrafo del PR queda como explicación de alto nivel, escrita o curada por él. Es el texto más corto que permite a alguien ponerse al día.
A veces suma una captura de pantalla, porque una imagen explica una función nueva más rápido que un párrafo.
Todo el ensayo del agente va dentro de <details><summary>.
El summary lleva el nombre del modelo y el nivel de esfuerzo —por ejemplo, «Claude Opus 5.5 Medium»— para que quede claro de un vistazo qué hay adentro.

Willison aclara que no siempre escribe la introducción a mano: a veces el agente ya le dio lo que necesita, escondido en la avalancha de texto. Su compromiso con el lector es que ese párrafo corto representa su criterio humano sobre qué vale la pena leer.

Entre los PRs donde aplicó el patrón menciona datasette #3052 (rediseño de la página de fila como lista vertical de campos), datasette #3043 (barra de paginación que muestra qué filas están en la página actual), datasette #3042 (carga bajo demanda de edit-tools.js, un archivo de unos 220 KB que antes se cargaba en todas las páginas), datasette-agent #51 (nuevo hook de plugin) y llm #1838 (comandos para gestionar endpoints compatibles con OpenAI).

El truco para no olvidar el orden de las etiquetas

Willison admite que confundía el orden: ¿<details><summary> o <summary><details>? Dos ayudas simples resuelven la duda.

El summary es donde resumes; el details envuelve todo lo demás. La lógica del nombre ya marca el orden.
Decir «details-summary» en voz alta: dos sílabas más tres fluye mejor que el golpe de tres más dos de «summary-details».

También pide que GitHub agregue un botón en su editor de Markdown para insertar la etiqueta, tanto para ahorrar tipeo en el móvil como para que más usuarios descubran que la función existe.

Cómo aplicar el patrón a tus pull requests

La implementación no requiere herramientas nuevas. Requiere disciplina editorial.

Escribe el opener tú, aunque el agente lo haya escrito. Toma el párrafo que mejor explique el para qué del cambio y muévelo arriba. Si el agente no lo produjo, escríbelo: dos o tres oraciones sobre qué problema resuelve y qué debería mirar el revisor primero.
Pon el modelo y el nivel de esfuerzo en el summary. Cuando varios agentes trabajan en paralelo, saber que un cambio salió de un modelo con razonamiento alto y otro de una corrida rápida cambia cuánto tiempo le dedicas a cada uno.
Define qué se puede plegar y qué no. Migraciones de base de datos, cambios de autenticación y modificaciones a datos en producción no van escondidos: van arriba y con la advertencia explícita.
Suma una captura cuando el cambio sea visual. Es la forma más barata de que el revisor entienda el resultado sin leer el diff completo.

Qué significa esto para tu startup

Si tu equipo ya usa agentes para escribir código, el cuello de botella se movió de la escritura a la revisión. Esconder el texto generado no es cosmética: es una decisión de diseño de proceso que protege el recurso más escaso, que es la atención del revisor.

Dos acciones concretas para esta semana:

Instala el patrón como estándar del equipo. Agrega una plantilla de PR con el opener obligatorio y el bloque <details><summary> vacío debajo. Si el estándar no está en la plantilla, nadie lo va a recordar.
Mide tiempo hasta el merge, no cantidad de PRs. Un equipo que fusiona más rápido porque revisa mejor vale más que uno que produce más cambios que nadie alcanza a leer.

Hay un efecto secundario valioso: cuando el opener es responsabilidad de una persona, esa persona tiene que entender el cambio. El patrón obliga a un momento de juicio humano antes de que el PR entre a la cola de revisión.

El cuello de botella ya no es escribir código, es revisarlo

El contexto respalda el diagnóstico. Según el informe Octoverse 2026 recogido por Developer Tech News, el uso de revisión de código asistida por IA y de GitHub Advanced Security creció más del 90% interanual, y entre los usuarios activos mensuales de GitHub Copilot, el 55% ya usaba funciones agénticas, frente al 35% un año antes.

La propia GitHub movió ficha en esa dirección: a fines de octubre puso en vista previa Copilot code review Max, que usa agentes de revisión independientes corriendo modelos de distintos proveedores y un agente agregador que combina los hallazgos en una sola revisión. También habilitó las aprobaciones de Copilot, que cuentan para los approvals requeridos de un repositorio cuando el administrador lo activa.

El mercado se está reordenando alrededor de esa idea. TechTimes reporta que GitHub procesa más de 17 millones de pull requests generados por IA por mes, frente a unos 4 millones en septiembre de 2025. Y GeekWire cubrió el lanzamiento de Entire, la plataforma del ex CEO de GitHub Thomas Dohmke, cuyo producto Trails directamente reemplaza el pull request por un tablero de puntajes de agentes que incluye una medida cuantitativa de salida de IA de baja señal, a la que el equipo llama «slop».

El dato que mejor dimensiona el problema viene del mismo artículo de GeekWire: Anthropic describió haber construido su propio sistema de control de código fuente cuando la cantidad de cambios que fusionaba por día pasó de unos 2.500 en mayo a más de 30.000 en septiembre. Y TechRepublic cita un estudio de Microsoft según el cual los agentes de código se asociaron con un 24% más de pull requests fusionados cuando los desarrolladores realmente los usaban.

Más PRs fusionados, con la misma cantidad de ojos humanos. De ahí la necesidad de filtrar qué merece atención.

Conclusión

El aporte de Willison no es técnico: <details><summary> existe desde hace años y GitHub lo soporta en su Markdown sin fricción. El aporte es de criterio. En un flujo donde los agentes escriben más de lo que cualquier persona puede leer, la intervención humana de mayor valor ya no está en escribir el código, sino en decidir qué parte del texto merece ser leída.

Ese párrafo corto arriba del PR es, en el fondo, una declaración de responsabilidad editorial: alguien leyó, entendió y decidió que eso es lo importante. Es la parte que ningún agente puede firmar por ti.