Estás intentando decidir en qué agente de programación confiar para trabajo real: Claude Code, Codex, Gemini CLI, OpenCode, o dos de ellos a la vez. Así que lees las puntuaciones de los benchmarks. Un agente resuelve el 68% de un conjunto de tareas públicas, otro el 71%, y se supone que debes elegir a partir de eso. Luego el agente aterriza en tu repositorio y se atasca en un paso de compilación que ningún conjunto de datos público ha visto jamás.
Un benchmark mide un conjunto fijo y compartido de problemas. Tu base de código es un conjunto privado de problemas: tus convenciones, la disposición de tu monorepo, el test inestable que todo el mundo ignora, el script de despliegue que solo una persona entiende. La puntuación que decide tu semana es la que generas sobre ese código, no la que publicó un laboratorio. Esta guía recorre un método para comparar agentes de programación en el software que realmente publicas, y cómo hacer esa comparación sin abrir cinco terminales para mantener a los agentes separados.
Sharkly es donde aterriza ese método. Sharkly es una plataforma todo en uno de gestión y comando de Agentes: conectas tu propio Ordenador, asignas la misma Tarea a distintos Agentes, y cada ejecución devuelve su diff, su salida de tests y su revisión a un solo lugar. Eso es lo que hace posible una comparación justa. La variable que quieres medir es el agente, no el malabarismo con terminales que tendrías que hacer de otro modo para evitar que tres ejecuciones se pisen entre sí.
Una puntuación de benchmark mide un conjunto de datos, no tu repositorio
Un benchmark de agentes de programación es un conjunto de pruebas público y fijo, puntuado igual para todos. Eso es precisamente lo que lo hace útil para los laboratorios que construyen modelos, y precisamente lo que lo convierte en un mal predictor para ti.
Los benchmarks públicos como SWE-bench extraen sus tareas de proyectos de código abierto bien conocidos, con un entorno de pruebas ajustado y comprobaciones de aceptación seleccionadas. Nada de eso describe tu martes. Las cosas que determinan cómo se desempeña un agente en tu código son las que un conjunto de datos público nunca podrá contener: tus librerías internas que el modelo nunca ha leído, tu configuración de lint, el archivo de contexto de 400 líneas que explica cómo arranca realmente el servicio, el único módulo sin tests.
Una puntuación alta en un benchmark no predice cómo se comporta un agente en tu repositorio. Predice cómo se comporta en el de otro. Trata la tabla de clasificación como un filtro aproximado de qué agentes merece la pena probar, y luego haz la prueba que cuenta. Si aún estás eligiendo a qué modelo apuntar cada agente, emparejar modelos con roles de agente es una pregunta de partida mejor que la puntuación bruta.
Elige una tarea real, no un prompt de juguete
Empieza por la comparación útil más pequeña. No hagas benchmark de agentes con «construye una app de tareas pendientes». Elige un requisito real de tu backlog: un bug acotado, una funcionalidad pequeña en un solo módulo, una migración que ibas a hacer de todos modos. Algo con un test de aceptación que puedas ejecutar y un diff que puedas leer en unos minutos.
Luego dale a cada agente la misma entrada: la misma descripción de la tarea, el mismo commit inicial, los mismos criterios de aceptación. Escríbelo tal como lo haría tu gestor de incidencias, una tarea como SH-312: fix the timezone drift in the invoice export. Si un agente recibe un prompt más rico que otro, estás midiendo tu prompt, no al agente.
Usa una corrección de bug cuando quieras ver cómo un agente lee código existente y se mantiene dentro de los límites. Usa una funcionalidad pequeña cuando quieras ver cómo estructura código nuevo y si escribe sus propios tests. Ejecuta ambas con el tiempo; una sola tarea solo te dice cosas sobre una sola tarea.
Compara cada agente en su mejor versión, nunca en la peor
Cada agente tiene una configuración en la que hace su mejor trabajo: el modelo adecuado, el archivo de contexto adecuado, los permisos que realmente necesita. Dale a Claude Code su CLAUDE.md, dale a Codex su configuración, dale a cada Runtime el entorno que recomiendan sus docs. Comparar un agente bien configurado contra uno pelado no te dice nada salvo cuál te molestaste en configurar.
Ejecutarlos en su mejor versión, en paralelo, es donde el enfoque de terminales se desmorona. En Sharkly asignas la misma Tarea a cada Agente, y cada Agente se ejecuta en un Ordenador conectado dentro de un worktree aislado, así que tres agentes editando el mismo repositorio nunca tocan los archivos de los demás. Obtienes tres intentos limpios del mismo problema en lugar de un árbol de trabajo compartido y un merge que tienes que desenredar a mano. Si has estado haciendo esto manualmente, ejecutar varios agentes a la vez es la parte que Sharkly está diseñado para quitarte de encima.
Si solo usas un agente y vives en la terminal, una única sesión de Claude Code bien ajustada en un worktree es suficiente, y puede que no necesites nada de esto. La ecuación cambia en el momento en que comparas dos o más agentes, en más de una tarea, y quieres los resultados en un formato que puedas leer realmente en paralelo.
Cinco criterios que lo deciden en trabajo real
Un benchmark puntúa un solo número: si la tarea pasó. El trabajo real lo deciden cinco cosas que ese número deja fuera.
| Criterio | La pregunta que responde |
|---|---|
| Ejecución en paralelo | ¿Puedo ejecutar los agentes sobre la misma tarea a la vez, en aislamiento, sin conflictos? |
| Visibilidad para el equipo | ¿Puede alguien que no sea yo ver qué hizo cada agente, y por qué? |
| Flujo de revisión | ¿Con qué rapidez puedo leer el diff, los tests y los límites conocidos y aceptar o rechazar? |
| Ejecución en la propia máquina | ¿Se ejecuta el agente en mi Ordenador, contra mi entorno y mis secretos reales? |
| Integraciones | ¿Aterriza el resultado en el gestor de incidencias, el repositorio y las herramientas de revisión que ya usamos? |
Los cuatro primeros son donde la mayoría de los agentes parecen idénticos en un benchmark y se comportan de forma totalmente distinta en tu código. La ejecución en la propia máquina, en particular, es invisible para una prueba pública: un agente que se ejecuta contra tu cadena de herramientas real, tu base de datos local, tus hooks de CI reales, se está probando sobre lo que publicas, no sobre un entorno aislado que se le parece.
Los agentes investigan, ejecutan, prueban y reportan. Tú marcas la dirección, concedes autoridad y aceptas el resultado. Una comparación solo es honesta si puedes ver cada parte de eso, para cada agente, sin reconstruirlo a partir del scrollback.
Puntúa lo que vuelve, no lo que el agente afirma
Un agente que imprime «hecho» no es lo mismo que un cambio que pasa. Puntúa cada ejecución por lo que vuelve, no por lo que afirma. Para cada intento, la evidencia útil es la misma lista corta: el diff, los resultados del typecheck y los tests, el resumen del cambio y los límites que el agente admite. Sharkly mantiene el contexto, el progreso, los bloqueos, los resultados y la revisión humana visibles desde la petición hasta el despliegue, así que la comparación se lee como una tabla de resultados en lugar de cinco terminales que tienes que recordar.
Aquí es también donde aparece el verdadero cuello de botella. Dos agentes pueden «terminar» una tarea en veinte minutos y aun así costarte una hora a cada uno en revisión. Revisar la salida de los agentes suele ser el verdadero límite de cuánto trabajo en paralelo puede absorber un equipo, y debería pesar mucho a la hora de elegir agente. Qué ponderar depende de quién elige:
| Eligiendo para | Ponderar con más peso |
|---|---|
| Desarrollador individual | Flujo de revisión y ejecución en la propia máquina; tú eres el único revisor |
| Equipo pequeño | Ejecución en paralelo y visibilidad para el equipo; varias personas necesitan ver las mismas ejecuciones |
| Equipo de plataforma | Integraciones y visibilidad; el flujo de trabajo tiene que sobrevivir al próximo mejor agente |
Esa última fila es el sentido mismo de comparar. El mejor agente de hoy puede no ser el mejor agente el próximo trimestre, y reconstruir tu flujo de trabajo cada vez que cambia el líder es un impuesto en sí mismo. Sharkly no es un agente de programación ni un entorno de pruebas de benchmarks; es la capa que te permite seguir probando agentes contra tu propio código sin reconstruir el proceso a su alrededor cada vez.
Si quieres seguir usando varios agentes de programación en lugar de comprometerte con un solo ecosistema, ese es el problema en torno al cual está diseñado Sharkly. Descarga Sharkly, conecta un Ordenador y asigna la misma tarea real a dos agentes. La comparación que obtienes habla de tu base de código, que es la única que predice tu semana.
