La mayoría de las páginas “vs” no son comparaciones. Son tres fichas de producto cosidas. Una herramienta es la que el autor ya usa. La otra se abre lo justo para una captura. La tarea cambia a mitad de camino. Un precio se copia de memoria. Los comentarios discuten después una comparación que no ocurrió del todo.

Claude Radar va a publicar comparaciones de todos modos. No poner nunca dos herramientas juntas sería eludir el trabajo. La versión honesta es más lenta: fijar una tarea, fijar una condición de parada, escribir lo que hizo el operador y rechazar afirmaciones que parecen evidencia y no lo son.

Este artículo es ese método: un protocolo que una segunda persona podría seguir desde la página. Tiempos, cifras y tasas de victoria esperan un fixture público y una prueba con fecha de ejecución registrada.

El problema de los recopilatorios

Un agente de código no es una cámara. No puedes poner dos en un trípode y disparar al mismo muro de ladrillo. El operador está en el bucle: el prompt, el momento en que interrumpe, los archivos que no deja tocar, el test que decide que está “casi”. Si ese bucle es invisible, la comparación es un test de personalidad.

Los recopilatorios también mezclan categorías. Un agente de terminal, un editor con compleciones en línea y un constructor de apps en el navegador pueden “escribir una app de tareas”. No te dejan el mismo tipo de repositorio, ni los mismos tests, ni el mismo tipo de trabajo al día siguiente. Tratarlos como productos intercambiables es cómo se obtiene una cuadrícula de logos y un cierre vago.

Si un segundo operador no puede repetir la comparación desde la página, era un diario con titular de comparación.

Preferimos publicar menos, con la parte de diario etiquetada como diario y la de comparación como comparación. Este protocolo es para la segunda.

Qué comparamos y qué no

La revista es primero en inglés y global. El centro de gravedad es Claude Code, porque eso es lo que cubre esta revista. Cursor, Codex y las herramientas de vibe coding están en el mismo campo de visión porque los lectores se mueven de verdad entre ellas. Los catálogos de automatización, los mercados de plantillas y los directorios de “1.000 flujos” pueden aparecer después como nota al margen si el trabajo de un constructor choca con ellos. No son el eje de esta revista.

Una comparación pertenece a este sitio cuando todo esto es cierto:

  • El lector intenta producir software que funciona, no una diapositiva.
  • Cada herramienta puede apuntarse al mismo fixture público.
  • Podemos nombrar una definición de terminado que no sea “se sintió más rápido.”
  • Estamos dispuestos a publicar los fallos, no solo la corrida que se portó bien.

Una comparación no pertenece aquí cuando la única fuente es una página de marketing, una demo de lanzamiento recordada o un hilo social. Citaremos documentación oficial con fecha de consulta. No la lavaremos hasta convertirla en un banco de pruebas.

El fixture compartido

Cada comparación del primer conjunto editorial debería partir de una pequeña app web pública: el mismo repositorio, los mismos tests que fallan, el mismo README. El punto de un fixture no es parecer cinematográfico. Es que las condiciones coincidan. Si la corrida A es “reconstruir de memoria nuestro monolito de producción” y la B es “andamiar un contador”, hemos comparado dos trabajos distintos.

El fixture debería ser aburrido a propósito:

  • Lo bastante pequeño para leerlo de una sentada.
  • Público, para que un lector pueda clonarlo.
  • Sin secretos de cliente, logs de producción ni nombres privados.
  • Ya equipado con tests que fallan por una razón conocida al inicio de la corrida.
  • Sin relación con el código de esta revista, para no puntuar una herramienta por lo bien que nos halaga.

El primer fixture público se enlazará desde cada comparación que lo use, con un hash de commit. Hasta que ese hash exista, las comparaciones se quedan en método, no en resultados.

El protocolo

Estos son los pasos, escritos para poder copiarse. Si una comparación publicada se salta un paso, el texto debe decir cuál y por qué — no esconder el salto en una narración más lisa.

  1. Registrar las herramientas. Anotar nombres de herramientas, canales o identificadores de build, elecciones de modelo que la herramienta expone, versión del editor o CLI, SO y la fecha de inicio. Si una herramienta no expone versión, escríbelo. No aproximes.
  2. Reiniciar el fixture. Partir del commit acordado. Sin astucias de node_modules sobrantes, sin WIP escondido, sin skills ni reglas extra salvo que la comparación trate precisamente de esos archivos. El árbol de partida es parte del método.
  3. Entregar el mismo paquete de prompt. Un paquete por corrida, guardado en el artículo o en un archivo contiguo. Nada de “también se lo dije en privado.” Si el operador debe añadir una restricción, es una intervención (paso 4), no un prólogo secreto.
  4. Poner tope a las intervenciones. Decidir de antemano cuántos turnos de operador caben después del paquete: un número, no “hasta que se vea bien.” Cada intervención se anota en una línea: qué se dijo, por qué, y si filtró información que la otra corrida no recibirá.
  5. Parar en la misma definición de terminado. En el primer fixture esperamos: los tests acordados pasan, la app sirve en local y no se coló una función extra para embellecer una captura. Si la herramienta no llega dentro del tope, el resultado es una corrida incompleta, no un “casi” poético.
  6. Archivar el registro antes de mirar el otro. Escribir las notas de la corrida A como si la B no existiera. Luego al revés. Solo cuando ambos archivos estén guardados podrán juntarse en una tabla. Mirar de reojo es cómo los diarios fingen ser ensayos.
  7. Publicar los límites junto a la tabla. Una página de comparación que no puede listar lo que no midió no está lista.

Paquete de prompt de ejemplo

El paquete de abajo es una muestra de tono y alcance. Cópialo si quieres probar la corrida. Un intento local no es un resultado publicado.

Tarea en lenguaje llano: añadir un analizador de notas de sesión a una app pequeña de TypeScript para que un texto crudo se vuelva una nota estructurada, con tests que ya describen la forma.

You are working in a small public web app at the tagged commit.

Add `src/notes/parseNote.ts` so the tests in
`src/notes/parseNote.test.ts` pass. Do not add features
the tests do not describe. Do not rewrite unrelated files.

Constraints:
- TypeScript, no new dependencies.
- Refuse sample data that looks like a real person.
- If a test is unclear, stop and ask one question.
  Do not invent a business rule.

Stop when `npm test` is green for that file, or when you
cannot proceed without a decision from me. Write a short
summary of files touched and any test you could not satisfy.

Los tests a los que apunta el paquete ya deberían existir en el fixture, para que la herramienta no se ponga nota a sí misma.

Qué registraremos

La tabla es el contrato de una página de comparación posterior. Las celdas vacías en una pieza publicada significan “no medimos esto”, no “está bien.” No las rellenaremos con adjetivos.

Criterio Qué registramos Qué no inferiremos
Hecho o no Si los tests acordados pasaron dentro del tope de intervenciones. Que la herramienta es “mejor en ingeniería.”
Tiempo hasta una corrida útil Tiempo transcurrido en una máquina nombrada, del inicio al corte, si decidimos medir tiempo. Productividad de equipo, o cómo te iría en una tarde cansada.
Calidad de la edición Tamaño del diff, archivos tocados, tests que siguen pasando, reescrituras ajenas evidentes. Gusto, seniority o “arquitectura limpia.”
Esfuerzo del operador Cuenta y texto de las intervenciones que de verdad enviamos. La pericia de los operadores en general.
Coste Solo el uso medido que la herramienta expone, con fecha y nombre de plan. Si no: “no divulgado.” Tu factura mensual, o un ranking por precio de etiqueta.
Modos de fallo Dónde paró, qué rompió, cómo recuperamos — o que no lo hicimos. Una personalidad para el modelo.
Fricción de arranque Instalación, login y ganchos de proyecto, como lista. Que un arranque más largo es siempre peor.

Qué contendrá una comparación publicada

Cuando una comparación salga de la lista de candidatos, la página debería llevar:

  • El hash del fixture y el paquete de prompt.
  • La lista de herramientas del paso 1.
  • Ambos registros, o un recorte justo que no tire los fallos.
  • La tabla de criterios, con las celdas vacías vacías.
  • Enlaces a docs oficiales usadas para nombres de plan o límites, con fechas de consulta.
  • Un hueco de correcciones, aunque solo diga “ninguna aún.”

Si más adelante añadimos enlaces de afiliado o un patrocinador, irán etiquetados y fuera de la tabla de puntuación. Un ranking que se mueve tras una relación comercial es una corrección, no un refresco.

Limitaciones

Este protocolo ya está sesgado, y preferimos nombrar el sesgo a maquillarlo.

  • Un fixture no es la industria. Un parser en una app pequeña de TypeScript dice poco sobre móvil nativo, cuadernos de datos o un monorepo de un millón de líneas.
  • El operador es una variable. Otra persona interrumpirá antes, o no lo hará. Podemos registrar nuestras interrupciones; no podemos restarnos.
  • Las herramientas se mueven. Una prueba con fecha de ejecución registrada es un resultado de esa fecha. No disfrazaremos tablas viejas de actualidad.
  • Los contadores expuestos son incompletos. Si un producto oculta el uso de tokens o agrupa el uso en un plan por puesto, no podemos inventar una columna de coste.
  • Aún no se ha corrido ninguna comparación. Las tablas vacías siguen vacías hasta que exista una prueba con fecha de ejecución registrada.
  • La independencia es una práctica, no un estado de ánimo. Usar Claude en el nombre no nos autoriza a favorecer esa herramienta. Si una comparación se lee como favoritismo, falló el método.

Política de fuentes

Distinguiremos cuatro clases de fuente y no las dejaremos mezclarse:

  1. Documentación oficial — citada o parafraseada con URL y fecha de consulta. Las cifras de precio y límite salen de aquí o no aparecen.
  2. Nuestro fixture y registros — lo bastante públicos para inspeccionar. El trabajo privado de clientes se queda fuera.
  3. Otro periodismo y posts primarios — enlazados cuando son la fuente de una afirmación sobre el mundo, no como sustituto de una corrida que nos saltamos.
  4. Lenguaje de marketing — usable como cita de lo que dice un vendedor, nunca como medición.

No rasparemos chats privados, no pegaremos runbooks internos ni trataremos una captura social como número de versión. Cuando exista una relación de afiliado o patrocinio, se nombrará en la página que lleva el enlace.

Política de correcciones

Si una comparación publicada está mal, la página cambia en público.

  • Los errores de hecho (versión, nombre de plan, test mal leído) llevan una nota fechada arriba o en un bloque de correcciones, y un arreglo en el cuerpo.
  • Una corrida nueva es una corrida nueva. No sobrescribe una tabla vieja sin decirlo.
  • No reordenaremos en silencio un ranking tras un trato comercial, un correo de un vendedor o una noche mala de tráfico.
  • Si no podemos defender una frase contra este protocolo, borramos la frase, no la vergüenza.

Aún no se ha publicado ninguna comparación, así que no hay nada que corregir. El bloque de correcciones está aquí para que las piezas posteriores se corrijan del mismo modo.