¿Deberías hablarle a Claude en inglés o en tu idioma nativo?

El contexto

Soy un ingeniero de software hispanohablante que usa Claude Code como herramienta principal de desarrollo. En los últimos meses he acumulado ~2.000 sesiones y 620K+ mensajes de uso real. Mi flujo de trabajo está muy orientado a la ejecución: sesiones largas de depuración, discusiones de arquitectura, revisiones de código. (Aquí ponía originalmente “todo en español” — los datos de la Parte 4 cuentan una verdad más interesante.)

En algún momento me hice la pregunta obvia: ¿debería estar escribiendo todos estos prompts en inglés? El inglés es la lingua franca de la programación. La mayoría de los datos de entrenamiento están en inglés. Todos los benchmarks están en inglés. Seguro que estoy perdiendo rendimiento, ¿no?

Decidí averiguarlo.

Parte 1: El impuesto de tokens

Los LLMs no ven palabras — ven tokens. Y los tokenizers están fuertemente optimizados para el inglés. La palabra authentication es un solo token. Su equivalente en español, autenticación, son tres tokens.

Pasé prompts equivalentes por el tokenizer de Claude (proxy cl100k_base) para medir el coste real. Estos son prompts reales que uso a diario en Claude Code:

Eso es un sobrecoste del 54,5% en tokens de media. Para prompts más largos y complejos, empeora — el prompt de revisión de código llegó al +63%.

¿Por qué la diferencia es tan grande?

Los tokenizers BPE construyen su vocabulario a partir de datos de entrenamiento, que son predominantemente en inglés. Las palabras comunes en inglés tienen su propio token. Las palabras en español a menudo se dividen en sub-palabras:

Observa que middleware se mantiene en 1 token en ambos idiomas — los términos técnicos tomados directamente del inglés no pagan el impuesto. Esto es importante: cuanto más técnico sea tu prompt, más anglicismos contiene, y menor es la diferencia.

Parte 2: La realidad de la ventana de contexto

En una sesión típica de Claude Code, tus prompts son una fracción mínima del contexto total. Esto es lo que realmente llena la ventana de contexto:

Tus mensajes suelen representar ~10% del contexto. Un sobrecoste del 54% sobre el 10% del contexto es un aumento del ~5,5% en el uso total de tokens. Ese es el número real.

Parte 3: ¿Afecta el idioma a la calidad?

Esta es la pregunta que realmente importa. Los tokens son dinero, pero la calidad lo es todo.

Para generación de código: sin diferencia significativa

Claude genera el mismo Go, TypeScript o Python independientemente de si le preguntas en inglés o en español. La salida de código es agnóstica al idioma. Los nombres de variables, las firmas de funciones y las decisiones de arquitectura no cambian según el idioma del prompt.

Considera estos dos prompts equivalentes:

Ambos producen código idéntico. Los nombres de funciones generados, las consultas SQL, los structs de respuesta — todo igual. Claude entiende la intención independientemente del idioma que la envuelve.

Para tareas de razonamiento: ligera ventaja del inglés

Los benchmarks académicos como MMLU y GSM8K muestran una pequeña ventaja (2-5%) para prompts en inglés en tareas que requieren mucho razonamiento. Es esperable — el modelo ha visto más ejemplos de razonamiento encadenado en inglés durante el entrenamiento.

Pero hay un matiz: esos benchmarks evalúan el idioma del modelo, no el tuyo. Cuando escribes en español, Claude sigue razonando internamente en la representación que usa y solo traduce la salida final. No le estás obligando a “pensar en español”.

Para claridad en las instrucciones: gana el idioma nativo

Aquí es donde está la diferencia real. Testé mi propia velocidad de escritura y descubrí que escribo ~30% más rápido en español que en inglés. No solo más rápido — también con más precisión. Cuando intenté escribir una nota rápida en inglés para probarlo, inmediatamente cometí una errata. ¿En español? Limpio a la primera.

Cuando intentaba escribir prompts en inglés:

• Pasaba más tiempo redactando el prompt en vez de describir lo que quería
• Ocasionalmente usaba expresiones ambiguas que no usaría en español
• Las discusiones arquitectónicas complejas perdían matices
• Simplificaba las descripciones para evitar la fricción del idioma
• Más erratas, que a veces confundían al modelo

Cuando escribo en español, expreso exactamente lo que quiero decir, con todos los matices, condiciones y casos límite. Un prompt que me lleva 5 segundos en español me lleva 8-10 en inglés — y la versión en español suele ser más precisa y sin erratas.

Parte 4: Los números — y el día que cambié de idioma

Esta es la sección que reescribí en mayo de 2026. La versión original listaba unos números redondos enormes que no pude reproducir desde mis logs reales, así que aquí van los agregados verificados directamente de las estadísticas de uso de Claude Code (2025-12-23 → 2026-05-06, 108 días activos):

• 621.987 mensajes intercambiados
• 1.980 sesiones
• 141.279 llamadas a herramientas (todas las herramientas, no solo bash)
• ~23.600 prompts escritos por mí, registrados en mi historial de prompts desde septiembre de 2025

Pero el verdadero hallazgo no estaba en los totales — estaba en los timestamps. Asumía que era un usuario estable “60/40 español-inglés”. No lo soy. Clasifiqué todos los ~23.600 prompts por idioma y los agrupé por mes:

Hasta diciembre de 2025 escribí casi todo en inglés. Luego, entre enero y febrero de 2026, salté a casi todo en español — y me quedé ahí. La “mezcla 60/40” que imaginaba no existe; era una media que ocultaba dos épocas opuestas. (Lo que también significa que, cuando publiqué esto en marzo, mi marco de “años en español” era erróneo — acababa de cambiar.)

Qué cambió al pasarme al español

La señal limpia es la primera: en español escribo prompts un 44% más cortos. Es exactamente el efecto de “menos fricción en mi idioma nativo” de la Parte 3, ahora visible en 13.000 prompts — digo lo que quiero con menos esfuerzo.

La tasa de corrección subió un poco, pero no lo leo como “Claude entiende peor mi español”, por tres razones: (1) la familia de modelos también cambió entre épocas, así que está confundido; (2) prompts más cortos llevan menos detalle por adelantado, así que itero más en vez de especificarlo todo de golpe — un cambio de flujo de trabajo, no una mala interpretación; y (3) el pico fue justo el mes en que cambié (un mes de adaptación torpe) y luego bajó acercándose al nivel base de la época inglesa. El idioma no era el cuello de botella — la claridad sí lo es, y los modos de fallo (requisitos ambiguos, contexto faltante, casos límite poco especificados) son idénticos en ambos idiomas.

Parte 5: El coste real

Pongamos números reales. Con Claude Sonnet a $3/M tokens de entrada:

El “impuesto” del español en mis prompts de entrada cuesta aproximadamente 23 céntimos al mes. Eso es menos de un céntimo por día laborable. Y recuerda: esto solo afecta a tus mensajes, no al system prompt, los resultados de herramientas o el contenido del código que componen la mayor parte del uso de tokens.

Con el modelo de suscripción de Claude Code, esto es aún menos relevante — pagas una tarifa plana independientemente del número de tokens.

Parte 6: Qué dice la investigación

Tras escribir la primera versión, busqué si alguien había estudiado esto en serio. Lo han hecho — pero casi siempre como benchmarks controlados (traducir la misma tarea a ambos idiomas, manteniendo al humano constante), nunca como el uso longitudinal de un desarrollador real. La literatura se divide en tres corrientes que parecen contradictorias hasta que te fijas en qué caso mide cada una:

• El inglés gana en benchmarks de razonamiento. Un estudio de árabe vs inglés encontró que el inglés ganaba en todas las tareas (7–9%), incluso en un modelo nativo de árabe. Las grandes suites multilingües muestran lo mismo, con brechas de hasta +20 puntos — pero concentradas en idiomas de bajos recursos y tareas de razonamiento puro. Y, clave: el conocimiento de código es la dimensión que mejor se transfiere entre idiomas.
• La lengua nativa gana para output en lengua nativa. Los estudios de “haz coincidir el prompt con el contenido” reportan hasta +50% en extracción/localización — pero solo cuando generas texto en ese idioma. No es mi caso: mi output es código.
• El impuesto de tokens es real. Mediciones independientes sitúan el español en ~25–60% más tokens (árabe/japonés 3×+). Coincide con mi +50%.

Para código en concreto, hay “sesgo lingüístico” medido (p.ej. un prompt en un idioma dando una solución O(n²) donde el inglés daba O(n·log n)), y los prompts mezclados pueden perjudicar — pero ambos efectos tienden a cero en modelos frontera grandes.

Referencias: Native Design Bias, Native vs Non-Native Prompting, Better to Ask in English, Linguistic Bias in Code Generation, CodeMixBench, How NL Proficiency Shapes GenAI Code, llm-language-token-tax. Lista completa en el apéndice de datos.

El veredicto

Dos matices. Primero: si escribes prompts que se van a compartir como plantillas con un equipo angloparlante, escríbelos en inglés. Segundo, y más honesto: este consejo es más fuerte para mi situación exacta — un idioma de altos recursos, output de código y un modelo frontera. Si hablas un idioma de bajos recursos y te apoyas en el modelo para razonamiento puro intenso, la brecha a favor del inglés es mayor y el trade-off es real. Pero para el trabajo diario de programación — depurar, arquitectura, “arregla este bug” — usa el idioma que te permita pensar más rápido.

Eso es lo que hago yo. ~23.000 prompts después, y no pienso volver atrás.

Análisis de Jairo Caro-Accino. Originalmente marzo 2026; datos auditados y actualizados en mayo 2026. Conteos de tokens medidos con la API count_tokens de Claude (y cl100k_base para la tabla original). Datos de sesiones y prompts de los logs locales de Claude Code (history.jsonl, estadísticas de uso). Metodología completa en el apéndice de datos.