En el mundo de la ciberseguridad, encontrar vulnerabilidades reales en sistemas y programas es una tarea compleja, laboriosa y sumamente valiosa. Por ello existen los llamados bug bounty programs —programas de recompensas por errores—, mediante los cuales empresas e instituciones pagan a investigadores de ciberseguridad por reportar fallos de seguridad antes de que los delincuentes puedan localizarlos y explotarlos. Los pagos pueden llegar a ser millonarios.

Sin embargo, en los últimos meses ha emergido una nueva amenaza inesperada: las vulnerabilidades falsas inducidas por la IA. Y es que estamos experimentando una oleada de "descubrimientos" inexistentes que está inundando las plataformas de referencia de bug bounty como HackerOne o Bugcrowd, en un intento de usuarios por conseguir recompensas rápidas sin hacer investigación real.

El fenómeno ha alcanzado tal nivel que incluso proyectos emblemáticos como cURL, una de las herramientas más utilizadas de la red, han tenido que tomar medidas drásticas: bloquear de inmediato a quienes envían reportes generados por IA.

Qué está pasando realmente

El caso de cURL es ilustrativo. Su responsable principal, Daniel Stenberg, recopiló recientemente decenas de reportes de 'vulnerabilidades' supuestamente críticas enviadas al programa oficial de recompensas de la herramienta. Los títulos suenan bastante alarmantes:

• “Buffer Overflow Vulnerability in WebSocket Handling”
• “HTTP/3 Stream Dependency Cycle Exploit”
• “Use of Deprecated strcpy() with Fixed-Size Buffers”

Pero tras una revisión mínima, se descubrió que ninguna de ellas tenía la más mínima base técnica. Los informes repetían patrones comunes de descripciones generadas por IA: lenguaje vago, ejemplos de código inventado, ubicaciones de archivo incorrectas y referencias a funciones inexistentes.

En Genbeta

Siete hackers se hicieron millonarios 'cazando' vulnerabilidades en 2019: qué son los programas de 'bug bounty' que lo hacen posible

En palabras de los propios responsables del proyecto:

"Nuestra política actual establece que banearemos instantáneamente a todos los que envían 'AI slop'".

El término AI slop (literalmente 'papilla de IA') es uno de esos que seguramente estará generalizado en unos meses: se usa ya en varios entornos para describir contenido de baja calidad generado por modelos de lenguaje (coherente a simple vista, pero carente de sustancia técnica o de verificación factual).

Cómo se detecta el 'slop' generado por IA

Los responsables de seguridad están desarrollando estrategias para filtrar automáticamente este tipo de reportes. Como decíamos, algunos indicios comunes son:

• Repetición de frases idénticas en múltiples informes.
• Referencias a funciones, rutas o ficheros que no existen.
• Código de ejemplo que no compila o carece de coherencia lógica.
• Falta total de Proof of Concept (prueba de concepto) o de exploit verificable.

La economía del bug bounty y los incentivos perversos

Los bug bounty programs ofrecen incentivos financieros legítimos: grandes empresas como Google, Meta o Apple pagan entre cientos y miles de dólares por vulnerabilidades comprobadas. Esto ha generado un ecosistema de investigadores, muchos de ellos 'freelance', que dedican su tiempo a auditar código y buscar errores reales.

Pero con la expansión de herramientas generativas, apareció una tentación obvia: ¿y si una IA puede redactar un informe convincente de 'caza de bugs' sin que el supuesto experto se moleste en hacer su trabajo?

En Genbeta

Vio que podía ganar dinero arreglando bugs... y empezó a crearlos a propósito. Cinco ejemplos de malos incentivos para programadores

Algunos usuarios han empezado a alimentar a modelos con repositorios completos de código fuente y pedirles que 'encuentren vulnerabilidades', o simplemente que inventen ejemplos plausibles. En cuestión de minutos, generan descripciones que parecen profesionales y las envían a plataformas de recompensas.

El resultado: un volumen creciente de reportes falsos, que consumen tiempo de revisión y reducen la confianza en los investigadores legítimos.

Un problema ético y de confianza

Todo esto no es más que un reflejo de un fenómeno que afecta a toda la red: la sobreproducción de contenido artificial sin verificación humana. Lo que antes era un campo de perfil técnico y hasta artesanal —la búsqueda de vulnerabilidades— se está viendo colonizado por el mismo ruido que invade la escritura, el arte o las redes sociales.

La IA puede ser una aliada poderosa en ciberseguridad —para análisis estático, detección de anomalías o simulaciones de ataque—, pero sólo si se usa con criterio y bajo supervisión humana.

El impacto de este fenómeno va más allá del tiempo perdido. Los bug bounty dependen de la confianza entre las partes:

• La empresa asume que quien reporta actúa de buena fe.
• El investigador confía en que su trabajo será valorado justamente.

La llegada de reportes fabricados por IA erosiona esa relación. Los equipos de seguridad se vuelven más escépticos y los verdaderos investigadores pueden ser penalizados injustamente por la desconfianza generada.

Además, existe un dilema ético: ¿debería considerarse válido el uso de IA como apoyo para analizar código, siempre que el resultado sea verificado por una persona? La frontera entre asistencia legítima y fraude automatizado es cada vez más difusa.

Imagen | Marcos Merino mediante IA

En Genbeta | El 'vibe coding' hará que cada vez escribamos menos código. Así que los ingenieros de software tendrán una tarea titánica 

Simon Højberg, ingeniero frontend, ha publicado en su blog un texto que es algo más que una crítica al uso de la IA en el desarrollo de software: no se queja porque la IA "venga a quitarnos el trabajo", sino porque —según él— está borrando la misma identidad cultural del programador.

La programación, dice, siempre fue un acto de precisión, artesanía y pensamiento lógico. Hoy, con las herramientas de inteligencia artificial generativa, está mutando en algo completamente contrario a esa idea: en el llamado vibe-coding (recordemos que una posible traducción literal podría ser 'programar por sensaciones').

De artesanos a 'operadores'

Durante décadas, los programadores se definieron como artesanos del pensamiento formal. Su tarea no era solo construir software, sino comprender profundamente los sistemas: cómo funcionan, cómo fallan y cómo se transforman.

En su ensayo, Højberg recuerda sus días programando frente a Vim, su editor de texto. Ahí, dice, encontraba el placer de la creación pura: resolver un rompecabezas lógico con las manos y la mente sincronizadas. Pero ese mundo —según él— se está evaporando:

"Hoy nos piden escribir especificaciones en Markdown en lugar de código. Ya no exploramos los rincones del sistema ni resolvemos acertijos [...] Ahora operamos una nube de agentes que piensan por nosotros".

El vibe-coding reemplaza el oficio por una especie de dirección de orquesta, donde el programador dicta órdenes en lenguaje natural y la IA ejecuta. El problema, dice Højberg, es que eso desconecta al ser humano de su propia herramienta. Ya no somos creadores, sino supervisores: y lo peor es que nos estamos acostumbrando a no entender lo que producimos.

En Genbeta

"Escribir código no es 'lo aburrido', es mi oficio". Este programador ha vuelto al modo texto para evitar la tentación de la IA

El retorno al caos

Para Højberg, el corazón del problema no es la IA en sí, sino el lenguaje con el que programamos cuando la usamos: el lenguaje natural. El nuestro, vaya.

"Los LLMs (modelos de lenguaje) son imprecisos por naturaleza. Tanto en sus propiedades como en la manera en que los instruimos: con lenguajes naturales que se pueden malinterpretar".

"Es curioso que hayamos elegido este enfoque para la computación, considerando cuánto nos incomoda a los programadores el no determinismo. Preferimos la previsibilidad [pero] el código generado por LLMs representa lo opuesto a eso: un caos inconsistente".

Durante más de 70 años, la computación evolucionó buscando la precisión. Los lenguajes de programación formales —desde el ensamblador hasta Python— fueron específicamente diseñados para eliminar la ambigüedad, y el ordenador debía hacer exactamente lo que el humano ordenara. Esa era, de hecho, la belleza del código: la posibilidad de dominar el caos del lenguaje humano mediante estructuras lógicas, reglas y tipos de datos claros.

Con la IA, afirma Højberg, esa claridad se desvanece. El código generado por un modelo de lenguaje puede cambiar con cada intento, aunque el 'prompt' sea el mismo... todo ello porque es probabilístico, no determinista. Y lo peor: puede parecer correcto, compilar incluso, y aun así estar profundamente roto.

Dijkstra tenía razón

Ojo, que Højberg no está solo en su cruzada. De hecho, para justificar su posición, cita a uno de los grandes filósofos de la computación: Edsger W. Dijkstra, pionero de la ingeniería de software y defensor acérrimo del rigor formal.

En 1979, Dijkstra escribió un breve (y ahora visionario) texto titulado “On the foolishness of natural language programming” ("Sobre la tontería de programar con lenguaje natural"). Allí advertía:

"Debemos desafiar la idea de que los lenguajes naturales simplifican el trabajo. [...] La virtud de los textos formales es que su manipulación, para ser legítima, debe cumplir solo unas pocas reglas simples. Son, cuando lo piensas, una herramienta asombrosamente efectiva para excluir todo tipo de sinsentidos que, al usar nuestras lenguas nativas, resulta casi imposible evitar".

Casi medio siglo después, Højberg rescata esa advertencia y la aplica a los sistemas de inteligencia artificial actuales. Su mensaje es claro: volver al lenguaje natural es un retroceso intelectual.

En Genbeta

Este programador, sobre los colegas que recurren a la IA: "No me importa cómo llegó el código a tu IDE, quiero que te importe"

Donde antes buscábamos precisión, ahora aceptamos probabilidad. Donde antes cultivábamos el pensamiento lógico, ahora confiamos en un modelo estadístico que 'adivina' lo que queremos decir.

La pérdida del rigor mental

Programar no es solo dar instrucciones a un ordenador: es una forma de pensar. Cuando un programador traduce su idea a código, está forzando su mente a formalizar, depurar y estructurar su razonamiento. Es ese proceso lo que genera comprensión... algo que con la IA se pierde, y el pensamiento formal se sustituye por el consumo pasivo.

"Hay algo en el código generado por IA que hace que mis ojos se nublen. Lo leo sin atención, abrumado y aburrido. Acepto errores invisibles, siempre que el programa compile".

El programador ya no necesita construir una 'teoría' interna del sistema, como decía el informático danés Peter Naur en su célebre texto 'Programming as Theory Building': Naur sostenía que lo más importante del proceso de programar no es el software resultante, sino el entendimiento que el programador desarrolla al hacerlo, sin esa comprensión, mantener y extender un sistema se vuelve imposible.

El vibe-coding destruye precisamente eso, el contacto directo con la complejidad: la IA oculta el proceso y ofrece resultados opacos... y, así, el código 'funciona' —hasta que deja de hacerlo—, y nadie sabe muy bien por qué.

Imagen | Marcos Merino mediante IA

En Genbeta | El inesperado paralelismo entre el 'vibe coding' y las tragaperras. Este programador explican cómo logran que el usuario se 'enganche' 

En una época donde los sistemas operativos móviles están completamente dominados por Android y iOS, cuesta imaginar que hubo un tiempo en el que otras alternativas radicalmente distintas tenían presencia relevante en el mercado: una de ellas fue Symbian, el sistema operativo pionero que dominó la era de los primeros smartphones.

Pero lo más sorprendente no es que se haya visto expulsado del mercado por iOS y Android, sino su total olvido, porque Symbian fue liberado en su momento como software libre, y más de una década después, nadie ha hecho nada relevante con su código.

Un gigante que dominó el mundo móvil

Symbian nació a partir del sistema operativo EPOC32, desarrollado por Psion, una empresa británica que fabricaba asistentes personales (PDA). En 1998, Psion se alió con Nokia, Ericsson y Motorola para formar la Symbian Ltd., cuyo propósito era crear una plataforma estándar para smartphones. Lo lograron: Symbian dominó el mercado móvil durante más de una década, llegando a estar presente en más del 60 % de los teléfonos inteligentes vendidos en todo el mundo a mediados de los 2000.

A diferencia de otros sistemas de la época, Symbian fue construido desde cero como un sistema operativo de tiempo real y arquitectura microkernel, diseñado en C++ cuando este lenguaje aún ni siquiera se había estandarizado por completo. Su núcleo EKA2, una maravilla de ingeniería liderada por Dennis May, ofrecía capacidades únicas de multitarea, eficiencia energética y adaptabilidad a hardware limitado. Fue, sin duda, un OS adelantado a su tiempo.

El experimento fallido del código abierto

En 2010, tras años de competencia creciente (y cuota de mercado decreciente) frente a iOS y Android, Nokia tomó una decisión histórica: liberó el código fuente de Symbian, convirtiéndolo en un proyecto de software libre. Fue un movimiento valiente, pero quizás también desesperado. Con ello se esperaba que la comunidad de desarrolladores se volcara en mantener vivo el sistema.

Pero eso nunca ocurrió.

Pese a que el código sigue disponible en plataformas como GitHub y SourceForge, y a que existen recursos técnicos valiosos para ayudar a trabajar con el mismo, como Symbian OS Internals o The Symbian OS Architecture Sourcebook, el proyecto fue completamente abandonado. Mientras que otros sistemas propietarios extintos —como BeOS o AmigaOS— han dado lugar a forks o reimplementaciones activas, el pobre Symbian se limita a languidecer en el limbo digital.

En Xataka Móvil

¿Qué fue de Symbian?

¿Por qué nadie lo retomó?

Hay muchas teorías. Algunos argumentan que programar en Symbian nunca fue fácil, al menos comparado con otras plataformas. Aunque herramientas como P.I.P.S. facilitaron el uso de bibliotecas estándar de C, desarrollar apps nativas seguía siendo un proceso farragoso. Además, el ecosistema Symbian se autoboicoteó con una guerra de interfaces de usuario —Nokia creó múltiples UIs incompatibles entre sí—, lo que fragmentó aún más la plataforma.

Pero quizás la razón más relevante es que el mundo ya se había movido en otra dirección: Android, con su base en Linux y filosofía abierta, pero pragmática, había capturado el interés de fabricantes y desarrolladores. iOS, por otro lado, ofrecía una experiencia pulida y un ecosistema rentable. Symbian, con su complejidad técnica, su herencia de hardware limitado y una comunidad diezmada, simplemente se quedó sin aliados.

Un legado ignorado... pero aún hay tiempo

Resulta irónico que, en pleno 2025, cuando proliferan proyectos de sistemas operativos escritos desde cero en C++ —como Serenity OS o Genode—, nadie mire hacia Symbian, que fue probado en batalla, desplegado en cientos de millones de dispositivos, y sigue siendo más completo que muchos de estos nuevos experimentos.

El código está ahí, al igual que herramientas modernas —como Qt, también en C++— que podrían facilitar una adaptación contemporánea. En un mundo donde resucitamos sistemas obsoletos como OS/2 o PalmOS por pura nostalgia retroinformática, Symbian ofrece, además, solidez técnica y eficiencia probada.

¿Podría alguien retomarlo? Técnicamente, sí. No hay necesidad de salvaguardar la retrocompatibilidad, ni de preservar el funcionamiento de apps heredadas. En el contexto actual —con dispositivos como Raspberry Pi, microcontroladores avanzados y hardware embebido— Symbian podría renacer como un sistema operativo ligero, robusto y abierto, ideal para entornos donde Android es demasiado pesado y Linux, demasiado generalista.

Vía | The Register

Imagen | Marcos Merino mediante IA

En Xataka Android | Tizen, Windows Phone, Symbian y más: los sistemas operativos que se enfrentaron a Android y acabaron en el olvido

En el mundo del software, las licencias juegan un papel crucial: determinan no solo cómo se distribuye el software, sino también cómo puede reutilizarse, modificarse o comercializarse. Y eso se aplica a todo el software, incluso al 'software libre', aunque la terminología parece hacer pensar a muchos que son 'libres... de hacer lo que quieran con su código'.

Así, de cuando en cuando salen a la luz casos de 'desarrolladores' que reutilizan código 'open source'... pero lo redistribuyen bajo una licencia incompatible con la original. En ocasiones el problema es que intentan apropiárselo para lanzarlo con licencia cerrada (comercial) y en ocasiones se sienten con libertad de suprimir alguna de sus contadas restricciones para hacerlo 'más abierto'.

Y este es el caso del conflicto desencadenado en torno al proyecto 'Glass', un asistente de reuniones de código abierto, y su presunto uso indebido de código sometido a la licencia GPLv3.

¿Qué es la licencia GPLv3?

La Licencia Pública General GNU versión 3 (GPLv3) es una de las más estrictas en el ecosistema FOSS. Establece que:

• Cualquier software que utilice código con licencia GPLv3 debe también publicarse bajo la misma licencia.
• No se permite redistribuirlo con una licencia más permisiva (como Apache 2.0) si ello reduce las libertades garantizadas por la GPL.
• Exige que se mantenga la cadena de derechos: libertad para usar, modificar y compartir.

El creador de 'Glass' lo tiene claro no, cristalino

Todo comenzó con un anuncio en X, en el que el desarrollador del nuevo proyecto 'Glass' (respaldado por la influyente 'aceleradora de startups' Y Combinator, para más inri) celebraba que su equipo había creado y lanzado en tan solo 4 días este nuevo software, basado en su anterior herramienta llamada Cluely.

En Genbeta

La corte estadounidense ha dictaminado que una licencia open source cuenta como contrato legal

Sin embargo, la comunidad rápidamente detectó similitudes notables entre 'Glass' y otro proyecto publicado bajo GPLv3, 'Cheatting Daddy'. El autor original del código, tras exponer claramente el caso aportando pantallazos del código, ha denunciado en X que:

• El código de Glass reutilizaba partes sustanciales del suyo.
• No se hizo mención de la autoría original.
• Se cambió la licencia a Apache 2.0, incompatible con GPLv3.
• Incluso los comentarios y bibliotecas usadas eran idénticos.

Es decir, en resumen, una apropiación indebida de trabajo ajeno, vulnerando tanto el espíritu como la letra de la GPLv3.

Comparación de código de ambos repositorios

¿Por qué esto es problemático?

Reetiquetar código GPLv3 como Apache 2.0 no es solo poco ético, sino explícitamente ilegal. Y es que, aunque Apache 2.0 puede ser incorporada en proyectos GPLv3, lo contrario no es válido: un proyecto GPLv3 no puede ser relicenciado como Apache 2.0.

Por eso se dice que GPLv3 es una licencia viral: no tiene nada que ver con redes sociales, sino con el hecho de que el código derivado está automáticamente 'infectado' desde un punto de vista legal, con la GPLv3.

Gergely Orosz (autor del influyente newsletter 'The Pragmatic Engineer') explica que lo ocurrido es una ilegalidad que puede desembocar en costosas demandas, y critica duramente a YC por apoyar a fundadores que "no entienden ni lo más básico sobre licencias".

La tomadura de pelo del Caso PearAI

Pero no es la primera vez que Y Combinator se encuentra en el ojo del huracán tras haber demostrado estar dispuesta a respaldar proyectos con poco rigor legal con tal de no perderse "la próxima gran novedad". Y es que, el pasado mes de septiembre, PearAI (otra startup de la aceleradora) lanzaba un editor de código dotado de funciones de IA.

Duke Pan, su fundador, anunció entusiasmado su proyecto a través de publicaciones en redes sociales y con un vídeo en YouTube. Lo que inicialmente parecía una propuesta innovadora terminó atrayendo la atención por una razón equivocada: Pan admitió abiertamente que PearAI era una bifurcación (o 'fork') del editor de código Continue, que a su vez se basa en el popular Visual Studio Code (VSCode).

El problema no fue solo el uso del código, sino la forma chapucera en que Pan lo hizo. Su desarrollador cogió el código de 'Continue', cambió todas las referencias al termino "Continue" en el mismo por "PearAI" y a continuación lanzó el resultado bajo una licencia propia inventada —la "Pear Enterprise License"... redactada por ChatGPT.

Imagen | Marcos Merino mediante IA

En Genbeta | "No envíes código contaminado": estos proyectos de software libre dicen 'No' al uso de asistentes de programación con IA

Hace apenas unos años, Microsoft dominaba sin competencia real el naciente mercado de la programación asistida por IA. Con GitHub Copilot (una por aquel entonces revolucionaria plataforma basada en Codex, descendiente de GPT-3) logró captar la atención de millones de desarrolladores a ser capaz de generar tanto código como sugerencias a partir de prompts.

Pero, como ocurre tantas veces en el mundo tecnológico, poco queda de lo que parecía una hegemonía sólida: hoy, la de Microsoft es sólo la opción más veterana entre un buen puñado de buenas propuestas. El mercado de las herramientas de desarrollo con IA ha explotado, y Copilot ya no es el copiloto único en esta carrera.

El boom de Copilot: un inicio prometedor

GitHub Copilot nació como una auténtica revolución. Su capacidad para generar código autónomo a partir de simples instrucciones en lenguaje natural (consecuencia de haber entrenado a Codex con el código público de los repositorios de GitHub) dejó boquiabiertos a miles de desarrolladores. Desde completar funciones completas en React hasta sugerir fragmentos reutilizables, parecía que el futuro de la programación había llegado.

La comunidad se entusiasmó. En foros como Hacker News, muchos lo comparaban con tener un compañero de 'pair programming' invisible que incluso les obligaba a escribir mejores comentarios y estructuras más claras.

Pero… ¿qué pasó?

Lo que pasó fue, sencillamente, el dinamismo brutal del sector: mientras Microsoft dormía en los laureles del éxito de Copilot, surgieron startups con modelos de desarrollo más ágiles, ciclos de producto mucho más cortos y una obsesión radical por la velocidad y experiencia del usuario.

Uno de los casos más claros es Cursor, una alternativa basada en un fork de VSCode (sí, el propio editor de Microsoft), que ha sabido capitalizar todo lo bueno de la base original… y hacerlo mejor. Cursor permite ediciones en bloque con IA, navegación semántica del código, refactorización guiada, y está orientado a desarrolladores que quieren mantener el foco y la velocidad.

En Genbeta

Un desarrollador preguntó qué IA es mejor para programar. Los más de 28.000 votos fueron muy contundentes

Y por si fuera poco, ahora el sector ha comenzado a atraer la atención de gigantes como OpenAI. Según las últimas noticias (de ayer mismo, vaya), OpenAI está en negociaciones para adquirir Windsurf (anteriormente conocida como Codeium) por cerca de 3.000 millones de dólares.

¿Por qué tanto interés? Porque Windsurf ha crecido rápido, ofreciendo una integración fluida, sugerencias más rápidas y personalizables, y porque representa un futuro donde la IA deja de ser solo autocompletado y se convierte en coproductora de software.

Editor de código + chatbot en Cursor

Una competencia feroz y una fragmentación creciente

La situación actual muestra un tablero mucho más fragmentado. A Copilot no solo le ha salido competencia directa en la escritura de código: el ecosistema alrededor de la programación asistida con IA se está expandiendo hacia la gestión de infraestructura, testing, refactorización automática, incluso UI/UX.

Google, por ejemplo, ha lanzado recientemente Firebase Studio, una plataforma gratuita que integra capacidades de generación de código, backend y despliegue, todo potenciado por IA. ¿El objetivo? Que crear una aplicación web sea tan simple como escribir lo que quieres que haga.

Además, hay empresas como Anysphere (responsables de Cursor) que ya están siendo valoradas cerca de los 10.000 millones de dólares, y cada ronda de financiación solo valida lo que muchos desarrolladores ya están diciendo en voz alta: estas herramientas nos hacen más productivos que Copilot.

Microsoft no está fuera del juego, pero ya no va solo

Sería un error pensar que Microsoft ha perdido del todo. GitHub Copilot sigue siendo una herramienta muy potente, con una integración profunda en el ecosistema de Visual Studio Code, GitHub Actions, y la nube de Azure (y eso no es poca cosa). Además, cuenta con un músculo financiero y de datos inmenso. Pero ya no es suficiente.

Los nuevos jugadores no solo compiten con funcionalidades: lo hacen con velocidad, innovando en la interfaz... muchas veces, ofrecen una experiencia mejor para proyectos modernos, lenguajes emergentes o flujos de trabajo más ágiles.

El hecho de que Cursor sea un fork de VSCode debería ser una señal para Microsoft: su propia tecnología ha sido usada como trampolín para construir algo más rápido, más enfocado y, para muchos, más útil.

En Genbeta

El 'vibe coding' hará que cada vez escribamos menos código. Así que los ingenieros de software tendrán una tarea titánica

Rivales destacados de GitHub Copilot en 2025

La explosión de herramientas de programación asistida por inteligencia artificial ha dado lugar a una competencia feroz. Estas son algunas de las alternativas más relevantes y que están ganando terreno rápidamente:

• Cursor: Editor de código basado en un fork de VSCode con IA integrada, destaca por su capacidad de refactorización automática, edición guiada por instrucciones en lenguaje natural y navegación semántica del código.
• Windsurf: Plataforma de autocompletado y asistencia IA para múltiples lenguajes. Extremadamente rápida, con soporte para múltiples IDEs y entornos.

• Amazon CodeWhisperer: Esta herramienta de generación de código IA integrada en AWS está pensada para soluciones serverless y cloud, integración profunda con AWS Lambda, CloudFormation, etc.
• Google Firebase Studio: Plataforma unificada de desarrollo frontend /backend impulsada por IA.
• Tabnine: Motor de autocompletado IA para varios IDEs, que destaca por su velocidad y la posibilidad de entrenar con código privado. Otro veterano de este mercado.
• v0: Herramienta de diseño y desarrollo web con IA que transforma texto en interfaces visuales listas para producción. Ideal para frontends rápidos, 'landing pages' y MVPs.
• Lovable Un asistente de desarrollo con IA centrado en experiencias UX/UI y producto, muy valorado por startups y diseñadores con alma de devs.
• Bolt: Un entorno de desarrollo acelerado para startups técnicas que construye arquitectura backend completa, APIs REST y lógica de negocio en minutos. Enfocado a velocidad de ejecución para MVPs y escalado temprano.

Imagen | Marcos Merino mediante IA

En Genbeta | El 'vibe coding' está revolucionando la programación. Y también haciendo destrozos muy grandes en el código 

Durante décadas, 'Matrix' ha sido un referente del cine de ciencia ficción, no sólo por su filosófica trama y sus efectos visuales, sino también (o, quizá, 'sobre todo') por su impactante estética. Y entre los elementos más icónicos de la misma destaca el 'código verde cayendo en cascada', una lluvia digital de datos que representa la estructura fundamental del mundo virtual y que permite 'leerlo' desde el mundo real.

Sin embargo, detrás de su apariencia misteriosa se oculta un origen mucho más mundano de lo que podría imaginarse: libros de recetas de cocina japonesa.

"¡Ya sé hacer shushi!" "Demuéstralo"

En realidad, hace ya unos años que se difundió la afirmación de que el código de 'Matrix' consiste en recetas típicas japonesas. Simon Whiteley, diseñador de producción de la película, lo reveló en una entrevista con CNET de 2017

"Me gusta decirle a todo el mundo que el código de 'Matrix' está hecho de recetas de sushi japonesas".

La afirmación no es, sin embargo, 100% precisa: si bien el diseño del código se elaboró escaneando caracteres de los libros de cocina de su esposa (ciudadana japonesa), éstos fueron estilizados y mezclados con otros símbolos, como números y letras del estilo de las antiguas pantallas IBM, y símbolos japoneses katakana al azar (los libros japoneses suelen usar las otras dos escrituras del país: kanji e hiragana).

Luego, la mezcla resultante fue alterada para lograr el efecto visual distintivo de la película.

En Xataka

Inteligencia artificial en Matrix: "El problema es la elección"

En otra entrevista, ya en 2019, Whiteley profundizó en el proceso de creación. Reveló que, además de en los citados libros de cocina, también se había inspirado en hojas de aprendizaje del alfabeto japonés que usaban sus hijos en la escuela.

Para obtener el aspecto deseado, dibujó a mano los caracteres antes de digitalizarlos, asegurándose de añadir imperfecciones deliberadas (como símbolos recortados o líneas irregulares) para hacer que el código pareciera más "orgánico y encriptado".

Otro detalle clave del código, en el que también se aprecia la influencia japonesa, fue la dirección de desplazamiento. Inicialmente, Whiteley había pensado hacer que los caracteres fluyeran de izquierda a derecha en la pantalla, pero el resultado no resultaba visualmente atractivo.

De modo que, inspirándose en los libros japoneses, donde los textos suelen escribirse en columnas de arriba hacia abajo, decidió copiar dicha disposición... generando así el icónico 'scroll de datos' que hoy todos reconocemos.

De realidades y sabores

Curiosamente, Whiteley nunca ha querido revelar qué receta (o recetas) en particular usó para diseñar el código de 'Matrix', y afirma que mantenerlo en secreto es "parte de la magia". Quizá estés pensando ahora mismo que vaya estupidez, que bastaría con preguntar a cualquiera que supiese japonés para que lo leyera...

En Genbeta

Este era el código fuente del programador traidor de Parque Jurásico. 32 años después, sabemos para qué servía

...pero, de hecho, el código está tan modificado que, al final, ni los propios nipones pueden identificar palabras o frases completas en la película: la combinación de caracteres estilizados y elementos numéricos impide reconstruir cualquier texto coherente.

Resumiendo: que lo que comenzó como un simple recurso visual basado en un libro de cocina terminó convirtiéndose en uno de los iconos más reconocibles del cine moderno. La historia detrás del 'código verde' de 'Matrix' es un reflejo perfecto del tema central de la saga: que la realidad no es lo que parece... y que siempre nos vamos a quedar con la duda al respecto, como les pasaba a los personajes de la película al preguntarse sobre el sabor real del filete.

Imagen | Escena de 'Matrix' (Warner Bros. Pictures) + Marcos Merino mediante IA

En Genbeta | Los errores de 'Hackers', la película que marcó cómo ve Hollywood a los 'piratas informáticos'

En el vertiginoso mundo de la IA, pocas cosas impulsan más la innovación que la competencia: recientemente, OpenAI ha dado un paso significativo al incorporar en su modelo o3-mini una funcionalidad conocida como 'cadena de pensamiento', previamente incluida (y acogida con entusiasmo) en plataformas como DeepSeek.

Esta característica promete transformar (entre otras cosas) la forma en que los usuarios aprenden y perfeccionan sus habilidades de programación a través de ChatGPT. Ya repasamos hace unas semanas cómo ayudaba DeepSeek en esta tarea.

Pero ¿qué es la "cadena de pensamiento"?

La "cadena de pensamiento" es un proceso mediante el cual un modelo de IA desglosa su razonamiento en pasos secuenciales antes de proporcionar una respuesta: algo así como su monólogo interno. Este enfoque permite al modelo analizar y verificar internamente cada etapa de su razonamiento, reduciendo la posibilidad de errores y ofreciendo respuestas más precisas y fundamentadas.

En el contexto del aprendizaje de programación, esta funcionalidad resulta especialmente valiosa, ya que permite a los usuarios seguir el proceso lógico que conduce a una solución, facilitando una comprensión más profunda de los conceptos y técnicas aplicadas.

La implementación en o3-mini de OpenAI

OpenAI ha integrado esta funcionalidad en su modelo o3-mini: al hacer uso de éste, los usuarios pueden visualizar el razonamiento paso a paso que el modelo sigue para llegar a sus conclusiones. Esto es posible haciendo clic sobre el texto que antecede a la respuesta del chatbot (en el que se indica cuánto ha tardado en 'razonar' la respuesta), lo que desplegará el relato de la 'cadena de pensamiento'.

Desde luego, resulta bastante más informativa la cadena de pensamiento que la respuesta propiamente dicha. Y aun así, es errónea: la respuesta correcta sería "yo"... aunque es más fácil darse cuenta de eso revisando la cadena de pensamiento, claro.

Esta transparencia no solo mejora la confianza en las respuestas proporcionadas, sino que también sirve como una herramienta educativa, permitiendo a los usuarios identificar posibles errores en su propio código y comprender mejor las soluciones propuestas.

En Xataka

o3-mini: qué es, cómo funciona y cómo usar el nuevo modelo de inteligencia artificial gratis con razonamiento de ChatGPT

¿Ofrece lo mismo que DeepSeek?

Por desgracia, no: esta nueva característica de o3-mini no es idéntica a la de DeepSeek. Yes que OpenAI ha optado por no revelar la totalidad del proceso de pensamiento: lo que la mayor parte de los usuarios (tanto gratuitos como de pago) verán a partir de ahora es más bien un resumen estructurado del razonamiento que sigue el modelo para generar sus respuestas.

Una filtración permite apreciar las diferencias entre la cadena de pensamiento 'en crudo' y la 'procesada':

Esta decisión responde a la necesidad de proteger su tecnología y mantener una ventaja competitiva (es más fácil 'clonar' un modelo de IA si se tiene acceso a su verdadera cadena de pensamiento), al mismo tiempo que busca satisfacer las exigencias de mayor claridad por parte de la comunidad.Para los suscriptores premium que utilicen o3-mini-high, eso sí, se añadirá una lectura más detallada del proceso, permitiendo el acceso a un análisis más profundo del pensamiento de la IA.

Beneficios para el aprendizaje de programación

Ejemplo de cómo la cadena de pensamiento analiza un problema de código. Leer tanto ésta como la respuesta propiamente dicha garantiza que ninguna información importante se queda 'en el aire'

Una de las características más destacadas de esta funcionalidad es la posibilidad de observar en tiempo real cómo el modelo desglosa y analiza un problema. Esta experiencia interactiva no solo hace que el aprendizaje sea más dinámico, sino que también permite a los usuarios adaptar y aplicar el razonamiento del modelo a sus propios desafíos de programación. Ver el proceso en directo es, sin duda, una herramienta muy útil para cualquier aspirante a programador.

Así, la incorporación de la cadena de pensamiento en ChatGPT, sea equiparable o no a la de DeepSeek, ofrece sin lugar a dudas múltiples ventajas con respecto a modelos precedentes de OpenAI para quienes buscan aprender o mejorar en programación:

• Comprensión profunda: Al seguir el razonamiento del modelo, los usuarios pueden entender mejor cómo se llega a una solución específica, reforzando su aprendizaje.
• Detección de errores: La transparencia en el proceso permite identificar y corregir errores en el código de manera más eficiente.
• Mejora en la lógica de programación: Observar el enfoque paso a paso del modelo ayuda a los usuarios a desarrollar una mentalidad lógica y estructurada para abordar problemas de programación.

Imagen | Marcos Merino mediante IA

En Xataka | La paradoja DeepSeek: el modelo de IA más exitoso de 2025 es también el más vetado

En el mundo del cine, a menudo se pueden encontrar detalles y elementos que pueden pasar desapercibidos para la mayoría de los espectadores, pero que resultan intrigantes para aquellos con conocimientos técnicos o especializados.

Las escenas relacionadas con la programación o con el hacking suelen estar entre ellas, por la frecuencia con que se cometen errores de bulto a la hora de representarlas.

Muchos de los que lean este texto recordarán la famosa escena de 'Parque Jurásico' en la que Dennis Nedry, el programador jefe del parque, manipula los sistemas de seguridad del mismo para poder tener acceso al laboratorio y huir así con embriones de dinosaurio.

La jugada le sale bastante mal (por lo de terminar muriendo durante su huida a manos del dilofosaurio, y todo eso) pero, de paso, desencadena el incidente reflejado en la película.

Meme basado en escena del videojuego 'Jurassic Word: Evolution'

Pero antes de todo eso, mientras se dispone a ejecutar el malware que ha creado ('Whte_rbt.obj', una referencia a 'Alicia en el País de las Maravillas'), los espectadores tienen ocasión de vislumbrar la pantalla de la terminal de Nedry, y la presencia de código fuente en la misma.

¿Eso era un entorno de desarrollo real? ¿El código se corresponde con algún lenguaje existente o es texto aleatorio? Y si es real, ¿de verdad está diseñado para gestionar el sistema de seguridad de un parque de dinosaurios?

Jurassic Park 1.5: Informática Forense

El debate surgió ya hace años en StackExchange, haciendo que los usuarios analizaran cuidadosamente las imágenes de la pantalla de la computadora de Nedry para intentar identificar los elementos del mismo.

Fotograma de 'Parque Jurásico' (1993)

En primer lugar, lo más fácil, el modelo de ordenador: se trata de un Macintosh Quadra 700, uno de los mejores lanzados a principios de los años 90 (el modelo se lanzó en 1991, dos años antes del estreno de la película).

Cuando la cámara hace zoom sobre la pantalla, nos permite vislumbrar tres buffers  de texto diferentes con código fuente en un IDE muy reconocible por los usuarios más veteranos de Mac: el Macintosh Programmer's Workshop.

Una de las pistas más notables es el título de la ventana en la esquina superior izquierda de la pantalla, que muestra "NEDRYLAND :MPW:Examples". 'MPW' se refiere, claro, al citado IDE.

En esa misma shell, se observa la función "NewHandle(GetHandleSize())", que forma parte de la API del Mac OS clásico (antes decir, de antes de que empezara a estar basado en BSD/Unix).

En Genbeta

Algunas de las escenas de hacking más genialmente ridículas del cine y la TV: los guionistas de Hollywood no leen Genbeta

Por otro lado, el operador de asignación ":=" y la sintaxis de las sentencias if/else sugieren sin lugar a dudas que estamos ante un lenguaje basado en Pascal. Concretamente, Object Pascal.

Además, la ventana de la derecha parece mostrar un script relacionado con el control de versiones de código fuente... un script que usa un lenguaje que antiguos desarrolladores han reconocido como el MPW Shell, basado en el lenguaje de shell csh de Unix, y de uso exclusivo por parte del antiguo IDE de Apple.

En la parte inferior de la pantalla, se puede ver otro script, en este caso relacionado con la conversión de imágenes en formato .PICT de Apple en recursos integrables en archivos binarios, algo frecuente a la hora de desarrollar software.

La conclusión a la que llegan la mayoría de los usuarios es que lo que vemos en pantalla son sólo códigos de ejemplo que venían ya incluidos en esa versión de MPW. Todo muy genérico, nada relacionado con sistemas de seguridad de parques ni zoos, por desgracia.

Imagen | Fotograma de 'Parque Jurásico'

En Espinof | ¿Sabías que 'Parque Jurásico' esconde un homenaje a otra mítica película de Steven Spielberg? El divertido guiño del director a sus fans que es casi imposible de detectar

WinAmp, el reproductor multimedia que bien puede reivindicar a estas alturas la etiqueta de 'legendario', y que ha vivido últimamente unos años convulsos en los que pareció que se convertiría en 'abandonware', acaba de ver publicado su código fuente en GitHub.

Este hecho se venía esperando desde su anuncio en mayo de 2024 y se ha cumplido hace unas horas, pero ha supuesto un chasco para muchos usuarios esperanzados, que confiaban en que esta publicación del código permitiera aprovechar su código para otros proyectos.

Sin embargo, se han encontrado con que el 'código en abierto' no siempre es lo mismo que el 'código abierto'.

Icono de una era

WinAmp se convirtió en un fenómeno cultural a finales de los años 90, cuando la popularidad de los archivos MP3 estaba en auge, poco antes de que Napster desembarcara en nuestros PCs.

Desarrollado por Nullsoft, el reproductor ofrecía una interfaz personalizable (muchos aún recordamos la fiebre que hubo con las 'skins' de WinAmp por aquellas fechas), soporte para una amplia gama de formatos de audio y complementos de visualización.

A pesar de su éxito, el ritmo de desarrollo del software se desaceleró después de que Nullsoft fue adquirido por AOL, y en 2013, el producto fue descontinuado. El resurgimiento de Winamp llegó en 2014 cuando Radionomy adquirió el proyecto con la intención de revitalizarlo, pero pese a sus actualizaciones, nunca llegó a restaurar su gloria pasada.

En Genbeta

Probamos el nuevo Winamp, la reinvención del mítico reproductor de música para competir con Spotify

Retorno controvertido

Ahora, el código fuente de WinAmp está disponible en GitHub (junto con las herramientas de desarrollo y bibliotecas asociadas), y sus responsables ofrecen a los desarrolladores la oportunidad de colaborar en la modernización del reproductor, contribuyendo con correcciones de errores y nuevas funcionalidades.

No obstante, la liberación del código fuente ha sido recibida con escepticismo por parte de muchos expertos: aunque se ha presentado como una medida para abrir el desarrollo a la comunidad, la realidad es que la licencia bajo la cual se ha publicado el código tiene restricciones significativas.

Así, la 'WinAmp Collaborative License' prohíbe la distribución de versiones modificadas o bifurcadas del software, limitando su uso y distribución a los mantenedores oficiales del proyecto.

En resumen, los desarrolladores independientes harán aportaciones (trabajarán gratis), y la mayoría caerán en saco roto... mientras que el código de WinAmp no podrá reutilizarse en otros proyectos.

El escepticismo de parte de la comunidad ante las intenciones de los propietarios de la aplicación no es infundado, especialmente si tenemos en cuenta que WinAmp, en el pasado, se aventuró en el mundo de los hoy polémicos NFT sin mucho éxito.

Dicho eso, el repositorio que alberga el código fuente de WinAmp ha generado un notable interés en la comunidad de desarrolladores, y ya acumula 3.300 estrellas en menos de 24 horas.

Imagen | Captura de pantalla + Marcos Merino mediante IA

En Genbeta | No hay mejor ni mayor homenaje a Winamp que esta web con 65.000 skins

En una entrevista realizada en mayo del año pasado, el CEO de Nvidia, Jensen Huang, afirmaba que la IA afectará a todas las industrias, incluida a la del desarrollo de software, y que cualquier persona podrá ser programador gracias a esta tecnología emergente.

Pero, claro, se plantea entonces una pregunta: ¿acaso podrá haber 'programadores' como tal cuando todos seamos programadores?

Emad Mostaque, CEO de Stability AI, realizó semanas después una aportación a ese debate en una entrevista reciente con Peter H. Diamandis para el podcast 'Moonshots and Mindsets'. Según la cabeza visible de la compañía desarrolladora de Stable Diffusion, la respuesta era 'No'.

O mejor dicho, la respuesta es que sólo programarán, en el estricto sentido del término, las inteligencias artificiales.

Los programadores ya se apoyan masivamente en quien les quitará el puesto

Según Mostaque, esta desaparición de los programadores humanos tendrá lugar de aquí a cinco años. Esta previsión de un futuro poco halagüeño para los desarrolladores está respaldada, según él, por evidencia, puesto que los datos de GitHub revelan que ya hace un año "el 41% de todo el código en este momento está siendo generado por IA".

En Genbeta

Los desarrolladores pasan los días escribiendo código y solucionando errores. La IA es su aliada para centrarse en lo que prefieren

Por supuesto, ni siquiera ahora, un año más tarde, el código generado por las IAs no es tan bueno como el de un buen programador humano, pero en la mayoría de los campos sí iguala al de un programador promedio. Y lo escriben en mucho menos tiempo que cualquiera de ambos perfiles.

Los propios programadores ya han empezado a apoyarse masivamente en la IA para realizar su labor. Según la encuesta de 2023 de StackOverflow, el 70% de los encuestados usaba o tenía previsto usar herramientas de IA en sus procesos de desarrollo a lo largo de dicho año. Otra encuesta realizada en las mismas fechas por GitHub manejaba cifras mucho mayores.

Pero Mostaque va un paso más allá, y cree que la IA está avanzando tan rápido que pronto superará la capacidad humana en la programación: "No habrá necesidad de programadores humanos". Punto.

¿Exageraciones? Quizás Mostaque 'se ha venido muy arriba' con su predicción… pero los programadores ya están empezando a perder puestos de trabajo en favor de la IA: Arvind Krishna, CEO de IBM, ya anunciaba hace varios meses la suspensión de contrataciones de perfiles que pueden ser sustituidos por la IA. E iba más allá:

"Podría ver fácilmente un 30% de la plantilla de IBM siendo sustituida por IAs y automatización en un periodo de cinco años".

¿Y después de eso? Bueno, a comienzos de 2023, Mostaque ya señalaba que en 5-10 años le llegaría su hora a diseñadores gráficos, ilustradores y fotógrafos. Bueno, es cierto que no lo dijo con esas palabras, sino con éstas:

"En los próximos cinco a 10 años podremos crear [con IA] cualquier cosa que puedas imaginar con una calidad visual perfecta en tiempo real".

Imagen | Marcos Merino mediante IA

En Genbeta | Bill Gates cuenta cómo consiguió convertirse en un gran desarrollador: este es su principal consejo