El Código Siempre Se Dirigía al Inglés. Ya Llegó.

Cada desarrollador senior que me cruzo estos días (10, 15 años de empresas, migraciones, stacks abandonados en el peor momento, gente que sobrevivió a la era donde todo tenía que ser microservicios incluso para una app CRUD que manejaba 12 usuarios al día) carga con lo mismo. "No sé si debería seguir aprendiendo a programar o mejorar en prompting." "Enseño en la universidad, pero ¿deberíamos seguir enseñando PHP a estudiantes que se graduarán en 4 años..." "Mi trabajo no se parece a lo que era hace 1 año, no sé por qué."

Tokenmaxxer o pro vibe-coder. ¿Cuál eliges?

Lo que me mata cada vez no es la preocupación. Es la precisión de la confusión. Esta gente debuggea race conditions en producción, ven los ciclos de hype llegar desde lejos. Y sin embargo: el mismo vacío al final de la frase. Reconocí ese vacío. Ya hemos estado aquí antes. Solo que no con LLMs.

Cada Conversación. El Mismo Silencio.

El ángulo de la enseñanza sigue apareciendo en todas estas conversaciones, y es el que más me marca. "¿Sigo enseñando Python a estudiantes que se graduarán en 4 años?" Tiene una fecha límite dura. La persona que pregunta tiene que tomar una decisión curricular para septiembre. No hay espacio para "veamos cómo evoluciona."

A través de foros, servidores de Discord, hilos de Slack: alguien construyendo SaaS en Next.js, alguien manejando un estudio de desarrollo de 3 personas tratando de decidir si capacitarse en agentes o profundizar en fundamentos, alguien que hace integraciones para vivir y se pregunta si ese trabajo todavía existe en 18 meses. Diferentes países, diferentes stacks, diferentes contextos.

No "no entiendo qué está pasando." Más bien: "Puedo sentir que algo está cambiando pero no puedo nombrarlo. Y he pasado por suficientes transiciones para saber que eso importa."

Esa última parte es la clave. No saber qué está pasando es incómodo. No poder nombrar algo que claramente puedes sentir es un tipo de incomodidad completamente diferente. Usualmente significa que el vocabulario no se ha puesto al día todavía.

Pasé 40 minutos el martes pasado tratando de nombrar una carpeta. No un repo. Una carpeta. El problema de naming en software es eterno y los LLMs no lo mejoran. Generan más nombres malos que suenan plausibles, más rápido. Eso es todo, sigamos.

70 Años, Una Dirección

Hay algo que nadie enseña en ciencias de la computación porque arruina la mística de "los lenguajes son difíciles": desde 1957, cada generación de lenguajes de programación se movió en la misma dirección, hacia el inglés, sin excepción.

El código máquina era binario. Assembly te daba mnemónicos que casi podías leer si entrecerrabas los ojos. Luego FORTRAN y COBOL, en 1957 y 1959, llegaron con algo que nunca había existido antes: una línea de código que podías leer en voz alta sin explicación. "MULTIPLY HOURS-WORKED BY HOURLY-RATE GIVING GROSS-PAY." Eso es COBOL. Un gerente de negocios en 1960 podía parsearlo en frío, sin experiencia en programación.

[INFOGRAPHIC: TITLE "70 Años Moviéndose Hacia el Inglés" + subtitle "una dirección, sin excepciones". Metaphor: a long horizontal road with 5 milestone road signs, left-to-right progression from binary to speech bubble. Style: Franco-Belgian ligne claire comic, thick black outlines, flat colors, clean horizon. Palette: cobalt blue #1A4FD8, signal red #E8291C, warm cream #FFF9F0, black #111111, light gray #DDDDDD. Content: 5 signs labeled MACHINE CODE (1950), ASSEMBLY (1952), COBOL/FORTRAN (1957-1959), PYTHON (1991), LLMs (2026). Each sign shows a small developer figure getting progressively more relaxed, last figure standing with mouth open and no keyboard visible. Highlight: LLMs sign in signal red with starburst, figure gesturing without keyboard. Footer: copyright rentierdigital.xyz. NOT flat corporate infographic, NOT minimalist tech aesthetic, NOT boring timeline with dots.]

Python, cuando llegó en 1991, fue diseñado explícitamente para leerse como pseudocódigo. La legibilidad no fue un accidente, fue un objetivo de diseño, declarado en la propia documentación del lenguaje. Y cada transición tuvo la misma reacción de la generación siendo desplazada. "Demasiada abstracción." "Pierdes control." "Eso no es programación real." FORTRAN fue considerado peligrosamente alto nivel en 1957. A la gente que lo escribía le dijeron que los compiladores nunca podrían igualar assembly optimizado a mano. Misma reacción, diferente archivo guardado. Estaban equivocados. La gente que llamó a Python demasiado lento y no código real en 1991 también estaba equivocada.

Esto no es una revolución. Es la continuación de un movimiento de 70 años.

La Pregunta Ya Es Obsoleta

Todos preguntan si deberían seguir aprendiendo a programar. La pregunta ya es obsoleta. Eso suena más dramático de lo que es.

Lo que pasó con cada capa de abstracción anterior: la capa de abajo no desapareció. Assembly todavía existe. COBOL todavía ejecuta más transacciones bancarias que cualquier otro lenguaje en la tierra (creo que hay más líneas de COBOL en producción activa hoy que líneas de Python, aunque nadie quiere decir eso en una charla de conferencia). La pregunta nunca fue "¿desaparece la capa vieja?" Siempre fue "¿qué cambia la nueva capa sobre cuándo usar qué herramienta?"

Por primera vez en la historia de la computación, la nueva capa de abstracción no es un lenguaje ligeramente más legible que el anterior. Es un sistema que ya entiende lenguaje humano y puede ejecutarlo directamente. El intermediario sintáctico es, por primera vez, opcional. No desaparecido. Opcional.

Eso cambia cuál es la pregunta real. El post viral de X burlándose de "80% del código escrito por AI en 2025, luego 100%, luego 12%, luego 300% de bugs en 2028" tuvo más de 1 millón de vistas porque el enfoque es absurdo y la gente lo reconoció inmediatamente. No es una pregunta de porcentaje. Es una pregunta de capas.

Pero hay una segunda pregunta dentro de la pregunta de capas, y es la incómoda: ¿qué pasa cuando tus especificaciones se vuelven directamente ejecutables? Cuando la spec no es un documento que le das a un desarrollador que escribe código, sino algo que el LLM ejecuta directamente, sin intermediario, sin traducción? En un flujo de trabajo AI-first hoy, todavía hay un humano que lee la spec y escribe código que traduce intención en algo ejecutable. El LLM asiste, acelera, a veces genera la mayor parte del código. Pero el paso de traducción todavía está ahí. La pregunta que incomoda a la gente no es "¿desaparece ese paso?" Es "¿para qué categorías de problema desaparece primero, y qué tan rápido se mueve esa línea?" El movimiento de 70 años acaba de llegar a su destino lógico para esas categorías. No para todos los problemas. Ni siquiera la mayoría, todavía. Pero la dirección no ha cambiado en 7 décadas.

Tokenmaxxing y Vibe Coding Son Síntomas, No Estrategias

Aquí es donde se supone que te digo que uno de estos está bien y el otro mal. Ambos son síntomas de lo mismo.

Tokenmaxxing es lo que haces cuando crees que más contexto siempre ayuda. Vibe coding es lo que haces cuando crees que el LLM maneja todo si te quitas del camino. Ninguno es una estrategia. Ambos son el comportamiento de alguien que puede sentir el cambio de capa sucediendo pero no ha desarrollado el modelo mental para ello todavía.

Una historia que circula en la comunidad: un builder envió 540k líneas. Entre ellas, 276k líneas de tests. 33 cron jobs. El post-mortem fue brutal. Los tests estaban controlando un agente que no necesitaba control. Los cron jobs estaban monitoreando un sistema que ya se gestionaba solo. Todo ese código era una jaula. El instinto estaba bien (controlar lo que importa), el modelo estaba mal (el código sigue siendo cómo obtienes control en el nuevo paradigma). YOU DIED. La próxima vez tal vez construye la cárcel después de confirmar que el prisionero necesita una.

Mismo impulso, dirección opuesta: alguien construye 2 pipelines paralelos para la misma tarea. Uno es impresionante, con loops de feedback y agentes en cascada. El otro son 4 archivos. Ponen ambos frente a un LLM y preguntan cuál extender. Dada la opción entre arquitectónicamente impresionante y algo que simplemente funcionaba en 4 archivos, el modelo eligió la versión de 4 archivos cada vez.

Ambos patrones son exactamente lo que hacían los primeros programadores de COBOL cuando obtuvieron acceso a un lenguaje de alto nivel: estructuraron su código como el assembly que conocían antes, porque no tenían un nuevo modelo mental todavía. El modelo viejo aplicado a una nueva capa produce desperdicio en cualquier dirección, ya sea 540k líneas de construcción de jaulas o 1000x token burn en una tarea que necesitaba 4 archivos.

El punto de partida práctico para no caer en ninguna de estas trampas es el método Blueprint en Vibe Coding, For Real, lo suficientemente estructurado para que no estés haciendo vibe-coding a ciegas, lo suficientemente ligero para que no estés construyendo la jaula. Y a nivel de infraestructura, why CLIs beat MCP layers for AI agents aplica la misma lección al tooling: menos abstracción, más predictibilidad.

3 Objeciones. 3 Paralelos Históricos.

Las 3 objeciones serias a este cambio de capa merecen respuestas reales.

El costo. AI agéntica consume hasta 1000x más tokens que una llamada estándar de LLM. Microsoft, Meta y Amazon retrocedieron en tokenmaxxing interno este año. 1 constructor de infraestructura citó públicamente $1.3M en tokens en un solo mes. Eso es dinero real. El paralelo: las primeras ejecuciones de compilador eran caras. IBM cobraba por ciclo de CPU en 1957. La pregunta siempre fue si la ganancia de productividad justificaba el costo, y lo hizo. Los costos de tokens están cayendo aproximadamente 10x cada 18 meses. Mintlify redujo el consumo de tokens 30x sirviendo Markdown a sus agentes en lugar de HTML. Cloudflare redujo 80%. La objeción del costo es un problema de tooling con soluciones ya en producción.

La confiabilidad. El estudio de ETH Zurich (438 tareas de coding, abril 2026) encontró algo contraintuitivo: archivos AGENTS.md generados por LLMs redujeron el éxito de tareas en 3% y aumentaron el costo en 20%. AGENTS.md escritos por humanos: subieron 4% en éxito. La interpretación importa aquí: esto es evidencia de que las prácticas para esta capa tienen 2 años, no 20, no que los LLMs fundamentalmente no se puedan confiar. FORTRAN no era confiable en 1957. Tomó años de fallas acumuladas en producción antes de que los equipos confiaran en él en rutas críticas. Estamos en el equivalente de 1959 con AI agéntica. Las prácticas se están formando ahora, exactamente como siempre han hecho.

La seguridad. Real, y no resuelta todavía. Los buffer overflows fueron descubiertos en los 1970s y todavía se encuentran en código legacy hoy. SQL injection fue descrito formalmente en 1998 y permanece en el top 10 de OWASP. Los problemas de seguridad introducidos por nuevas capas de abstracción son problemas de ingeniería que se resuelven con el tiempo, con incidentes en el camino. La capa LLM ya tiene su propia versión. Eso no es un argumento contra la capa.

Lo Que Realmente Estás Decidiendo

Los 7 devs no podían nombrar su incomodidad. Aquí está lo que es: el perímetro de su trabajo se movió. El trabajo no desapareció. El perímetro se movió.

El código no va a desaparecer. Se está convirtiendo en el lenguaje de las capas determinísticas, las partes donde estar equivocado cuesta algo real. Una validación de pago, un webhook ruteado al handler correcto basado en un enum fijo, un límite de auth, una operación que debe suceder exactamente una vez o no suceder en absoluto — esos problemas viven en código porque el código es auditable, testeable, determinístico. No tokenmaxxeas tu camino a través de una transacción financiera.

El lenguaje natural toma las capas intencionales: generar una descripción de producto desde input del usuario, decidir qué contenido mostrar para un segmento de usuario, redactar una respuesta a un ticket de soporte que cayó en un caso edge que tu spec no cubrió. Esos problemas viven en prompts y specs porque son sobre intención expresada, donde la iteración en comportamiento importa más que ejecución exacta. Que la spec se vuelva directamente ejecutable es el punto ahí, no un riesgo.

La pregunta concreta para un builder hoy no es "¿sigo escribiendo código?" Es "¿dónde vive este problema específico?" La validación de pago vive en código, y también rutear un webhook a un enum fijo o hacer cumplir un límite de auth. Generar descripciones de producto desde input del usuario vive en una spec, y también ajustar el subject de un email al historial de un usuario. La línea se mueve mientras los LLMs se vuelven más confiables en contextos determinísticos. Pero el modelo mental para dibujarla está disponible ahora mismo.

El profesor decidiendo su currículum para septiembre tiene una respuesta más clara de lo que piensa. Enseñar por qué existe el código en absoluto. Qué es un tipo, qué es una excepción, qué significa que una operación sea idempotente. No PHP específicamente, porque los lenguajes específicos importan menos cada año. Estudiantes que entienden por qué el determinismo es valioso sabrán qué usar y cuándo, sin importar cómo se vea el stack en 4 años.

How to stop gambling on prompts and start shipping es un framework práctico si ahí es donde estás atascado en el lado intencional.

El vacío al final de la frase que esos 7 devs no podían llenar no era ignorancia. Era lucidez, llegando antes de que el vocabulario lo hiciera.

El cambio ya pasó. Ahora el vocabulario necesita ponerse al día.

Fuentes

• Tom's Hardware, "AI cost crisis hits tech giants as employee tokenmaxxing backfires" (May 23, 2026): https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-cost-crisis-hits-tech-giants-as-employee-tokenmaxxing-backfires-agentic-ai-eats-up-to-1000x-more-tokens-than-standard-ai-sparks-corporate-pullback-at-microsoft-meta-and-amazon
• Kamil Banc, "Token maxing is what you do when you can't budget" (AI Adopters Club, May 12, 2026): https://aiadopters.club/p/token-maxing-is-what-you-do-when
• ETH Zurich SRI Lab, 438 coding tasks study (arxiv, April 2026): https://arxiv.org/abs/2503.13501

Este post puede contener enlaces de afiliados. Si los clickeas, podría ganar una pequeña comisión — no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura.