Introducción​

Voy a ser completamente honesto: este fin de semana no me senté a construir un agente de IA desde cero. No entrené un modelo, no inventé un protocolo nuevo y tampoco hice una demo con fuegos artificiales. Hice algo bastante menos glamuroso: abrí mi configuración de pi agent y empecé a preguntar por qué algunas cosas no funcionaban como yo creía.

Empecé a las 8 de la noche, con la idea de revisar un par de cosas y dormir temprano. Cada respuesta abría otra pregunta, cada arreglo destapaba un fallo que llevaba semanas ahí, y en algún punto dejé de mirar el reloj. Cuando por fin levanté la vista de la terminal ya eran las 7 de la mañana y había amanecido. Once horas seguidas para descubrir que mi harness funcionaba mucho menos de lo que yo daba por hecho.

El resultado fue más interesante de lo esperado. Descubrí extensiones que no estaban cargadas, reglas que se contradecían, herramientas que el modelo ignoraba, un overlay que impedía detectar los bloqueos de herdr y más de veinte mil tokens de contexto fijo antes de empezar a trabajar. En otras palabras: el arnés tenía piezas buenas, pero estaban tiradas en el piso como las herramientas de un cajón que nunca ordenaste.

Introducción​

Llega visita, te pide la WiFi, le pasas el QR de la red y listo. El problema aparece la segunda vez que viene: ese QR sigue funcionando. Y la tercera. Y dentro de seis meses, cuando ya ni te acuerdas de que se lo diste. La contraseña de una red WiFi es un secreto compartido de por vida: una vez que sale de tu casa, no vuelve.

Yo quería lo contrario. Quería que cada visita tuviera acceso mientras está aquí y que ese acceso se apague solo. Sin portal cautivo, sin hardware nuevo, sin ponerme a administrar clientes uno por uno. La idea terminó siendo simple de enunciar y bastante entretenida de implementar: rotar la contraseña de la red de invitados cada 24 horas, de forma automática, y tener el QR nuevo siempre a un toque en el celular.

Spoiler: el módem no tiene API. Este post es cómo le hice una.

Introducción​

Voy a ser completamente honesto: cada vez que abro un proyecto nuevo de React para hacer un simple panel interno, algo dentro de mí se apaga un poco. pnpm install, veinte minutos esperando, tres gestores de estado que no necesito, un build pipeline que hay que mantener, y todo para mostrar una tabla con botones de "eliminar". Si estás igual de jodido que yo con esto, quiero contarte de una combinación que me tiene bastante convencido: htmx + Pico CSS (y, si hace falta, un toque de Alpine.js).

No es una tecnología nueva ni mágica. Es, más bien, una negación deliberada de cómo se construye frontend hoy. Y para cierto tipo de proyecto —CRUDs, admin panels, herramientas internas, prototipos— me parece que es objetivamente mejor que meter un SPA completo.

Introducción​

Quizá suene un poco nostálgico, pero todavía recuerdo el primer programa que resolví solo, sin copiar nada, sin preguntarle a nadie. Era una tontería, un bucle que imprimía números pares, pero la sensación de haberlo armado con mi propia cabeza fue de las cosas que más me engancharon a programar. Ese subidón hace tiempo que no lo siento.

Lo que pasa después de un tiempo trabajando en esto es que el código deja de ser un juego. Se vuelve una herramienta, una obligación, algo que resuelves porque hay que entregarlo, no porque te divierte. Y programar solo, sin nadie del otro lado, sin nada en juego más que tu propio tiempo, termina sintiéndose distinto a cuando había alguien con quien compararte o competir.

Así que hice algo al respecto: cada semana publico un reto de programación en la Cueva. Nada del otro mundo, nada de estructuras de datos complicadas a las tres de la mañana. Problemas del tamaño justo para recuperar esa sensación de la primera vez, con la diferencia de que ahora hay un leaderboard real esperando del otro lado, así que ya no soy solo yo hablándole a mi propio editor de texto.

Introducción​

Seguramente ya te ha pasado. Corres un pnpm install, todo funciona bien, te vas a dormir tranquilo, y al día siguiente el build está roto sin que tú hayas tocado ni una sola línea de código. Vas a investigar y resulta que una dependencia se actualizó sola de la 2.4.1 a la 3.0.0 y decidió, sin avisarte con la debida cortesía, cambiar por completo su API.

Ahí es cuando uno se pregunta: ¿para qué existen los números de versión si de todos modos nos rompen el proyecto? Pues resulta que sí existe una respuesta, y es que ese numerito no se escribe al azar, tiene un nombre y unas reglas bien definidas que la mayoría ignoramos hasta que nos pega en la cara. Se llama Semantic Versioning, o como le decimos de cariño, SemVer.