Elon Musk afirma que la IA hará que los lenguajes de programación queden obsoletos en 2026. El compilador ya hace lo que él describe, de forma determinista, en milisegundos.
#4#2 Un niño rico con claros problemas de narcisismo y de adicciones, con cero empatía y que por motivos que escapan a mi entendimiento (bueno, no tanto: muchos gilipollas) ha sido endiosado a la categoría de genio a pesar de actuar como un mongolo.
Resumen del autor en /r/programming por si a alguien le da pereza leerse el artículo.
So recently Elon Musk is floating the idea that by 2026 you “won’t even bother coding” because models will “create the binary directly”.
This sounds futuristic until you stare at what compilers actually are. A compiler is already the “idea to binary” machine, except it has a formal language, a spec, deterministic transforms, and a pipeline built around checkability. Same inputs, same output. If it’s
#3 El artículo original es brutal, y está tan bien explicado paso a paso que lo entendería mi madre, sin saber nada de programación.
Creo que no le hace justicia este resumen, y recomiendo encarecidamente leerlo entero.
Es el zasca más categórico, kantiano, formal e incontestable que he leído en mucho tiempo.
Realmente no hacía falta una respuesta tan contundente a la tontería de Elon, que parece que acaba de terminar sexto de EGB con muchas suspensas, pero alegra el corazón leer a gente que se expresa tan bien y que tan bien transmite su intelección de los conceptos.
Espero que llegue a portada, y que ilumine unas cuantas cabezas.
Me hace mucha gracia la imagen que se ha construido de si mismo, segun dice "programa a nivel genio" y se encargo de corregir codigo de decenas de expertos en su campo al comprar twitter, presuntamente detectando muchas ineficiencias y mal codigo... todo esto segun el.
Luego los hechos comprobados es que ni acabo la carrera, ni tiene pinta de que pasaria un examen de programacion de primero, pero aun asi ahi lo tenemos con sus hordas de fans y lamefalos a pesar de sus numerosas… » ver todo el comentario
#2 Un niño rico con claros problemas de narcisismo y de adicciones, con cero empatía y que por motivos que escapan a mi entendimiento (bueno, no tanto: muchos gilipollas) ha sido endiosado a la categoría de genio a pesar de actuar como un mongolo.
#9 Ciertamente, pero como el muchacho es torpe, en lugar de eugenesia hace kakogenesia ( malgenesia ). No está capacitado para el mal, salvo cuando intenta hacer las cosas "bien". No es un supervillano, es un villano estúpido, lo cual lo convierte en alguien realmente peligroso.
#2 Sin ánimo de defender a Musk: uno de los mejores programadores con los que me he topado en mi carrera laboral no había ido a la universidad.
Muy raro, pero posible.
#2 No recuerdo a quien leí que decía algo así como:
Yo no entiendo de cohetes, y Musk dice cosas de cohetes. La gente dice que es un genio, así que como no sé de cohetes pues lo será.
Yo no entiendo de coches eléctricos, y Musk dice cosas de coches eléctricos. La gente dice que es un genio, así que como no sé de coches eléctricospues lo será.
Resulta que yo si entiendo, y mucho, de programación, y cuando Musk ha hablado de programación ha dicho las mayores gilipolleces que he oído en años. Con ese dato, a lo mejor ni de cohetes ni de coches eléctricos tampoco sabe una mierda, y solamente está apuntándose los logros de gente que sabe mucho más que él.
#25 no olvidemos que fue cabezonería suya lo de quitar el radar de los Tesla, logrando uno de los vídeos más cómicos de la historia con un coche (y unas cuantas muertes) lo cual permitió resolver para siempre el dilema de que decide un coche autónomo en una emergencia: se desconecta y pasa el control al conductor justo antes de la hostia
#2 Sólo hay que ver la declaraciones de Linus Torvalds sobre Musk para hacerse a la idea de cuánto entiende Musk de programación.
Como resumen, Musk aboga por medir el rendimiento de los programadores por la cantidad de líneas de código que escribían cada día.
Durante una entrevista a Linus Torvalds, fue algo así:
Entrevistador: "En cierta empresa, les preguntan a los desarrolladores cuántas líneas de código escriben cada día. Y si la respuesta es demasiado baja, los despiden"… » ver todo el comentario
#2 Estuvo en el top del path of exile hasta que saltó que pagaba porque un verdadero crack (o varios) usase su cuenta y nos tenemos que creer todo lo demás
#2 He conocido unas cuantas personas que sabían un montón, te sacaban cualquier programa que quisieses, pero no acabaron la carrera, tenían problemas con los exámenes porque no aguantaban la presión, miedo escénico o inseguridades.
#2 Es un tio que dijo que era el mejor jugador de Diablo IV y tenia contratado a un equipo de indios farmeando por el.... si es que el chiste de Musk se cuenta solo.
#1 La droga por sí sola no causa tal degeneración del intelecto. Tienes que tener el cableado muy mal de base para que sandeces como estas traspasen el umbral de tu boca.
#1 Esta es la vida de un estudiante
Que estudiaba sin parar
Se estaba haciendo una carrera
Y no era en la universidad
Era una carrera que no tenía final.
Sus padres le preguntaban
"¿Hasta dónde vas a llegar?"
Él muy tranqui; él pasaba:
"Hasta que ya no me quede más"
Al final de la carrera
Ningún titulo te van a dar
Sólo te han dado un carné:
Politoxicomanía total
Y te quedan, y te quedan
Y te quedan, y te quedan
Y te quedan muchas venas por chutar
Muy atinado el artículo. Los compiladores no desaparecerán porque por muy buenos que sean los LLM programando siempre se necesitará el código para mantener, mejorar y entender el software que hacen. Incluso para los propios LLM es más eficiente trabajar en ventanas de contexto de código y no de instrucciones binarias.
Una vez más Musk demuestra que es más mito que sustancia real y te cuestionas si realmente sabe de lo que habla y es tan inteligente como está instalado en el pensamiento colectivo.
#10 La realidad actual es que la IA ya se hace la picha un lío con código extenso. Funciona muy bien para generar funcionalidades concretas, pero un programa de 30.000 líneas de C directamente no es capaz de manejarlo como un todo, porque no está hecha para "entender".
Si transformas todo eso en código máquina, que recordemos, NO está estructurado, va a empezar a poner parches uno detrás de otro como los niños cuando programaban en BASIC. No funciona esto, le añado este trocito aquí, pero resulta que ese trocito que añades rompe algo en otro extremo del código y no lo sabes hasta que no te ocurre en tiempo de ejecución una de cada quinientas veces.
#13, pero lo que comentas no tiene nada que ver con las razones que da el autor del artículo de por qué no tiene ningún sentido que los LLM trabajen en binario.
#20 No, estoy dando mi opinión por mi propia experiencia. La ventaja de los lenguajes estructurados es precisamente eso, la modularización, la separación de funciones (y problemas), encapsulación, reutilización de código, etc. El código máquina está desestructurado y es inmantenible a base de arreglos puntuales.
Cómo buen capitalista rico está a favor de que se distribuyan los binarios, distribuir el código fuente es de comunistas. Además, ¿Para que queréis saber todo lo que hace el software? Nos tenemos que fiar de él porque es superdotado y blanco.
Es que lo que dice es tan tonto que me parece increible que incluso él no se haya dado cuenta...
- Sin código no sabes lo que hace el programa, no tienes ni idea, te pueden decir que el programa suma las horas y las multiplica por el coste según el código del nosequé calculando las horas extras de tal manera... pero será literatura, no podremos saber de ninguna manera que eso se hace tal como dice el texto.
- Si hay que variar algo que no esté parametrizado se tiene que hacer TODO el código… » ver todo el comentario
#12 No hace falta esforzarse tanto ni darle tantas vueltas, es algo nítido para cualquiera, son mil inconvenientes y ninguna ventaja, seguramente haya pensado que así el desarrollo "irá más rápido" porque es una máquina entendiendo el código máquina, pero aparte de todo lo que es evidente que conlleva y no es nada deseable, es que ni siquiera ese punto tiene lógica, porque un LLM no es un "algoritmo" al uso, sino un Large Language Model, y como su propio nombre… » ver todo el comentario
¿Qué va a decir un retrasado que opinaba que la cantidad de líneas de código escritas por una persona eran una forma buena de determinar la productividad de un programador?
#49 pero quien hace el spec . no ves que es la pescadilla que se muerde la cola. Si tu haces el spec la complejidad es mayor que hacer el código. Si lo hace el LLM tienes el mismo problema del unkown unkown de ahora
Yo entiendo que tienen que vender su producto, y es un buen producto, pero los CEOs de compañía de IA parece que estén haciendo una carrera de retrasados últimamente vendiendo hypes absurdos. Y Elon Musk es el campeón, claro.
#40 Yo creo que eso es un dead end. Esos lenguajes formales ya existen. Y no es trivial usarlos. Vamos a perder mas tiempo escribiendo el spec que haciendo el codigo.
#41Vamos a perder mas tiempo escribiendo el spec que haciendo el codigo.
Utilizando LLMs cada día como apoyo para programar (Windsurf, ahora Antigravity) mi experiencia es que están muy bien para hacerte de programador junior asistente, para ahorrarte tiempo y encontrar a veces bugs, o incluso para hacer un prototipo interesante del que partir.
Pero cuando he tenido que hacer un programa o una parte de este con unas especificaciones concretas, entre que hago el prompt apropiado cubriendo todos los casos de uso, me genera un resultado en el que me ha puesto algunas cosas sí y otras no, y corrijo el prompt o el código directamente a mano, tardo lo mismo o más que si lo programo yo.
#44 Lo que va a pasar con estos specs o lenguajes formales es que la gente va a usar la IA para generarlos y tendremos el mismo problema. La IA no sabe lo que no sabe. Y eso no lo arregla ni specs ni nada.
#45 Al menos ganaríamos que se podrán debuggear, pero sigue sin convencerme. Igual que es una burrada cargarse los lenguajes de programación para generar ensamblador, no creo que los patrones de software a nivel arquitectura o a nivel OOP sean tampoco algo que nos podamos cargar alegremente sin empeorar la calidad del software.
Ahí es donde veo los límites de los LLMs, por un lado visión global y arquitectura y por otro transformación de requisitos de situaciones del mundo real a un entramado software que no reviente por algún lado.
#41 Es que el código no lo vamos a hacer nosotros, sino una herramienta que, dado el spec, escriba el código. Pero eso es menos dramático de lo que suena.
A día de hoy, los lenguajes de programación se usan como forma de escribir de forma formal y sistemática la intención del "stakeholder".
Esto involucra mezclar la intención (la lógica de negocio) con la implementación (cómo hacemos al ordenador ejecutar paso a paso esa lógica de negocio).
A algunos por aquí los veo un poco inconscientes y perdidos por lo que viene.
Dentro de poco los lenguajes de programación tal y como los entendemos irán desapareciendo en sustitución de prompts con instrucciones en lenguaje natural.
No se tendrá un código fuente, sino unas especificaciones claras que un intérprete se encargará de ejecutar en una máquina.
La teoría no es nueva, por cierto, es de los 90, el problema es que la tecnología no daba para ello.
#34
1- La lógica de negocio de un programa necesita expresarse de forma explícita y sin ambigüedades.
2- Un lenguaje natural está lleno de ambigüedades. Puedes definir reglas explícitas a base de matizar mucho las instrucciones para eliminar toda ambigüedad y cubrir todos los casos y escenarios.
3- Para ahorrar tiempo y trabajo, mejor usar un lenguaje formal que no sea ambiguo.
4- El camino lógico es que se crearán nuevos lenguajes formales, sin ambigüedades, que permitan describir la… » ver todo el comentario
#40
1: Se cae por su propio peso. Analiza qué le falta a un lenguaje formal para ser igual de conciso que uno de programación.
2: Similar al 1. Sólo que además un compilador no entiende la lógica de negocio y es malo reconociendo fallas en la lógica por falta de contexto, un compilador está centrado en traducir código más entendible por un humano a código máquina.
3: Las ambigüedades no son problema del lenguaje sino del que las escribe.
4: En esto está ahora la tecnología, no tanto en la definición del lenguaje, como en detección de contexto y ambigüedades.
Lo dicho, a los compiladores tal y como los conocemos les quedan dos días.
Tiempo.
Si la IA genera un binario de 500Mb, y algo falla o no funciona acorde a la especificación, ¿cómo lo arreglas? ¿Generas otra vez y esperas que esta vez haya suerte?
¿Vas a tirar para adelante con una caja negra donde es imposible auditar qué está haciendo realmente la máquina? ¿De verdad te parece remotamente un avance convertir en una caja negra todo el software?
Esto sin entrar en que el lenguaje natural es vago. Y si te has dedicado mínimamente a proyectos de software, sabrás de sobra que el cliente rara vez sabe exactamente lo que quiere en términos de casos de borde, seguridad y concurrencia, y que a menudo pide cosas que son contradictorias, y no es un trabajo sencillo hacerle entender las posibilidades reales.
#42 Peino canas ya en esto de los proyectos software y uno de los problemas precisamente es el de las ambigüedades y contradicciones en los requerimientos que los sistemas de hoy día están ya empezando a detectar y corregir.
Ahora en una mañana se puede hacer un prototipo para presentar al cliente e ir analizando y corrigiendo requerimientos para tener un producto mínimamente viable y sin grandes sorpresas en un tiempo récord.
El mayor punto de fracaso de un proyecto software es precisamente esto, cosa que los lenguajes de programación tradicionales no abordan ni por asomo y mucho menos la tradicional estructura de equipos de desarrollo.
#34 ¿cómo verificas que esas especificaciones claras acaban en el binario? ¿Quién lo hace?, ¿cómo lo hace? ¿Cómo se verifica el método usado?
¿Comprendes que un LLM se entrena con texto? Para que funcionara, tendrías primero que entrenar un modelo con todos los binarios, de todos los programas existentes, con sus bugs, para que luego dicho modelo pudiera generar ese código binario. Y nadie ni nada en el mundo sería capaz de depurar los bugs.
#43 Lo mismo que ahora.
¿Acaso existe alguien capaz de asegurar ahora un código sin bugs y ser capaz de encontrarlo de forma rápida y eficiente?
No estamos hablando de que la tecnología sea infalible, es un cambio de paradigma y de modo de hacer las cosas.
Los proyectos van ha ser más de definición y de testing que de programación.
Y esto no es el futuro, se está ya haciendo hoy día.
Profesión de futuro: decompilar, rehacer con ingeniería del software y arreglar burradas realizadas por el subnormal de turno con su vibe coding.
O quizá es un puto genio Elon Musk porque todo es un plan para favorecer a los programadores; si su ocurrencia se llevara a cabo iba a crear tanta deuda técnica que necesitaríamos el doble de currantes
Yo lo veo como una evolución: modelos LLM compilándose a sí mismos en binarios basura para intentar mejorarse, alcanzando así cotas de alucinación de los modelos jamás vistas por ningún ser humano (o IA)
![Por qué «saltarse el código y dar directamente el binario» es un error de categoría [ENG]](https://www.meneame.net/backend/media?type=link&id=4147736&version=0&ts=1771289766&image.webp)
So recently Elon Musk is floating the idea that by 2026 you “won’t even bother coding” because models will “create the binary directly”.
This sounds futuristic until you stare at what compilers actually are. A compiler is already the “idea to binary” machine, except it has a formal language, a spec, deterministic transforms, and a pipeline built around checkability. Same inputs, same output. If it’s
… » ver todo el comentario
Creo que no le hace justicia este resumen, y recomiendo encarecidamente leerlo entero.
Es el zasca más categórico, kantiano, formal e incontestable que he leído en mucho tiempo.
Realmente no hacía falta una respuesta tan contundente a la tontería de Elon, que parece que acaba de terminar sexto de EGB con muchas suspensas, pero alegra el corazón leer a gente que se expresa tan bien y que tan bien transmite su intelección de los conceptos.
Espero que llegue a portada, y que ilumine unas cuantas cabezas.
Edito: gracias por este envío
Luego los hechos comprobados es que ni acabo la carrera, ni tiene pinta de que pasaria un examen de programacion de primero, pero aun asi ahi lo tenemos con sus hordas de fans y lamefalos a pesar de sus numerosas…
Saben aquél que diu, que Dios es real... Salvo que lo hayas definido como entero...
Muy raro, pero posible.
Yo no entiendo de cohetes, y Musk dice cosas de cohetes. La gente dice que es un genio, así que como no sé de cohetes pues lo será.
Yo no entiendo de coches eléctricos, y Musk dice cosas de coches eléctricos. La gente dice que es un genio, así que como no sé de coches eléctricospues lo será.
Resulta que yo si entiendo, y mucho, de programación, y cuando Musk ha hablado de programación ha dicho las mayores gilipolleces que he oído en años. Con ese dato, a lo mejor ni de cohetes ni de coches eléctricos tampoco sabe una mierda, y solamente está apuntándose los logros de gente que sabe mucho más que él.
Le debemos mucho a este genio
Como resumen, Musk aboga por medir el rendimiento de los programadores por la cantidad de líneas de código que escribían cada día.
Durante una entrevista a Linus Torvalds, fue algo así:
Entrevistador: "En cierta empresa, les preguntan a los desarrolladores cuántas líneas de código escriben cada día. Y si la respuesta es demasiado baja, los despiden"… » ver todo el comentario
Que estudiaba sin parar
Se estaba haciendo una carrera
Y no era en la universidad
Era una carrera que no tenía final.
Sus padres le preguntaban
"¿Hasta dónde vas a llegar?"
Él muy tranqui; él pasaba:
"Hasta que ya no me quede más"
Al final de la carrera
Ningún titulo te van a dar
Sólo te han dado un carné:
Politoxicomanía total
Y te quedan, y te quedan
Y te quedan, y te quedan
Y te quedan muchas venas por chutar
Extremoduro.
Una vez más Musk demuestra que es más mito que sustancia real y te cuestionas si realmente sabe de lo que habla y es tan inteligente como está instalado en el pensamiento colectivo.
Si transformas todo eso en código máquina, que recordemos, NO está estructurado, va a empezar a poner parches uno detrás de otro como los niños cuando programaban en BASIC. No funciona esto, le añado este trocito aquí, pero resulta que ese trocito que añades rompe algo en otro extremo del código y no lo sabes hasta que no te ocurre en tiempo de ejecución una de cada quinientas veces.
En fin, otra gilipollez de Musk.
No hemos venido aquí a hablar del tamaño de su pene
( No cabe otra interpretación, aquí no hay ambigüedad )
- Sin código no sabes lo que hace el programa, no tienes ni idea, te pueden decir que el programa suma las horas y las multiplica por el coste según el código del nosequé calculando las horas extras de tal manera... pero será literatura, no podremos saber de ninguna manera que eso se hace tal como dice el texto.
- Si hay que variar algo que no esté parametrizado se tiene que hacer TODO el código… » ver todo el comentario
www.meneame.net/story/elon-musk-predice-muerte-programacion-finales-20
Utilizando LLMs cada día como apoyo para programar (Windsurf, ahora Antigravity) mi experiencia es que están muy bien para hacerte de programador junior asistente, para ahorrarte tiempo y encontrar a veces bugs, o incluso para hacer un prototipo interesante del que partir.
Pero cuando he tenido que hacer un programa o una parte de este con unas especificaciones concretas, entre que hago el prompt apropiado cubriendo todos los casos de uso, me genera un resultado en el que me ha puesto algunas cosas sí y otras no, y corrijo el prompt o el código directamente a mano, tardo lo mismo o más que si lo programo yo.
Ahí es donde veo los límites de los LLMs, por un lado visión global y arquitectura y por otro transformación de requisitos de situaciones del mundo real a un entramado software que no reviente por algún lado.
A día de hoy, los lenguajes de programación se usan como forma de escribir de forma formal y sistemática la intención del "stakeholder".
Esto involucra mezclar la intención (la lógica de negocio) con la implementación (cómo hacemos al ordenador ejecutar paso a paso esa lógica de negocio).
El trabajo de un desarrollador (así, en… » ver todo el comentario
Dentro de poco los lenguajes de programación tal y como los entendemos irán desapareciendo en sustitución de prompts con instrucciones en lenguaje natural.
No se tendrá un código fuente, sino unas especificaciones claras que un intérprete se encargará de ejecutar en una máquina.
La teoría no es nueva, por cierto, es de los 90, el problema es que la tecnología no daba para ello.
1- La lógica de negocio de un programa necesita expresarse de forma explícita y sin ambigüedades.
2- Un lenguaje natural está lleno de ambigüedades. Puedes definir reglas explícitas a base de matizar mucho las instrucciones para eliminar toda ambigüedad y cubrir todos los casos y escenarios.
3- Para ahorrar tiempo y trabajo, mejor usar un lenguaje formal que no sea ambiguo.
4- El camino lógico es que se crearán nuevos lenguajes formales, sin ambigüedades, que permitan describir la… » ver todo el comentario
1: Se cae por su propio peso. Analiza qué le falta a un lenguaje formal para ser igual de conciso que uno de programación.
2: Similar al 1. Sólo que además un compilador no entiende la lógica de negocio y es malo reconociendo fallas en la lógica por falta de contexto, un compilador está centrado en traducir código más entendible por un humano a código máquina.
3: Las ambigüedades no son problema del lenguaje sino del que las escribe.
4: En esto está ahora la tecnología, no tanto en la definición del lenguaje, como en detección de contexto y ambigüedades.
Lo dicho, a los compiladores tal y como los conocemos les quedan dos días.
Tiempo.
Si la IA genera un binario de 500Mb, y algo falla o no funciona acorde a la especificación, ¿cómo lo arreglas? ¿Generas otra vez y esperas que esta vez haya suerte?
¿Vas a tirar para adelante con una caja negra donde es imposible auditar qué está haciendo realmente la máquina? ¿De verdad te parece remotamente un avance convertir en una caja negra todo el software?
Esto sin entrar en que el lenguaje natural es vago. Y si te has dedicado mínimamente a proyectos de software, sabrás de sobra que el cliente rara vez sabe exactamente lo que quiere en términos de casos de borde, seguridad y concurrencia, y que a menudo pide cosas que son contradictorias, y no es un trabajo sencillo hacerle entender las posibilidades reales.
Ahora en una mañana se puede hacer un prototipo para presentar al cliente e ir analizando y corrigiendo requerimientos para tener un producto mínimamente viable y sin grandes sorpresas en un tiempo récord.
El mayor punto de fracaso de un proyecto software es precisamente esto, cosa que los lenguajes de programación tradicionales no abordan ni por asomo y mucho menos la tradicional estructura de equipos de desarrollo.
¿Comprendes que un LLM se entrena con texto? Para que funcionara, tendrías primero que entrenar un modelo con todos los binarios, de todos los programas existentes, con sus bugs, para que luego dicho modelo pudiera generar ese código binario. Y nadie ni nada en el mundo sería capaz de depurar los bugs.
¿Acaso existe alguien capaz de asegurar ahora un código sin bugs y ser capaz de encontrarlo de forma rápida y eficiente?
No estamos hablando de que la tecnología sea infalible, es un cambio de paradigma y de modo de hacer las cosas.
Los proyectos van ha ser más de definición y de testing que de programación.
Y esto no es el futuro, se está ya haciendo hoy día.
No es para mí, es para un amigo que yo me estoy quitando.
O quizá es un puto genio Elon Musk porque todo es un plan para favorecer a los programadores; si su ocurrencia se llevara a cabo iba a crear tanta deuda técnica que necesitaríamos el doble de currantes
Idos a la mierda