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:

De eso que te encuentras un código viejo y le das un remate. aunque no me convence la visualización. pic.twitter.com/1BoLAuShy2

— fernand0 (@fernand0) December 28, 2023

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,

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

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!

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.

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.

De eso que te encuentras un código viejo y le das un remate. aunque no me convence la visualización. pic.twitter.com/1BoLAuShy2

— fernand0 (@fernand0) December 28, 2023

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.

El mundo ha cambiado mucho: cuando antes bastaba con un identificador y una contraseña, ahora utilizamos sistemas algo más sofisticados. En Identity Tokens Explained: Best Practices for Better Access Control hablan de los objetos de identificación identity tokens, como base para los mecanismos modernos de autentificación.

Identity tokens—particularly JSON Web Tokens (JWTs) and OpenID Connect tokens—can be considered the backbone of modern application security, as they enable most of the authentication solutions we’ve come to rely on.

La clave está en que, normalmente, una cosa es la gestión de la identidad y la autorización de lo que pueden hacer las aplicaciones.

This article will walk through what identity tokens are, the types of tokens you might encounter, and why you need to decouple authentication from authorization.

Todo ello desde el punto de vista de una solución concreta, que tampoco es muy relevante para lo que podemos aprender allí.

Estos objetos (valores, variables, …) permiten representar alguna forma de identidad dentro de entorno de alguna solución informática. Se trata de alguna información generada por un proveedor de identidad o un servicio de autentificación que la aplicación o servicio pueden validar y utilizar.

First off, when I say “identity tokens,” I’m referring to tokens intended to represent some form of identity—either a human user or a machine identity—within your software ecosystem. They’re basically a packet of information generated by an identity provider or authentication service, which your application or service can then validate.

Estamos hablando de protocolos comop OpenID Connector u OAuth 2.0 que generan típicamente cadenas de caracteres (strings) que codifican algunos detalles de identidad.

A common approach is to rely on a protocol such as OpenID Connect or OAuth 2.0 to manage these tokens. In these cases, the tokens can be short strings that encode vital identity details.

Esto nos permite delegar la confianza, sin manejar las credenciales del usuario directamente, lo que reduce la visibilidad y exposición de estas credenciales.

An interesting thing about identity tokens is how they let you delegate trust. When a user logs in through an identity provider, you don’t need to handle that user’s credentials directly. You can simply trust the identity token the provider generates, assuming you validate its signature.

Sin embargo, podemos tener la tentación de incluir en los objetos demasiada información, con lo que perdermos las ventajas de esta aproximación.

However, they’re far from all-encompassing, and if you try to cram every piece of user-related information into one token, you’re gonna have a bad time.

Luego detalla algunas características de algunos tipos de objetos de este tipo, como pueden ser los JSON Web Tokens (JWTs), OpenID Connect Tokens, Opaque Tokens, o diferentes Machine Identity Tokens / API Keys.

Las ventajas, además de la compartimentalización señalada arriba, tienen que ver con la simplificación a través de la centralización en la gestión de la autentificación, mientras se permite a las aplicaciones realizar su cometido.

That identity provider issues a token, and suddenly all your services know how to trust that user or machine without juggling credentials.

Se añaden otras ventajas como la escalabilidad, su estandarización, mecanismos de identificación única single sign-on, gestión del ciclo de vida/revocación, gestión consistente de las identidades….

Alguonos errores comunes tienen que ver con pedirles demasiado: por ejemplo, incluir ámbitos, conjutos de permisos, o información de estado más o menos complicada.

If you put entire permission sets or complicated state data into a token, you’re forcing a re-issuance of the token every time something changes. That’s not realistic for a dynamic environment, and it’s definitely not secure.

Esto puede ser hasta difícil, por las limitaciones de tamaño.

Tokens have practical limits on size. Some identity providers or networks even place limits on header sizes.

Otro problema puede tener que ver con la duración, que puede ser demasiado corta (y por lo tanto una molestia, o una sobrecarga para el proveedor de identidad) o demasiado larga (con los consiguientes riesgos de que ya no corresponda a lo que necesita el usuario, si es que todavía lo es).

A short-lived token might mean you’re validating everything on every request, hitting the identity provider too often, causing friction and performance bottlenecks. A long-lived token might stick around so long that you have no quick way to invalidate it if the user’s status changes. So you’re either locked into major performance overhead, or you risk giving out indefinite access.A short-lived token might mean you’re validating everything on every request, hitting the identity provider too often, causing friction and performance bottlenecks. A long-lived token might stick around so long that you have no quick way to invalidate it if the user’s status changes. So you’re either locked into major performance overhead, or you risk giving out indefinite access.

Otro problema puede tener que ver con la gestión de las sesiones interactivas (para los humanos) y las sesiones para los servicios (para las máquinas). Si las manejamos de forma diferente tendremos problemas de complejidad, confusión y divergencia en la gestión de las políticas de seguridad.

Sometimes teams think machine identities (service-to-service tokens) deserve a completely different approach than human tokens. While there can be some differences, if you diverge too far, you’ll cause confusion, complexity, and potentially misaligned security policies.

Por lo tanto, nuestros objetivos será:

• Desacoplar la autentificación de la autorización.

Decouple Authentication and Authorization

• Mantener los objetos sencillos

Keep Tokens Lean

• Utilizar protocolos estándar.

Use Standard Protocols

• Mantener un balance adecuado en la duración.

Balance Token Lifespan

• Disponer de mecanismos de revocación.

Plan for Token Revocation

También debemos tener en cuenta los aspectos de aseguramiento de los identificadores: utilizar HTTPs para que no pueda verlos nadie, tener cuidado al almacenarlos (cuidado con el registro de actividad, log), verificarlos, cambiarlos de vez en cuando por si alguien consiguiera robarlos, …

Además hay algunos casos de uso (identificación unificada, aplicaciones móviles, comunicaciones entre servicios, microservicios en la nube, …) y termina con algunas preguntas frecuentes.

Me ha gustado.

No solemos hablar aquí de guerras ni armamento, pero el caso es que muchos fallos de seguridad pueden convertirse con cierta facilidad en armas y entonces se habla de una herramienta más dentro del ciber-armamento.

En Ukraine’s Trojan Horse Drones: A New Frontier in Cyber Warfare habla de los drones y cómo en Ukrania los utilizan para atacar a sus enemigos rusos, incorporándoles diversos programas maliciosos, con objetivos diversos.

• Sabotaje: si en uno de estos aparatos incluye un ataque sencillo que estropee la conexión USB puede causar algunas molestias a quien intente analizarlos.

Hardware Sabotage: Basic malware triggers upon connection to enemy systems, physically burning out USB ports or damaging internal components to prevent data extraction or repurposing.

• Bloqueo de sistemas: si los programas son algo más avanzados pueden bloquear las actualizaciones, deshabilitar ciertos componentes, dejando el aparato inutilizable.

System Lockout: Intermediate versions target onboard chips, blocking firmware updates and disabling critical components, effectively rendering the drone unusable.

• Espionaje: si el aparato entra en territorio enemigo y es transportado a instalaciones militares, puede atacar a los sistemas que utilizan contra ellos o mostrar la localización de estos lugares.

Covert Cyber Espionage: Advanced malware remains undetected until reaching enemy territory, where it hijacks control systems to redirect drones or geolocates Russian operators attempting to reuse them.

Al final, estamos hablando de una guerra convencional, pero que tiene una componente importante de innovación informática. Esto tiene muchas consecuencias en cuanto al balance de fuerzas, pero también a la forma en que los contendientes tienen que trabajar.

Ukraine’s strategy exemplifies how cyber capabilities are reshaping warfare, forcing adversaries to balance innovation with security.

No es una casualidad que un experto en ciberseguridad como Mikko Hyppönen decidiera hace unos meses pasarse al mundo de los drones (Ukraine war spurred infosec vet Mikko Hyppönen to pivot to drones.