Cada Error Se Convierte en una Regla:
Cómo diffray Aprende de Tu Feedback

Por qué la revisión de código con IA sin aprendizaje de feedback es solo un generador de ruido costoso

9 de Enero, 2026
10 min de lectura

Boris Cherny, el creador de Claude Code, reveló recientemente su flujo de trabajo, y una frase de su hilo explotó en la comunidad de desarrolladores: "Cada vez que vemos a Claude hacer algo incorrecto, lo añadimos al CLAUDE.md, para que Claude sepa no hacerlo la próxima vez."

El líder de producto Aakash Gupta lo resumió perfectamente: "Cada error se convierte en una regla." Cuanto más tiempo trabaja un equipo con IA, más inteligente se vuelve.

Esta es exactamente la filosofía sobre la que está construido diffray. Hoy te mostraremos cómo funciona internamente.

El Problema: La Contaminación del Contexto Mata la Calidad de la Revisión

Antes de hablar sobre reglas, necesitamos entender el principal desafío técnico de la revisión de código con IA — la contaminación del contexto.

La investigación de Anthropic muestra que los LLMs, como los humanos, pierden el enfoque a medida que la ventana de contexto se llena. Las correcciones se acumulan, las discusiones secundarias se apilan, las salidas de herramientas obsoletas permanecen. El resultado es predecible:

Falsos positivos

La IA encuentra "problemas" que no existen

Alucinaciones

Bugs imaginarios y patrones inexistentes

Deriva de objetivos

Las revisiones se vuelven progresivamente menos relevantes

JetBrains Research (Diciembre 2025) cuantificó esto: los contextos de agentes crecen tan rápidamente que se vuelven costosos, pero no ofrecen un rendimiento de tareas significativamente mejor. Más contexto ≠ mejores resultados.

La Solución: Subagentes Especializados con Contexto Aislado

Boris Cherny usa subagentes como "encapsulaciones automatizadas de los flujos de trabajo más comunes." Su filosofía:

"La fiabilidad viene de la especialización más la restricción"

En lugar de un revisor omnisciente, su comando de revisión de código genera múltiples agentes paralelos con responsabilidades distintas:

1.Un agente verifica las guías de estilo
2.Otro analiza el historial del proyecto para entender patrones
3.Un tercero señala bugs obvios
4.Luego cinco agentes adicionales específicamente encuentran fallas en los hallazgos iniciales

Esta capa adversarial es crucial. Los agentes secundarios desafían los hallazgos del primer pase, eliminando falsos positivos a través del escepticismo estructurado.

El resultado, en palabras de Cherny: "encuentra todos los problemas reales sin los falsos."

Cómo Funciona Técnicamente

Cuando el agente principal delega a un subagente, se genera una ventana de contexto nueva que contiene solo la descripción de la tarea y los parámetros relevantes. El subagente puede explorar extensivamente—consumiendo decenas de miles de tokens buscando código—pero devuelve solo un resumen condensado de 1,000-2,000 tokens.

Esto preserva el enfoque del agente principal mientras permite un análisis profundo.

Agente Principal(contexto limpio)
🛡️
Seguridad
contexto aislado
Estilo
contexto aislado
Rendimiento
contexto aislado
🏗️
Arquitectura
contexto aislado
Resúmenes condensados(1-2K tokens cada uno)

En diffray, usamos más de 30 agentes especializados, cada uno enfocado en un dominio específico: seguridad, rendimiento, estilo de código, patrones arquitectónicos, y más. Cada agente opera en un contexto aislado y devuelve solo hallazgos sustanciales.

Creación de Reglas: Convirtiendo Feedback en Conocimiento

Ahora el evento principal. Los subagentes resuelven el problema del contexto. Pero ¿cómo haces que la IA aprenda de tus correcciones?

El Patrón CLAUDE.md

En Claude Code, los equipos mantienen un archivo CLAUDE.md en su repositorio—una especie de "constitución" para el proyecto. El archivo se carga automáticamente en contexto en cada sesión.

Pero hay una limitación crítica. La investigación de HumanLayer muestra que el prompt del sistema de Claude Code ya contiene ~50 instrucciones, y los LLMs de frontera siguen de manera confiable solo 150-200 instrucciones en total. La calidad de seguimiento de instrucciones disminuye uniformemente a medida que aumenta el conteo.

Esto significa: no puedes simplemente volcar 500 reglas y esperar magia.

Tres Niveles de Conocimiento

Las reglas efectivas codifican conocimiento en tres niveles:

QUÉ (Mapa del Proyecto)

## Stack Tecnológico
- Backend: Python 3.11, FastAPI, SQLAlchemy
- Frontend: React 18, TypeScript, TailwindCSS
- BD: PostgreSQL 15

POR QUÉ (Decisiones Arquitectónicas)

## Por Qué NO Usamos ORM para Consultas Complejas
Historial: ORM generaba consultas N+1 en reportes.
Decisión: SQL crudo para analytics, ORM solo para CRUD.

CÓMO (Procesos)

## Antes de Hacer Commit
- Ejecutar `make lint` — debe pasar sin errores
- Ejecutar `make test` — la cobertura no debe bajar

El Problema con los Enfoques Manuales

El mantenimiento manual de reglas funciona... mientras tu equipo sea pequeño y disciplinado. En realidad:

Los desarrolladores olvidan actualizar las reglas

Las reglas se vuelven obsoletas más rápido que el código

Las convenciones implícitas permanecen implícitas

El conocimiento tribal muere cuando las personas clave se van

Cómo diffray Automatiza la Creación de Reglas

diffray invierte el proceso. En lugar de escribir reglas manualmente, simplemente das feedback en las revisiones.

El Ciclo de Aprendizaje

📝
PR
🔍
Revisión diffray
💬
Feedback del Dev
🧠
Análisis
🔬Extracción de Patrones
¿Qué estuvo mal?
⚙️Generación de Reglas
Crear regla específica
Validación
Probar en historial de PR
El próximo PR incorpora la regla

Paso 1: Das Feedback

¿Diste un pulgar abajo a un comentario de diffray? ¿Respondiste "esto no es un bug, es intencional"? ¿Ignoraste una recomendación? diffray captura todo.

Paso 2: Extracción de Patrones

diffray analiza: ¿qué estuvo mal exactamente? ¿Fue una falsa alarma (el código está correcto), contexto inaplicable (la regla no aplica aquí), o convención específica del proyecto (así lo hacemos aquí)?

Paso 3: Generación de Reglas

Basado en el patrón, diffray formula una regla que especifica el alcance (qué archivos/directorios), qué suprimir o aplicar, y por qué. La regla se vincula al feedback original para trazabilidad.

Paso 4: Validación

Antes de aplicar la regla, diffray la ejecuta contra PRs históricos. ¿Cuántos comentarios se habrían suprimido? ¿Cuántos de esos fueron realmente falsos positivos? La regla se aplica solo si mejora la precisión.

Tipos de Reglas en diffray

🚫

Reglas de Supresión

"No marcar X en contexto Y" — silenciar advertencias específicas en código legacy, archivos de test, o código generado.

🛡️

Reglas de Aplicación

"Siempre verificar Z" — asegurar que patrones críticos como parametrización SQL o verificaciones de auth nunca se pasen por alto.

🎯

Reglas de Contexto

"Considerar las especificidades" — ajustar prioridad basado en tipo de archivo, decoradores, o patrones de código circundante.

📖

Reglas de Terminología

"Lo llamamos así" — enseñar a diffray tu vocabulario de dominio para que entienda mejor tu base de código.

Ejemplo Práctico: De Molestia a Regla

Imagina: diffray deja un comentario en tu PR:

Advertencia Rendimiento: Usar any reduce la seguridad de tipos. Considera tipado explícito.

Sabes que este es un módulo legacy programado para reescritura el próximo trimestre. Arreglar los tipos ahora sería una pérdida de tiempo.

Respondes: "Esto es legacy, el tipado se abordará durante la refactorización del Q2"

Lo que sucede después:

1.diffray reconoce el feedback negativo
2.Analiza el contexto: el archivo está en src/legacy/, hay un TODO con fecha
3.Encuentra casos similares en el historial: 12 comentarios análogos en el último mes
4.Genera una regla de supresión para src/legacy/** con fecha de expiración (Q2)
5.El próximo PR en src/legacy/ — diffray permanece en silencio sobre tipos

Pero importante: la regla no es permanente. La fecha de expiración significa que después del Q2, diffray comenzará a verificar tipos en ese directorio nuevamente.

La Métrica: Reduciendo la Tasa de Falsos Positivos

La medida clave de la efectividad de la revisión de código con IA es la tasa de falsos positivos. ¿Cuántos comentarios de 100 fueron inútiles?

Benchmarks típicos de la industria:

40-60%

Falsos positivos de revisión IA base

25-35%

Con reglas manuales

8-13%

diffray con reglas aprendidas

Cómo lo logramos:

Aislamiento de contexto

A través de subagentes previene la deriva

Especialización de agentes

Mejora la precisión en cada dominio

Aprendizaje del feedback

Elimina falsos positivos recurrentes

Validación de reglas

Previene el sobreajuste

Comenzando: Tres Pasos

Paso 1: Conecta diffray a Tu Repositorio

La integración toma 5 minutos vía GitHub App o webhook de GitLab.

Paso 2: Solo Trabaja

Durante las primeras 2-3 semanas, diffray opera en modo de aprendizaje. Estudia la estructura de tu proyecto, tus patrones de PR, y el estilo de comentarios de tus revisores.

Paso 3: Da Feedback

No ignores silenciosamente los comentarios de diffray. Da pulgar arriba a los útiles, pulgar abajo a los inútiles, responde a los debatibles.

Cada interacción hace a diffray más inteligente. Después de un mes, tendrás un revisor de IA personalizado que conoce tus convenciones mejor que un nuevo desarrollador después del onboarding.

Conclusión: IA Que Crece con Tu Equipo

La filosofía de "cada error se convierte en una regla" no es solo una frase pegadiza. Es un principio arquitectónico que separa las herramientas de juguete de las soluciones listas para producción.

diffray está construido sobre tres pilares:

Subagentes con contexto aislado

Para precisión sin contaminación

Creación de reglas desde feedback

Para aprendizaje sin trabajo manual

Validación en historial

Para confianza en mejoras

El resultado: revisión de código con IA que mejora con cada PR. No porque el modelo se actualizó, sino porque aprende de tu equipo.

Comienza a Enseñar a Tu Revisor de IA Hoy

Instala diffray y abre un PR. Es gratis para repos públicos e incluye un generoso nivel gratuito para repos privados.

Artículos Relacionados