Tu evaluación de rendimiento es una prueba de memoria

Pregúntale a cualquier engineering manager quién es su mejor ingeniero. Observa lo rápido que llega la respuesta. No hay duda, ni matiz, ni un “déjame comprobarlo primero”. Lo saben. Siempre lo han sabido.

Ahora pídeles que muestren el trabajo.

Obtendrás una historia. Una buena historia, por lo general, sobre un incidente que alguien manejó a las 2 de la mañana, o una refactorización que desbloqueó un trimestre, o la persona que siempre responde en el canal. Lo que no obtendrás es un número, ni una comparación, ni ningún registro de los cuatro ingenieros cuyo trabajo el manager no presenció. La confianza nunca se basó en mediciones. Se basó en el recuerdo, y el recuerdo es función de la proximidad.

Esta es la tesis, y todo lo que sigue es evidencia de ella. El rendimiento en ingeniería se juzga desde la memoria, la memoria recompensa la visibilidad por encima del valor, y lo que realmente quieres que la gente construya está escrito en un roadmap que nunca está conectado con aquello por lo que los evalúas. Esos dos documentos, el roadmap y la revisión de desempeño, no tienen nada que ver entre sí en casi todas las empresas que he visto, incluida la mía hasta hace poco.

Así que los conectamos. Cada pull request fusionado es leído por un modelo, se le asigna una severidad y se multiplica por lo mucho que nuestro roadmap se preocupa por el componente que tocó. El resultado es una tabla de clasificación mensual, y alimenta las decisiones de bonificaciones.

Voy a mostrarte la nuestra, incluyendo las partes en las que es embarazosa y las partes en las que es incorrecta.

La sabiduría recibida dice que esto no se puede medir, y la sabiduría recibida es un encogimiento de hombros

La postura estándar sobre medir el rendimiento individual en ingeniería es que no debes hacerlo, porque cualquier proxy es una trampa. Las líneas de código recompensan la hinchazón. El recuento de commits recompensa la división. Los story points son una negociación, no una medición. Incluso los buenos marcos son deliberadamente a nivel de equipo: DORA mide cuatro cosas sobre un pipeline de entrega y no dice nada sobre las personas, lo cual es una decisión de diseño que sus autores explicitan.

Todo eso es correcto, y nada de eso es una respuesta. Negarse a medir no produce una empresa donde nadie sea clasificado. Produce una empresa donde todo el mundo es clasificado de todas formas, por un mecanismo sin rastro de auditoría. La clasificación sigue ocurriendo en el momento de la compensación. Solo que ocurre en una sala, desde la memoria, ponderada por con quién pasó más tiempo la persona en la sala.

Llamémoslo la prima del ingeniero ruidoso: la brecha entre lo bien que te evalúan y lo bien que te desempeñaste, explicada enteramente por tu distancia de quien escribe tu revisión. No es un defecto de carácter en los managers. Es el resultado predecible de pedirle a un humano que compare las contribuciones técnicas de quince personas a lo largo de un año usando solo lo que lograron notar.

La prima era inevitable hasta hace unos dos años, porque la materia prima para una mejor respuesta era un montón de diffs que nadie tenía tiempo de leer. Esa restricción ha desaparecido. Un modelo puede leer todos los diffs de tu repositorio cada mes por menos del costo de una hora de la reunión en la que actualmente adivinas.

Leerlos es la parte fácil. Decidir cuánto vale la lectura es todo el problema, y eso no es una cuestión técnica.

La fórmula completa cabe en una línea

Aquí está, completa, desde la ruta de puntuación en GitRank:

final_score = is_eligible ? severity_base_points × component_multiplier : 0

Eso no es una simplificación para el blog. Esa es la línea. No hay regresión oculta, ni ponderación aprendida, ni término de reputación, ni ajuste por antigüedad. Severidad por importancia, o cero.

La mitad de la severidad es una escalera fija. Cuatro niveles, cuatro valores de puntos, establecidos una vez y visibles para todos los evaluados:

Una corrección crítica vale veinte de baja prioridad. Esa proporción es una declaración de política, y la escribimos en lugar de dejarla en la cabeza de alguien.

La mitad de la importancia es la parte que realmente importa, y es la razón por la que creo que este enfoque se generaliza. Cada componente del repositorio lleva un multiplicador, y el multiplicador lo establece lo que el producto necesita este trimestre:

Chat es 2.0x porque el chat es en lo que estamos apostando el producto. Autenticación es 1.0x porque funciona y nos gustaría que siguiera funcionando sin problemas. Las funciones de colaboración y el resaltado de documentos son 2.0x por la misma razón que el chat. Ninguno de esos números son juicios técnicos. Son el roadmap, reescrito en un campo que paga.

Este es el movimiento. No el modelo, ni la tabla de clasificación, ni la gamificación. El movimiento es que el documento de estrategia y el insumo de compensación se convirtieron en el mismo documento. Si el roadmap cambia en octubre, los multiplicadores cambian en octubre, y el incentivo cambia en octubre en lugar de en el próximo ciclo de revisión anual dentro de catorce meses.

Déjame explicarlo claramente, porque es la parte que la gente se salta. El problema difícil en una organización de ingeniería en crecimiento nunca fue que la gente sea perezosa. Es que cuarenta personas inteligentes, cada una optimizando local y honestamente, producirán colectivamente una cuarta parte del trabajo que no suma lo que la empresa dijo que quería. La gerencia media existe en gran parte para solucionar eso llevando la estrategia en conversaciones, de escritorio en escritorio, perdiendo fidelidad en cada salto. Una tabla de multiplicadores hace el mismo trabajo de enrutamiento en un solo salto y no se cansa, no tiene favoritos y no olvida lo que le dijiste en enero.

Una corrección crítica en el chat vale cuarenta commits de pulido en la API

Ejecuta las dos mitades juntas y la dispersión es severa.

Un P0 en el chat obtiene 100 base por 2.0, es decir, 200 puntos. Un P3 en la API obtiene 5 base por 1.0, es decir, 5 puntos. La solicitud de extracción individual más valiosa que puedes fusionar aquí vale cuarenta de las menos valiosas. No un cuarenta por ciento más. Cuarenta veces.

Ese número es deliberadamente violento, y hace lo que los incentivos suaves nunca logran. Nadie reorganiza su semana por una diferencia del 15%. La gente reorganiza absolutamente su semana por una de 40x.

Mira lo que le sucede a una semana real bajo esos pesos. Aquí está la distribución de severidad a lo largo de cinco semanas, con la semana del 13 de julio expandida:

188 solicitudes de extracción. P2 es el 59% de ellas, que es lo que parece una semana normal de ingeniería en todas partes: principalmente correcciones de tamaño mediano con una solución alternativa disponible.

Ahora pondéralo. Esos 111 P2 valen 2,220 puntos a 1x. Los 50 P1 valen 2,500. Menos de la mitad de las solicitudes de extracción llevan más de la mitad del valor de la semana, y el único P0 vale tanto como veinte de los P3 que un recuento bruto de commits habría tratado como trabajo idéntico.

Ese es el argumento completo para la ponderación, en una semana de datos reales. Cuenta las solicitudes de extracción y concluyes que la semana fue sobre P2. Pondéralas y descubres que la semana fue sobre cincuenta piezas específicas de trabajo, y puedes nombrar quién las hizo.

Dos personas fueron el 58% de la producción, y no habría adivinado el orden

Volvamos al marcador, porque aquí es donde dejé de confiar en mi propia intuición.

Siete desarrolladores, 10,415 puntos en la ventana de 30 días. El desarrollador principal tiene 3,530 de ellos, que es el 33.9% de todo lo que el equipo produjo en valor. Los dos primeros tienen el 57.7% entre ellos.

Quiero ser cuidadoso sobre lo que eso significa y no significa. No significa que los otros cinco estén rindiendo por debajo, y si lo lees así, has aprendido la lección equivocada de esta publicación. Una concentración así generalmente significa que los dos primeros están trabajando en los componentes de mayor multiplicador, que es exactamente para lo que está diseñado el sistema y exactamente lo que les pedimos que hicieran. El número es una descripción de dónde está aterrizando el valor, no un veredicto sobre cinco personas.

Pero mira el orden, porque rompió mi predicción. Aquí está quién posee qué:

Mulualem-E es el experto principal en chat, nuestro componente 2.0x, con 71 de sus 230 solicitudes de extracción. También es el experto principal en agents, nuestro componente 1.5x, con 86 de 148, o el 58% de esa área. Si me hubieras descrito eso y me hubieras preguntado quién encabeza el marcador, lo habría dicho sin dudar. Él es segundo.

El primer lugar es para tugberkayartextcortex, con 31 solicitudes de extracción P1 frente a las 12 de Mulualem-E. La mezcla de severidad superó la propiedad del componente. Ser dueño del área más importante del producto no es lo mismo que aterrizar repetidamente trabajo de alto impacto en ella, y hasta que publicamos esto no podría haberte dicho cuál de esas dos cosas estaba recompensando realmente nuestra compensación. Estaba recompensando la que yo había notado.

Esa es la prima del ingeniero ruidoso, atrapado en el acto, en mi propia empresa. Mi intuición tenía a las dos personas correctas y el orden incorrecto, y el orden incorrecto es lo que es un bono.

La persona que escribió más código está en último lugar

Ahora el hallazgo que me incomodó, que es el que quiero que realmente consideres.

karthikmudunuri es el experto principal en el presentation maker, con 51 de las 58 solicitudes de extracción de ese componente. Eso es el 88% de un área de producto completa. El volumen no es su problema. Él es el último en el marcador, con 300 puntos.

Hay una combinación que da exactamente ese número: cuatro solicitudes de extracción P1 en un componente 1.5x, y nada más que puntúe. 4 × 50 × 1.5 = 300. Su insignia dice 4 P1, lo que encaja. No puedo probar que esa sea la descomposición real de este panel, y quiero señalar la imprecisión honestamente, porque el marcador cubre 30 días mientras que los gráficos de componentes cubren del 6 de julio al 3 de agosto, por lo que las dos ventanas son cercanas pero no idénticas.

Si la descomposición es correcta, aproximadamente 47 pull requests fusionados produjeron cero puntos. Solo hay dos explicaciones. O bien eran pulidos genuinamente de baja severidad, en cuyo caso la puntuación es correcta y la conversación útil es sobre si deberíamos tener a una persona dedicando un mes al 88% de concentración en un componente que no hemos marcado como importante. O bien eran trabajo real que la puerta de elegibilidad anuló, en cuyo caso la puntuación es incorrecta y la herramienta le debe una explicación.

La puntuación es todo o nada en cuanto a elegibilidad. Si fallas un criterio habilitado, y el conjunto predeterminado es vinculación con el issue, implementación de la corrección, calidad de la descripción del PR, pruebas donde el modelo juzga que se requieren pruebas, y un límite de 3000 líneas, la puntuación es cero independientemente de la severidad. Una corrección realmente crítica con una mala descripción puntúa igual que nada en absoluto.

No sé cuál explicación es la correcta, y aquí está mi queja real: el panel debería poder decirme, por pull request, y hoy me obliga a hacer ingeniería inversa a partir de un total. Eso es una brecha real en nuestro producto y se está solucionando. También es el modo de fallo exacto que la gente teme de los sistemas de puntuación, así que no voy a fingir que lo encontré en una revisión de diseño. Lo encontré mientras escribía esta publicación.

Dónde están los bugs es una decisión de producto, no de ingeniería

La otra cosa que se desprende de puntuar cada pull request es que dejas de discutir sobre la calidad a partir de anécdotas.

740 pull requests en los diez componentes más activos. 230 de ellos, el 31%, eran correcciones de bugs en lugar de trabajo nuevo. Solo Chat tiene 230 pull requests, otro 31%, que es lo que se supone que debe verse cuando un multiplicador 2.0x está funcionando.

Luego está el presentation maker: 58 pull requests, 23 de ellos bugs. Eso es una tasa de bugs del 40% en un componente con cuatro contribuidores, frente al 25% en chat con siete. Y payments tiene 44 pull requests con 20 bugs, una tasa del 45%, en el componente que maneja dinero.

Chat y agents están empatados con 57 bugs cada uno, pero chat produjo esos a lo largo de 230 pull requests y agents a lo largo de 148. Misma cantidad de bugs, un 55% más de trabajo detrás de uno de ellos. Esa es una señal sobre agents que ninguna retrospectiva iba a sacar a la luz, porque ninguna persona individual en el equipo fusionó suficientes de ambos para notarlo.

La línea de bugs y la línea de funcionalidades suben juntas a lo largo de la ventana en lugar de compensarse, que es la forma que quieres y no la forma que esperaba. Estoy interpretando ese gráfico como descriptivo, no como una afirmación de que mejoramos algo. Cubre cinco semanas y la tendencia está dentro del ruido que obtendrías de un solo proyecto grande que aterriza.

Aquí es donde nuestra propia herramienta está actualmente equivocada

Si solo te mostrara las partes que funcionan, tendrías razón para descartarlo todo. Así que:

• La pestaña de prompt no hace lo que dice en la ruta de producción. Hay una pantalla de administración que te permite personalizar el prompt de evaluación. Impulsa el ejecutor de evaluación por lotes. La ruta de webhook y cron que puntúa pull requests en producción usa un prompt hardcodeado en el código fuente. Si editas esa plantilla esperando que cambie tus puntuaciones en vivo hoy, no lo hará, y nada en la interfaz te lo dice.

• La columna de la tabla de clasificación del panel etiquetada como “PRs” no es un conteo de pull requests. Es la puntuación de autoría. Puedes verlo en la captura de pantalla anterior: la fila superior muestra 3530 en PRs y 3530 en Score. La página independiente de la tabla de clasificación lo hace bien, con columnas separadas para pull requests y autoría, por lo que es una etiqueta incorrecta en la única pantalla que todos abren realmente, que es casi el peor lugar para tener una.

• Nuestro README publica valores de puntos incorrectos. Dice que P2 son 25 puntos y P3 son 10. La base de datos siembra 20 y 5, y la captura de pantalla de configuración anterior confirma 20 y 5. La documentación y el software no están de acuerdo sobre la puntuación, y el software gana.

• El track de revisiones está casi muerto. Revisar el código de otras personas gana puntos en una escalera de velocidad separada, las revisiones más rápidas puntúan más alto. En toda esa tabla de clasificación, exactamente una persona tiene algún punto de revisión: 90 de 10,415 totales, o el 0.86% de todo lo puntuado. Sea lo que sea que pensemos que estamos incentivando sobre la revisión de código, no lo estamos. La razón más probable es que la sincronización de revisiones solo comenzó a recolectar recientemente, pero no lo he confirmado, y hasta que lo haga, la lectura honesta es que la funcionalidad no está aterrizando.

• Nuestro propio FAQ afirma aproximadamente un 90% de precisión de clasificación y no puedo respaldarlo. No hay un conjunto de evaluación en el repositorio, ni un script de benchmark, ni un corpus adjudicado detrás de ese número. Es una afirmación que no aceptaría de un proveedor, y está en nuestra propia página de marketing. Va a desaparecer.

Un marcador se manipula, y el nuestro casi no tiene defensas

Busqué en nuestro código de puntuación medidas anti-manipulación. Aquí está la lista completa de lo que existe.

Las solicitudes de extracción con más de 3.000 líneas modificadas no son elegibles, lo que detiene la forma más burda de inflar puntuaciones. Las auto-revisiones puntúan cero y se excluyen de toda consulta del marcador. Las revisiones de cuentas con [bot] en el inicio de sesión se omiten. Se le pregunta al modelo si el código realmente hace lo que la descripción afirma, que es lo más parecido a un detector de sinsentidos. Los administradores pueden anular cualquier puntuación, y la anulación requiere una razón escrita de al menos diez caracteres.

Esto es lo que no existe. No hay un límite de puntos semanal o mensual por persona. No hay rendimientos decrecientes por trabajo repetido en el mismo componente. No hay decadencia temporal de ningún tipo, y la ventana de 30 días en el leaderboard es un rango de fechas predeterminado que cualquiera puede ampliar, no un límite. No hay detección de duplicados o reversiones, así que arreglar algo que rompiste la semana pasada puntúa igual que arreglar algo que rompió otro. No hay detección de colusión entre revisores. Y el filtro de bots se aplica a los revisores pero no a los autores de pull requests, así que un pull request fusionado escrito por un bot puntúa como uno humano, lo cual en 2026 no es una hipótesis.

Cualquiera que esté decidido a explotar este sistema puede hacerlo. Dividir el trabajo en más pull requests, cada una con un enlace a un issue y una descripción limpia, apuntando al componente 2.0x. Ese es el exploit, y quiero nombrarlo precisamente por lo que parece: parece cambios pequeños, bien documentados y bien probados en la parte más importante del producto. La forma más efectiva de engañar a nuestro marcador es hacer lo que queremos. Eso no es un accidente, es el objetivo de diseño, y es la única defensa contra la ley de Goodhart que realmente ha funcionado. Haz que el proxy sea caro de falsificar de cualquier manera que no sea lo real.

No es una defensa completa. La gravedad la asigna un modelo que lee un diff, y se puede convencer a un modelo de que llame a un error medio como alto mediante una descripción de pull request suficientemente dramática. No hemos medido con qué frecuencia ocurre eso. Nadie lo ha hecho. Si estás evaluando cualquier herramienta en esta categoría, incluida la nuestra, esa es la pregunta que hay que hacer, y “aproximadamente el 90%” no es una respuesta.

No voy a darte el número de mejora, porque no tengo uno

Esta es la afirmación que me gustaría hacer. Desde que empezamos a publicar este leaderboard mensualmente, el trabajo se ha desplazado visiblemente hacia los componentes que marcamos como importantes, porque los ingenieros quieren la puntuación.

He aquí por qué no lo estoy presentando como un número. Activamos esto a mitad de camino, sin una línea base limpia, sin un repositorio de control y sin una definición preregistrada de lo que significaría “desplazado”. Los multiplicadores cambiaron durante el período. También lo hicieron la plantilla y la hoja de ruta. Cualquier porcentaje que publicara sería un número que elegí después de ver los datos, lo cual no es una medición, es un adorno.

Lo que puedo decirte es cualitativo y lo etiqueto como tal. Los argumentos cambiaron. La gente dejó de preguntarme si su trabajo era apreciado y empezó a preguntar por qué un componente estaba valorado en 1.0x. Ese es un argumento mucho mejor para tener, y es lo único por lo que habría pagado por sí solo.

Si alguna vez tengo un antes y después real, publicaré la metodología primero y el número después. Si lo publico al revés, no me creas.

Apúntalo a la hoja de ruta, luego dale la regla a la gente

Quiero terminar por encima del producto, porque el producto es lo menos interesante aquí.

El verdadero trabajo del organigrama nunca fue la autoridad. Era el enrutamiento. Llevaba la respuesta a “qué importa este trimestre” hacia afuera desde las personas que lo decidían, y llevaba la respuesta a “quién hizo qué” hacia adentro, y lo hacía mal, lentamente y con una enorme distorsión en cada salto. Todo lo que no te gusta de la política corporativa es un artefacto de compresión de ese enrutamiento. Los gerentes no fueron la causa. Eran el único hardware disponible.

Ya no son el único hardware disponible. Un modelo que lee cada diff más una tabla de multiplicadores hace el enrutamiento hacia afuera en un salto y el enrutamiento hacia adentro en una consulta. Lo que queda para los humanos es la parte que siempre fue realmente el trabajo y nunca tuvo tiempo: decidir cuáles deberían ser los multiplicadores, y sentarse con las personas cuyas puntuaciones movieron esas decisiones.

La política no desaparece. No dejes que nadie te venda eso. Se mueve. Se mueve de “¿mi gerente recuerda mi trimestre?” a “¿por qué mi componente está valorado en 1.0x cuando la hoja de ruta dice que es central?”, y esa segunda pelea es una pelea sobre la estrategia real de la empresa, realizada en público, en una tabla que cualquiera puede leer. Prefiero tener esa pelea cada mes que la actual, que se realiza una vez al año, en privado, por alguien que reconstruye once meses desde la memoria.

Alguien va a gestionar esto mal. Alguien va a poner un marcador en la pared sin explicaciones de elegibilidad ni rastro de anulaciones y despedirá al decil inferior, y será un desastre, y se culpará al modelo en lugar de a la persona que eligió los multiplicadores. Esa es la parte por la que se paga, y no la pagará quien lo configuró.

Así que mídeme con el mismo instrumento. Si ejecutas algo como esto, publica tres cosas junto al leaderboard: la tabla de multiplicadores, para que la gente pueda discutir la estrategia en lugar de la puntuación. El desglose por pull request, para que cualquiera que haya puntuado cero pueda ver qué puerta se le cerró y apelarla. Y el registro de anulaciones, porque el número que un humano cambió es el único número que vale la pena auditar.

Actualmente publicamos el primero. Hacemos el tercero mal: una anulación escribe su razón en la fila de evaluación, y al limpiar la anulación se elimina la razón con ella, así que lo que tenemos es una nota que puede ser revocada en lugar de un registro. Y no publicamos el segundo lo suficientemente bien, lo cual descubrí solo porque un desarrollador con el 88% de un componente terminó último en mi propio leaderboard y no pude explicarle por qué.

GitRank está en gitrank.dev y tiene licencia CC BY-NC 4.0. La puntuación en la ruta de producción se ejecuta en Claude Haiku 4.5 con temperatura 0.3. Todas las cifras anteriores son de nuestro propio repositorio de la plataforma entre el 6 de julio y el 3 de agosto de 2026, con un tamaño de muestra de una empresa y siete desarrolladores, lo cual es una descripción de nosotros y no un benchmark de nada.