Cómo llevar las reglas de revisión extraídas de Qodo al agente que escribe tu código (Paso a paso, 2026)

La revisión de código es donde se aplican los estándares en la mayoría de los equipos, y funciona mediante el retrabajo. Alguien lo escribe de una manera, un revisor que ha visto que esto sale mal antes lo señala, y se vuelve a escribir. La transferencia de conocimiento es real, y ocurre después del trabajo.

Con un autor humano, ese bucle es tolerable: los revisores corrigen una vez y el autor generalmente lo recuerda. Con un agente escribiendo el código, el bucle no se cierra. El agente que lo escribió de la manera incorrecta lo escribirá de la manera incorrecta la próxima semana, porque nada de la revisión pasó a formar parte de lo que sabe. Pagas el costo del retrabajo repetidamente en lugar de una sola vez.

Rule Miner hace que esto sea mejor y más visible. Mejor, porque los estándares se convierten en artefactos explícitos en lugar de vivir en la cabeza de un ingeniero senior. Más visible, porque ahora puedes ver la lista de cosas que tus revisiones siguen detectando. Qodo es preciso sobre lo que califica: "Solo se consideran los comentarios que fueron aceptados por los desarrolladores y que llevaron a cambios en el código". Cada regla extraída representa una corrección que realmente se aplicó, repetidamente.

La ponderación de la señal te dice cuáles son estas reglas. Qodo "estima la propiedad de cada revisor sobre el código cambiado y pondera sus comentarios en consecuencia, de modo que las reglas reflejen los estándares de quienes están más familiarizados con él". El feedback recurrente "se convierte en un candidato a regla", y "un solo comentario también puede calificar cuando proviene de un revisor con una fuerte propiedad del código afectado". La agrupación produce "reglas específicas del área, limitadas a las rutas que gobiernan". Y el sistema se autocorrige: "una vez que una regla está activa, las sugerencias descartadas que genera reducen su señal con el tiempo, por lo que el ruido se desvanece por sí solo".

Ese es un bucle de aprendizaje bien diseñado dirigido completamente al revisor. El autor —cada vez más un agente— no está en él.

Escribir a mano un AGENTS.md a partir del feedback de revisión. Alguien lee tres meses de pull requests y destila las convenciones en un archivo de instrucciones. Funciona y luego se detiene, porque nadie repite el ejercicio. Seis meses después, el archivo describe los estándares de la primavera pasada, y el fallo es invisible: un archivo de instrucciones desactualizado se ve exactamente igual que uno actual. Ese es el problema de la desviación en por qué los agentes ignoran tus archivos de instrucciones.

Copiar a mano las reglas extraídas de Qodo en un archivo de instrucciones. Mejor, ya que la fuente se mantiene. Peor en mantenimiento, porque Rule Miner sigue adelante —"continúa aprendiendo cada dos semanas, generando hasta 5 nuevas reglas por repositorio por ejecución"— y tu copia no. Dos fuentes de verdad con un paso de sincronización manual es una fuente de verdad y un error.

Dejar que la revisión lo detecte. El valor por defecto honesto en el que se encuentran la mayoría de los equipos. Está bien para los humanos, es costoso para los agentes.

Asumir que el agente inferirá las convenciones a partir de la base de código. Los agentes son decentes para igualar patrones locales visibles y malos para inferir prohibiciones. Nada en tu código dice "dejamos de hacerlo de esa manera después del incidente"; la ausencia de un patrón no se puede leer como una regla.

Paso 1: Descubre qué se ha extraído realmente y en qué ventana

Antes de conectar nada, mira qué existe. Las reglas extraídas aparecen en la pestaña Rules en la página de Review Standards "con un tipo de origen de Mined Pattern", lo que las distingue de las reglas que escribió un humano. Si tu repositorio no muestra ninguna, verifica la condición de activación antes de asumir que algo está roto: la primera ejecución "se activa cuando se abre el primer pull request en un repositorio después de conectarse a Qodo, no automáticamente en el momento de la conexión", y las reglas aparecen "pocas horas después de la primera ejecución".

Dos límites importan más que la cantidad.

El primero es la ventana. Qodo afirma que "Rule Miner se basa en una ventana indexada de hasta aproximadamente 1,000 de los pull requests recientemente fusionados de tu repositorio, que puede incluir actividad de antes de que tu repositorio fuera conectado", y luego dice la parte importante directamente: "Este no es el historial completo de tu repositorio". Para un repositorio activo, mil pull requests fusionados pueden ser unos pocos meses. Los estándares que tu equipo estableció y luego dejó de violar con éxito —que es como se ve el éxito— pueden quedar completamente fuera de esa ventana, precisamente porque nadie ha necesitado señalararlos recientemente. Qodo es directo al decir que un rendimiento bajo no es un mal funcionamiento: "Un repositorio puede estar perfectamente sano y aun así producir solo unas pocas reglas, o ninguna en absoluto".

El segundo es la activación, y depende de una fecha. La documentación de Qodo establece que Rule Miner está habilitado por defecto, y que "para las organizaciones que comenzaron a usar Qodo desde el 1 de septiembre de 2026, las reglas generadas se activan automáticamente", mientras que "para las organizaciones incorporadas antes de esa fecha, las reglas generadas aparecen primero como sugerencias en Rules > Suggestions para su revisión antes de ser aplicadas". Ambas configuraciones se pueden cambiar —"Mine rules from code review history" y "Auto-approve rule miner suggestions" viven en la configuración del portal bajo la pestaña Context, en la sección Review standards— pero el valor por defecto en el que te encuentres determina si las reglas extraídas ya están dando forma a las revisiones o esperando en una cola. Verifica antes de asumir.

Paso 2: Instala el Agentic Toolbox y confirma que Get Rules sea accesible

El Agentic Toolbox es el mecanismo de Qodo para poner estas capacidades dentro del agente que ya utilizas. Su propio enfoque: "lleva la comprensión de código, los estándares de codificación y las capacidades de revisión de Qodo a tu agente de codificación existente" y "no reemplaza a tu agente de codificación ni requiere que interactúes directamente con Qodo".

La instalación es un script de una sola línea desde el endpoint de instalación de Qodo —sus documentos proporcionan las formas para macOS, Linux y Windows PowerShell— y requiere Node.js 20 o posterior. Lee el script antes de ejecutarlo, al igual que cualquier instalación por tubería (pipe). Dos cosas que debes saber sobre lo que sucede a continuación: "el instalador instala la caja de herramientas y configura las herramientas de Qodo disponibles para los entornos de agentes compatibles", y "puedes instalar el Agentic Toolbox sin una cuenta de Qodo, pero deberás registrarte o iniciar sesión en Qodo antes de que tu agente pueda ejecutar realmente cualquiera de las herramientas". Tanto la caja de herramientas como Get Rules están documentadas como Beta.

Get Rules se expone a través de varias interfaces: un plugin de Claude Code, un plugin de Codex, un plugin de Kiro, una CLI, habilidades de agente y un servidor MCP para "cualquier cliente o agente compatible con MCP". La ruta de MCP es la preferible si tu equipo no está todo en el mismo cliente, ya que no vincula la configuración al sistema de plugins de un solo editor.

Confirma que funciona preguntándole a tu agente, en un repositorio conectado a Qodo, qué reglas se aplican a la tarea que estás a punto de comenzar. Lo que devuelva debería combinar ámbitos: los documentos de Qodo dicen que Get Rules "combina reglas globales, reglas específicas del repositorio y guía contextual", y sus preguntas frecuentes son explícitas en que "incluye reglas globales aplicables además de las reglas específicas del repositorio". Si solo ves reglas del repositorio, es probable que el ámbito a nivel de organización aún no esté conectado.

Vale la pena señalar lo que no hace: "¿Modifica el código Get Rules? No. Get Rules proporciona al agente la guía aplicable". Es una lectura.

Paso 3: Dile a tu archivo de instrucciones cuándo preguntar

Una herramienta que el agente nunca llama es una herramienta que no instalaste. Este es el paso que la gente se salta y luego concluye que la función no funciona.

Los documentos de Qodo son directos al respecto: "Los agentes de codificación pueden usar el Agentic Toolbox de manera más efectiva cuando sus instrucciones se incluyen en su archivo de instrucciones del agente. Agrega las instrucciones del Qodo Agentic Toolbox... a tu archivo de instrucciones del agente, como AGENTS.md o CLAUDE.md, para ayudar al agente a usar el Toolbox de manera efectiva a lo largo de su flujo de trabajo". Publican una plantilla predeterminada para esto.

La línea que importa es el activador: las reglas deben cargarse antes de que comience la implementación, no después del primer fallo. Las preguntas frecuentes de Qodo establecen la intención —"las reglas se cargan antes de que comience la implementación, lo que permite al agente usarlas mientras genera código en lugar de descubrir problemas durante la revisión"— y el punto de la entrada del archivo de instrucciones es hacer que eso sea el hábito del agente en lugar de tu recordatorio. Escríbelo como una condición previa para escribir código, no como una capacidad disponible.

Un detalle operativo: la caja de herramientas se actualiza sola. "Durante el uso interactivo, el Agentic Toolbox busca actualizaciones periódicamente e instala una versión más nueva en segundo plano", y por defecto "agrega habilidades recomendadas recientemente lanzadas a los entornos de agentes de codificación donde ya instalaste habilidades de Qodo". "No sobrescribe las habilidades que posees o has personalizado", lo cual es el comportamiento correcto, pero la superficie de la herramienta puede crecer sin que hagas nada.

Get Rules cierra el bucle sobre los estándares que pasaron por la revisión de código. Hay una segunda categoría a la que no llega, y es la que más les cuesta a los equipos.

El propio enfoque de Qodo dibuja el límite por ti. Rule Miner trabaja sobre "comentarios que fueron aceptados por los desarrolladores y llevaron a cambios en el código", dentro de una ventana indexada de aproximadamente mil pull requests fusionados. Todo lo que tu equipo decidió que nunca tomó la forma de un comentario de revisión queda fuera de eso: la llamada de arquitectura realizada en una reunión, la conclusión de un postmortem de incidente, la restricción del proveedor que impuso un cliente, el enfoque que intentaste dos veces y abandonaste por razones que ningún diff registra. Nada de eso es aplicable como una regla de revisión, y nada de eso está en la ventana.

MemoryLake contiene esa otra mitad: un almacén fuera de cualquier repositorio o plataforma de revisión, legible a través de MCP o una API por cualquier agente que esté trabajando, y construido para ser corregido en lugar de quedar silenciosamente obsoleto.

Paso 1: Crea una clave API

Genera una clave y realiza tu primera solicitud en unos treinta segundos. Una sola clave cubre cada superficie de agente que usa tu equipo, que es lo que evita que el conocimiento sea propiedad de una sola plataforma.

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que ya contienen decisiones que la revisión nunca vio: postmortems, registros de decisiones de arquitectura (ADRs), la revisión de diseño a la que todos se refieren y nadie vuelve a leer.

Paso 3: Conecta tu IA y agentes

Dale acceso a Claude, Codex, OpenClaw y otros agentes a través de MCP o la API. Combinado con Get Rules, el agente comienza una tarea con ambas mitades: los estándares que aplican tus revisiones y las decisiones que tus revisiones nunca discutieron.

Los hallazgos de revisión disminuyen por una razón aburrida: el agente deja de cometer los errores que tus revisores estaban detectando, porque se le informó sobre ellos antes de escribir nada. Qodo nombra esto como el objetivo: reglas "como barandillas de seguridad desde la primera línea de código".

La cadencia de extracción de dos semanas comienza a acumularse de manera compuesta en lugar de simplemente acumularse. Las nuevas reglas llegan al autor automáticamente en lugar de esperar a que alguien actualice un archivo de instrucciones, por lo que la brecha entre "aprendimos esto" y "el agente sabe esto" es de un ciclo de extracción en lugar de depender de un voluntario.

La incorporación (onboarding) cambia de forma. El agente de un nuevo ingeniero obtiene los mismos estándares extraídos que los de todos los demás desde el primer día, además de las decisiones que preceden a la ventana de extracción. Esa es casi toda la razón por la que "conocimiento tribal" es una frase común, y es el mismo problema que mantener el contexto de IA cuando alguien se va.

And la ventana de extracción deja de ser una responsabilidad oculta. Una vez que las decisiones más antiguas viven en un lugar que no es un índice de pull requests, no importa que hayan quedado fuera de las últimas mil fusiones.

Verifica en qué valor por defecto de activación te encuentras. Auto-approve activado significa que las reglas extraídas ya se están aplicando; auto-approve desactivado significa que están en cola en Suggestions. El comportamiento depende de cuándo se incorporó tu organización.

Lee la cola de Suggestions antes de aprobar en masa. Las reglas extraídas reflejan el comportamiento de revisión, lo que incluye preferencias del revisor que quizás no desees como estándares.

Prefiere MCP sobre un plugin de cliente único. Get Rules se distribuye como plugins de Claude Code, Codex y Kiro, además de un servidor MCP. MCP sobrevive a un cambio de editor.

Haz que la llamada a la herramienta sea una condición previa. Colócala en AGENTS.md como algo que el agente hace antes de escribir código, no como una capacidad que podría usar.

No copies a mano las reglas extraídas en archivos de instrucciones. Rule Miner sigue generando; tu copia no lo hará. Recupera en lugar de duplicar.

Rule Miner se basa en una observación correcta —que la mayoría de los estándares de ingeniería "existen solo en la memoria del revisor"— y hace algo útil con ello, convirtiendo el feedback de revisión aceptado y repetido en reglas explícitas con una ponderación sensata y una señal autocorregible. La brecha está en la ubicación. Los estándares de revisión se ejecutan en el momento de la revisión, que es el extremo incorrecto del bucle cuando el autor es un agente que no recordará haber sido corregido.

Get Rules es la pieza que lo soluciona, y la configuración consta de tres pasos reales: ver qué se ha extraído y en qué ventana, instalar la caja de herramientas y confirmar que Get Rules sea accesible a través de una interfaz que seguirás usando el próximo trimestre, y hacer que la llamada sea una condición previa en tu archivo de instrucciones en lugar de una opción.

Luego, sé honesto sobre la ventana. Mil pull requests fusionados es mucho historial de revisión y una pequeña parte de lo que sabe un equipo. Las decisiones que nunca se convirtieron en comentarios de revisión —la reunión, el incidente, la restricción del cliente, los dos intentos fallidos— son exactamente las que la gente vuelve a explicar con más frecuencia. Esas necesitan un almacén propio, y una vez que lo tienen, los estándares que aplican tus revisiones y las decisiones que tus revisiones nunca vieron llegan al mismo tiempo: antes de la primera línea de código.