ImpactGate: el merge gate que mide la deuda de cada cambio

¿Qué es ImpactGate y por qué un merge gate para el decay?

ImpactGate es una herramienta open-source del proyecto OfficeFloor que mide cuánto decay estructural introduce un cambio antes de mergeearlo al repositorio. La idea es directa: cada pull request no debería evaluarse solo por tests y linter, sino también por cuánto peso muerto le suma al código que ya existe.

La herramienta corre como:

CLI standalone (pip install impact-gate)
Git pre-commit hook local
Plugin de CI para GitHub Actions, GitLab CI y Jenkins

Cuando el impacto supera el umbral configurado, el gate puede advertir (warn) o bloquear el merge (block). El repositorio cuenta con 3 estrellas en GitHub en el momento de publicación, pero la propuesta llega en un momento donde el problema que aborda está mejor documentado que nunca.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La fórmula: por qué importar archivos nuevos es barato pero tocar god-classes duele

El impact score no es una métrica arbitraria. La fórmula expuesta en el README es:

impact = files_changed * Σ max(WMC_other, 1) * CC * Δlines (sobre funciones cambiadas)

Lo que captura cada componente:

WMC_other es la complejidad que ya vivía en el archivo antes del cambio. Se mide sobre el estado pre-cambio.
CC es la complejidad ciclomática de la función modificada.
Δlines son las líneas modificadas.
files_changed pondera la dispersión del cambio.

La consecuencia práctica: importar un archivo nuevo cuesta poco (no había nada antes), pero sumarle métodos a una clase ya pesada cuesta muchísimo. Esa asimetría es, justamente, la señal de decay que el gate quiere atrapar. Además, cuando un archivo tiene un diff mayor a max_diff_lines (200.000 por defecto), el gate lo descarta como skipped — suele ser un dump generado o un blob vendorizado — para no distorsionar el número ni frenar el scoring.

El reporte también lista los archivos candidatos a refactorizar, rankeados por su aporte al impacto. Así, un archivo que crece silenciosamente hacia god-class aparece en el radar antes de bloquear nada.

La deuda que añade la IA ya está cuantificada

ImpactGate llega cuando el mercado ya tiene data dura sobre el problema que ataca. Varios estudios publicados en 2025 y 2026 pintan el mismo cuadro:

Info-Tech Research Group publicó en agosto de 2026 el blueprint Defend Against Defects and Technical Debt in Your AI-Generated Code. Según el comunicado reportado por Yahoo Finance, "AI-generated code introduces different kinds of mistakes than humans do because the technology lacks full comprehension of business context and long-term operational impact", en palabras de Ari Glaizel, VP asociado de investigación de Info-Tech. El reporte advierte que, sin guardrails, la IA introduce problemas de calidad, seguridad y mantenibilidad en el SDLC.
Google DORA 2025, citado por Forbes en septiembre de 2026, encontró que 90% de los profesionales tech ya usan IA para escribir código, pero que mayor adopción de IA se asocia con mayor inestabilidad en entregas.
Sonar, en su encuesta 2026 también citada por Forbes, reportó que 96% de los developers dicen no confiar plenamente en el código generado por IA, pero menos de la mitad lo verifica siempre antes de commitear.
IBM research, según el mismo artículo de Forbes, concluyó que 81% de ejecutivos dice que la deuda técnica ya está limitando el éxito de la IA, con sobrecostos de 15% a 22% en cronogramas.
GitClear, reportado por The Hans India, analizó 211 millones de líneas de código y encontró que, desde que los asistentes de IA se masificaron, los bloques de código duplicado se multiplicaron por 8, mientras que el refactoring activo colapsó del 25% de líneas modificadas en 2021 a menos del 10%.
CodeRabbit, en auditorías de PRs reales citadas por The Hans India, reportó que los PR co-firmados por IA producen 1,7 veces más issues de lógica y correctitud que los hechos solo por humanos, además de 2,74 veces más vulnerabilidades de seguridad.
Cortex midió un 20% más de PRs por año atribuibles a IA, pero un 23,5% más de incidents en producción por PR.
Lightrun reportó que el 43% de los cambios generados por IA requirieron debugging directamente en producción.

Ese conjunto de datos es, justamente, lo que un merge gate como ImpactGate busca frenar antes de que se materialice en producción.

Cómo se instala y se enchufa al pipeline

La fricción cero fue una prioridad clara del diseño. Tres formas de correrlo:

1. Local, como hook de pre-commit

pip install impact-gate
impact-gate install-hook

A partir de ahí, cada commit puntúa el cambio staged contra HEAD. Con enforcement: block en .impact-gate.yml, un commit con impacto demasiado alto se rechaza antes de llegar al remoto.

2. Como CLI en cualquier CI

El binario corre en modo --mode range --base origin/main para comparar el branch contra su merge-base. El exit code 2 indica bloqueo; el 0, ok o warning.

3. Como Docker, sin instalar nada

docker run --rm -v "$PWD:/repo" ghcr.io/officefloor/impact-gate \
 score --mode range --base origin/main

Para GitHub Actions, el repo provee una composite action oficial (officefloor/ImpactGate@v0) que postea el score como comentario sticky en el PR. Para GitLab, hay un template en ci/gitlab-ci.yml que postea una nota similar en el MR si se le pasa un GITLAB_TOKEN con scope api. Para Jenkins, hay un Jenkinsfile que envuelve la imagen Docker y archiva el reporte.

Grading contra una curva en vez de un threshold fijo

Un problema clásico de los thresholds absolutos: lo que es grande en un lenguaje puede ser normal en otro. ImpactGate resuelve esto con --curve, que califica cada cambio por percentil contra dos distribuciones combinadas:

Un seed prior por lenguaje, construido sobre un corpus de 20 repos open-source (con fallback agrupado para lenguajes sin tabla propia).
El baseline propio del proyecto, que impact-gate baseline reconstruye recorriendo el historial mergeado a main.

El blend pesa el baseline del proyecto por w = n / (n + K), donde K (curve_prior_weight, default 200) es cuánta historia necesita el repo para que el seed pierda peso. Un repo nuevo sin baseline califica solo contra el seed; uno con historia profunda se califica contra sí mismo.

El archivo de configuración central es .impact-gate.yml, donde se define warn_at, block_at, enforcement, tolerance (multiplicador ajustable desde CI sin editar el repo) y los parámetros del curve.

¿Qué significa esto para tu startup?

Si tu equipo está adoptando Cursor, Copilot, Claude Code o agentes similares a velocidad, ya estás acumulando la deuda que estos estudios documentan. Un merge gate de impacto es una capa de defensa barata, en una línea de CI, que te da tres cosas concretas:

Una señal cuantificable de cuánto daño introduce cada cambio, no solo si pasa los tests. Es el equivalente, en código, a medir el blast radius antes de tirar una pared.
Ranking de archivos a refactorizar, no solo un número. Esto te da un input directo para el backlog de tu próximo sprint técnico: si un archivo aparece en el top del reporte tres PRs seguidos, es candidato a un refactor dedicado.
Una política de enforcement ajustable. Empieza en warn para ver qué pasa, calibra thresholds con datos reales, y flipa a block cuando el equipo confíe en los números.

Acciones concretas que puedes implementar esta semana:

Instala el hook local (pip install impact-gate && impact-gate install-hook) en un repo de prueba y mira qué score sacan tus últimos 5 PRs. Es la forma más barata de calibrar si tus thresholds tienen sentido.
Agrega el action de GitHub (officefloor/ImpactGate@v0) en modo warn sobre un repo no crítico. Vas a empezar a ver, en cada PR, qué archivos son los que más decay aportan. Eso te dice dónde se está concentrando la carga.
Genera tu propio baseline con impact-gate baseline --base-ref main y activa --curve. En un repo con suficiente historia, el percentil es más justo que cualquier número absoluto, especialmente en equipos multilingües.

El contexto importa: no se trata de dejar de usar IA para escribir código, sino de poner un control de calidad alrededor de ese código. Las startups que escalen sin esa capa van a pagar, según IBM, entre 15% y 22% extra en cronogramas cuando la deuda les explote.