Si la IA escribe el código, ¿por qué usar Python?
(medium.com/@NMitchem)- Con el desarrollo asistido por IA, el criterio para elegir lenguajes pasa de la velocidad de escritura humana a la capacidad de la IA para corregir y al rendimiento en ejecución
- En 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1 y DeepSeek V4 superaron el 80% en SWE-bench Verified
- En Rust, el bucle de retroalimentación del compilador ayuda a la autocorrección de la IA, y Go y Swift también favorecen a los agentes con una verificación de tipos rápida
- Ya están en marcha grandes transiciones, como el port de TypeScript Compiler a Go, un compilador de C basado en Rust, Rue y el port del motor JavaScript de Ladybird
- Los ecosistemas de Python y JavaScript también dependen cada vez más de herramientas y wrappers en Rust, aunque siguen existiendo excepciones como Prisma, PyTorch y lenguajes pequeños
El desarrollo asistido por IA cambió los criterios para elegir lenguaje
- Durante mucho tiempo, la opción por defecto para proyectos nuevos fue Python o TypeScript
- Porque tenían ecosistemas grandes, un amplio mercado de contratación y permitían crear demos rápidamente
- Rust, Go y C++ podían ofrecer un rendimiento entre 10 y 100 veces mayor, pero el tiempo de aprendizaje, el mercado de talento más pequeño y los sistemas de build complejos actuaban como costo
- Por eso, primero se lanzaba una versión en Python y se decía “luego mejoramos el rendimiento”, pero en la práctica muchas veces se quedaba así
- Ese intercambio empezó a tambalearse cuando la IA comenzó a manejar lenguajes difíciles
- Al elegir lenguaje, ahora pesa más si “la IA puede escribirlo y corregirlo bien” y el rendimiento en ejecución, que si “una persona puede escribirlo rápido”
Los lenguajes difíciles primero se volvieron fáciles para la IA
- Hace 2 años, GPT-4 apenas estaba en un nivel en el que inventaba nombres de crates inexistentes al escribir funciones en Rust
- En abril de 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1 y DeepSeek V4 superaron el 80% en SWE-bench Verified con pocas semanas de diferencia
- Los laboratorios están optimizando de forma explícita el trabajo en sistemas
- bugs de concurrencia
- condiciones de carrera
- defectos de arquitectura detectados en la etapa de planeación
- CtrlAltDwayne encuentra la fortaleza de Rust en 2026 no en la seguridad de memoria ni en el rendimiento, sino en el bucle de retroalimentación del compilador
- La IA escribe mejor Rust que C++
- Los mensajes de error del compilador de Rust se convierten en una señal que ayuda a la autocorrección en tiempo real del modelo
- Rust funciona como si fuera un lenguaje “accidentalmente diseñado” 10 años antes para el desarrollo asistido por IA
- La misma lógica también aplica, en distinto grado, a Go y Swift
- Los sistemas de tipos fuertes y los bucles rápidos de compilación y verificación les dan a los agentes ciclos de iteración más cerrados
- Los lenguajes de sistemas que eran difíciles para las personas pueden convertirse, al contrario, en objetivos más fáciles para los agentes
Casos que ya se lanzaron en la práctica
-
Port de Microsoft del compilador de TypeScript a Go
- Microsoft lanzó TypeScript 7.0 beta y llevó una base de código de TypeScript con 10 años de antigüedad a Go
- TypeScript 7.0 beta es aproximadamente 10 veces más rápido que 6.0
- Según la evaluación de Anders Hejlsberg, Go ofrece la mayor parte de las ventajas de rendimiento con solo una fracción del costo de ingeniería
- El cálculo de costo-beneficio cambió al punto de que una de las organizaciones de JS/TS más grandes eligió un lenguaje más difícil y más rápido para una herramienta central
-
Un compilador de C basado en Rust hecho con 16 agentes de Claude
- El investigador de Anthropic Nicholas Carlini coordinó en paralelo 16 agentes de Claude para escribir un compilador de C de producción en Rust
- Su escala fue de 100 mil líneas y logró arrancar Linux 6.9 en x86, ARM y RISC-V
- Compiló QEMU, FFmpeg, SQLite, PostgreSQL y Redis, y hasta ejecutó Doom
- El costo total fue de menos de 20 mil dólares a lo largo de casi 2,000 sesiones de Claude Code
- Un compilador de C escrito en Rust antes era un trabajo al nivel de una tesis de posgrado, pero ahora dejó de ser algo únicamente excepcional
-
Rue, de Steve Klabnik
- Steve Klabnik, coautor de The Rust Programming Language y veterano de Rust con 13 años de experiencia, creó junto con Claude un nuevo lenguaje de sistemas llamado Rue en 2 semanas
- El resultado fue de aproximadamente 70 mil líneas de Rust
- Dijo que este trabajo de 2 semanas avanzó más que intentos anteriores en los que había invertido uno o dos meses
-
Port a Rust del motor JavaScript de Ladybird
- Andreas Kling, fundador del navegador Ladybird e ingeniero de C++, hizo con Claude Code y Codex un port en 2 semanas del motor JavaScript de Ladybird de C++ a Rust, usando cientos de prompts pequeños
- El resultado fue de alrededor de 25 mil líneas de Rust, con equivalencia byte por byte respecto al original en C++
- No hubo regresiones en más de 65 mil pruebas combinando test262 y las pruebas de Ladybird
- Dijo que hacer lo mismo a mano habría tomado varios meses
La lógica del “ecosistema” se debilita
- El argumento más fuerte de Python y JavaScript era menos el lenguaje en sí y más el ecosistema
- Existían bases como FastAPI, Django, PyTorch, React, Next.js y los 4 millones de paquetes de npm
- Los equipos podían lanzar funciones en cuestión de días porque el ecosistema ya resolvía el 90% del problema
- Esa ventaja fue decisiva durante la última década, pero en los últimos 2 años empezó a debilitarse
- Incluso dentro del ecosistema de Python hay una dependencia creciente de componentes basados en Rust
- El núcleo completo de validación de
pydantices una librería en Rust - Polars, alternativa a pandas, está escrito en Rust
- Hugging Face tokenizers y orjson también están en Rust
- Según la encuesta Python 2025 de JetBrains, el uso de Rust en extensiones binarias de Python subió de 27% a 33% en un año
- El núcleo completo de validación de
- La base de las herramientas de desarrollo se mueve en la misma dirección
- Astral, fundada en 2022 por Charlie Marsh, lanzó ruff, uv y ty, escritos en Rust, y las descargas mensuales de las tres herramientas crecieron de 0 a cientos de millones
- El 19 de marzo de 2026, OpenAI adquirió Astral y considera que uv ahorra a Codex alrededor de 1 millón de minutos de cómputo por semana
- Hace 10 semanas, Anthropic también adquirió Bun
- Bun registró 7 millones de descargas mensuales y 89 mil estrellas en GitHub, y fue descrito como “infraestructura esencial para la ingeniería de software impulsada por IA”
- VoidZero, de Evan You, lanzó Rolldown-Vite
- Este bundler en Rust redujo un build de 2.5 minutos de GitLab a 40 segundos y bajó el uso de memoria a una centésima parte
- Lee Robinson, vicepresidente de producto en Vercel, dijo que “ya llegamos al techo de optimización en JS”
- Los paquetes que se consumen desde Python y JavaScript se están convirtiendo cada vez más en wrappers de código escrito en lenguajes que antes se consideraban difíciles de llevar directamente a producción
- Si ahora se puede lanzar directamente en esos lenguajes, los wrappers empiezan a verse como overhead
Un cambio donde portar se vuelve más fácil que parchear
- El círculo virtuoso del ecosistema open source existente estaba centrado en parches
- Se elegía Python porque era fácil
- Se encontraba un bug en una dependencia
- Se corregía y se enviaba upstream
- El ecosistema se volvía más saludable
- Los agentes están moviendo la unidad de contribución del parche al port
- En enero, Armin Ronacher, creador de Flask, usó agentes para portar a Go la librería en Rust MiniJinja
- El tiempo total de ejecución fue de 10 horas
- De esas, supervisó 3 horas y 7 transcurrieron sin intervención
- El tiempo humano real fue de 45 minutos
- El costo de API fue de 60 dólares
- Si portar una librería entre lenguajes se convierte en una tarea de 45 minutos, el argumento para enviar cambios a la librería de otra persona se debilita
- Ya no es “si puedes parchearlo, ¿por qué no hacer fork?”, sino “si puedes hacer fork, ¿por qué parchearlo?”
- Armin Ronacher cree que el valor se está moviendo del código hacia las pruebas y la documentación
- Una buena suite de pruebas puede valer más que el código
- El ciclo que construyó PyPI y npm todavía funciona, pero no está claro si seguirá funcionando igual en 2028
Excepciones que todavía permanecen
- No todos los cambios fluyen en una sola dirección
- En algunos casos, la elección tradicional sigue siendo la correcta
- Prisma eliminó su query engine en Rust y migró a un núcleo TypeScript/WASM
- El tamaño del bundle se redujo en 85% y las consultas fueron hasta 3.4 veces más rápidas
- Los binarios nativos en Rust juegan en desventaja en runtimes serverless
- PyTorch todavía representa alrededor del 85% de la investigación en deep learning
- Como los pesos del modelo no dependen del lenguaje que los envuelve, esa posición no cambia fácilmente
- La IA tampoco maneja todos los lenguajes de sistemas igual de bien
- En lenguajes más pequeños como Zig, Haskell y Gleam, la calidad de generación actual de IA no está al nivel de Rust o Go
- Los datos de entrenamiento determinan el alcance en el que el modelo puede ayudar
- Rust y Go están en una posición ventajosa porque aparecen en GitHub con suficiente frecuencia
- Zig, Haskell y Gleam siguen estando en el lado desfavorable de esa curva
Por qué este cambio podría sostenerse
- La defensa tradicional de Python y TypeScript era, en realidad, una defensa de la experiencia de desarrollador
- Se elegían porque minimizaban la fricción entre la idea de una persona y el producto lanzado
- Rust no era un lenguaje lento en runtime, sino un lenguaje lento cuando había que lanzar algo a las 2 de la mañana
- Ahora los agentes empiezan a hacerse cargo de la parte difícil
- El rol humano se mueve de “escribir código” a “diseñar sistemas y revisar resultados”
- Bajo este flujo, la comodidad sintáctica de Python se vuelve menos importante en cada iteración
- Las ventajas de runtime de lenguajes más difíciles se acumulan cada día que un servicio está en producción
- En su texto de febrero A Language For Agents, Armin Ronacher considera que el costo de programar cae tan rápido que la amplitud del ecosistema importa menos
- Durante los últimos 20 años, la elección de lenguajes se formó alrededor de la restricción de que “las personas escriben el código, y las personas son lentas en lenguajes de bajo nivel”
- Esa restricción está empezando a desaparecer
- En la encuesta Stack Overflow 2025, Rust fue el lenguaje más admirado por décimo año consecutivo con 72%
- Gleam obtuvo 70%
- Elixir, 66%
- Zig, 64%
- La preferencia ya existía, y ahora las herramientas están alcanzando esa preferencia
El siguiente paso hacia lenguajes fáciles para agentes
- Karpathy dijo en febrero que los LLM cambian por completo el terreno de restricciones del software
- Ve esa señal en la corriente de ports de C a Rust
- También añadió que incluso Rust está cerca de ser un lenguaje no óptimo como lenguaje objetivo para LLM
- Los ganadores actuales son apenas el punto de partida, y la forma final podría estar más lejos
- @RealRichomie dijo el 24 de abril que el futuro de la programación no irá hacia el lenguaje más fácil para las personas, sino hacia el lenguaje más fácil para los agentes
- Ingenieros lanzaron una app para Mac sin saber nada de Rust ni de Tauri
- El resultado tenía aproximadamente una décima parte del tamaño de la versión en Electron y mejor rendimiento en ejecución
- Las personas pudieron llegar a ese resultado sin necesidad de aprender Rust
- El próximo proyecto no necesariamente tiene que tomar Python como opción por defecto
1 comentarios
Opiniones de Hacker News
Si estás de acuerdo con la idea de ver las herramientas de programación con LLM como un compilador no determinista, entonces tiene bastante sentido elegir un lenguaje lo más eficiente posible
Claro, hay muchas excepciones como las bibliotecas o ventajas nativas de cada lenguaje, pero después de trabajar más o menos un mes con C++, lo único que se volvió más lento por la elección del lenguaje fue el tiempo de compilación
Me sorprendió leer los primeros comentarios y no ver hablar de los datos de entrenamiento. Hay muchísimo código Python en esos datos
Con IA podrías hasta escribir Brainfuck, pero no creo que obtengas el mismo resultado que usando Python
La siguiente pregunta sería esta: ahora que existe la IA, ¿por qué preocuparse por el lenguaje antes de que realmente haga falta?
Claude Code escribió la mayor parte, y Claude manejó Perl increíblemente bien. Le pedí que no tocara CPAN y que usara solo la biblioteca estándar de Perl, y aun así ya tenía cliente HTTP, TLS y JSON integrados, así que pude reemplazar algo que normalmente habría hecho con scripts de shell por una solución muy estable y sencilla
Como Perl no ha cambiado tanto y hay muchos datos de entrenamiento, parece que Claude usa bastante bien Perl en situaciones donde uno pensaría en scripts de shell
Los datos están aquí: https://gertlabs.com/rankings?mode=agentic_coding
Hice una base de código grande en Python con IA, y el LLM seguía adivinando mal los argumentos o la forma de los diccionarios. Herramientas como pruebas unitarias o pydantic ayudan, pero es mejor evitar ese tipo de errores en tiempo de ejecución desde el principio
Incluso en lenguajes con relativamente poco código público, los resultados fueron excelentes. El obstáculo mayor es que el LLM copia modismos comunes del lenguaje objetivo, y en lenguajes “enterprise” como Java o C#, el código boilerplate inútil puede explotar de inmediato. Entonces crece el riesgo de que el resultado exceda el tamaño útil de la ventana de contexto y baje la calidad
Pero si un agente genera código, intenta compilarlo, ve mensajes de error detallados y luego refina el código a partir de esos mensajes, el resultado es de mayor calidad. Los diagnósticos de rustc son muy buenos, y aunque haya mucho más Python o JavaScript/TypeScript, hoy ya hay suficiente código Rust en línea
¿Por qué Python? Porque lo llevo usando más de 10 años, sé cómo depurarlo y puedo oler en 10 segundos si el agente hizo algo que podría terminar en un desastre grande
Con otros lenguajes no me pasa, y tendría que reaprender mucho. Aunque la IA produzca código rápidamente, termino prefiriendo Python porque siento que todavía tengo cierto control. Si lo hiciera en Go o Rust, se sentiría menos como programación asistida por IA y más como “vibe coding”, empujando todo el producto en modo YOLO
Tuve que aprender la parte de seguridad de memoria porque no sabía qué era lo “correcto”, pero fuera de eso todo fue fluido
La sintaxis se va desvaneciendo al fondo, empiezas a concentrarte en cosas de más alto nivel y a explorar caminos nuevos. Si lo pruebas, puede sorprenderte gratamente cuánto de tu experiencia sí se transfiere
Si la IA te escribe, ¿para qué usar el cerebro?
/s
¿Por qué detenerse en hacer que la IA use Rust? Si todo es vibe coding y ya nadie revisa código, entonces que el LLM diseñe un lenguaje ultracondensado y ultradenso creado solo para minimizar el uso de tokens y maximizar velocidad
Este comentario termina con un /s solo parcialmente en broma
Un poco fuera del tema, pero de verdad no entiendo por qué la gente sigue publicando en Medium
La experiencia de lectura es terrible. Un popup de pantalla completa literalmente me tapó la oración que estaba leyendo, así que ni siquiera pude terminar este artículo
¿Hay algún incentivo que yo no esté viendo?
Nada de lo que se lee en el navegador puede darles a todos exactamente la experiencia de lectura definitiva, excelente y superior. El modelo web moderno choca con eso por naturaleza
Una página HTML simple, sin CSS, es casi una experiencia de lectura perfecta. El problema es que casi nadie publica así. La web se convirtió en una plataforma editorial donde los autores compiten por atención. Un protocolo de texto plano bajo control del usuario se acerca mucho más a “la mejor experiencia de lectura para todos”. La web podría haber sido eso, pero en su mayor parte no lo es
Dejé de intentar leer textos largos en el navegador. Si puedo extraer fácilmente el texto plano relevante, o incluso texto estructurado, y leerlo en mi editor, ¿por qué leerlo en el navegador? Ahí yo controlo tipografías, colores, navegación, etc. El navegador es un medio de entrega, no un entorno de lectura. Tratarlo como lo segundo es costumbre, no necesidad
Desde hace mucho ya no escribo nada de más de tres palabras fuera del editor. Ya tengo ahí corrector ortográfico, diccionario de sinónimos, consulta etimológica, traducción, acceso a todas mis notas e integración con LLM. Si algún día lo pruebas, se siente increíblemente liberador. Y entonces también puedes dejar de leer textos largos en el navegador
Medium ha hecho un intento bastante serio de pagarles a los autores. Es un modelo distinto al de Substack, pero esa es la razón
Lo veo parecido a cómo veo los muros de pago de los diarios. No me gusta, pero entiendo por qué existen
La explicación más plausible es la inercia. Algunas personas son muy leales a las marcas y necesitan moverse según lo que hacen los demás y cómo lo hacen
En realidad no importa dónde esté publicado algo mientras me den la URL, pero no todo el mundo actúa así
Parece la evolución más reciente de una plataforma de blogs amigable para escritores. Es más fácil empaquetarlo como newsletter que con WordPress, y también monetizarlo con un nivel de pago
Si usas Scribe, un frontend alternativo para Medium, mejora muchísimo:
https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...
https://sr.ht/~edwardloveall/Scribe/
https://libredirect.github.io/
Python tiene un ecosistema mucho más maduro que Rust, especialmente en IA/machine learning
Me topé con un crate de Rust que decía implementar cierto algoritmo de machine learning, pero no funcionaba bien. Aun así, pude escribir una implementación alternativa con Claude
Con IA, me parece una buena idea forzar corrección al nivel del sistema de tipos, así que suelo elegir lenguajes como C# o Rust antes que Python. Aun así, para algunas cosas Python claramente es la herramienta correcta
Podría haber usado Rust, pero si el resultado salía bien, sentía que para los demás era más valioso usar una sola toolchain, así que Go tenía más sentido
La razón principal es que hay que poder leerlo cuando haga falta. Y también existe el lenguaje que espera el ecosistema receptor. Que algunas comunidades de ciencia de datos elijan R, MatLab, Julia, Python o Mojo no depende de qué sea técnicamente superior, sino de lo que usan sus colegas
Mi intuición es que los lenguajes tipados suelen tener servidores de lenguaje más rápidos y mejores, así que se puede modificar código con más eficiencia usando herramientas
También, cuando una persona tiene que intervenir directamente para investigar o modificar código, los tipos fuertes hacen mucho más fácil orientarse dentro del espagueti
Así obtienes las ventajas del garbage collection y de los tipos fuertes
Por ahora, es exactamente la misma razón por la que la gente usa Python al programar a mano. Más personas conocen Python que un lenguaje como Zig, así que para los humanos es más fácil leer y modificar el código
Entiendo el punto del artículo, pero creo que todavía no estamos en esa etapa
La idea de “una app lanzada en un lenguaje que nadie del equipo conoce” me encanta. En un futuro no tan lejano vamos a mirar atrás y recordar esto
No es cierto que “el investigador de Anthropic Nicholas Carlini coordinó 16 agentes Claude en paralelo para escribir en Rust un compilador de C para producción”
Ese compilador genera código muy inferior al de gcc/clang, así que en la práctica es inútil