Resumen

Este generador de informes con IA estima cuánto tarda un ingeniero nuevo en enviar su primer PR relevante y qué tan arriesgado es trabajar en un codebase, a partir de cinco datos: líneas de código, colaboradores activos, cobertura de tests, antigüedad del código y tipado. La fórmula es una heurística transparente basada en estudios publicados de code review y encuestas a developers (Google y SmartBear sobre tamaño de review, el informe Developer Coefficient de Stripe), no una caja negra. Todo corre en el cliente: nada de tu codebase se envía a ningún sitio.

Un generador de informes de código con IA para el onboarding y el riesgo

Introduce líneas de código, cobertura de tests, tamaño de equipo y antigüedad. Obtén un informe en español claro que puedes pegar en una descripción de PR o en un hilo de Slack: sin registro, sin llamadas al servidor.

Probarlo ahora

Generador de Informes de Código con IA

Introduce los datos de tu codebase abajo. El informe se actualiza en vivo y puedes copiarlo como texto plano.

Tiempo de onboarding estimado -
Puntuación de riesgo del código - -

Qué arreglar primero

    Cómo funciona el informe

    Qué entra en la estimación

    Tamaño y cobertura

    El tiempo de onboarding escala con las líneas de código y empeora claramente por debajo del 50% de cobertura de tests: revisores y nuevos ingresos acaban leyendo la implementación línea a línea en vez de confiar en la suite para saber qué sigue funcionando.

    Capacidad del equipo

    Los equipos con menos de 5 colaboradores activos no tienen red de seguridad informal: una pregunta sin dueño claro se queda un día entero en un DM. Pasados los 15 colaboradores, la capacidad de mentoría deja de ser el cuello de botella y el propio codebase toma el relevo como factor limitante.

    Antigüedad y tipado

    Los codebases de más de 3 a 7 años acumulan conocimiento tribal que nunca llegó a los comentarios ni a la documentación: convenciones de nombres, módulos obsoletos que nadie borró, workarounds de un bug ya arreglado en otro sitio. El tipado estático (TypeScript, Go, Rust, Java) recorta el tiempo de rampa frente a los lenguajes dinámicos porque los tipos hacen de documentación.

    Lee la sala antes de asignar el ticket

    Una puntuación de riesgo es el punto de partida de una conversación con tu equipo sobre dónde están los cuellos de botella reales, no un veredicto grabado en piedra: úsala para decidir qué arreglar antes de que empiece el próximo ingreso, no para puntuar a los ingenieros.

    Primer plano de manos escribiendo en un teclado con una laptop mostrando widgets de informe abstractos y difuminados

    Preguntas frecuentes

    ¿Es gratis usarlo?
    Sí. El generador de informes corre íntegramente en tu navegador: no hay registro, no hay muro de pago y no se envía ningún dato a un servidor para calcular la estimación.
    ¿De dónde salen estos benchmarks?
    La fórmula es una heurística transparente, no un modelo revisado por pares. La recomendación sobre el tamaño de review (PRs de menos de unas 400 líneas, la efectividad cae tras unos 60 minutos de lectura continua) viene de la documentación de prácticas de ingeniería de Google y del estudio de code review de SmartBear/Cisco. El tamaño de las penalizaciones por cobertura y antigüedad se apoya en el informe Developer Coefficient de Stripe, que encontró que los ingenieros dedican buena parte de su semana a código malo y trabajo de mantenimiento. Lo llamamos heurística a propósito: trata el número como orientativo, no como algo exacto.
    ¿Se envían a algún sitio los datos de mi codebase?
    No. Cada dato que introduces se queda en tu navegador y el cálculo corre en JavaScript en tu propio dispositivo. La única actividad de red es un ping anónimo que cuenta cuántas veces se usa el widget, sin ningún detalle de tu código adjunto.
    ¿Esto sustituye a un plan de onboarding real?
    No. Te da un número de partida para planificar: una cifra de días y un nivel de riesgo. Combínalo con un checklist de onboarding de verdad, un mentor asignado y una lista de lectura de la primera semana construida a partir de tu propio repo.
    ¿Por qué me salió un riesgo más alto de lo esperado?
    Tres factores lo disparan más rápido: cobertura de tests por debajo del 30%, un codebase con más de 7 años, y una proporción alta de líneas de código por ingeniero. Revisa esos tres primero: normalmente son los que puedes arreglar este mismo trimestre.
    ¿Qué pasa si mi repo es un monorepo con varios lenguajes?
    Calcula los números para el lenguaje y el área que va a tocar de verdad un nuevo ingreso, no para todo el monorepo. Un monorepo de 2 millones de líneas donde un junior solo trabaja en un servicio de 40K líneas debería puntuarse por ese servicio, no por el repo entero.
    ¿Puedo usar esto también para planificar la capacidad de code review?
    En parte. La puntuación de riesgo se correlaciona con la carga de review (un codebase de alto riesgo suele significar reviews más lentas y más caras), pero no sustituye a medir de verdad el tiempo de ciclo de tus PRs en tu propio panel de métricas.
    ¿En qué se diferencia la puntuación de riesgo de la estimación de onboarding?
    El tiempo de onboarding responde a cuánto tarda en ser productivo un ingeniero nuevo. La puntuación de riesgo responde a qué tan frágil es el codebase en general: la cobertura de tests baja y un código envejecido y concentrado suben el riesgo incluso para quienes ya llevan años ahí.

    Convierte este informe en un deck de onboarding

    Skywork convierte notas sueltas en slides, documentos y diagramas: útil para el paquete de onboarding que nadie tiene tiempo de diseñar a mano cuando un nuevo ingeniero empieza el lunes.