Noticia7 min

Linear Diffs mete la revision de PR dentro del flujo del agente: menos salto a GitHub, mas follow-through

Linear lanzó Diffs el 28 de mayo de 2026 para revisar pull requests, pedir cambios a agentes y seguir el estado del review sin salir del workspace. La mejora útil no es otra vista bonita: es comprimir revisión, contexto y iteración en el mismo loop.

LinearGitHub
Vista editorial inspirada en Linear Diffs con revisión de código, agentes y pull requests sincronizados

Por qué importa

Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.

La mayoría de herramientas de agentes siguen ayudando a escribir cambios, pero dejan la parte más lenta igual que antes: revisar el diff, decidir qué importa y pedir otra iteración sin perder el hilo.

Linear quiere atacar justo ese hueco. El 28 de mayo de 2026 lanzó Linear Diffs para revisar PRs desde el mismo workspace, con la posibilidad de iterar sobre cambios usando agentes en background y sincronizar la revisión de vuelta a GitHub.

La mejora útil no es “ahora también puedes ver código en Linear”. La mejora útil es otra: review, contexto del issue y follow-through del agente quedan mucho más cerca entre sí.

Panel editorial con un diff guiado, comentarios de revisión y contexto del issue en una sola superficie

Qué cambia de verdad

Linear lo explica bastante bien. Con Diffs ahora puedes:

  • abrir un diff desde cualquier issue con PR;
  • revisar cambios sin salir de Linear;
  • usar guided reviews para entrar por el núcleo del cambio;
  • pedir nuevas iteraciones con un agente desde la misma superficie;
  • y mantener sincronizado el estado de la revisión con GitHub.

Eso importa porque el review dejó de ser sólo una lectura humana de código. Cuando ya hay agentes generando bastante volumen, el problema pasa a ser cómo revisar más rápido sin bajar demasiado el estándar.

Guided reviews es la parte que más me interesa

La idea de guided reviews es simple y buena: mostrar primero la parte central del cambio y separar el pegamento o los efectos secundarios.

No es una garantía de calidad, pero sí responde a un problema real. En PRs grandes, buena parte del tiempo se va en encontrar:

  • dónde empezó el cambio importante;
  • qué archivos son ruido;
  • y cuál es la consecuencia real para el sistema.

Linear está intentando convertir esa búsqueda en una experiencia más dirigida. Para equipos que ya delegan código a agentes, eso puede ahorrar bastante fatiga de revisión.

Review Inbox completa el loop

La otra pieza valiosa es el Review Inbox. Suena menor, pero no lo es.

Cuando los agentes empiezan a tocar más cosas, el review compite con:

  • issues nuevos;
  • comentarios;
  • notificaciones de merge;
  • y otros pendientes del día.

Meter la revisión dentro del mismo inbox y del mismo sidebar hace que el trabajo pendiente sea más visible. Y cuando una revisión pide cambios, Linear dice que puedes seguir iterando desde el mismo diff con un agente al fondo, sin bajar todo de vuelta a local para ajustes pequeños.

Composición editorial con bandeja de revisiones, comentarios y nuevas iteraciones de agente dentro del mismo workflow

Dónde sí le veo valor

No lo vendería como reemplazo universal de GitHub. Lo vendería como una capa que puede funcionar muy bien si tu equipo ya vive en Linear y quiere reducir cambio de contexto.

Los casos donde más sentido le veo son:

  1. equipos de producto e ingeniería que ya coordinan casi todo desde issues y proyectos en Linear;
  2. PRs donde el agente ya hizo el trabajo pesado y la persona humana necesita llegar rápido al corazón del cambio;
  3. revisiones repetitivas donde pedir una corrección chica desde la misma vista ahorra varios minutos por ciclo.

Lo que no resuelve

Conviene no romantizarlo.

Diffs no arregla:

  • cambios mal pensados;
  • PRs demasiado grandes;
  • agentes que ya arrancaron sobre una tarea ambigua;
  • ni revisores que no tengan criterio técnico para validar el resultado.

Si el agente te deja un cambio malo, verlo en otra superficie no lo vuelve bueno. La ventaja real está en acortar el loop entre revisar, pedir ajuste y volver a revisar.

Qué búsquedas puede capturar bien

Aquí la intención es bastante clara:

  • linear diffs
  • review pr in linear
  • linear agent code review
  • guided reviews linear

Es tráfico menos masivo, pero mucho más cualificado. Quien busca esto suele estar comparando flujos de trabajo reales, no curioseando un anuncio.

Esta nota conversa bien con Linear ya comparte skills entre equipos, porque una historia va sobre estandarizar instrucciones y esta va sobre cerrar mejor la parte incómoda del ciclo: revisión y follow-through. Y si todavía te falta la base para montar agentes con un contrato más limpio, empieza por el curso gratis.

Mi lectura corta es esta: Linear no está intentando ganar por "tener agente". Está intentando ganar en el sitio donde los agentes crean más deuda visible: el review de código y la coordinación que viene después.