La irrupción de Claude Code ha abierto una pregunta muy concreta entre desarrolladores y equipos técnicos: si el agente puede programar en casi cualquier lenguaje, ¿cuál conviene usar para trabajar más rápido, gastar menos tokens y mantener una buena tasa de éxito? Un benchmark publicado este mes por Yusuke Endoh, autor de mame/ai-coding-lang-bench, ha intentado responderlo con números en la mano. El experimento pidió a Claude Code que implementara una versión simplificada de Git en 13 lenguajes, con 15 configuraciones en total al añadir Python con mypy y Ruby con Steep, y lo hizo 20 veces por configuración usando Claude Opus 4.6. En total, 600 ejecuciones.
El resultado general es llamativo, aunque no definitivo: Ruby, Python y JavaScript fueron los más rápidos, baratos y estables en este escenario de prototipado, mientras que Go quedó en una zona intermedia-alta, claramente por delante de C, Haskell, TypeScript o Lua, pero sin alcanzar el ritmo de los tres primeros. Para quien trabaja en Go, la lectura no es que el lenguaje quede descalificado para Claude Code, sino que el agente parece hoy más eficiente cuando el problema se formula en lenguajes dinámicos y con menos fricción inicial.
Qué mide realmente este benchmark
El experimento no intentaba decidir qué lenguaje es “mejor” en términos absolutos, sino cuál funciona mejor con Claude Code en una tarea concreta. La prueba consistía en construir un “mini-git” en dos fases: una primera con init, add, commit y log, y una segunda con status, diff, checkout, reset, rm y show. El prompt era deliberadamente simple y el benchmark evitaba dependencias externas usando incluso un hash personalizado, en lugar de SHA-256, para aislar mejor las diferencias a nivel de lenguaje.
En esa comparativa, Ruby terminó primero con 73,1 segundos y 0,36 dólares de coste medio; Python quedó segundo con 74,6 segundos y 0,38 dólares; y JavaScript, tercero, con 81,1 segundos y 0,39 dólares. Go ocupó la cuarta posición con 101,6 segundos, 0,50 dólares de coste medio, 324 líneas de código tras la segunda fase y una tasa de 40/40 tests superados. Es una marca sólida, sobre todo porque Go no falló ninguna de las ejecuciones, algo que sí ocurrió en Rust y Haskell. Pero también deja claro que, en este ejercicio, Claude Code tardó bastante más en cerrar la tarea en Go que en Ruby o Python.
Hay otro matiz importante: el propio autor advierte de que estas conclusiones valen, sobre todo, para tareas de escala de prototipo. En su texto reconoce además su sesgo como Ruby committer y subraya que la tipificación estática podría demostrar ventajas en proyectos más grandes, aunque diseñar un benchmark justo de mayor escala entre tantos lenguajes no es fácil. También recuerda que rendimiento en producción, ecosistema y librerías siguen siendo factores decisivos en cualquier elección real.
Qué dice el resultado sobre Go
El dato que más debería interesar a un equipo Go no es tanto que Ruby y Python hayan ganado, sino cómo pierde Go. No aparece como un caso problemático, sino como un lenguaje fiable, aunque menos ágil para el agente en este tipo de flujo. Pasó todas las pruebas, quedó cuarto en coste medio empatado con Java, y se movió en una zona claramente mejor que TypeScript, C o Haskell. El problema estuvo más en la velocidad y en la variabilidad: Go promedió 101,6 segundos, pero con una desviación de ±37,0 segundos, bastante más alta que la de Ruby, Python o JavaScript.
Eso sugiere que Claude Code puede producir buen Go, pero todavía necesita más vueltas, más contexto o más iteración para llegar al mismo punto que en lenguajes dinámicos. En la primera fase del benchmark, crear un proyecto nuevo en Go costó de media 47,5 segundos frente a 33,2 en Ruby y 32,9 en Python. En la segunda fase, ampliar el proyecto llevó 54,1 segundos en Go, frente a 40,0 en Ruby y 41,8 en Python. No es una distancia trivial cuando se trabaja en ciclos cortos de “prompt, espera, corrección y nuevo prompt”, precisamente el tipo de dinámica que Claude Code fomenta.
Ahora bien, tampoco conviene sacar la conclusión simplista de que “Claude Code no sirve para Go”. Go sigue teniendo atributos muy valiosos para proyectos reales: es un lenguaje fuertemente tipado, diseñado para sistemas, con soporte explícito para concurrencia y una biblioteca estándar robusta, además de una cultura fuerte de simplicidad operativa y despliegue. Es perfectamente razonable que un equipo acepte una generación algo más lenta si a cambio obtiene un resultado alineado con su stack, su perfil de rendimiento y su forma de operar en producción.
Tipos, tokens y fricción
Uno de los hallazgos más interesantes del benchmark está en el coste de añadir tipado estricto dentro de lenguajes ya conocidos por el modelo. Python con mypy --strict pasó de 74,6 a 125,3 segundos y de 0,38 a 0,57 dólares. Ruby con Steep fue aún más lejos: de 73,1 a 186,6 segundos y de 0,36 a 0,84 dólares. El autor interpreta esta diferencia como una combinación de varios factores: más fricción sintáctica, más trabajo para el agente y quizá también más familiaridad del modelo con ciertos ecosistemas que con otros.
Eso no significa que los tipos sean una mala idea. Significa que, en marzo de 2026 y para este benchmark concreto, el agente parece trabajar con más soltura cuando el lenguaje le permite avanzar con menos estructura obligatoria desde el primer minuto. De hecho, las únicas tres ejecuciones fallidas de todo el experimento se produjeron en Rust y Haskell, dos lenguajes estáticos con conceptos que pueden añadir dificultad al razonamiento del modelo. El autor deja claro que eso no demuestra que los tipos empeoren la calidad, pero sí desmonta la idea fácil de que el tipado estático, por sí solo, evita los problemas del agente.
Aquí aparece una lectura práctica interesante para equipos Go. Si el objetivo inmediato es iterar muy rápido con Claude Code, validar una idea y llegar cuanto antes a algo funcional, el benchmark sugiere que Ruby, Python o JavaScript pueden ser mejores compañeros de prototipado. Si el objetivo es llevar ese trabajo a un sistema concurrente, mantenible y alineado con un stack backend moderno, Go sigue siendo una apuesta razonable, aunque el agente tarde más en llegar. El propio repositorio plantea como hipótesis que empezar en un lenguaje dinámico y migrar después a uno estático podría seguir siendo una estrategia válida, aunque esa migración aún necesite más verificación empírica.
En el fondo, el benchmark deja una enseñanza más amplia. Claude Code no elimina las diferencias entre lenguajes; las reordena. La velocidad de generación, el coste en tokens, la estabilidad del flujo y la familiaridad estadística del modelo con cada ecosistema empiezan a ser variables reales de productividad. Para Go, eso no supone una derrota, pero sí una advertencia: en la era de los agentes, elegir lenguaje ya no afecta solo al tiempo de ejecución del programa o a la mantenibilidad humana. También afecta a cómo de bien y de rápido colabora la IA contigo.
Preguntas frecuentes
¿Cuál fue el mejor lenguaje para Claude Code en este benchmark?
Ruby terminó primero, seguido por Python y JavaScript. Los tres fueron los más rápidos, baratos y estables en la tarea de construir un mini-git con Claude Code.
¿Cómo quedó Go frente a Ruby y Python?
Go terminó cuarto, con 40/40 tests superados, 101,6 segundos de media y 0,50 dólares por ejecución media. Fue más lento y algo más caro que Ruby y Python, pero mantuvo una tasa de éxito perfecta.
¿Significa esto que Go no es buena opción para Claude Code?
No. El benchmark sugiere que Claude Code prototipa más rápido en lenguajes dinámicos, pero Go sigue ofreciendo buenos resultados, sin fallos en esta prueba, y mantiene ventajas propias en concurrencia, sistemas y robustez para proyectos reales.
¿Se puede decidir un stack real solo con este benchmark?
No. El propio autor avisa de que el experimento mide tareas de escala de prototipo y que en proyectos más grandes la tipificación, el ecosistema, el rendimiento y otros factores pueden cambiar mucho la conclusión.
