Por qué el inglés no puede estar equivocado

En enero de 2023, Andrej Karpathy publicó una frase que se citó hasta el cansancio: "El nuevo lenguaje de programación más popular es el inglés."

Era una buena frase porque era mayormente cierta, y era cierta de una forma que tardó dos años en volverse incómoda. En febrero de 2025, el propio Karpathy nombró la consecuencia. Lo llamó vibe coding: "Hay un nuevo tipo de programación que llamo 'vibe coding', donde te entregas por completo a las vibras, abrazas los exponenciales y olvidas que el código siquiera existe." El detalle operativo era la parte que valía la pena releer: "Siempre presiono 'Aceptar todo', ya no leo los diffs."

Merriam-Webster recogió el término en marzo de 2025 como expresión de jerga y tendencia. Collins English Dictionary lo nombró Palabra del Año 2025.

Detente un segundo en eso. Un diccionario, una institución cuya función entera es fijar significados con la firmeza suficiente para que un uso pueda contrastarse contra ellos, le dio su máximo honor anual a una práctica definida por no revisar el resultado. Eso no es un chiste técnico que se escapó de su contexto. Es una admisión a nivel cultural sobre hacia dónde se movió el trabajo.

La pregunta interesante no es si el vibe coding es bueno o malo. Es qué revelan sobre el inglés los dos años entre esas dos citas. El inglés fue ascendido a lenguaje de instrucción, y lo primero que hizo en el puesto fue dejar de verificar su propio trabajo. Eso no es una falla de disciplina de quienes lo usan. Es una propiedad del lenguaje mismo.

El defecto es la virtud

El inglés no puede estar equivocado.

No "rara vez está equivocado." No puede estarlo. No existe una operación que puedas correr sobre una oración en inglés que devuelva falso. Puedes estar en desacuerdo con una oración, malinterpretarla, encontrarla inútil, o descubrir después que el mundo no coincidió con ella. Pero la oración misma nunca falla. Siempre se puede interpretar. No tiene mecanismo para rechazarse a sí misma.

Considera tres instrucciones, cada una de las cuales suena completa.

"Hazlo más rápido." ¿Más rápido en qué sentido? Latencia, el tiempo que toma una solicitud. Throughput, el número de solicitudes atendidas por segundo. Velocidad percibida, el tiempo hasta que algo aparece, que es otra cosa distinta. ¿Costo por unidad de trabajo? Estas no son matices de una misma idea. Compiten entre sí. Optimizar por throughput típicamente empeora la latencia. Una respuesta a "hazlo más rápido" puede ser un éxito técnico y un fracaso completo de la instrucción.

"Reintenta las solicitudes fallidas." Suena a regla. Es una pregunta disfrazada de regla. ¿Qué es una solicitud fallida? ¿Una solicitud que fue rechazada, o una cuya respuesta nunca volvió? Son eventos distintos con la misma apariencia desde afuera. Si la solicitud original tuvo éxito y solo se perdió la confirmación, el reintento hace el trabajo dos veces. Cobra la tarjeta dos veces. Envía el pedido dos veces. La oración calla sobre lo único que importa, y calla mientras suena tajante.

"Solo los administradores pueden eliminar cuentas." ¿Quién cuenta como administrador, el rol, o cualquiera que pueda asumirlo actualmente? ¿La autoridad se delega, y de ser así, el delegado es administrador para efectos de esta oración? ¿Qué pasa con una sesión ya abierta cuando le revocan los permisos a alguien a mitad de vuelo? Cada una de estas es una decisión que la oración parece haber tomado y no ha tomado.

Ninguna de estas es una oración descuidada. Son oraciones ordinarias. El lenguaje natural está construido para funcionar así. La ambigüedad es compresión: quien habla omite lo que quien escucha puede reconstruir, y la reconstrucción suele ser correcta. El contexto hace el resto del trabajo. La contradicción se tolera porque un oyente competente la repara en silencio y sigue adelante, y ambas partes experimentan esto como comprensión, no como adivinanza.

Esas son propiedades extraordinarias en la conversación. Son defectos en la instrucción. El trabajo de una instrucción es eliminar futuros. Una oración que permite cuatro resultados incompatibles no ha instruido nada. Ha señalado una región y dejado que el lector elija un punto dentro de ella.

Esto no se limita al software. "La demanda será fuerte el próximo trimestre" es un pronóstico que no puede estar equivocado, porque "fuerte" no tiene umbral, y precisamente por eso sobrevive al trimestre que describe. "Aprobar descuentos caso por caso" es una política que no puede violarse. "Priorizaremos el trabajo de mayor impacto" es un plan compatible con cualquier asignación posible de esfuerzo. Todas estas oraciones pasan la reunión. Ninguna puede fallar, y eso es lo que las vuelve inútiles como restricciones y populares como lenguaje.

Lo que realmente compra un sistema formal

Un sistema formal empieza exactamente donde termina esa tolerancia.

Una función es correcta de tipo o no lo es. Una transacción satisface sus restricciones o la base de datos rechaza la escritura. Un esquema valida el registro o lo rechaza. Un plan de producción es factible frente a la capacidad o no lo es, y el solver te dirá cuál. Una prueba pasa o falla.

La historia convencional sobre los sistemas formales es que son precisos. Eso es cierto, y no es el punto. La precisión es el mecanismo. El producto es el rechazo.

Esa es la propiedad que el inglés no tiene y no puede recibir. Un sistema de tipos no es valioso porque describa tu intención con elegancia. Es valioso porque existen programas que no aceptará. Quítale la capacidad de rechazar y no has debilitado el sistema: lo has eliminado. Un sistema de tipos que acepta todo es un comentario. Una restricción de capacidad que nunca se activa es una nota al margen. Una prueba que no puede fallar es decoración.

La economía se invirtió, y nadie se movió

Durante la mayor parte de la historia del trabajo del conocimiento, el artefacto era la parte cara. Escribir el código, construir el modelo, redactar el documento, producir el plan: ahí se iban las horas. Revisar era comparativamente barato, y en su mayoría implícito: producir la cosa te obligaba a pensarla bien. La lentitud era trabajo de verificación hecho fuera de los libros. No podías escribir el párrafo sin haber decidido qué querías decir.

Ese acoplamiento desapareció. Generar es ahora casi gratis, y el artefacto llega en segundos.

Revisar no se abarató. Es la única parte del proceso cuyo costo no cambió, así que a medida que todo lo demás colapsó en precio, su participación en el total se acercó a casi todo. Lo escaso ya no es la capacidad de producir el artefacto. Es la existencia de algo dispuesto y capaz de decirle que no.

Y aquí las dos propiedades chocan. Una instrucción que no puede estar equivocada no se puede verificar. Una instrucción que no se puede verificar no se puede confiar a volumen.

Volumen es la palabra que hace el trabajo. Un borrador generado está bien; una persona lo lee, y su juicio es la verificación. Mil borradores generados no se pueden leer, y la revisión humana simplemente deja de ocurrir, no por decisión, sino por aritmética. Ese es el contenido honesto de "ya no leo los diffs". No es pereza. Es lo que le pasa a cualquier paso de verificación manual cuando lo que se está verificando empieza a llegar más rápido de lo que una persona puede absorber. La revisión no se anula. Se queda atrás.

La complicación, dicha con honestidad

La lectura obvia de todo esto es "sé preciso, siempre, desde el inicio." Esa lectura está equivocada, y está equivocada de una forma costosa.

La ambigüedad es genuinamente útil al principio. La intención vaga es cómo empieza el trabajo. "Algo anda mal con cómo renuevan los clientes" no es una especificación y no podría serlo: todavía nadie sabe lo suficiente para escribirla. La vaguedad de esa oración es lo que permite que cuatro personas con distinta experiencia se paren frente a ella y cada una vea un problema abordable distinto. La precisión prematura mata eso. Una especificación escrita antes de que alguien entienda la cosa no capta el problema; lo clausura. Formalizar demasiado pronto convierte una pregunta abierta en una respuesta equivocada con buena postura.

Así que el argumento no es que la formalidad deba ir primero. Es que lo vago tiene que terminar aterrizando en algo capaz de rechazarlo. La exploración es una fase, no un destino. La oración puede quedarse blanda mientras todavía encuentra su forma, y luego tiene que encontrarse con algo con poder para rechazarla: un esquema, un tipo, una restricción, una prueba de factibilidad, una prueba, un número con un umbral adjunto.

El modo de falla de este momento en particular es que la gente se salta ese aterrizaje, porque el resultado ya parece terminado. La fluidez solía ser evidencia débil de cuidado. Costaba algo producir un artefacto limpio, seguro y bien estructurado, y ese costo era mayormente pensar. Ahora no cuesta nada. Las señales superficiales que un lector pasó décadas aprendiendo a leer como competencia se han desacoplado por completo de la competencia, y el reconocimiento de patrones humano no se ha puesto al día.

Adónde se fue el apalancamiento

Si generar es gratis y rechazar es escaso, entonces el apalancamiento está donde estén las restricciones.

No en el prompt. El prompt es inglés; aceptará cualquier cosa. No en el modelo, cuya fluidez es precisamente la razón por la que su producción se desliza más allá de la revisión. El apalancamiento está en el esquema que rechaza el registro mal formado, el tipo que no compilará, la restricción que el solver no puede satisfacer y lo dice, la prueba que falla, el umbral de aceptación definido antes de que llegara el resultado en lugar de después.

Ese trabajo no tiene glamour y es adonde se movió el valor. Cualquiera puede producir ahora un plan. La habilidad escasa es decir de antemano qué lo haría infactible. Cualquiera puede producir un pronóstico. La habilidad escasa es nombrar el número que lo hace estar equivocado, antes de que sea conveniente saberlo. Cualquiera puede generar el código. La habilidad escasa es construir lo que no lo aceptará.

La frase de Karpathy en 2023 tenía razón. El inglés es el nuevo lenguaje de programación más popular, y 2025 canonizó lo que eso cuesta. El inglés aceptará cualquier cosa que le digas. También el modelo. En algún punto río abajo, algo tiene que ser capaz de decir que no, y si nada en la cadena puede hacerlo, entonces nada fue verificado. Solo fue producido.

---

Sources

• Karpathy, A. (2023). "The hottest new programming language is English." X/Twitter, 24 January 2023.
• Karpathy, A. (2025). Post coining "vibe coding." X/Twitter, February 2025.
• Merriam-Webster. (2025). "Vibe coding," Slang & Trending listing. March 2025. merriam-webster.com
• Collins English Dictionary. (2025). Word of the Year 2025: "vibe coding." Announced 6 November 2025. collinsdictionary.com
• BBC News. (2025). "Vibe coding" named word of the year by Collins Dictionary. 6 November 2025. bbc.com
• The Independent. (2025). What does vibe coding mean? The AI term crowned Collins word of the year. 6 November 2025. independent.co.uk