Nuestra lectura
Qodo actúa en dos momentos: en el editor o el agente antes de la pull request y sobre la propia pull request, con reglas del equipo y contexto multirrepositorio. Sus páginas de inicio y precios describen revisión y gobierno; no aclaran si genera tests. La decisión de fusionar, los tests y la aprobación de las reglas aprendidas siguen en manos de su equipo.
Dos puntos del ciclo en los que interviene Qodo
Qodo se describe como una plataforma de revisión de código y gobierno con IA. Funciona en dos superficies que comparten contexto y estándares: el IDE, para validar mientras se escribe, y Git, para revisar pull requests. El argumento del proveedor es que los agentes de programación generan cambios más rápido de lo que las personas pueden revisarlos, mientras los estándares siguen en wikis y en la cabeza de los ingenieros sénior.
Ese enfoque condiciona el resto. El producto gira en torno a la revisión y los estándares, no a escribir la funcionalidad. La descripción del catálogo de Qodo (antes CodiumAI) destaca la generación de tests, algo que las páginas actuales de inicio y precios no hacen; esa diferencia tiene su propia sección.
Antes de la PR: habilidades de revisión en el editor y el agente
El primer paso es lo que el proveedor llama habilidades de revisión shift-left. Se ejecutan dentro del agente del desarrollador y muestran reglas, hallazgos y correcciones antes de que el código llegue a Git. En el IDE, los flujos de revisión locales permiten corregir el código señalado y validar el cambio sin salir del editor. La página de precios incluye la revisión previa a la PR y las integraciones con Git e IDE en el plan Pro Team.
En la práctica, la primera retroalimentación llega cuando el autor aún tiene el cambio fresco. Las fuentes no explican cómo tratar un hallazgo con el que el desarrollador no está de acuerdo: ese criterio es suyo.
Sobre la pull request: agentes con contexto de código, historial y tickets
En cada pull request, el proveedor indica que agentes especializados buscan errores, infracciones de reglas y carencias frente a los requisitos, con contexto completo del código. Ese contexto incluye la estructura y las dependencias de los repositorios, los diffs, comentarios y correcciones de PR anteriores indexados, y los requisitos extraídos de tickets y especificaciones.
La revisión multirrepositorio es el mecanismo más concreto. Si un cambio de firma en una biblioteca compartida puede romper a los consumidores, Qodo lo señala en la PR con un enlace a la línea afectada y razona entre proveedores de Git: un servicio en GitHub y su consumidor en GitLab pueden estar en la misma revisión. La página de precios lista las capacidades multirrepositorio tanto en Pro Team como en Enterprise.
Los clientes nombrados aportan poco detalle. La página de inicio del proveedor presenta un vídeo en el que Jensen Huang describe el motor de contexto de Qodo como búsqueda y recuperación de código para los equipos de ingeniería de NVIDIA, y cita a Pax8, que afirma que Qodo ayuda a sus equipos a validar la calidad del código en un desarrollo guiado por agentes. Walmart, Intel o monday.com, en la lista de usedby, solo aparecen como logotipos mostrados por el proveedor, sin uso especificado.
Reglas: aprendidas de su historial, pero alguien debe responsabilizarse
Según el proveedor, Rules Miner convierte los comentarios recurrentes de las PR y las decisiones de los revisores en reglas aplicables; las reglas caducan cuando dejan de ser útiles y un portal muestra con qué frecuencia se resuelven las infracciones antes de fusionar. Las reglas también se afinan según lo que los revisores aceptan o rechazan.
Hay una pregunta que hacer antes de probar. La página de inicio describe reglas autoaprendidas desde el historial de PR, pero la tabla de precios marca el sistema de autoaprendizaje como no incluido en Pro Team e incluido en Enterprise, y el sistema de reglas como incluido en ambos. No queda claro qué funciones de descubrimiento ofrece Pro Team. En cualquier caso, una regla extraída de comentarios pasados fija hábitos pasados, también los malos, así que una persona designada debería revisar la lista. Es una recomendación editorial, no una función del proveedor.
Tests: la pregunta abierta
Las páginas de inicio y precios leídas describen revisión de PR, reglas, análisis multirrepositorio y revisión en el IDE. No mencionan una función específica de generación de tests, mientras que la ficha del catálogo cita generación y automatización de tests. Lo tratamos como una incógnita, no como una ausencia.
Una forma editorial de resolverlo durante la prueba de 14 días: abra una pull request que cambie un comportamiento sin añadir tests y observe si Qodo pide tests, los escribe o no dice nada. En cualquier caso, los tests que redacte la herramienta requieren que un desarrollador confirme que comprueban el comportamiento correcto.
Créditos, alojamiento y condiciones de datos
La prueba dura 14 días, no exige tarjeta y la instalación requiere acceso de administrador. El uso de pago consume un saldo mensual de créditos compartido, a 0,012 $ por crédito, y los créditos no usados caducan al final de cada ciclo. Al agotarse el saldo, las revisiones continúan como excedente a la misma tarifa hasta un tope mensual de gasto que usted fija; si se alcanza, las revisiones se pausan hasta que lo suba.
SaaS de inquilino único, despliegue local, claves de modelo propias, SSO y registros de auditoría figuran solo en Enterprise. El proveedor afirma que no entrena modelos con su código. Cuenta con SOC 2 Type II, con informe disponible bajo petición en su centro de confianza, y publica un anexo de tratamiento de datos que cita a Google Cloud y AWS como subencargados de alojamiento, con elección de región.
Método y límites
2026-10-29
Esta instantánea fechada cuenta empresas distintas con pruebas públicas de clientes. CONFIRMED indica un caso de estudio, testimonio identificado o fuente de prensa; DECLARED, una declaración de la propia empresa; OBSERVED, una lista de clientes del proveedor; SIGNAL, una oferta de empleo. Los cuatro niveles cuentan, con distinta solidez. Se excluyen las líneas retiradas o sin nivel. Los ejemplos son una selección limitada verificada en los últimos 90 días. Los datos del proveedor tienen fuentes comprobadas en los últimos 60 días. La cobertura es desigual y la ausencia de pruebas es desconocida. Las cifras no miden cuota de mercado ni rendimiento; las fechas de captura no son fechas de adopción.
