BilboStack 2026 – 12 años después

Hace 4 años de mi ultimo artículo sobre el BilboStack en 2022, y 12 años desde que descubrí el evento en 2014. En estos cuatro años han cambiado muchas cosas, y aunque he podido venir un par de veces más, no he tenido oportunidad para sentarme a escribir, y la sala de espera de un aeropuerto es un buen lugar como otro cualquiera para poner mis notas en orden.

El Bilbostack es un evento técnico, pero sobre todo es un evento de ideas, ideas revolucionarias, ideas obvias, e ideas que surgen con una sidra en la mano, un talo, o escuchando música en la ribera del nervión. El evento tiene dos tracks, así que esta es mi visión sesgada de uno de ellos, que era el que más resonaba con el trabajo que estoy haciendo en la actualidad.

Este año la presencia ominosa de la IA no ha impedido que habláramos de temas más clásicos como rendimiento en la web, pair programming, cultura de equipos de alto rendimiento cuando tenemos entregables acelerados, y organización de datos.

Rendimiento

Empezamos con rendimiento absoluto. Estela Franco nos contó sobre los indicadores que tenemos disponibles para medir la calidad de nuestra web, qué métricas coinciden con la latencia percibida por parte del usuario y por qué deberíamos conocer acrónimos como LCP, INP, o TTFB, este último «Time to First Byte» clave para medir cuando empieza la página a cargar en el navegador de nuestros usuarios.

Estas métricas las podemos mejorar con buenas prácticas que incluyen diferir carga de recursos, la siempre presente compresión en gzip, el atributo poster para vídeos y client side rendering (cuando podamos), entre otras.

Como herramientas recomendaba integrar LightHouse en nuestro entorno CI/CD, así como los informes de Google Chrome User Experience Report (CrUX) y el HTTP Archive. Finalmente recomendaba probar nuestras herramientas simulando condiciones de red y rendimiento de nuestros usuarios, que lo podemos conseguir con las herramientas de desarrollo de Google. Como deberes me quedo con revisar LightHouse para mi entorno, buscar qué dicen las métricas de las diferentes páginas que tenemos en el equipo, y qué mejoras podemos hacer para aumentar la percepción de velocidad por parte de los usuarios.

Cultura

De rendimiento de páginas pasamos a rendimiento de equipos, donde Jorge Barroso, un maestro en el arte de recordarte lo que a veces debería ser obvio pero no siempre lo es, comentaba su experiencia liderando equipos de alto rendimiento en las trincheras, con entregables en tiempos críticos.

De todas las ideas interesantes de su charla me quedo con tres que más me han resonado con mi trabajo actual:

• Al establecer un equipo, lo más importante no son las features, sino establecer las prácticas para entregar las features, mientras entregas las features. Es decir, lo importante para el negocio sigue siendo entregar las características pero definir desde el principio prácticas como CI/CD, logging estructurado, soluciones rápidas de back-office para delegar trabajo o mejorar automatización, hace que el equipo pueda construir sobre prácticas estables y ser más rápido a medio plazo. Eso coincide con parte del trabajo que hice a principios de año en el nuevo equipo, pero es un buen recordatorio que tengo que prestar más atención a procesos y prácticas.
• Entregar software de manera colectiva es más importante que cerrar nuestras tareas de manera individual. Para ello hablaba de la idea de «right to left», que en el contexto de kanban implica centrarnos en el trabajo que esté más cerca de producción, aunque no sea el que estamos trabajando nosotros, y priorizar las necesidades del equipo (y del entregable de manera holística) sobre nuestras tareas individuales, por mucho impacto que tengan.
• Evitar silos y pérdidas de contexto es clave para iterar rápido. Prácticas como establecer el equipo como tech, sin establecer distinciones de front-end y back-end, permite que una característica se pueda implementar completamente sin dependencias arbitrarias, o patrones como ADRs (Architectural Decision Record) ayudan a explicar los cambios y las decisiones, sobre todo el por qué. La clave de esto último era que podemos escribirlos después de implementar el código, lo cual puede significar «hacer trampa», pero el resultado es que elcontexto de la decisión se mantiene en el tiempo. Esta última es muy interesante y me gustaría pensar en cómo implementarla.

Pair Programming

Siguiendo con la línea de mejorar el rendimiento de los equipos, Leopoldo Romacho nos comentaba su experiencia estableciendo prácticas de Pair Programming en BestSecret. Reconozco que nunca he implementado pair programming «de manual», pero la charla ha contado algunas buenas prácticas que valen tanto si hacemos pairing como si no.

A lo largo de la charla, Leopoldo comentaba ideas como definir el espacio de colaboración, expectativas y roles cuando estamos revisando un problema, centrarnos en el problema que queremos resolver como manera de solucionar conflictos, usar pomodoros para evitar agotamiento entre sesiones, y terminar cada sesión con un commit. Esto último me ha hecho pensar que ha habido días que he tenido sesiones maratonianas, y no había hecho commit de los cambios, con lo cual el dia siguiente tenía que recordar en que lugar estaba.

Por otra parte la llegada de los LLMs hace que las dinámicas de pair programming cambien, y el foco se mueva al diseño y al análisis, dejando la implementación (o ciertos roles de driver) al agente. En ese aspecto recomendaba revisar el Context engineering workflow que recomienda Microsoft para Copilot, pero que se puede aplicar también para otras herramientas, y al que echaré un vistazo, ya que es prometedor, y va en la línea que he estado siguiendo últimamente para colaborar con LLMs.

Confianza

Finalmente, enlazando con las ideas de preservar el contexto, Issey Masuda nos recordaba que los LLMs siempre nos proporcionan información secundaria, y tras hacer un recorrido por las diferentes maneras en las que accedíamos a la información (desde la imprenta a las browser wars de los 2000), se centraba en la idea de modelar nuestra información separando entidades de relaciones, usando bases de datos como neo4j y frameworks como graphiti para externalizar el conocimiento fuera del LLM, así como mecanismos como estructurar la respuesta del LLM para aumentar este conocimiento.

Me quedo con la idea de extraer la idea de entidades y relaciones de todas las notas que tengo en obsidian, como manera de mejorar el grafo que tengo conectando las notas existentes.

En resumen

Además de las interesantes conversaciones de pasillo sobre cómo el trabajo cambia con la llegada de los LLMs (de lo que ya has visto que no puedo parar de hablar), en general los temas me han hecho pensar en tres convergencias; estructuras predecibles tanto para equipos como para documentación, foco en el proceso como parte del producto, y uso de la IA para expandir nuestras capacidades y nuestros conocimientos en vez de sustituirlos.

Un día muy largo pero con mucho que pensar y que contar. Y tú, ¿con qué ideas te quedaste?