Tres agentes de código, tres lockfiles: por qué Codex, Claude Code y Cursor no se ponen de acuerdo

El 3 de septiembre de 2026, Armature Research publicó un experimento de 16.893 sesiones. No les pidieron a Claude Code, Codex y Cursor una recomendación. Les pidieron que eligieran e implementaran servicios de terceros en repositorios reales: 75 repos, 10 lenguajes, 1.163 variaciones de prompt.

Los tres coinciden en la misma herramienta solo en el 42% de las celdas analizadas. En agentes de voz, Claude Code se fue a Twilio, Codex a la OpenAI Realtime API y Cursor a Vapi. Misma petición. Tres proveedores.

Tres aparatos de saber distintos producen tres lockfiles. El que abras en el IDE ya está votando stack por ti.

Codex busca, Claude Code recuerda

Según Armature, Codex busca en la web en el 94% de las sesiones. En nueve de cada diez, esas búsquedas llevan operadores site: para cerrar el tiro a un dominio concreto o de confianza. El ejemplo del estudio es de manual: site:auth0.com password reset MFA social connections. No está comparando el mercado. Está leyendo el folleto oficial del dominio que ha decidido respetar.

Claude Code hace lo contrario. Se apoya en su conocimiento previo, los priors, lo que el modelo ya trae de entrenamiento, y solo busca en alrededor del 30% de las sesiones. Cuando se pone a navegar, visita tres veces más páginas que Codex: menos a menudo, más profundo. El patrón se rompe donde esos priors son flojos. En sectores recientes como sandboxes, busca alrededor del 80% del tiempo. Ahí deja de recitar y se pone a investigar.

Cursor se planta en medio: fundamenta la decisión en la web en dos de cada tres sesiones.

Codex es un agente con el buscador puesto. Claude Code es un agente con la memoria de entrenamiento puesta. Cursor mezcla las dos cosas. Ninguno está haciendo una evaluación neutral de calidad. Están resolviendo qué acaba en el lockfile con el aparato de saber que su diseño les da.

Eso también explica un hábito que no sale en los rankings de herramientas. Claude Code resuelve construyendo soluciones in-house casi el doble que los otros dos: 19% de las sesiones frente al 10% de Codex y Cursor. Si no encuentra, o no busca, un producto que le encaje, se fabrica el módulo. El repo hereda esa manía.

El agente que uses sesga tus decisiones técnicas.

El fallo de Codex es visión de túnel: si el producto mejor no está bien documentado en un dominio site: de confianza, no existe. El de Claude Code es confianza caliente: cuando no duda, nunca sale del prior; cuando duda, se pone a comerse páginas. Cursor hereda un poco de los dos.

La ficha del proveedor vale más que el producto

Armature documenta que detalles de la web del proveedor cambian la elección. Mailgun perdía frente a Postmark cuando los agentes leían "retención de 1 día" en su plan gratuito. Supabase perdía por empaquetar auth, storage y realtime cuando el agente solo buscaba una base de datos. El producto no había empeorado. El texto había activado un veto.

De las ~5.300 sesiones válidas, 388 mencionaron sobrecoste de gestión de la plataforma y 195 mencionaron costes. En un porcentaje significativo de casos infló más la forma de presentar la información que un dato realmente descalificante. El copy de pricing y el empaquetado de features no son adorno: son input del agente.

Si vendes una dev tool, tu página de docs forma parte del runtime de decisión de tres coding agents. Si desarrollas, el README que el agente lee puede importar más que el benchmark que tú tienes en la cabeza. Un párrafo de retención o un bundle de features de más y el lockfile se va a otro lado.

16.893 sesiones, un vendedor al volante

El panel no era un playground limpio. Según Armature: 75 repositorios con nombres de empresa, historiales git y claves API falsos, pero lockfiles reales verificados contra registros como npm. Cada prueba corrió en un sandbox efímero dedicado, rotando entre E2B, Blaxel y Daytona después de que Armature afirmara que el sandbox no movía las conclusiones.

El número gordo es 16.893 sesiones. El que filtra es ~5.300 válidas. El resto del detalle por categoría, dice Armature, vive en su leaderboard web; las fuentes citadas no recogen el desglose completo.

El contrapunto no se puede esconder debajo de la cifra. Armature Research vende servicios de growth para dev tools y declara que el estudio forma parte de su trabajo para influir en cómo los coding agents eligen herramientas y conseguir que productos sean seleccionados e implementados. No es un laboratorio midiendo el mercado desde fuera. Es una empresa que cobra por meterse en exactamente este embudo.

Las fuentes consultadas no recogen qué versiones concretas de modelo usaban Claude Code, Codex y Cursor, ni cómo se configuraron. Tampoco la definición exacta de "celda" en ese 42%, ni el listado completo de criterios del juez automatizado, ni cuántas sesiones cayeron en cada combinación persona-repositorio-categoría. No consta en las fuentes consultadas una réplica independiente. Las cifras son de Armature.

El patrón, web contra priors, es coherente con lo que se ve en las sesiones. La magnitud exacta, con el conflicto de interés encima, pide sal.

Lo que te llevas al repo

Trabajar con uno de estos tres no es cambiar de teclado. Es cambiar de sesgo. Codex te trae lo que esté bien explicado en un dominio que respete. Claude Code te trae lo que recuerde, o un invento propio si no recuerda bastante. Cursor, una mezcla.

Esa vía in-house sale cara. En un experimento de ingeniería distinto al de Armature, una aplicación de unas 150.000 líneas, sobre todo Rust, escrita enteramente por Claude Code y Cursor sin revisión humana dejó el acceso a datos en 17.155 líneas de un solo archivo, con la lógica HTTP y JSON duplicada hasta el aburrimiento. El mismo prompt representativo, pasado por un subagente fresco después de cada paso de refactor, bajó de unos 159.000 a unos 27.000 tokens de entrada por cambio: alrededor de 6 veces menos. El agente que "resuelve in-house" no te ahorra una dependencia. Te deja una factura de contexto para cada cambio futuro, que es el coste que importa: el del trabajo terminado.

El estudio no mide cómo editan ni cómo usan el shell. Mide qué servicio de terceros acaban eligiendo e implementando. El lockfile es la decisión que sobrevive al chat: los agentes pagan en artefactos, no en conversación.

Si dejas que el agente instale solo, estás eligiendo también su manera de saber. El 42% de acuerdo es el solapamiento. El 58% restante es tu stack divergiendo según qué ventana tengas abierta.

Preguntas frecuentes

¿Claude Code, Codex y Cursor eligen las mismas herramientas?

No. En el experimento de Armature Research coinciden solo en el 42% de las celdas analizadas. El caso más limpio es agentes de voz: Claude Code eligió Twilio, Codex la OpenAI Realtime API y Cursor Vapi. El resto del desglose por categoría está, según Armature, en su leaderboard; las fuentes citadas no recogen el listado completo.

¿Por qué Codex busca más en internet que Claude Code?

Porque su arquitectura empuja a la web: Armature mide búsqueda en el 94% de las sesiones de Codex, con operadores site: en nueve de cada diez. Claude Code se apoya en priors y busca solo en 30%, salvo categorías nuevas como sandboxes (80%). Cursor se queda en dos de cada tres. Las fuentes consultadas no recogen que eso se deba a versiones concretas de modelo.

¿El estudio de Armature sobre coding agents es independiente?

No. Armature Research vende growth para dev tools y declara que el trabajo sirve para influir en cómo los agentes eligen e implementan productos. Las 16.893 sesiones y la metodología (75 repos, lockfiles reales, sandboxes E2B, Blaxel y Daytona) salen de ellos. Las fuentes consultadas no recogen réplica independiente ni las versiones de modelo usadas.

¿Cómo influye el agente de código en las librerías de un proyecto?

El agente sesga el lockfile. Codex tiende a instalar lo que encuentra en dominios de confianza; Claude Code instala lo que recuerda o se fabrica el módulo (19% in-house frente a 10%); Cursor mezcla web y prior. Un cambio en la web del proveedor, la retención de Mailgun, el paquete de Supabase, basta para cambiar la elección.