Usando IAs para portar código

Buque carguero Humbergracht

En el mundo actual, con las IAs generativas trabajando a todo trapo y mejorando a buen paso, la pregunta no es si se hará alguna tarea concreta con ellas, sino cuando.

En este caso, en Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library nos cuentan una experiencia de Microsoft re-escribiendo una biblioteca criptográfica con la ayuda de una de estas IAs.

Nos hablan del proceso de verificación formal para asegurarse de que lo que obtienen es correcto y algunas otras pruebas.

Formal verification will confirm that implementations behave as intended and don’t deviate from algorithm specifications, critical for preventing attacks. We’ll also analyze compiled code to detect side-channel leaks caused by timing or hardware-level behavior.

Porque utilizar la IA y aceptar sus resultados sin más sería suicida, ¿no es así?

Interesante.

Secuestro de datos en el entorno industrial: un gran problema

En la fábrica de galletas

El secuestro de datos (ransomware) es un problema que sigue de actualidad, aunque ahora esté un poco silenciado por los riesgos de la IA. Hace algún tiempo podíamos leer On average, manufacturing companies lose $1.9 million per day to downtime from ransomware attacks. Esto es, este tipo de ataques estarían teniendo unas consecuencias del orden de 1.9 millones de dólares diarios. Se centra en empresas de fabricación (manufacturing companies).

Estos datos siempre hay que tomarlos con cuidado, porque suelen provenir de vendedores de algún producto que intentará evitarnos el problema, pero tampoco suelen ser inventados (o no del todo). En este caso los datos venían de 858 empresas que desde octubre de 2018 habrían sufrido ataques de este tipo con unos costes muy imporantes.

From 2018 to October 2024, 858 manufacturing companies suffered a confirmed ransomware attack. On average, this costs companies over $1.9 million per day of downtime, resulting in total estimated losses of $17 billion.

Este ataque es bien conocido, pero por si acaso, vale la pena recordar que se trata de que alguien (o algo) accede a nuestros sistemas y cifra la información, haciendo que no podamos utilizarla. A partir de ese momento nos piden un rescate y las pérdidas pueden venir por dos caminos:

  • Por un lado, relacionadas con el tiempo que la empresa no puede desarrollar su trabajo con normalidad
  • Por el otro, si tiene que pagar el rescate

Los ataques se producen a nivel mundial, siendo las zonas más desarrolladas las más afectadas, como es natural (ojo, seguramente también porque son de las que se tienen datos).

Luego proporciona una serie de números de los que saco que el tiempo de no dispoinibilidad iba de unas pocas horas a más de cuatro meses.

Downtime varied from several hours to 129 days

Las cantidades solicitadas por los secuestradores podían ir desde los 5000 dólares a los 200 millones, con una media de 10.7 millones.

Ransom demands varied from $5,000 to $200 million. The latter was demanded after LockBit’s attack on Boeing (which wasn’t paid)

On average, attackers demanded $10.7 million in ransom. Based on that figure, we can estimate that around $9.3 billion in ransom has been demanded in total

Hay un montón de cifras más y creo que vale la pena echarle un vistazo, aunque sean datos de hace poco más de un año.

Los países más afectados serían EEUU, Alemania, Francia, Japón, ….

Muy interesante.

Vibe coding y programación asistida por LLMs

Agua y luz

Estoy haciendo algunos experimentos con el denominado vibe coding y me parece bastante interesante: por un lado, se pierde la pereza a realizar determinados cambios que supondrían esfuerzo de mover código, renombrar cosas, … porque la IA lo hace bastante bien; por otro, algunas veces se ‘enganchan’ en determinadas decisiones y si no tenemos cuidado podemos tener un pequeño monstruo en nuestras manos. Además, desde siempre he reivindicado el verbo ‘jugar’ para aprender: en el sentido de probar cosas, hacer experimentos, ver qué sucede cuando cambiamos cosas…

Voy recopilando ideas en este hilo de X:

Pero hoy quería traer aquí al experto oficial del tema, Simon Willison, que no solo lo utiliza, hace recomendaciones y seguimiento de las novedades, sino que también aporta reflexiones y terminología. En Not all AI-assisted programming is vibe coding (but vibe coding rocks) hablaba de vibe coding, un término acuñado por Andrej Karpathy,

La definición incluye la idea de que se trata de fluir con la IA y nuestras ideas, llegando a olvidar la existencia del propio código.

En este sentido, lo que decía arriba no sería vibe coding porque mis viejas costumbres me fuerzan en muchos casos a revisar, recolocar cosas, sugerir detalles a la IA… en definitiva, lo que hace un viejo programador (si es que puedo lamarme así) para asegurarse de que lo que le entrega la IA funcionará, podrá mantenerse y seguir desarrollándose en el futuro, tendrá las prestaciones adecuadas, accesibilidad, seguridad, coste razonable (aunque aquí, moviéndonos en el tiempo ‘libre’ a veces lo podemos descuidar).

We need to create code that demonstrably works, and can be understood by other humans (and machines), and that will support continued development in the future.

We need to consider performance, accessibility, security, maintainability, cost efficiency.

We also need to read the code.

Pero, nos dice, no se trata de transformar el vive coding en un término peyorativo o un uso poco responsable de la tecnología, porque puede haber valor en ello.

I don’t want “vibe coding” to become a negative term that’s synonymous with irresponsible AI-assisted programming either. This weird new shape of programming has so much to offer the world!

Todo el mundo, nos dice, debería poder automatizar tareas aburridas, y no debería ser necesario un informático para eso.

I believe everyone deserves the ability to automate tedious tasks in their lives with computers. You shouldn’t need a computer science degree or programming bootcamp in order to get computers to do extremely specific tasks for you.

Y es posible que esta aproximación sea útil para mucha gente, que de otra forma no tendría acceso a estas comodidades.

If vibe coding grants millions of new people the ability to build their own custom tools, I could not be happier about it.

Naturalmente, mucha de esa gente se llevará sustos y disgustos y no conseguirá lo que quería, pero también habrá gente que empezará a mirar lo que ha generado, aprenderá sobre ello y, tal vez, terminen siendo buenos desarrolladores.

Some of those people will get bitten by the programming bug and go on to become proficient software developers.

La curva de aprendizaje es muy empinada al principio, pero las IAs son muy adeucadas para explicarnos lo que hace el código que han generado, y no se cansan nunca.

Por lo tanto, ¿qué deberíamos tener en cuenta?

  • Proyectos de bajo riesgo: cuando algún fallo no vaya a producir problemas catastróficos o problemas de cualquier tipo.

Projects should be low stakes. Think about how much harm the code you are writing could cause if it has bugs or security vulnerabilities.

  • Atentos a la seguridad, cuidado con los secretos (contraseñas, identificadores, ..) y también a la privacidad.

  • Ser un buen ciudadano de la red. Que nuestras pruebas no vayan a provocar algún problema en los servidores de alguien

Be a good network citizen. Anything that makes requests out to other platforms could increase the load (and hence the cost) on those services.

  • Cuidado con el coste. No será la primera vez que alguien se pone a programar ocn una herramienta de estas, se lía y termina teniendo una factura importante que pagar correspondiente al uso de la herramienta.

I’ve seen horror stories about people who vibe coded a feature against some API without a billing limit and racked up thousands of dollars in charges.

Finalmente nos hace algunas recomendaciones.

Fundamentalmente, hacer las pruebas con cuidado, no nos vayamos a cargar nuestros datos, nuestro sistema o cualquier otra cosa a la que tengamos acceso. Habla de algunas herramientas, pero todavía no hay demasiado.

Safe vibe coding for complete beginners starts with a sandbox.

¡A jugar!

MCP y la interacción de las IAs con otros sistemas

Vagón 124. Puerta.

La IA lleva una temporada trayéndonos cada poco tiempo términos nuevos. Uno de ellos es el MCP (Model Context Protocol) y me gustó MCP (Model Context Protocol): Simply explained in 5 minutes porque cumple lo que promete, que es explicar este protocolo en un ratito.

La idea es integrar nuestros LLMs (las IAs de moda, los modelos de lenguaje gigantes) con herramientas externas.

Put simply, MCP is a way for LLMs to more easily integrate with external tools.

Esencialmente es, por lo tanto, un mecanismo que pueden seguir estas IAs para trabajar con sistemas (o aplicaciones) que proporcionan alguna forma para que estas IAs interactúen.

Esto nos ahorraría el esfuerzo de integrar cada uno de los mecanismos de interacción que puedan proporcionar estos sistemas (sus APIs).

So why was MCP introduced? It solves the problem of needing to manually integrate the different APIs you want to use.

Esto no quita, sin embargo, esfuerzo de configuración, porque para cada sitio será necesario establecer algunos parámetros. También será necesario configurar la IA para que interactúe con este intermediario.

Each MCP will have its own instructions, but in general, you just need your MCP client (Cursor in this case) to run the MCP server. Things get more complicated when you need additional integrations, API keys, or permissions.

En Model Context Protocol está la definición del protocolo y mucha más información.

Alucinanciones de las Inteligencias Artificiales y sus consecuencias en el desarrollo de código

¡Oh! ¡Qué bonito!

Tengo sentimientos enfrentados con el código generado por inteligencias artificiales. Por un lado, ando haciendo pruebas y me permite avanzar en cosas aburridas y que no haría por mi propia cuenta o me costaría esfuerzo abordarlas. Por otro lado, de vez en cuando me la lía y pierdo tiempo que podría estar dedicando a otras cosas.

En AI-generated code could be a disaster for the software supply chain. Here’s why. dan una visión pesimista, por losproblemas que pueden aparecer.

Nos habla de un estudio donde se observa como las IAs alucinan, y generan dependencias que no existen, por ejemplo. Eso no sería un problema salvo que alguien se de cuenta y las cree para nosotros: entonces nuestro código dependerá de algo que se ha creado a propósito para perjudicarnos.

These non-existent dependencies represent a threat to the software supply chain by exacerbating so-called dependency confusion attacks. These attacks work by causing a software package to access the wrong component dependency, for instance by publishing a malicious package and giving it the same name as the legitimate one but with a later version stamp. Software that depends on the package will, in some cases, choose the malicious version rather than the legitimate one because the former appears to be more recent.

Estas alucinaciones, como sabemos, se corresponden con propuestas incorrectas generadas como respuesta a determinadas peticiones por la propia naturaleza de los LLMS.

In AI, hallucinations occur when an LLM produces outputs that are factually incorrect, nonsensical, or completely unrelated to the task it was assigned.

Lo peor del caso es que en algunos casos esas alucinaciones se concentran en situaciones muy concretas, dando lugar a que sea relativamente sencillo concentrarse en estos casos y que todo sea más problemático.

In other words, many package hallucinations aren’t random one-off errors. Rather, specific names of non-existent packages are repeated over and over. Attackers could seize on the pattern by identifying nonexistent packages that are repeatedly hallucinated. The attackers would then publish malware using those names and wait for them to be accessed by large numbers of developers.

Actualización (2025-12-23) En LLMs can’t stop making up software dependencies and sabotaging everything otro enlace donde hablan del tema.