¿Cómo evaluar la calidad de código de un squad antes de contratarlo?

Evaluar la calidad de código de un squad antes de contratarlo significa medir señales objetivas —cobertura de tests, code churn, densidad de código duplicado, tiempo real de code review— en vez de confiar en un portfolio prolijo o en una sola entrevista técnica. Hacerlo bien importa más que antes: con cada vez más código escrito o asistido por IA, la línea entre “funciona” y “es mantenible” se volvió más difícil de ver a simple vista.

Esto no es un matiz técnico menor. Según la 2025 Developer Survey de Stack Overflow, el 84% de los desarrolladores ya usa o planea usar herramientas de IA para programar —pero la confianza en la precisión de ese código cayó del 40% al 29% en el mismo período, y el 66% señala que el problema más frecuente es código que queda “casi bien, pero no del todo”. Un squad puede estar generando más código que nunca y, al mismo tiempo, generando más trabajo de corrección del que parece a simple vista.

¿Por qué la calidad de código es más difícil de evaluar ahora que hace dos años?

Porque el volumen de código ya no dice nada por sí solo. GitClear analizó más de 211 millones de líneas de código en su AI Copilot Code Quality Research 2025 y encontró que la frecuencia de bloques de código duplicado se multiplicó por ocho durante 2024, que el code churn —código reescrito a los pocos días de haberse escrito— pasó de un piso histórico de 3,3% a 7,1% en 2025, y que el código refactorizado cayó de un 25% de las líneas modificadas en 2021 a menos del 10% en 2024. Por primera vez en la serie de GitClear, hubo más código copiado y pegado que código movido o reorganizado con criterio.

¿Un squad que entrega más rápido con IA entrega necesariamente mejor?

No necesariamente, y ahí está la trampa de mirar solo la velocidad. El informe Acceleration Whiplash de Faros AI, sobre telemetría real de 22.000 desarrolladores en más de 4.000 equipos, encontró que la adopción de IA subió un 34% las tareas completadas por desarrollador —pero también subió un 54% los bugs por desarrollador, más que triplicó la proporción de incidentes por pull request, y multiplicó por cinco el tiempo mediano de revisión de código. Un squad puede parecer más productivo en la superficie y estar generando, al mismo tiempo, más deuda técnica de la que factura.

¿Qué métricas de calidad de código sí sirven para evaluar un squad antes de contratarlo?

Ninguna métrica sola alcanza, pero combinadas dan una foto bastante más confiable que un portfolio:

• Cobertura de tests, y si esos tests corren en cada pull request —no solo cuando alguien se acuerda de correrlos.
• Code churn: qué porcentaje del código escrito se reescribe a los pocos días. Un piso normal existe; un salto sostenido es señal de apuro, no de iteración sana.
• Densidad de duplicación: cuánto del código nuevo es una variación de algo que ya existía en el repo, en vez de una solución pensada para ese caso puntual.
• Tiempo real de code review: si un segundo par de ojos revisa antes de mergear, y cuánto tarda en hacerlo —no si la política existe en el papel.
• Densidad de bugs encontrados después del merge, no solo durante el desarrollo, que es cuando son más baratos de arreglar.

¿Cómo se audita esto sin pedirle al squad que se autoevalúe?

Mirando el historial real en el repositorio, no una demo armada para la entrevista. Un commit con fecha y autoría dice más que un caso de éxito bien redactado, porque no depende de que alguien lo escriba a favor del squad —o el patrón está en el historial, o no está.

Cómo lo resuelve Zenit

En vez de pedirle a la empresa que audite manualmente el código de cada squad, ZenitRank cruza esas señales —código real en GitHub, cumplimiento de milestones, disputas resueltas— en un puntaje que se actualiza solo con cada entrega, no con lo que el squad dice de sí mismo en una llamada de ventas.

Y antes de llegar a esa instancia, Kaizen ya entendió el proyecto real —no un brief genérico— así que el match prioriza al squad con historial verificable frente a proyectos comparables, no al que arma la mejor demo.

La pregunta que importa no cambió con la IA, se volvió más urgente: no es cuánto código produce un equipo, es si ese código se puede sostener seis meses después de la entrega —y esa respuesta nunca está en el portfolio, está en el historial.