El fin del código IA: ¿Por qué Linux, Java y Rust han dicho basta? transcript

¿Cuándo fue la última vez que leíste de verdad línea a línea el código que te generó la IA antes de hacer un comit o de utilizarlo en general? Sé sincero que aquí no pasa nada, que nadie te va a juzgar. Pues bueno, por el otro lado, los mantenedores de Linux, de Java, de Rust se han cansado del código generado por IA y que sus autores no saben ni explicar. reciben informes de seguridad inventados que suenan perfectos, librerías recomendadas por la inteligencia artificial que directamente ni existen y han empezado a hacer algo que hace unos años yo creo que era impensable en el mundo open source, decir que no prohibir poner condiciones.

Hoy vamos a ver quién está prohibiendo de verdad la utilización de IA, quién por otro lado la está apoyando por encima de todo como empresas como Google, como Microsoft, donde no dejan de decirnos que la mayoría de su código ya está generado por IA. ¿Por qué existen estas dos vertientes? ¿Quién tiene razón? Y lo más importante, como siempre, ¿qué significa todo este rollo para nosotros? [música] Hace solo unas semanas te conté cómo las empresas de inteligencia artificial cambian de estrategia cada pocos días.

Pues bueno, hoy vamos a ver la otra cara, qué está pasando con el código, que esas inteligencias artificiales generan cuando llegan a los proyectos que de verdad sostienen internet. Y para entenderlo tengo que establecer una pequeña cronología, así que vamos a revisarlo. Ya en 2024 comenzaron estas primeras prohibiciones. Por ejemplo, Gento, una de las distribuciones de Linux más veteranas, pues prohibía las contribuciones generadas por IA por diferentes razones: copyright, calidad y ética, sobre todo.

Ese fue ahí el primer ladrillo de una gran empresa o de un gran software que empezaba a decir, "E, la IA está bien, pero cuidado porque afecta nuestra calidad." Al poco tiempo también lo hizo NetBSD, también lo hizo Kemu, pero personalmente a mí cuando más me llamó la atención este grupo de prohibiciones ya fue en julio de 2025 cuando Daniel Steinber, el creador de CUR, básicamente es un programa que llevamos instalado en todos los lados, en el móvil, los sistemas operativos, en el coche, en la televisión, pues lo que empieza a decir es que el 20% de los informes de seguridad que recibe son lo que se llama llama AI Slop, es decir, basura generada por inteligencia artificial y que poco a poco había detectado que la tasa de informes válidos había caído al 5%.

Aquí nos damos cuenta que uno de los proyectos más importantes, aunque personalmente igual tú no lo conozcas, realmente está metido en todo el software del mundo. Lo que nos dicen sus mantenedores, sus dueños, llamémoslo así, o por lo menos la gente que mejor lo conoce, es que no lo pueden seguir evolucionando de una manera segura. Porque el código que les llega es que directamente no sirve, no funciona, está inventado, es más grave de lo que parece.

Como te decía, para mí esto fue ya el primer signo de atención realmente serio, ya que en octubre de 2025 Fedora, que tiene a Reat detrás, aprueba la primera gran política de sí, utiliza Ia, pero cuidado, ya que tú vas a ser el responsable total. Esto como desarrolladores ya nos mete un poquito más de miedo porque nos está cargando legalmente con la propia responsabilidad de que nuestras aportaciones, como es normal, ya que somos personal cualificado y profesional, pues tienen que estar bien formuladas.

Por supuesto, nos podemos equivocar, pero no se trata de simplemente para intentar, no sé, ganar reconocimiento o incluso ganar dinero, ya que existen programas donde te pagan por encontrar BS o por mejorar el software, no sé, eh, nos acabemos cargando la integridad de ese software. El caso de CURL en realidad fue en aumento, ya que lo que estaba pasando es que cada vez aumentaban más esos informes falsos y realmente casi no era ni útil lo que estaban recibiendo.

En enero de 2026 se cierra el programa de recompensas para cazar BS y para acabar ayudando a evolución del software que llevaba abierto desde 2019 y que ya habían pagado a lo largo de todos estos años, pues por los números que he encontrado, más de $100,000. Imagínate lo grave de la situación cuando prefieren dejar de evolucionar su software ante la mala calidad de lo que estabas recibiendo. Pero lo verdaderamente grave empieza a llegar estos últimos meses del año, ya que es cierto que cada vez los modelos de inteligencia artificial funcionan mejor, generan mejor código, cada vez cometen, vamos a llamarla así, menos errores, pero ahora nos encontramos con que en abril de 2026 gente del kernel de Linux, Linux Thorbarts y grupo de Allegados empiezan a decir algo así como que vamos a crear un documento oficial sobre cómo hay que utilizar asistentes de inteligencia artificial en nuestro núcleo.

No prohíben directamente, hacen algo más inteligente o por lo menos a mi manera de verlo que te voy a explicar ahora. Y por otro lado también llega Oracle, la empresa detrás de Java que publica una política para el Open JDK, es decir, el núcleo también el corazón de Java. Y ahí estos sí que son claros, prohíben código, texto, imágenes, correos, wikis generadas en parte o en su totalidad por inteligencia artificial. Te cuento un poquito más sobre Linux, ya que si en abril empezaban a plantearse esa política de uso de agentes, en mayo de 2026 Tolbartz, el creador de Linux estalla y dice que la lista privada de seguridad del kernel está casi totalmente inmanejable, ya que no dejan de recibir un montón de informes creados por inteligencia artificial duplicados.

Aquí aparece una nueva norma y es que los BS encontrados con inteligencia artificial se reportan en público porque si tu herramienta lo encontró, la del vecino seguramente también y de esta manera se empieza a intentar eliminar esos duplicados. ¿Y por qué me he decidido hacer este vídeo? Porque nada, hace solo unos poquitos días, Rust, ya sabes, uno de los lenguajes más admirados de la última década que viene un poquito a competir o sustituir a C y AC C++ esos lenguajes de más bajo nivel que sostienen también el software mundial y RAS viene un poquito como a actualizar esa manera que teníamos de programar con esos lenguajes.

Pues bueno, ¿qué política acaba de adoptar Rust en el repositorio del compilador? Pues yo creo que la frase que lo resume es que sí puedes utilizar LMS para responder preguntas, para analizar, para comprobar y para revisar, pero no para crear. Así que ya lo ves, un montón de empresas y muchas otras que no te he contado que generan software crítico y que ellos mismos se tienen que responsabilizar de esa calidad, ya que es open source y está incluido en medio mundo, empiezan a parar los pies a la IA.

Pero es cierto que no nos podemos quedar únicamente con esta cara de la moneda, porque por el otro lado tenemos a empresas como Google que ya desde 2024 donde se empezó a bloquear este uso de IA, pues bueno, Google ya decía por aquel entonces que el 25% de su código pues ya estaba creado por IA y que esto ha ido aumentando hasta los últimos datos que he encontrado de abril de 2026, donde dicen que ya el 75% de su código está generado por IA.

Si nos vamos a los datos de Microsoft, pues también habla del 30%. Si nos vamos a la gente de meta, pues que bueno, porcentajes también altísimos de código generado por IA. Y aquí es donde ambos enfoques empiezan a chocar un poquito. ¿Cómo podemos tener a unas empresas muy muy buenas con gente de mucha calidad diciendo, "Ey, cuidado con cómo utilizamos la IA y otras con gente también de muchísimo talento y de software super importante diciendo cuidado que prácticamente todo nuestro código ya es IA." Aquí es donde yo veo el primer problema y es que los datos de las grandes compañías tecnológicas, Google, Meta, Microsoft, no voy a decir que son mentira, e no lo sé, pero es cierto que no dejan de ser datos de los CEO y del, digamos, la cúpula que domina esas empresas que los lanza de cara a la galería y de cara a las noticias y de cara a generar confiabilidad.

Estos datos no es que estén respaldados por empresas de fuera de la propia empresa, sino que son datos internos que ellos lanzan como noticia y que realmente nos los tenemos que creer. Y ya lo que pasa es que las grandes empresas sí cada vez tienen o dicen que tienen más código generado por IA, pero prácticamente no hay políticas que gobiernen esta generación de código, simplemente son datos que se lanzan. Por eso aquí sí que es cierto que yo de momento, ya te hablaré de mi conclusión, me voy a situar un poquito más del lado de los mantenedores open source.

Vamos a ponernos en la piel de Stber, la persona de Curl. Pues bueno, CURL son unas 180,000 líneas escritas en C que corren en miles de millones de dispositivos de todo tipo a lo largo del mundo. Y claro, esto lo mantienen un pequeño grupo de voluntarios. Cada informe de seguridad que llega hay que leerlo, hay que intentar reproducirlo, hay que investigar el código señalado y responder, da igual que ese informe sea falso, el coste de comprobarlo lo tienen que pagar ellos.

Y la verdadera trampa y de lo que más se quejan ellos es que justamente el AI slop, esta basura de código generado por IA, pues no parece spam o no parece basura. ¿Por qué? porque la es capaz de redactar código y texto muy bien formado. Otra cosa es que después te pongas a comprobar cómo funciona ese código y realmente pues sea falso. El problema es que el Ll va a generar en unos segundos y el humano experto le va a costar horas en desmontarlo y esto te lleva a soluciones como la que adoptaron en enero de cerrar ese programa de recompensas.

Aunque ojo porque meses después lo han acabado abriendo. ¿Por qué? porque los informes volvieron, pero es cierto que la comunidad se concienció un poquito más y la calidad de esos informes pues empezaron a mejorar. Los modelos habían mejorado, por supuesto, pero también la calidad de las propias personas que estaban intentando ayudar el proyecto y que no únicamente eran personas, sin una experiencia técnica que lo único que querían era a ver si ganaban ese reconocimiento de aportar al Open Softs.

Pero apareció otro problema. Es cierto que mejoraron la calidad, pero siguieron aumentando el número de informes. ¿Qué pasaba en este caso? lo mismo que lo que hablábamos en Linux, que un montón de personas encontraban lo mismo y realmente como no se tomaba la molestia de intentar cotejar esos datos y qué había pasado con la propia evolución del software, pues en realidad lo que teníamos era más informes pero que decían lo mismo, distinto problema pero mismo trabajo, porque la revisión tiene que seguir siendo humana y sigue quitando muchísimo tiempo.

Esto es lo mismo que decía Tolbarts, que dijo, "Ey, es que la inteligencia artificial no es mala." dijo, "Es que la lista de seguridad es inmanejable porque distintas personas encuentran lo mismo con las mismas herramientas." Y los mantenedores se pasan el día contestando, "Ey, que esto ya se arregló hace un mes, por ejemplo." Y aquí nos dejó un consejo importantísimo. Si encontraste un BG con inteligencia artificial, no seas esa persona que da el informe sin entenderlo.

Lee la documentación y aporta una solución a ese Bag, a ese error. Aporta el parche, aporta el valor por encima de lo que te da la IA. Porque tú piensas que si lo único que haces es compartir el resultado de la IA, tú poquito estás haciendo. De hecho, hace unos meses se borraron más de 100,000 líneas del código del kernel de Linux con drivers de red antiguos. Y según lo que nos contaron, uno de los principales motivos fue ruido de bots de inteligencia artificial reportando BS contra el código que ya nadie usaba, cosas que en cierto modo ya no importaban, pero que en realidad lo reflotaron como trabajo.

Y esto nos lleva a la actualidad. ¿Qué pasó con el lenguaje de programación Rust? Pues básicamente que nada, hace unos días en el momento que redactaron esta política, pues tenían más de 100 purreques abiertas, algo que, volvemos a lo mismo, es inmanejable y que el equipo de RAS diagnosticó de esta manera y creo que es muy importante porque nos da una visión de dónde estamos fallando a la hora de generar código con IA.

Por un lado, esa aportación, esa P request, aunque inicialmente parezca pulida o parezca correcta, no significa ni que tú como desarrollador te hayas esforzado ni que lo comprendas. Antes, si llegaba una contribución detallada y bien testada, sabías que detrás había alguien que había invertido horas y que había invertido un montón de tiempo en agarrar ese conocimiento y que lo más importante, lo que quería era regalarlo a la comunidad para seguir evolucionando el Open Source.

Claro, este contrato social realmente se está muriendo poquito a poco porque ahora una PR que parece perfecta puede venir, yo que sé, de Cloud Code que ha estado trabajando hay un buen rato y nos ha soltado esa respuesta, pero que del otro lado pues no estaba nadie al volante. Por otro lado, también nos dejan claro que generar código hoy en día es baratísimo, pero que revisarlo cada vez es más caro. Y ojo que revisar no es únicamente cazar si hay errores, si hay bags, es decidir si la decisión que se ha tomado es correcta, si el cambio que se aporta es buena idea.

Y esa decisión y más en software tan importante y tan crucial, no la puedes delegar, no le puedes decir a la gente de turno que haga lo que quiera. Por otro lado, también nos dicen que no contentos con crear estas pull request únicamente con IA. Si el revisor se toma el tiempo en analizar todo esto y responder, ¿qué hace la gente que aportó ese código con IA? Copia y pega la respuesta de revisor en una IA y le responde con lo que la IA ha contestado.

Aquí también nos dejan una frase que creo que nos tenemos que grabar a fuego y es que, ey, si quisiéramos la opinión de una IA se la habríamos pedido nosotros. Lo que quiere un equipo como el de RAS o un equipo de open source son tus propias ideas, no las de una máquina. Vamos, que con todo esto que nos dicen, yo empatizo bastante y entiendo también lo harto que se empiezan a sentir estos grupos de desarrolladores que en realidad ahora no pueden hacer su trabajo.

A raíz de estas noticias, me he puesto a buscar datos generales de cómo funciona el código junto con la inteligencia artificial, sobre todo atendiendo a los cuatro pilares principales, vamos a llamarlo así, la seguridad, la mantenibilidad, la cadena de suministro y la productividad. No te quiero aburrir con los informes, pero si hablamos de seguridad, básicamente todos están coincidiendo en que la mitad de las veces el modelo elige una opción insegura.

Veracode, que es una empresa que se dedica a hacer este tipo de informes, en este último informe de 2026 titula lo siguiente: "A pesar de lo que dicen, los modelos siguen suspendiendo en seguridad. Los modelos puede que sean más listos, pero no más seguros, realmente porque escriben el código que estadísticamente les parece correcto, pero que no tiene por qué ser el seguro. Por el bloque de la mantenibilidad tenemos a una empresa que se llama Gclear, que analiza cientos de millones de líneas que se han modificado desde 2020.

En 2024, ya en pleno boom de la inteligencia artificial por primera vez en la historia de su dataset, el copy paste superó al código refactorizado. Esto, ¿qué significa? que empezaban a aparecer más bloques duplicados en funciones que deberían ser de corrección de código. Y si nos vamos al informe de 2026, ojo, porque nos dice que hay un 81% más de duplicación de código que en 2023. Básicamente nos están diciendo la cara que nuestro código es muchísimo peor.

Y aquí aún nos dan un dato que a mí aún me asusta más y es que el código se reescribe de media a las dos semanas de crearse. Y esto es porque se ha duplicado, ya que la IA lo agarra, no revisa tampoco muy bien lo que estaba haciendo y decide modificarlo. Y esto lo traducen diciendo que si el código sale más rápido, que caduca más rápido y lo que estamos consiguiendo es fabricar una deuda técnica a una velocidad que nunca habíamos visto.

Pasemos ahora a la cadena de suministro. Aquí encontré un informe de Usenix Security que generó, pues bueno, creo que 600,000 muestras de código con 16 modelos. Y lo que acabó detectando es que casi un 20% de las librerías o de los paquetes que recomendaba la propia generación de código es que ni existían más de 200,000 nombres de librerías únicas que eran mentira. Y lo más grave es que más del 40% de esas alucinaciones se repetían sistemáticamente cuando le poníamos el mismo prompt.

Aquí hay un caso curioso, ya que viendo que la IA se inventaba diferentes librerías, una persona creó el nombre de una de esas librerías y la subió vacía, sin hacer absolutamente nada y se llevó más de 30,000 descargas en 3 meses. Así que imagínate las que estamos liando por ahí adelante. Pasemos ya a ese último bloque, al de productividad. Este informe de meter ya te lo comenté hace una temporada, pero bueno, si te lo resumo muy rápido es que hicieron un estudio para acabar midiendo si la gente se sentía más productiva y la realidad es que sí todo el mundo se acababa sintiendo más productivo, pero en realidad lo que iban es más lentos.

Se habían convencido a sí mismos que, claro, al estar utilizando inteligencia artificial estaban generando más y mejor, pero en realidad después se estaban retrasando por otros lados en las partes de la revisión, la calidad, los BS que acabamos surgiendo y que realmente estaban yendo más lentos. Por supuesto, esto simplemente son informes, no quiere decir que representen cómo funciona todo el sector, pero sí que nos da una visión de que, bueno, que las cosas a veces no son tan bonitas como nos las pintan.

Y aquí me gustaría nombrar a la encuesta de Stack Overflow, que yo siempre, por lo menos, ha sido una de las que más respeté. Y lo que nos decía este último año es que solo el 3% de los desarrolladores confía plenamente en lo que produce, es decir, tapándose los ojos. Claro, lo que pasaba es que la gran mayoría, lo que decimos y donde yo me incluyo también en un porcentaje de un 66% es que las soluciones están casi bien, pero no del todo.

El problema es cuando directamente ya le soltamos la mano a la IA y pasamos ese grupo que confía ciegamente. La verdad es que buscando estos datos me estoy divirtiendo un montón porque me ayudan a entender mucho mejor cuál es la realidad de nuestro sector. tensión entre la velocidad que promete la IA y la confianza que acaba destruyendo, pero que nadie supervisa. Pues justamente estos temas son los que analizo aquí semana a semana sin mucho guion, con calma, con un café en el podcast que estás escuchando ahora mismo en nos quedan 6 meses.

Si realmente te gusta y aprecias estas reflexiones que no dejan de ser mi propia forma de ver cómo está funcionando la industria, lo único que te pido es que no te cuesta nada dejar un like, seguirlo donde lo estés viendo, escuchando, en YouTube, en Spotify, en iBox, en Apple, dejarme algún comentario dándome tu opinión y valorando, si es posible el podcast para que así llegue a más gente y ya que tú crees o eso espero que te resulta útil, pues que más gente también lo pueda aprovechar, independientemente de Todo esto, muchísimas gracias por todo el apoyo que ya durante estos meses me estáis dando y ahora seguimos, ya que aquí quiero hacerte una pregunta que me parece muy interesante.

Oye, con estos datos que me estás dando, entonces, ¿por qué no lo prohíbe todo el mundo y punto? Aquí lo que yo veo es que hay diferentes formas de responder a esto. Lo primero, como ya hemos visto en el Open JDK, en Gento en SBSD, es que lo han prohibido totalmente. El caso de estos últimos meses del Open JDK de Java es para mí el más duro, que es que no se puede utilizar para nada. Incluso en las preguntas frecuentes de la documentación te dice esto, la IA generó 100 líneas y tú editaste 10 o 90.

Sigue prohibido únicamente utilizar IA en privado para entender y depurar el código. Por otro lado, tenemos la otra forma de entender todo esto o de solucionar esto, que es como ha hecho, pues, por ejemplo, el kernel de Linux y de Fedora, que es la responsabilidad humana. Linux no prohíbe, pero sí que nos dicen que los agentes tienen terminantemente prohibido firmar el código. Solo lo puede hacer un humano. Y si encuentras un error, no únicamente lo reportes, también tienes que aportar la solución.

Esto básicamente tiene mucha relación con esa filosofía que históricamente a lo largo de estos años nos ha ido trasladando Linus Torbers. Y es que la IA, por supuesto, es una herramienta. Como muchas otras, lo que importa es la calidad de resultado y quien tiene que responder por él somos nosotros. Y por otro lado, tenemos la tercera manera de, vamos a decir, prohibir, que es la de Rust. Y es que nos deja la IA para analizar, destilar, comprobar, sugerir, revisar, pero si queremos utilizarla para crear con restricciones muy duras.

Así que ya vemos, prohibir, responsabilizar, acotar. Tres respuestas para el mismo problema. Y sabes, en realidad lo que tienen en común las tres, que las escriben los que pagan la revisión con su propio tiempo. Quédate con esto porque ahora es donde entra el otro lado. ¿Qué pasa con quien no paga con su propio tiempo por esa propia calidad del software? La realidad es que encontramos todo lo contrario y aquí es donde nos explota la cabeza porque no sabemos qué hacer.

Te contaba como Oracle, la empresa de Java bloquea el uso de inteligencia artificial en el Open JDK, en el núcleo, pero Oracle como empresa este año ha gastado 70,000 millones en infraestructura para inteligencia artificial y no dejan de decirnos cómo empresa utilizan la IA para crear grandísima parte de su código. Pero por otro lado, su proyecto open source estrella tiene una de las políticas más restrictivas del mercado.

Esto es una contradicción. Bueno, no necesariamente. Lo que pasa es que por un lado tenemos la parte de la empresa que tiene que acelerar todo el software que crea y por otro lado la parte de la empresa donde el coste lo pagan los revisores. En realidad nos están diciendo de verdad dónde les duele. Por supuesto, ya te lo he contado, tenemos muchísimas grandes empresas de estas grandes tecnológicas que nos dejan de decir cómo su porcentaje de código creado por inteligencia artificial cada vez es mayor.

Vamos a poner, por ejemplo, un ejemplo, el de Google, el 75%. Pues bueno, nos dicen que es código ya generado por IA y está aprobado por sus ingenieros, pero para mí la métrica interesante no es cuánto genera la IA, es cuánto sobrevive a esa revisión. Y claro, esos datos no nos los dicen. Y si nos vamos a empresas menos especiales, que no son las top como un Google o como un Meta, en realidad cuando se encuesta a sus desarrolladores, lo que nos dicen es, "Sí, estamos generando un montón de código con inteligencia artificial, pero realmente sabemos que ese código puede aportar problemas, pero lo que estamos haciendo, como siempre ha pasado en nuestra industria, es adaptarnos a los cortos espacios de tiempo que tenemos para desarrollar.

Cuando yo conseguí mi primer trabajo como programador hace más de 16 años, lo que yo detecté es esto. No es tan importante la calidad como que tú tienes que entregar tal funcionalidad y tal fecha tiene que estar en producción. Y ahí no importaba si tu código era mejor, si trabajabas 8 horas o 20. Y es posible que me equivoque, pero creo que seguimos teniendo el mismo problema, que lo único importante es entregar, entregar, entregar y no le hacemos ningún caso a la seguridad.

Justo ahora cuando tenemos herramientas que nos permiten desarrollar más rápido que nunca, que nos permitirían revisar, que nos permitirían aumentar la calidad de la seguridad, pues realmente nos sigue importando lo mismo y es llegar antes. Antes llegábamos apretados a una tarea que teníamos que entregar en 15 días y ahora como la IA nos permite crear mucho más rápido, nos dan de plazo pues dos o tres días, pero sacrificando siempre la calidad.

Y por eso creo que el mundo open source nos está dando un poquito de claridad, cuando hay muchas veces no hay una gran empresa, ni hay unos grandes salarios, ni hay unas prisas por llegar al mercado antes que nadie. Es un mundo donde se premia la seguridad, la calidad, el aportar como comunidad, digamos, el mundo ideal del software. Y estos son los primeros que están diciendo, "Ey, cuidado con la IA." Y creo que para nada tenemos que ligar esto a que la gente de Linux, de Java, de RAS sean antiinteligencia artificial.

Lo que yo creo es que sí que son muy conscientes de la factura técnica a la que pueden acabar llegando si de verdad no tienen ciertos controles. Así que vamos a ir enfocándonos, ya que no quiero que pienses que al ver este vídeo, pues oye, la inteligencia artificial ya es humo, no hay que utilizarla, mucho cuidado. No, no, no, no. Ahora viene lo interesante, ya que como siempre ocurre, las verdades no suelen estar en los extremos.

Te lo adelanté antes, pero el equipo de CURL reabrió el programa en marzo porque los informes por inteligencia artificial empezaron a ser técnicamente más sólidos, porque realmente la IA sí que encuentra Bags de verdad si la utilizamos bien. Al final encontraba el BAC, se escribía un buen parche, la responsabilidad la asumía esa persona y la inteligencia artificial como herramienta de un experto se acabó convirtiendo en la mejor herramienta de todas. no sustituye al experto, sino que lo complementa y ahora sí que han encontrado un flujo donde la inteligencia artificial ayuda a que este proyecto open source pues siga mejorando.

Por otro lado, tenemos las empresas donde sigue existiendo este bloqueo en Linux, en el Open JDK, pero si nos damos cuenta no es un bloqueo de inteligencia artificial. Nos están diciendo, "Ey, puedes utilizarla en privado para entender, para depurar. Cuando tú no lo firmes, tienes que responsabilizarte, tienes que firmarlo tú." Básicamente nos están dejando claro que sí, utilízala como herramienta, o utilízala para pensar, utilízalo para mejorar, pero siempre teniendo en cuenta que tienes que responder tú sobre ese trabajo.

Y por otro lado, nos están diciendo que no es tanto las ganas de proteger el código, sino y muy importante, el conocimiento. La gente de RAS nos explica que un proyecto open source no es un almacén de código, es una comunidad de gente que entiende ese código y que puede mantenerlo dentro de 10 años. Si aceptas un montón de PRs que nadie comprende, tienes un repositorio muy grande y cada vez un proyecto más muerto. Y esto es algo que nos deja claro que tenemos que aplicar también a nuestros proyectos o a la empresa donde estemos.

El código que nadie entiende no es un activo, es más hipoteca, es más una deuda técnica que se nos puede revelar en cualquier momento y que nos puede hacer muchísimo daño. Mi posición es que sí, ahora mismo existen prohibiciones y que son necesarias, pero que poquito a poco, a medida que los profesionales vayamos evolucionando, que la IA vaya evolucionando y que los modelos de trabajo también vayan evolucionando, pues justamente esas políticas también se van a ir adaptando.

Tenemos que ser conscientes de que el software sigue siendo importante, que tiene que seguir siendo verificable, que tenemos que entenderlo y que tenemos que responder por él. Las empresas o mantenedores o desarrolladores que controlen todo esto realmente son los que más valor van a aportar. Conclusión, como siempre, el punto medio. No tenemos que ser una empresa igual como el Open JDK de Java que está haciendo ese bloqueo durísimo. ¿Por qué? porque igual tu proyecto no es tan crítico como el kernel de Linux, pero como lo veo es que el punto extremo donde tenemos empresas Google o la que sea que dicen que la gran mayoría de su código ya está generado por IA sin más datos, pues realmente creo que también es peligroso. piensa que por un lado tenemos las empresas de open source que tienen que proteger su código por encima de cualquier cosa porque primero es gente que prácticamente cobra, es gente que tiene que utilizar su conocimiento en crear un software que se utiliza en medio mundo.

Y por otro lado tenemos las empresas, las grandes tecnológicas, que de cara a la galería tienen que dejar claro que están liderando este movimiento, que controlan la IA, que son más productivas que nunca, que la IA es el futuro, que todo el mundo tiene que utilizarlo y seamos sinceros, todo el mundo tiene que acabar comprando sus productos. ¿Ves que en realidad tenemos las dos caras de la moneda de la industria del software?

Y como es normal, después estamos tú y yo, que representamos el 99% de los desarrolladores que no trabajan ni en una grandísima compañía como puede ser un Google o un Meta que lideran estos movimientos de inteligencia artificial, ni tampoco trabajan en un código open source como puede ser el kernel de Linux que sostiene a Media Internet. somos desarrolladores, que creamos software, que sí que igual no es de una de estas grandes empresas, pero que realmente representan la gran mayoría del software a la que accede cualquier usuario normal.

Y aquí es donde nosotros tenemos que utilizar el camino del medio. Justamente dos posiciones que parecen opuestas y que son caminos distintos. Linux, Java, Ras, Kur, Fedora o lo que sea, esa gente que lleva décadas sosteniendo el software del mundo, al final siempre tiene que haber un humano que entiende el código, que responde por él y que por otro lado, las grandes empresas Google, Meta, Microsoft nos dejan también claro que la IA está ayudando y que nos está permitiendo generar código mejor que nunca.

Conclusión, actualizarnos, formarnos y entender cuál es el valor que nosotros podemos aportar por encima del aire. Si te interesa aprender los fundamentos, ya sabes que tienes un montón de cursos gratuitos en YouTube y también si lo que buscas son mentorías, es mi propia supervisión para atender a tus dudas, tienes Mour. Te dejo todos los enlaces en la descripción, pero sobre todo suscríbete al canal porque esta historia, la de quién supervisa las máquinas que escriben software, acaba de empezar aquí y tenemos que seguir viendo cómo evoluciona.

Muchas gracias por quedarte hasta el final y nos vemos en el próximo vídeo. [música]