At LinkedIn's scale, relying solely on human reviewers or simply putting an off-the-shelf AI reviewer in front of GitHub is not an effective way to manage PRs. To address this, LinkedIn engineers built a multi-agent AI code review platform that understands the organization’s coding context, treats code review as prod…
At LinkedIn's scale, relying solely on human reviewers or simply putting an off-the-shelf AI reviewer in front of GitHub is not an effective way to manage PRs. To address this, LinkedIn engineers built a multi-agent AI code review platform that understands the organization’s coding context, treats code review as prod…
In context
- Topic: Desarrollo de Software — Arquitectura de aplicaciones, prácticas de entrega y calidad.
- Source: InfoQ
- Published: 22/08/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por qué importa
Cuando aparece una herramienta que promete acelerar el desarrollo, la pregunta útil no es cuánto código genera sino cuánto trabajo genera aguas abajo. Pruebas, revisión, seguridad, deuda técnica, incidentes: ahí es donde se paga o se cobra la promesa.
Yo lo miro desde la operación, no desde la demo. La pregunta no es si el asistente escribe una función correcta, sino si el equipo puede sostener seis meses después lo que produjo, con otra gente, sin el contexto original. Esa es la prueba real y casi nunca aparece en los anuncios.
Lo que suele salir mal
El problema aparece cuando alguien acepta código que no entiende del todo pero que pasa las pruebas. Funciona, entra a producción, y seis meses después hay que modificarlo. Ahí se descubre que nadie en el equipo puede explicar por qué está escrito así, y el cambio chico se convierte en una reescritura.
Qué mirar
- Si baja el tiempo total hasta producción o solo el tiempo de escribir, que no es lo mismo.
- Cómo queda la revisión de código: si el asistente produce más, alguien tiene que leer más.
- Qué pasa con las pruebas — generar código sin generar pruebas solo mueve el problema hacia adelante.
Cómo leo esta entrada
Lo que yo pediría medir no es líneas ni sugerencias aceptadas, sino defectos que llegan a producción y tiempo de revisión por cambio. Si esas dos bajan, la herramienta sirve. Si suben mientras sube la velocidad, se está acumulando una deuda que se paga con incidentes.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
