A veces nos ponemos con una herramienta a realizar algún proyectito y cuando nos damos cuenta hemos invertido tantas horas que tal vez nos habría ido mejor utilizar alguna otra aproximación. Esto tiene que ver con las herramientas no code, de lo que va este artículo, pero podría aplicarse perfectamente a los auténticos monstruos que algunas personas construyen con las IAs y su vibe coding.

En Code is the new no-code nos provocan un poco con estas ideas.

La mayoría de la gente no sabe programar, así que tiene mucho sentido proporcionarles algún tipo de herramienta que les permita hacer sus programas sin saber.

A promised third option was that you could just drag-and-drop some blocks, connect a few nodes, and voilà — you’ve built a fully functional app without writing a single line of code!

Los problemas de esta aproximación son varios:

• Empezar es sencillo, pero cuando queremos ir más allá la cosa se complica.

You start with a simple workflow, add a few conditions, and suddenly you’re staring at a tangled spider web that even you, its creator, can’t understand.

• Llegaremos a un momento en que nos encontraremos con los detalles técnicos: las herramientas los esconden hasta que ya no es posible hacerlo más.

No-code tools hide complexity until they don’t. Then you’re stuck googling technical concepts you were promised you’d never need to learn.

• Terminamos descubriendo que lo que queremos sería posible con estructuras simples de programación.

Nearly every power user of no-code tools eventually hits the wall and thinks, “I wish I could just write a simple if statement here!”

Con la llegada de los modelos gigantes del lenguaje (Large Language Models, LLMs) todo se ha puesto más interesante: pueden generar código y (si les preguntamos) explicarlo.

AI got really, really good at writing and explaining code.

Ya no es necesario entender cada línea y lo que obtenemos puede ser más fácil de leer que esos grafos complejos que construimos con las herramientas no code, con la ventaja de que podemos ‘rellenar los huecos’ y probar simplemente escribiendo instrucciones.

Notice how readable this is compared to a visual flow with dozens of connected nodes. And if you want to add a condition? Just add an if statement.

Esto ha rebajado mucho la barrera de entrada y ya podemos hablar de programación dirigida por preguntas.

This brings us to this new phenomenon what’s commonly known as Vibe Coding or what refers to as Prompt-Driven Development as its more sophisticated cousin..

El proceso se convierte en

1. Describir lo que queremos
2. Comprender el código que se nos sugiere
3. Hacer pequeños ajustes y preguntas
4. Absorber conceptos de programación poco a poco.

Esta aproximación sería más sostenible, según el autor, porque nos moveremos todo el tiempo en un contexto más manejable, aprenderemos y no tendremos las restricciones que tiene una plataforma definida por otros.

You’re working with a medium (text) that scales infinitely better than visual nodes

You’re learning transferable skills that work across platforms and tools

You’re not constrained by what the no-code platform creators thought you might need

También nos habla de que el resultado que se obtiene de esta forma es más fácil de leer, autodocumentado, adaptable y trasnferible.

Yo no termino de estar de acuerdo porque creo que se dan dos fenómenos que afectan a toda esta ‘bondad’.

• Somos perezosos: este tipo de programación se presta a verificar que funciona y darlo por bueno
• La ignorancia es atrevida, lo que nos puede llevar a aceptar cosas sin ni siquiera ser conscientes de loque estamos haciendo.

No se me entienda mal, creo que lo que dice es una aproximación bastante buena y correcta, pero luego llegamos nosotros y tomamos los atajos.

Además las IAs no tienen ningún inconveniente en repetir cosas, añadir complejidad, …

Luego nos recomienda un proyecto, que no he probado pero que puede ser interesante.

No suelo hacer esto, de hecho creo que es la primera vez, pero voy a copiar un texto de mi otra bitácora porque el tema me parece importante y me preocupa. No sé si habrá mucha gente que lea las dos, supongo que no.

A pesar de estar completamente en contra, la verdad es que no estoy muy seguro del estado actual del tema, pero llevamos un par de semanas con bastante intensidad sobre Chat Control (lo cuentan, por ejemplo, en Cruce de cables: Chat Control, el enésimo intento de ponerle puertas al campo mientras coartan nuestros derechos con la disculpa de proteger a los menores.

Se trata de un mecanismo que la Unión Europea quiere hacer obligatorio en las plataformas de comunicación electrónicas que serviría para analizar todo lo que enviamos por ellas. y tiene la forma de reglamento de la Comunidad Europea.

Ha habido montones de reacciones y países que lo apoyan (entre ellos, lamentablemente, pero poco sorprentemente por el poco cariño que se le da a internet por aquí, España) y otros que están en contra.

Hay una web con información en Fight Chat Control.

No será ninguna sorpresa decir que aquí estamos en contra: a los menores hay que protegerlos, claro que sí, pero esta no es la forma.

A riesgo de repetirme (ya lo decíamos En el día mundial del cifrado con los Cibervoluntarios).

Este tipo de medidas:

• No garantiza la protección de nadie: leer todos los mensajes, buscar contenido dañino, verificarlo y realizar las acciones correspondientes excede claramente la capacidad de cualquiera que intente abordarlo.
• Dejar a la policía (o a quien sea) leer nuestros mensajes abre la puerta que puedan leerlos otras personas que no están intersedas en protegernos, dicho sea de paso. Ese es un riesgo que nadie debería estar dispuesto a asumir.

Veremos. Originalmente publicado en Contra Chat Control.

Suele hablarse con cierta ligereza de quién (todos) y cuándo (bien pronto) debería aprender a programar. Los que nos hemos enfrentado a gente que empezaba con ello descubrimos rápidamente que no es tan fácil. Es cierto que casi cualquiera debería poder dominar los conceptos básicos con rapidez, pero en la práctica hay personas a las que les cuesta mucho. Sobre el momento, creo que requiere un cierto nivel de madurez que no todo el mundo alcanza en el mismo momento. Luego está el siguiente nivel, que es programar bien, algo que ya no está al alcance de todo el mundo, o eso parece.

En 10 Signs You Will Suck at Programming hablan de algunas señales que nos podrían indicar que tal vez no vaya a ser lo nuestro. Parece que el autor está de acuerdo con lo que decíamos arriba:

As an Educator that teaches Full-Stack Web Development, I have taught many “first time programmers”. And the good news is that I have rarely found a student that couldn’t learn to program. I see it as a basic human skill, just like reading, writing, and arithmetic. Anyone can do it, it is part of our human capacities, but does need to be learned.

Esos indicios de dificultades a la hora de programa serían, según Jonathan Bluks:

• Falta de curiosidad
• Falta de autonomía e ingenio.
• Falta de persinstencia cuando nos encontramos un problema.
• No tener sentimiento de éxito cuando superamos un problema.
• Impaciencia en el aprendizaje y la comprensión.
• Aburrirse o cansarse pensando.
• Incapacidad de pensar por sí mismo.
• Pensamiento rígido, cerrado o desorganizado.
• Necesidad de tener la respuesta correcta, en lugar de reconocer un rango de buenas y malas respuestas.
• No prestar atención cuidadosa a los detalles.

Según el autor:

1	Lack of curiosity
2	Lack of autonomy and resourcefulness
3	Lack of persistence in the face of a problem
4	No feeling of success in overcoming a problem
5	Impatient about learning and understanding
6	Getting bored/tired from thinking
7	Inability to think for yourself
8	Rigid, narrow and/or disorganized thinking
9	Needing the “right” answer instead of recognizing a spectrum of “good” and “bad” answers
10	Not paying careful attention to details

Como conclusión, nos dice, programar puede ser difícil pero casi todo el mundo puede hacerlo.

While programming can be a difficult skill to learn, it is certainly one that most people can learn.

Me gusta hacer el ejercicio con personas más o menos técnicas de preguntar quén ha examinado alguna vez un certificado de una página web (el famoso candadito); suele resultar que casi nadie lo ha mirado y entonces aprovecho para mirar la información que aparece y lo confusa que es. Incluso, como digo, para personas de perfil más o menos técnico. Lo malo es que entre los consejos de seguridad habituales suele estar el de examinarlos. Y lo peor es que quién más quién menos se ha encontrado con una página legítima (¿en la red interna de su empresa? ¿en alguna organización poco cuidadosa con esos temas?) en la que ha necesitado darle al botón de ‘me fío, sigue adelante’ para poder llevar a cabo su cometido.

No tiene mucho que ver (o sí) pero lo cierto es que los certificados son unos grandes maltratados.

Los certificados suelen tener la posibilidad de ser revocados (esto es, decir que ya no valen) pero, adivinen: todavía menos gente mira esa información. Hace unos meses la gente de Let’s Encrypt anunciaba el Ending OCSP Support in 2025 que supondría el fin del uso del protocolo OCSP (Online Certificate Status Protocol). en The Slow Death of OCSP comentaban con cierto detalle el tema y por eso lo traemos aquí.

Este protocolo pretende proporcionar apoyo a la revocación en tiempo real de los certificados y su verificación.

As the name suggests, OCSP is intended to support real-time certificate revocation checking.

El problema es que no se ha utilizado mucho al principio, y cuando se empezó a usar más había problemas de rendimiento.

Because browsers were not implementing OCSP, CAs got used to receiving no traffic to their OCSP servers and didn’t spend a lot of time supporting that infrastructure. By the time the usage eventually grew, OCSP performance problems were common and frequent.

Había más problemas, que el autor detalla.

La alternativa son las listas de revocación de certificados, CLR (Certificate Revocation Lists), que permitirían a los emisores de estos elementos publicar su lista, que se pueden descargar de forma periodica y usarse para la verificación.

From the very beginning, we had Certificate Revocation Lists, or CRLs. The idea behind these lists was simple: every certificate issuer would also track and continuously publish a complete list of all revoked certificates. Certificate consumers would periodically download the CRLs from the CAs they cared about and verify that the certificates they were using were still valid.

Esto ha cambiado un poco porque ahora son los responsables (y otros agentes) de los navegadores los que gestionan estas listas.

Instead of user agents consuming the CRLs directly, major browser vendors (and, presumably, operating systems) maintain their proprietary revocation checking built on continuous processing of all known CRLs.

Termina diciendo que probablemente la mejor solución es que los certificados tengan vidas relativamente cortas (unos días), y así no hay que preocuparse de revocarlos.

At the end of the day, with short-lived certificates, we—finally—have a plausible revocation checking story, even if it doesn’t actually involve any revocation.

Curioso como los pilares de nuestra seguridad tienen a veces tantas dificultades para alcanzar situaciones razonables.

Volvemos al tema de las defensas poco ortodoxas. En Hacker infects 18,000 “script kiddies” with fake malware builder nos contaban el caso de alguien que se dedicó a infectar a atacantes poco hábiles.

Los script kiddies son dentro del mundo de la seguridad informática poco apreciados: normalmente consiguen herramientas que han realizado otros y las utilizan contra sus objetivos.

En este caso, alguien se dedicó a atacarles con un constructor de ataques falso, que lo que en realidad hacía era infectarles a ellos.

A threat actor targeted low-skilled hackers, known as “script kiddies,” with a fake malware builder that secretly infected them with a backdoor to steal data and take over computers.

Hasta para hacer maldades hay que saber un poco. Y tener cuidado.

Curioso.