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

Haz la división en tu factura de revisión de código con IA. Toma lo que pagaste el mes pasado y divídelo entre el número de pull requests que la herramienta revisó de verdad. El precio de etiqueta es otro número, y es el que tienes memorizado. Hice la división para nuestro equipo y obtuve algo tan alejado de la página de precios que asumí que me había equivocado.

La aritmética estaba bien. Había estado comprando el producto como se vende y usándolo como trabajamos de verdad, y resulta que son dos productos distintos.

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 diferencia entre ellos es a donde va tu dinero. Por separado, y peor, la herramienta que estábamos pagando leyó un diff con seis defectos reales y encontró uno.

La reemplazamos con algo que construimos nosotros. Voy a mostrarte los recibos de ambas afirmaciones, incluidas las partes que nos hacen quedar peor.

Entraron seis defectos. Salió uno.

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

Después, uno de nuestros ingenieros repasó el diff a mano y lo evaluó como es debido, anotando cada defecto real 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 se reintentaba en un bucle infinito. El autoguardado pisaba 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é. Un ingeniero se sentó y leyó el diff línea por línea. El revisor ya había ido y venido. Estábamos pagando por una red de seguridad que atrapó una cosa de seis, y las cinco que soltó fueron atrapadas por la actividad exacta que el producto existe para reducir.

Estar confiadamente al revés es peor que no decir nada

Hubo un séptimo hallazgo. No era real.

Nos dijeron: «el autoguardado fallido no tiene reintento». El defecto que estaba en esa misma función apuntaba en la otra dirección: el autoguardado fallido se reintentaba para siempre. La herramienta tenía la dirección al revés.

He pensado en ese más que en los cinco fallos combinados. Un fallo es silencio, y el silencio es soportable, 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 encuentra lo que nunca estuvo allí, cierra el archivo y lo marca como revisado. Un informe falso gasta tu atención, y la gasta en el lugar exacto donde se escondía el bug 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 era incorrecta, y superarla me llevó más tiempo del que me gustaría admitir.

Todo modelo de frontera tiene puntos ciegos, y no hay dos modelos con los mismos. Cada proveedor incluye esa propiedad, porque es lo que son estos sistemas. Así 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 está ciego.

Déjame explicarlo con claridad. Compra el mejor revisor del mercado y habrás comprado un patrón de ceguera a precio completo. La revisión de código funcionaba en primer lugar porque una segunda persona miraba el diff. Ese era todo el mecanismo, y lo abandonamos la semana 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 como su proveedor pretendía. Sus hallazgos se consolidan, así que tres informes casi duplicados de un defecto aterrizan en el pull request como un solo comentario.

Lo ejecutamos contra el mismo commit.

Revisor	Encontrados	Precisión	Coste	Tiempo
Greptile	1 de 6	50%	no divulgado	no divulgado
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. Junta ambos revisores y obtienes cinco de seis, que es mejor de lo que cualquiera logró por separado, y no voy a enterrar eso debajo de la tabla anterior.

Podría haber eliminado esta sección. La mantengo porque es el argumento. Modelos distintos atrapan cosas distintas, y que el modelo de un competidor encuentre algo que el nuestro pasó por alto es la demostración más limpia disponible de que ejecutar un solo revisor es el error. El día que eso deje de pasar es el día que empiece a preocuparme de que nuestro jurado se haya colapsado en una sola opinión con cuatro sombreros.

Tu factura sigue la plantilla. Tus revisiones siguen los merges.

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

El plan Pro de Greptile es de $30 por asiento al mes, a fecha 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, eso es barato. Unos sesenta centavos, si usas cada crédito que te dan. Quiero ser completamente justo aquí: por unidad, eso es más barato de lo que costó nuestra propia herramienta en el pull request anterior. Un equipo pequeño que consume por completo su asignación debería comprar los asientos, y no voy a fingir lo contrario.

Nadie consume por completo su asignación.

Te cobran por desarrollador. Consumes revisiones por pull request. Esos dos números dejan de seguirse el uno al otro en el momento en que la plantilla crece más rápido que la tasa de merges, 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 has dejado que 850 créditos caduquen.

Tu utilización cambió y el precio de lista no, así que 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 que se consume por artefacto. Es invisible en la página de precios, escala con la contratación 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 autosave, cuatro defectos reales y ningún falso positivo, costó $1.08 y tardó 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 de las dos, imprime unknown y el total se marca como límite inferior. No adivinamos y no redondeamos a nuestro favor.

Ahora mira de nuevo las dos celdas de esa tabla que dicen “no divulgado”. Fui a buscar esas cifras y no están publicadas en ningún sitio. La herramienta no te dice cuánto cuesta una revisión porque no tiene por qué. Compraste un asiento. La economía unitaria es asunto del proveedor, y el proveedor preferiría que siguieras haciendo la multiplicación a su manera.

Un revisor que imprime su propia factura es lo que quería y no pude comprar a ningún precio.

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

Esto es un 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 cualquiera de los dos revisores puede reemplazar al otro, y no voy a violar nuestra propia advertencia dentro de una entrada de blog sobre lo cuidadosamente que reportamos números.

Cuatro de seis contra uno de seis es un caso adjudicado. Me hizo estar dispuesto a ejecutar ambos revisores en paralelo, y ese es todo el peso que puede soportar. Un pull request diferente, uno que dependa en gran medida del contexto de todo el repositorio donde un revisor indexado debería rendir bien, podría plausiblemente invertir el resultado. Si lo hace, ese caso también va al corpus.

La aritmética es la parte que sobrevive a una muestra de uno. 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 te molestes en medir. Cambiamos por la estructura de precios, que puedo defender con una división, y por un caso prometedor. La afirmación de rendimiento es la que no nos hemos ganado, así que no la hago.

Ven a medirnos

No te fíes de mi palabra en 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 sombra en tu propio repositorio. Déjalos funcionar 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 encontró. Cuenta lo que cada uno inventó.

Publicamos 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, coste y latencia para cada revisor que le des, y lista cada fallo por nombre. El nuestro incluido.

No creo que el modelo de asientos sobreviva al contacto con cualquiera 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 tarde o temprano. Cuando lo hagan, la respuesta no será sesenta centavos.

Ese pull request de autosave 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 que el autosave 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 todo esto que debería preocuparte. El revisor que falló cinco cuesta lo mismo tanto si encuentra seis como si encuentra cero, y nunca te dirá 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.