Estoy preparando contenido increíble sobre desarrollo, tecnología y programación. ¡Vuelve pronto!

Lo que pienso en voz alta sobre software, IA y desarrollo

Blog

Web corporativa de Kumux desarrollada con Gatsby y JavaScript.

E-commerce B2B para un distribuidor de productos de seguridad industrial, desarrollado con PHP y PrestaShop.

App interna para diseñadores de iluminación, desarrollada en React puro.

E-commerce para una marca de cajas de suscripción enfocada en el sector camping y outdoor.

Experiencia

Trabajo en plugin workflows y SDKs de plataforma para una empresa global de comercio de viajes. Foco en tooling para desarrolladores, integraciones de API y rendimiento frontend para productos usados por aerolíneas, hoteles y agencias de viaje en todo el mundo.

Plataforma de telemedicina con diagnósticos asistidos por IA para el sistema de salud chileno. Desarrollada con React, Gatsby y Strapi.

Portfolio personal anterior y web de servicios profesionales desarrollada con Next.js y TypeScript.

Plataforma SaaS para restaurantes: menú QR, pedidos en mesa y pago integrado. Un proyecto freelance del que aprendí mucho sobre producto y clientes.

Actualmente en Travelport. Antes lanzando MVPs para startups de cero.

Ingeniero de software obsesionado con automatización, tooling y sistemas que escalan solos.

Tutoriales y experiencias

Hablemos de proyectos

Conectemos

Último post

Ahora

Tecnologías que uso en mi día a día

Hola, soy un desarrollador Full-Stack especializado en desarrollo Frontend con conocimientos en Marketing Digital.

Actualmente trabajo para TravelPort. Me gusta crear nuevos productos y ayudar a la gente a desarrollar sus ideas. Y cuando no estoy conectado, me gusta hacer deporte.

🐣 Nacimiento

Me regalan mi primera videoconsola. Una Sega Mega Drive!

🎮 Primera videoconsola

Me regalan mi primera Gameboy y con ello cada vez me aficiono más a la tecnología.

🎮 Gameboy

Tengo mi primer ordenador: Un Pentium 4 con 256MB de RAM + 📞 Internet. Pero solo a partir de las 6 de la tarde y dejando incomunicados a mis padres sin teléfono.

⌨️ Primer ordenador

Llega DSL y con ello el WoW, el counter strike y el LAG :(

🌐 DSL Internet

🏫 ESO Terminada

Termino ESI, "Explotació de Sistemes Informàtics".

🏫 ESI Terminada

Trabajo en Zimbra en Italia como Erasmus. Empiezo a trabajar en Punt Informatic.

🇮🇹 Erasmus & Primer trabajo

Empiezo en Grafix Gestió Informàtica y hago cursos de Android y Java.

💼 Grafix & 📚 Cursos

Termino el CFGS de DAI (Desarrollo de Aplicaciones Informáticas) en el IES Carles Vallbona, Granollers.

🎓 DAI Terminado

Empiezo a ser "Runner" y llegan a la empresa dos grandes compañeros: <a href="https://www.linkedin.com/in/mart%C3%AD-duran-69257374/" target="_blank" rel="noopener noreferrer" style="color: #4A90E2; text-decoration: underline;">Marti Duran</a> y <a href="https://www.linkedin.com/in/marcgirbau/" target="_blank" rel="noopener noreferrer" style="color: #4A90E2; text-decoration: underline;">Marc Girbau</a>.

🏃 Running + Compañeros

🐶 La Menta

🏃 Primera carrera 15k

Empiezo con el CrossFit y a invertir en criptomonedas ₿.

🏋️ CrossFit & Crypto

Hago una media maratón de montaña y una 10k. Viajo a Albania 🇦🇱 donde me cambia la perspectiva de como va el mundo.

🏃 Media maratón & ✈️ Albania

Primera competición y lesión en crossfit. Creación de la marca Gametravel en la incubadora de la universidad de Mataró.

🏋️ CrossFit & 🚀 Gametravel

Acabo un curso por la UOC impartido por <a href="https://www.linkedin.com/in/oriolrius/" target="_blank" rel="noopener noreferrer" style="color: #4A90E2; text-decoration: underline;">Oriol Rius</a> sobre IOT. Entro en Kumux como Frontend Developer — construyo visualizaciones React para datos colorimétricos y lanzo la web corporativa con Gatsby.js. COVID-19 nos tiene en cuarentena. 🏠 #QuédateEnCasa.

🎓 IOT & 🚀 Kumux & 🦠 COVID

Dejo Kumux y me hago freelance bajo la marca freak.wtf. Lidero desarrollo de MVPs de startups de principio a fin y creo Pideme.es — un sistema de pedidos por QR para que los clientes de restaurantes puedan pedir y pagar desde la mesa. Stack: React, Next.js, TailwindCSS, Node.js, Strapi.

💼 Freelance & 🚀 Pideme.es

Entro en Travelport como Software Development Engineer. Empiezo en el equipo SDK & Plugin Framework construyendo SDKs para APIs de reservas (vuelos, trenes, hoteles) y pipelines de CI para plugins de partners. Conozco gente genial y crezco mucho.

✈️ Travelport & 👥 Nuevos amigos

Al fin cumplí mi sueño de ver auroras boreales. Un viaje increíble a Islandia que quedará grabado para siempre en mi memoria. ✨ Aurora Borealis magic!

🏔️ Vacaciones en Islandia

Nos mudamos más cerca de la ciudad. Un cambio importante que nos acerca a nuevas oportunidades y experiencias urbanas.

🏠 Más cerca de la ciudad

Llega la Pam, un caniche mini toy que nos tiene enamorados. Por fin me compro un ordenador nuevo pensado para trabajar en IA - llevaba casi 20 años usando mi antiguo ordenador, ya tenía muchas ganas de retirarse.

🐩 Llega Pam & 💻 Nuevo ordenador IA

Un viaje a través de los momentos más importantes de mi vida, desde mis primeros pasos en la tecnología hasta donde estoy hoy.

Mi Timeline

Landing para recaudar fondos para niños hospitalizados

Plataforma SaaS para restaurantes: menú QR, pedidos en mesa y pago integrado.

E-commerce B2B para distribución de productos de seguridad industrial

WebApp para diseñar y configurar productos de iluminación

Tienda e-commerce creada para aprender Next.js, desplegada en Vercel

App React Native con precios en tiempo real de criptomonedas desde API pública

E-commerce para una marca de cajas de suscripción para el sector camping

Plataforma de telemedicina con diagnósticos asistidos por IA.

Portfolio web y servicios profesionales como desarrollador

Script JavaScript + Selenium para reservar automáticamente clases de CrossFit cuando hay hueco

App del tiempo con React, Redux y Jest para practicar gestión de estado moderna

Proyectos de aprendizaje

E-commerce B2B para un distribuidor de productos de seguridad industrial. Desarrollado con PHP y PrestaShop, con gestión de catálogo personalizado, precios por volumen y portal para pedidos recurrentes.

Plataforma web interna para diseñadores de iluminación de Kumux, desarrollada en React puro. Permite crear, configurar y visualizar productos de iluminación personalizados en tiempo real antes de la producción.

Tienda e-commerce completa desarrollada como proyecto práctico para aprender Next.js. Incluye listado de productos, carrito de la compra y flujo de pago. Desplegada en Vercel.

App móvil desarrollada con React Native que muestra precios y datos de mercado de criptomonedas en tiempo real, consumiendo una API pública. Proyecto práctico para explorar el desarrollo mobile multiplataforma.

Plataforma de telemedicina para el sistema sanitario chileno que aplica inteligencia artificial para asistir a los médicos en el diagnóstico temprano. Desarrollada con React, Gatsby y Strapi como CMS headless.

Web corporativa para Kumux, empresa de innovación en iluminación con sede en Barcelona. Desarrollada con Gatsby y JavaScript, con foco en rendimiento y narrativa visual para comunicar los valores de la marca.

Plataforma e-commerce para una marca de cajas de suscripción orientada al sector camping y actividades al aire libre. Desarrollada con PHP y PrestaShop, con lógica de suscripción personalizada y catálogo por temporada.

Plataforma de telemedicina con diagnósticos asistidos por IA. Los médicos pueden revisar datos de pacientes, ejecutar análisis con IA y emitir consultas remotas. Desarrollada con React, Gatsby y un backend Strapi.

Web de portfolio y servicios profesionales desarrollada con Next.js y TypeScript. Muestra mi experiencia, proyectos y habilidades técnicas. Optimizada para rendimiento, accesibilidad y SEO.

Plataforma SaaS que permite a los clientes de restaurantes escanear un QR, ver la carta, realizar pedidos y pagar directamente desde la mesa, sin descargar ninguna app. Desarrollada con PHP y Laravel, integrada con pantallas de cocina.

Script de automatización escrito en JavaScript con Selenium que monitoriza los huecos disponibles en mi gimnasio de CrossFit y reserva automáticamente una plaza cuando hay una libre — sin perder más clases.

Software Development Engineer en Travelport desde 2022. Trabajo en plugin workflows dentro de una plataforma global de comercio de viajes con presencia en más de 165 países, con foco en el frontend del formulario de búsqueda.

Aplicación del tiempo creada para practicar React con Redux en la gestión del estado, Jest para tests unitarios y el hook useEffect para llamadas asíncronas a una API pública del tiempo.

Landing page de captación de donaciones creada para un evento solidario en favor de niños hospitalizados. Desarrollada con HTML, CSS y Tailwind CSS, con foco en impacto emocional y conversión.

Landing solidaria para niños hospitalizados


Hace unos meses mi equipo publicó un cambio que funcionaba perfectamente. Todo iba bien hasta que otro equipo publicó algo por su lado y apareció un bug — nada obvio, del tipo que tarda en manifestarse y no apunta a su origen.

Cuando llegué a investigarlo, delegué a la IA. Me dio cuatro soluciones. Todas coherentes. Todas técnicamente válidas. Ninguna cuadraba del todo.

Nos reunimos con el otro equipo a hacer pair programming. En veinte minutos encontramos la solución real — una que la IA nunca propuso, porque requería entender una decisión de diseño que ninguno de los dos equipos había documentado por separado.

Esa experiencia me dejó pensando en algo que llevo meses viendo con más claridad: la IA multiplica la productividad, pero también puede hacer que pierdas el control sobre lo que estás construyendo. No creo que el problema sea la IA. Creo que el problema es cómo y cuándo decidimos delegar en ella.

> La IA siempre tiende hacia la opción más obvia. Técnicamente válida, pero no siempre correcta para tu contexto.

La diferencia entre lo que esperamos y lo que pasa:

![Expectativa: la IA entenderá todo el contexto del sistema. Realidad: la IA no sabe lo que se decidió en una reunión de 2019](/images/contents/ia-expectativa-vs-realidad.png)

## Cuando la IA funciona increíblemente bien

Hay tareas donde la mejora es absurda: boilerplate, refactors, tests, documentación, debugging inicial, exploración rápida de soluciones.

**La IA amplifica cuando...**
- Entiendes bien el sistema
- El problema está documentado
- Puedes evaluar el resultado

**La IA falla cuando...**
- El contexto es cross-team
- La decisión no está escrita
- El "válido" parece suficiente

## El verdadero riesgo no es que la IA falle

El riesgo real es más incómodo: confiar en soluciones que no entendemos del todo. La IA produce respuestas coherentes y técnicamente válidas, y ahora puedes producir cambios enormes en minutos. Pero modificas rápido sin entender de verdad, y eso genera una falsa sensación de comprensión.

> "Válido" no siempre significa "correcto para tu contexto". Y cuanto menos entiendes el sistema, más dependes del criterio de la IA para saberlo.

Yo, mergeando PR a las 11pm:

![This is fine: yo aceptando cambios generados por la IA mientras producción arde](/images/contents/ia-this-is-fine.png)

## Lo que la IA no ve

La IA puede leer código, pero no entiende por qué ciertas decisiones existen, qué deuda técnica no puede tocarse, ni lo que sabe el equipo de al lado que nunca se documentó.

Ese conocimiento vive en personas, conversaciones e incidentes pasados. En sistemas complejos, la mejor decisión no suele ser la más elegante: es la que encaja con todo lo que no está escrito.

## El nuevo valor no es escribir más rápido

> Es entender mejor.

La IA automatiza, acelera y propone. Pero el criterio es humano: decidir qué construir, qué no tocar, qué riesgos asumir.

Cuando el contexto es difuso, aceptas respuestas demasiado rápido. Delegas decisiones sin darte cuenta.

El coste de producir software baja. El coste de entender el problema, no. Y ese contexto sigue estando principalmente en las personas. A veces, en la intersección entre dos equipos en una reunión de veinte minutos.

---

*Por cierto: este post está hecho con IA. La ironía no se me escapa.*


IA y productividad: el precio oculto de delegar el control


# Construyendo una Red de Seguridad alrededor de la Automatización DeFi

En los últimos meses he estado construyendo una capa de seguridad alrededor de la automatización en DeFi.

No farmea, no persigue yields, no intenta ser “smart money”. Su trabajo es mucho más aburrido: **vigilar cosas, conectar algunos puntos y decir “es lo bastante seguro para actuar” o “mejor párate”**.

Este post es una pequeña introducción a lo que estoy construyendo y, sobre todo, a cómo lo estoy pensando. No voy a enseñarlo todo; eso es intencional.

## Qué problema intento resolver

Si llevas un tiempo cerca de la automatización en DeFi, probablemente has visto al menos uno de estos patrones:

- Scripts que siguen corriendo felices mucho después de que las suposiciones originales hayan muerto.
- “Health checks” que solo verifican que el proceso está arriba, no que sea seguro.
- Bots que intentan hacer rebalance o harvest en entornos claramente hostiles: sin gas, con precios malos, con RPC rotos.

Lo que quiero de esta capa de seguridad es sencillo:

> Antes de tocar fondos on-chain, responde una pregunta:  
> **«¿Es realmente responsable actuar ahora mismo?»**

A veces la respuesta debería ser “sí, adelante”.  
A veces la respuesta debería ser “no, y aquí está el motivo”.  
Y a veces la respuesta debería ser “no tengo ni idea, así que te voy a bloquear”.

Ese último caso es el que más me preocupa.

## Un poco de cómo funciona (sin contarlo todo)

Muy a alto nivel:

- Vigila distintos tipos de señales:  
  balances, disponibilidad de gas, salud de estrategias, condiciones de salida…
- Las combina en **decisiones explícitas**:
  - “actúa ahora”,
  - “espera y vuelve a mirar luego”,
  - “me niego a actuar en estas condiciones”.
- Intenta que los **motivos** sean visibles:
  - no solo “failed”, sino “skipped porque no hay suficiente gas runway”,
  - no solo “error”, sino “el RPC está ciego, trato esto como inseguro”.

Por debajo no es más que TypeScript, unos cuantos servicios y más tests de los que me gustaría admitir. Lo interesante no es el framework, son las preguntas que obligo al código a contestar.

Hay partes que no voy a describir en detalle:

- umbrales concretos y combinaciones de señales,
- internals operativos,
- parte del cableado de producción.

Piensa en esta serie como **notas de campo**, no como una especificación completa.

## En qué se va a centrar esta serie

No quiero convertir esto en un changelog de features. Prefiero escribir sobre las decisiones que hay detrás, por ejemplo:

- Cuándo debería un sistema automatizado **negarse** a actuar, incluso si técnicamente puede.
- Cómo decides qué significa “suficiente runway” antes de que empiece a ser irresponsable.
- Dónde cambias conscientemente comodidad del desarrollador por seguridad del usuario.
- Cómo codificas esas ideas para que tu yo del futuro no pueda ignorarlas en silencio.

Cada post probablemente se centrará en una pieza pequeña del sistema:

- un servicio,
- un patrón,
- un check o umbral concreto,

y lo usará como excusa para hablar de **buen vs mal código, y buenas vs malas decisiones**.

Verás fragmentos reales del código, pero siempre con un pequeño desenfoque donde no quiero entrar en detalles operativos.

## Qué estoy dispuesto a enseñar (y qué no)

Estoy dispuesto a enseñar:

- cómo diseño health checks que hacen algo más que “¿el proceso está arriba?”,
- cómo pienso en fallar *cerrado* vs fallar *abierto*,
- cómo me obligo a ser honesto con tests y contratos explícitos.

No voy a enseñar:

- todo lo que se puede configurar ni cómo,
- todas y cada una de las señales y umbrales,
- nada que realmente filtre postura operativa.

Si alguna vez algo de código parece un poco redactado o simplificado, asume que es a propósito.

## Qué viene después

En el siguiente post voy a entrar en una pieza que suena trivial y no lo es:

> cómo decido si hay “suficiente gas” como para dejar que el sistema actúe.

Sobre el papel parece “solo mira el balance”.  
En la práctica se convierte en una conversación sobre **runway, fallos de RPC y cuándo ir a ciegas debería significar un stop duro**.
