Una plataforma de revisión de código obligada a probar sus propios hallazgos
La mayoría de las herramientas de revisión produce más texto que leer que trabajo que arreglar. Construimos una donde varios agentes de análisis trabajan el mismo cambio en paralelo, una segunda pasada discute contra todo lo encontrado y lo que sobrevive llega con el código de reemplazo y la evidencia detrás. Detrás del terminal, del editor, de la API y de un servicio desatendido hay un solo motor, así que una revisión significa lo mismo empiece donde empiece.
- SectorHerramientas para desarrollo
- Tipo de trabajoProducto propio, construido en casa
- EstadoEn uso activo, todavía en desarrollo
Un solo motor detrás de cada forma de pedir una revisión
La plataforma lee el cambio propuesto, deduce qué toca y lo pone delante de varios agentes de análisis a la vez. Los hallazgos se fusionan, se depuran, se ordenan por severidad y se limitan, de modo que lo que vuelve es una cola de trabajo y no un muro. No es un linter, y no es la opinión de un modelo redactada como veredicto.
El mismo motor corre venga la petición de un comando de terminal, del editor, de la API o de un servicio en segundo plano que vigila un repositorio con su propio calendario. Comparten un historial: la revisión iniciada en el teclado es la que el panel muestra después, y en un pull request se actualiza su propio comentario en lugar de apilar uno nuevo.
Por qué otra herramienta de revisión
La revisión automática tenía un problema de credibilidad antes que un problema de cobertura. Diseñamos contra estos tres fallos.
El ruido cuesta más de lo que atrapa
Una herramienta que marca cambios de formato, importaciones reordenadas y conjeturas seguras de sí mismas enseña al equipo a leer en diagonal. Y en cuanto la salida se lee en diagonal, el único hallazgo que importaba se lee en diagonal con ella.
Un hallazgo sin corrección es otro ticket
Los comentarios de revisión que describen un problema y ahí se detienen devuelven el trabajo a quien ya estaba ocupado. Quien lee todavía tiene que averiguar cómo es el código corregido, y a menudo decide que puede esperar.
Cada superficie se comportaba distinto
La revisión en el terminal, en el editor, en un pull request y por calendario eran herramientas separadas, con comportamiento e historial separados. El mismo cambio podía pasar una y fallar en otra.
Lo que construimos
Una sola tubería, cuatro maneras de llegar a ella y varias capas de duda entre la conjetura de un modelo y aquello que se pide leer a una persona.
Un motor de revisión detrás de cada superficie
Una única tubería analiza el cambio, lo filtra, lo enriquece, lo reparte entre agentes y fusiona el resultado. El formato y el almacenamiento son cosa de quien llama, y por eso las superficies pueden diferir sin que la revisión difiera.
- Un comando de terminal, una integración con el editor, una API con actualizaciones en vivo y un servicio en segundo plano ejecutan la misma revisión
- Un historial compartido: la revisión iniciada en el teclado es la que el panel muestra después
- Los proveedores de modelos están detrás de una sola interfaz, así que añadir o cambiar uno es configuración y no reescritura
Hallazgos que llegan con la corrección puesta
Cinco niveles de severidad se reducen a tres acciones: arreglar ahora, arreglar pronto, mirar después. Así un informe se trabaja de arriba abajo. Cada hallazgo se enriquece con un mapa del código, de modo que señala una ruta real y no un patrón.
- Todo hallazgo lleva el código de reemplazo, y el esquema rechaza uno que no lo lleve
- Las revisiones se enriquecen desde un índice de símbolos: qué funciones cambiaron, quién las llama, qué pruebas las cubren y qué importa a qué
- Los hallazgos se identifican por su contenido y no por un número de línea, así que reformatear un archivo no resucita un asunto ya resuelto
Cinco capas entre una conjetura y un informe
Cada capa es más barata que la siguiente, así que casi todo lo que habría sido ruido desaparece antes de que ocurra nada caro. La última capa es la estricta: la plataforma intenta probar el hallazgo contra el código fuente.
- Los cambios de solo espacios, comentarios o importaciones se descartan antes de contactar con un solo modelo, y una pasada estática de patrones marca antes el código de riesgo
- Los hallazgos de baja confianza se retiran justo después de la revisión, y luego una segunda pasada discute contra cada superviviente y conserva solo lo que no consigue rebatir
- Cuando puede, la plataforma escribe un pequeño programa que comprueba la afirmación contra el código real dentro de un entorno aislado, y si esa comprobación no puede hacerse el hallazgo se conserva en vez de desaparecer sin ruido
Un modo adversarial que propone y nunca aplica
Un ejercicio de tres oleadas contra una base de código: un grupo de agentes busca algo explotable, un segundo escribe el parche y un tercero comprueba el parche contra la brecha que dice cerrar. Vuelve como verificado, parcialmente corregido, aún abierto o falsa alarma.
- Quienes atacan trabajan con encargos distintos, auditoría de lógica de negocio, cliente hostil, ingeniería del caos, observabilidad y cumplimiento, para que el barrido no sean cinco copias del mismo instinto
- Los parches se producen como diffs y se validan, nunca se escriben en el repositorio; qué entra lo decide una persona
- Los agentes trabajan dentro de una lista de comandos permitidos con las operaciones destructivas bloqueadas, y su salida se revisa en busca de instrucciones inyectadas
Qué cambió en la práctica
Publicamos lo que hace la plataforma, no una cifra de lo bien que lo hace. Cualquier afirmación de exactitud necesitaría una medición que no hemos publicado.
Una cola
Lo que produce una revisión
Hallazgos fusionados entre agentes, sin duplicados, ordenados por severidad y limitados. Algo que se trabaja de arriba abajo en lugar de leerse entero.
Comprobado, no supuesto
Lo que llega a una persona
Los cambios triviales nunca llegan a un modelo, los hallazgos débiles se descartan, los que quedan se rebaten y, cuando puede, la plataforma prueba antes el hallazgo contra el código fuente.
Decide una persona
Cómo entran los cambios
Las correcciones y los parches llegan como propuesta, con vista previa y una copia del archivo original. Nada se escribe en un repositorio sin que alguien lo acepte.
¿Su proceso de revisión produce más lectura que arreglos?
Cuéntenos cómo se revisa el código hoy en su empresa y dónde se atasca. Le diremos qué merece automatizarse y qué no.
Hablemos de su proyecto