La facturación por asiento convierte una revisión de código de 60¢ en $4

Haz la división de tu factura de revisión de código con IA. No el precio de etiqueta, la división real: lo que pagaste el mes pasado, dividido por el número de pull requests que revisó. Lo hice para nuestro equipo y el número era tan peor que el de la página de precios que asumí que había cometido un error.

No había cometido un error. Solo había estado comprando el producto de la manera en que me lo vendieron, en lugar de la manera en que lo usamos.

Aquí está la tesis, y todo lo que sigue es evidencia de ella. La revisión de código con IA se vende por desarrollador y se consume por pull request. Esos dos números no tienen nada que ver entre sí, y la brecha entre ellos es a donde va tu dinero. Por separado, y peor, la herramienta por la que estábamos pagando leyó un diff con seis defectos reales y encontró uno.

Lo reemplazamos con algo que construimos. Te voy a mostrar los recibos de ambas afirmaciones, incluyendo las partes que nos hacen quedar peor.

Seis defectos entraron. Uno salió.

El pull request era un refactor de autoguardado en nuestra plataforma. Normal, de tamaño mediano, del tipo que se abre un martes y nadie pierde el sueño. Greptile lo revisó, dejó dos comentarios y siguió adelante.

Después, uno de nuestros ingenieros revisó el diff manualmente y lo evaluó correctamente, anotando cada defecto genuino sin mirar qué herramienta había reportado qué. Seis defectos. Cuatro de ellos P1, del tipo que corrompe datos de usuario en lugar de molestar a alguien.

El autoguardado se rearmaba para siempre después de normalizar valores. Un guardado fallido reintentaba en un bucle infinito. El autoguardado sobrescribía lo que el usuario estaba escribiendo activamente en otra pestaña. Una promesa de guardado se descartaba sin manejar. Salir de la página descartaba todo lo pendiente. El botón de guardar se renderizaba solo cuando el paso no podía guardarse.

Uno de esos seis fue reportado.

Ninguno de esos seis llegó a producción, y quiero ser preciso sobre por qué, porque la razón es el punto central. Fueron detectados porque un humano leyó el diff. No porque el revisor los detuviera. Estábamos pagando por una red de seguridad que atrapó una de seis, y lo que atrapó las otras cinco fue un ingeniero leyendo el código línea por línea, que es exactamente la actividad que el producto existe para reducir.

Estar confiadamente equivocado es peor que no decir nada

Hubo un séptimo hallazgo. No era real.

Nos dijeron «el autoguardado fallido no tiene reintento». El defecto real, en la misma función, era lo opuesto: el autoguardado fallido reintentaba para siempre. No un error omitido. Uno invertido.

He pensado en ese más que en los cinco fallos combinados. Un fallo es silencio, y el silencio es sobrevivible, porque ya asumes que tu revisor no es omnisciente. Una inversión es peor que el silencio. Envía a un ingeniero al archivo correcto buscando lo incorrecto, y cuando no encuentran lo que nunca estuvo allí, cierran el archivo y lo marcan como revisado. Un informe falso no solo no te ayuda. Gasta tu atención, y la gasta en el lugar exacto donde se escondía el error real.

Un hallazgo real. Un hallazgo al revés. Seis defectos en el diff.

Un modelo significa un punto ciego, y nunca aprenderás su forma

Mi primera reacción fue que habíamos comprado la herramienta equivocada. Esa reacción fue incorrecta, y superarla me llevó más tiempo del que me gustaría admitir.

Cada modelo de frontera tiene puntos ciegos y no son los mismos puntos ciegos. Eso no es un defecto en el producto de ningún proveedor en particular, es lo que son estos sistemas. Lo que significa que si construyes tu proceso de revisión sobre exactamente un modelo, lo has construido sobre exactamente un patrón de ceguera, y nunca aprenderás la forma de ese patrón, porque el único instrumento que podría mostrártelo es el instrumento que es ciego.

Déjame explicarlo. El problema no es que tu revisor sea malo. El problema es que tu revisor es singular. Una segunda opinión nunca fue un lujo en la revisión de código, era el mecanismo completo por el cual funcionaba la revisión de código, y lo dejamos caer silenciosamente en el momento en que lo automatizamos.

Así que construimos Juror. Varios modelos de frontera revisan el mismo diff en paralelo, cada uno a través de su propio harness de agente nativo, cada uno libre de buscar en tu repositorio de la manera que su proveedor pretendía. Sus hallazgos se colapsan, así que tres informes casi duplicados de un defecto se convierten en un hallazgo en lugar de tres, y lo que llega al pull request es un solo comentario.

Lo ejecutamos contra el mismo commit.

Revisor	Encontrados	Precisión	Costo	Tiempo
Greptile	1 de 6	50%	no revelado	no revelado
Juror	4 de 6	100%	$1.08	8m22s

Aquí está la parte donde perdemos

Juror falló dos.

Greptile atrapó la promesa de guardado descartada y nosotros no. Ninguna herramienta encontró el bucle de reintento infinito. Pon ambos revisores juntos y obtienes cinco de seis, que es mejor de lo que cualquiera logró solo, y no voy a enterrar eso debajo de la tabla anterior.

Podría haber eliminado esta sección. La mantengo porque es el argumento. Diferentes modelos detectan cosas diferentes. Eso no es una advertencia incómoda adjunta a nuestra propuesta, es la propuesta, y que el modelo de un competidor encuentre algo que el nuestro no encontró es la demostración más clara disponible de que ejecutar un solo revisor es el error. El día que eso deje de suceder es el día en que empiece a preocuparme de que nuestro jurado se haya colapsado en una opinión con cuatro sombreros.

No estás pagando por revisiones. Estás pagando por sillas.

Ahora la factura, que es donde esto deja de ser sobre un pull request.

El plan Pro de Greptile es $30 por asiento por mes, a partir de agosto de 2026. Eso incluye 50 créditos por asiento, donde un crédito compra una revisión estándar y tres compran una más profunda, y los créditos adicionales cuestan $1 cada uno.

Por revisión, es barato. Aproximadamente sesenta centavos, si usas todos los créditos que te dan. Quiero ser completamente justo aquí: por unidad, es más bajo de lo que costó nuestra propia herramienta en el pull request anterior. Un equipo pequeño que consume completamente su asignación debería comprar los asientos, y no voy a fingir lo contrario.

Nadie consume completamente su asignación.

Se te factura por desarrollador. Consumes revisiones por pull request. Esos dos números dejan de coincidir en cuanto la plantilla crece más rápido que la tasa de merge, es decir, inmediatamente, en toda organización de ingeniería que haya existido. Veinte ingenieros en Pro son $600 al mes y mil créditos. Si ese equipo mergea 150 pull requests, un mes completamente normal, has pagado $4 por revisión y dejado que 850 créditos caduquen.

El precio de lista nunca se movió. Tu utilización sí. Sesenta centavos se convirtieron en cuatro dólares y nadie te envió un correo al respecto.

Llámalo el impuesto del asiento: dinero gastado en una licencia por desarrollador para un producto consumido por artefacto. Es invisible en la página de precios, escala con las contrataciones en lugar del uso, y es la partida más grande de lo que realmente pagas.

Puedo decirte cuánto costó esto porque imprimimos el recibo

Juror no tiene asientos. Se ejecuta en tu propio runner de GitHub Actions, llama a las APIs de los modelos con tus propias claves, y la factura es la inferencia y nada más. Esa revisión del PR de autoguardado, cuatro defectos reales y ningún falso positivo, costó $1.08 y tomó ocho minutos y veintidós segundos.

Puedo decírtelo al centavo porque cada revisión de Juror termina con una tabla: cada modelo, sus tokens de entrada, sus tokens en caché, sus tokens de salida, sus dólares. Cada cifra está etiquetada como reported cuando el proveedor la calculó, o estimated cuando la derivamos de los precios de lista publicados. Cuando un harness no nos da ninguna, imprime unknown y el total se marca como cota inferior. No adivinamos y no redondeamos a nuestro favor.

Ahora mira de nuevo las dos celdas de esa tabla que dicen “not disclosed”. Eso no es un vacío en mi investigación. La herramienta no te dice cuánto costó una revisión, porque no tiene por qué. Compraste un asiento. La economía unitaria es asunto del vendedor, y el vendedor preferiría que siguieras haciendo la multiplicación a su manera.

Eso era lo que realmente quería y no podía comprar a ningún precio. No un revisor más barato. Un revisor que me dijera cuánto gastó.

Lo que no voy a hacer es llamar a esto un benchmark

Esto es un solo pull request.

Nuestro propio protocolo de benchmarking dice que una decisión de reemplazo necesita de 20 a 30 PRs adjudicados que abarquen frontend, backend, migraciones, concurrencia, código sensible a la seguridad, y diffs tanto pequeños como grandes. Tenemos uno. Está en el repositorio con una advertencia adjunta que dice que no debe presentarse como evidencia estadísticamente suficiente de que un revisor pueda reemplazar al otro, y no voy a violar nuestra propia advertencia dentro de una publicación de blog sobre lo cuidadosamente que reportamos números.

Cuatro de seis contra uno de seis no es un resultado de benchmark. Es un caso adjudicado que me hizo estar dispuesto a ejecutar ambos en paralelo. Un pull request diferente, uno que dependa fuertemente del contexto de todo el repositorio donde un revisor indexado debería funcionar bien, podría plausiblemente invertirlo. Si lo hace, ese caso también va al corpus.

Lo que no es una muestra de uno es la aritmética. Treinta dólares por asiento por veinte ingenieros son $600 me guste o no, y 150 revisiones contra mil créditos es un 15% de utilización en cualquier mes que quieras medir. Cambiamos basándonos en la estructura de precios, que puedo defender con división, y en un caso prometedor. No en una afirmación de rendimiento que aún no nos hemos ganado.

Ve y mídemos

No te fíes de mi palabra para nada de esto. Tengo un interés comercial en tu conclusión y deberías ponderar todo lo anterior en consecuencia.

Pon ambos revisores en modo shadow en tu propio repositorio. Déjalos ejecutar unas semanas sin que ninguno bloquee un merge. Luego toma cada hallazgo, quita las etiquetas para que nadie sepa qué herramienta dijo qué, y haz que un ingeniero senior los adjudique en frío contra el código. Cuenta lo que cada uno detectó. Cuenta lo que cada uno inventó.

Enviamos las herramientas exactamente para esto, porque nosotros mismos las necesitábamos:

npx juror-ai benchmark --file your-corpus.json

Reporta recall, precisión, tasa de duplicados, costo y latencia para cada revisor que le introduzcas, y lista cada fallo por nombre. El nuestro incluido.

No creo que el modelo de asientos sobreviva al contacto con alguien que haga la división. Sobrevive ahora porque la división es ligeramente molesta y la página de precios está dispuesta para que no te molestes. Alguien en tu organización hace ese cálculo eventualmente. Cuando lo haga, la respuesta no será sesenta centavos.

Ese pull request de autoguardado se mergeó esta mañana, por cierto. Hicieron falta dos commits más para llegar ahí, uno para hacer que los guardados de navegación fueran single-flight y otro para hacer que el autoguardado convergiera y dejara al builder en paz. Buenos commits. Nada en llamas.

Nadie sabrá nunca que fueron necesarios, porque los bugs detectados antes del merge no dejan rastro y no generan ningún informe de incidente. Esa es la parte de esto que debería molestarte. El revisor que falló cinco de ellos cuesta lo mismo tanto si encuentra seis como si encuentra cero, y nunca te dirá por cuál de esos dos meses acabas de pagar.

---

Juror es open source y tiene licencia MIT: github.com/juror-ai/juror. Precios de Greptile citados de greptile.com/pricing a fecha de agosto de 2026.