Unificando Tecnologías: IA y Blockchain

bot de defi en acción
Caso de estudio

Construí un bot de DeFi en 5 días.
No escribí una sola línea de código.

Cómo usé IA para diseñar, auditar y desplegar un sistema autónomo de market-making en Avalanche — con circuit breakers, ejecución fraccionada y lógica de riesgo real.

5 días de desarrollo
0 líneas escritas manualmente
2 pools activos
iteraciones con IA

El punto de partida

Llevo años siguiendo DeFi. Entiendo la mecánica de los AMMs, los riesgos de impermanent loss, cómo funciona la liquidez concentrada. Pero no sé programar. Nunca aprendí. Y siempre sentí que eso me dejaba del otro lado del vidrio: podía ver el juego pero no jugarlo.

En marzo de 2026 decidí que eso ya no era una excusa válida. Tenía contexto técnico suficiente para saber qué preguntar. Y tenía un problema concreto: quería proveer liquidez en pools de Pharaoh en la red de Avalanche (un fork de Uniswap V3) de forma activa — no depositar y olvidar, sino rebalancear cuando el precio se mueve, regoger fees automáticamente para maximizar ganancias.

"No estaba construyendo un bot. Estaba construyendo un sistema autónomo de captura de valor — donde la velocidad, la selección de oportunidades y el control de riesgo definen el éxito."

La arquitectura

El sistema terminó siendo más sofisticado de lo que había planeado. Eso pasa cuando trabajas con un ingeniero que no duerme, analiza informaócin y tiene contexto mayor que cualquier humano. Aunque tiene límites y hasta te cobra por hora extra.

La lógica central se centra alrededor de dos pools simultáneos: P33/USDC y P33/AVAX. Cada uno corre su propio ciclo de evaluación cada 30 segundos, consultando el estado on-chain, calculando si la posición sigue dentro del rango, y decidiendo si actuar.

// Decisión central del motor — evaluatePool() if (outOfRangeSince > 60min) { return { action: 'REBALANCE_NOW' } } if (slippage >= SLIPPAGE_HARD_LIMIT) { return { action: 'RETRY_LATER' } } // Ejecuta solo si el costo justifica la acción

Lo que hace especial al sistema no es el rebalanceo en sí — es todo lo que rodea a esa decisión. Antes de ejecutar cualquier swap, el bot simula la transacción con callStatic, calcula el slippage estimado, y aborta si supera el 3%. No es un número arbitrario: es el hard limit que definí sabiendo que el fee tier del pool es 1%. Cualquier rebalanceo que me cueste más del triple del fee que voy a capturar, no vale la pena.

Lo que realmente me sorprendió: el rebalanceo fraccionado

Uno de los problemas clásicos de ser LP con liquidez concentrada es que cuando el precio sale del rango, tienes que hacer un swap para reequilibrar los tokens antes de volver a proveer liquidez. En un pool pequeño — el mío tiene alrededor de $10,000 USD de liquidez total — ese swap puede mover el precio contra ti.

La solución que implementé: ejecución fraccionada. En lugar de hacer el swap completo de golpe, el bot lo divide en tramos. Ejecuta un porcentaje, espera, evalúa si el precio se movió demasiado, y continúa o aborta. Si el precio se mueve más de un umbral definido desde el inicio del rebalanceo, rebalancea sólo una parte y cancela los tramos pendientes.

Es la misma lógica que usa un trader institucional para ejecutar órdenes grandes sin mover el mercado. Solo que aquí la implementa un bot autónomo en una blockchain pública, tomando decisiones cada 30 segundos.

El rol de la IA en el proceso

Sería fácil decir que "le pedí a la IA que escribiera el código". Pero la realidad es más interesante. Claude actuó como el ingeniero senior que no tenía: alguien que entiende los tradeoffs, detecta edge cases antes de que sean bugs en producción, y sabe cuándo rechazar una instrucción porque el contexto indica que haría más daño que bien.

El ejemplo más claro: durante la auditoría final, le pedí que aplicara un fix para unificar la lógica de rentabilidad entre los dos pools. Claude lo rechazó. No porque no pudiera implementarlo, sino porque después de analizar la configuración, calculó que el fix habría paralizado el pool en condiciones normales de mercado. Me explicó los números. Propuso una alternativa. Esperó mi decisión.

Eso no es un asistente de código. Es un colaborador técnico.

¿En qué etapa estamos?

Hoy el sistema corre en DRY_RUN: todas las decisiones se toman, todos los cálculos se ejecutan, todos los logs se generan — pero ninguna transacción se envía a la red. Es la fase de validación final antes de activar capital real.

Lo que observo en esta etapa: que los slippage estimados sean consistentes con mis supuestos, que el circuit breaker global no se dispare por errores de configuración, que el wallet mutex funcione correctamente cuando los dos pools quieren ejecutar al mismo tiempo. Son detalles que no se ven en el papel pero que pueden significar la diferencia entre un sistema robusto y uno que pierde dinero silenciosamente.

Lo que aprendí sobre construir con IA

El mayor error que cometen las personas cuando trabajan con IA en proyectos técnicos es tratarla como un motor de búsqueda glorificado. Le hacen preguntas, copian la respuesta, y siguen adelante. Eso produce sistemas mediocres.

Lo que funciona — lo que funcionó aquí — es tratar la conversación como una sesión de diseño con un ingeniero. Empezar con los principios, no con el código. Definir qué quieres optimizar. Nombrar los riesgos que no quieres asumir. Y cuando el sistema propone algo, preguntar: ¿por qué? ¿qué pasa si falla? ¿qué no estoy viendo?

Cinco días. Dos pools. Un sistema que toma decisiones on-chain con más disciplina que la mayoría de traders humanos. Sin escribir una sola línea.

Scroll al inicio