DEV Community: Christian Gonzales Komiya

[Spanish] La IA no reemplaza las metodologías ágiles: cambia la forma en que las integramos para transformar los negocios

Christian Gonzales Komiya — Mon, 02 Nov 2026 23:44:56 +0000

Con la llegada de la inteligencia artificial, es natural preguntarnos si metodologías como Design Thinking, Lean Startup, Agile y Change Management necesitan reinventarse.

Mi impresión es que sus fundamentos siguen vigentes, pero su aplicación está evolucionando.

No creo que necesitemos un nuevo Design Thinking o un nuevo Agile. Sin embargo, sí debemos revisar cómo aprovechamos estas metodologías en un entorno donde la IA está cambiando la velocidad, el costo y las posibilidades de hacer las cosas.

Ejemplos de evolución metodológica

1. Design Thinking: descubrir problemas sigue siendo fundamental

La IA permite analizar entrevistas, encuestas y comentarios de clientes con mayor rapidez. También facilita generar ideas y construir prototipos.

Lo que no cambia: Necesitamos comprender a las personas y validar que estamos resolviendo problemas reales.
El cuidado: La IA puede ayudarnos a interpretar información, pero no debemos confundir sus respuestas con evidencia de los usuarios.

2. Lean Startup: experimentar nunca había sido tan accesible

Crear un MVP, probar una hipótesis o explorar diferentes alternativas puede ser mucho más rápido y económico gracias a la IA.

Ciclo Build-Measure-Learn: Sigue teniendo sentido. Lo que cambia es nuestra capacidad para recorrerlo más veces, con menor inversión y aprendiendo más rápido.
La regla de oro: Construir un prototipo en minutos no significa validar un negocio en minutos. La evidencia sigue siendo indispensable.

3. Agile: los principios se mantienen, pero la ejecución cambia

La entrega incremental, la colaboración, el feedback y la adaptación siguen siendo relevantes.

La IA puede acelerar la programación, las pruebas, la documentación y otras actividades del desarrollo de software. Esto obliga a repensar algunas prácticas de los equipos, pero no elimina la necesidad de inspeccionar, adaptar y garantizar la calidad.

El reto: No es solamente desarrollar más rápido, sino asegurarnos de que estamos construyendo algo correcto, seguro y valioso.

4. Change Management: la transformación va más allá de adoptar una nueva herramienta

La IA no solo introduce nuevas tecnologías. También puede modificar procesos, responsabilidades, competencias y formas de trabajar.

Por eso, la gestión del cambio adquiere una dimensión adicional: ayudar a las personas y organizaciones a trabajar de una manera diferente, en colaboración con sistemas y agentes de IA.

El verdadero cambio es transversal

Quizás el cambio más importante no está dentro de cada metodología, sino en la manera en que las integramos. Podemos pasar de un enfoque tradicional a uno orientado a resultados de negocio.

Enfoque Tradicional	Nuevo Enfoque con IA
¿Qué sistema necesitamos desarrollar?	¿Qué resultado de negocio queremos mejorar y qué nos impide conseguirlo?

A partir de ahí, combinamos diferentes capacidades potenciadas de forma transversal por la IA:

Design Thinking: Comprender a las personas y descubrir oportunidades.
Lean Startup: Formular hipótesis y experimentar.
Agile: Desarrollar y evolucionar soluciones.
Change Management: Transformar procesos y facilitar la adopción.

Una reflexión final

Quizás el futuro de la agilidad no consiste en aplicar Scrum con herramientas de IA o en incorporar agentes a nuestros equipos.

Consiste en ampliar nuestra capacidad para ayudar a las organizaciones a descubrir qué necesitan transformar, experimentar con nuevas posibilidades y conseguir resultados de negocio mediante tecnología.

La IA no hace obsoletas nuestras metodologías; nos obliga a revisar si las estamos utilizando para el propósito correcto. Tal vez esa sea una de las evoluciones más interesantes del Agile Coach: pasar de ayudar a las organizaciones a desarrollar productos de manera ágil, a ayudarlas a descubrir y ejecutar su transformación.

¿Qué opinas? ¿Estamos ante una evolución de las metodologías actuales o necesitamos empezar a pensar en nuevos modelos de trabajo?

[Spanish] De desarrollar software a transformar negocios: el verdadero valor de la tecnología en la era de la IA

Christian Gonzales Komiya — Mon, 02 Nov 2026 21:26:23 +0000

La inteligencia artificial está cambiando la forma en que se construye
software. Hoy, una persona o un equipo pequeño puede desarrollar
aplicaciones, dashboards, automatizaciones y agentes de IA en mucho
menos tiempo y con menores costos que hace unos años.

Esto abre oportunidades enormes, pero también plantea una pregunta: si
cada vez más personas pueden construir soluciones tecnológicas, ¿qué
hará que una empresa o un profesional se diferencie?

El software como ventaja competitiva está cambiando

Durante mucho tiempo, desarrollar software exigía conocimientos
especializados, equipos, tiempo y presupuesto. Esas barreras limitaban
la cantidad de competidores y hacían que la capacidad de construir una
solución fuera, por sí misma, una ventaja.

La IA está reduciendo esas barreras. Cada vez es más sencillo crear
productos que resuelven problemas similares: sistemas de reservas, CRM,
dashboards, aplicaciones administrativas, tiendas virtuales, chatbots y
automatizaciones.

Eso no significa que todo el software vaya a convertirse en una
mercancía indiferenciada. La calidad, la seguridad, la arquitectura, la
integración y el mantenimiento siguen importando. Pero sí significa que
la capacidad de programar, por sí sola, puede dejar de ser un
diferenciador suficiente.

Además, que sea más fácil construir una aplicación no significa que sea
fácil conseguir clientes, comprender sus necesidades, generar confianza
o lograr que una solución se utilice y produzca resultados.

El valor se desplaza hacia el conocimiento del negocio

Quizás el cambio más importante sea pasar de preguntar:

¿Qué software necesita el cliente?

A preguntar:

¿Qué necesita mejorar el negocio y cómo puede ayudar la tecnología a
conseguirlo?

Un proveedor tradicional puede ofrecer una aplicación de ventas. Un
socio con visión de negocio empieza por entender cómo se consiguen los
clientes, dónde se pierden oportunidades, cuánto tarda el seguimiento
comercial y qué información necesita la dirección para tomar decisiones.

Después de ese diagnóstico, puede proponer una combinación de
herramientas: una aplicación, un dashboard, una integración, un agente
de IA, una automatización o incluso un cambio en el proceso.

La tecnología deja de ser el objetivo y se convierte en un medio para
conseguir una mejora concreta.

De proveedor de software a socio estratégico

Podemos distinguir dos enfoques:

Enfoque centrado en el software	Enfoque centrado en el negocio
Vender una aplicación, un dashboard o un chatbot.	Resolver un problema operativo o comercial.
Competir por funcionalidades, precio y tiempo de entrega.	Diferenciarse por la comprensión del negocio y los resultados.
Entregar el producto y cerrar el proyecto.	Acompañar la adopción, medir resultados y mejorar la solución.
El software es el producto principal.	La tecnología es una parte de una solución más amplia.

El segundo enfoque requiere más que conocimientos técnicos. Exige
entender procesos, costos, clientes, indicadores, prioridades y
objetivos. También exige comunicar, negociar, facilitar cambios y
conseguir que las personas adopten las soluciones.

La consultoría también tendrá que diferenciarse

No basta con cambiar el rótulo de desarrollador por el de consultor de
IA o transformación digital. Si todos ofrecen el mismo discurso, la
consultoría también puede saturarse.

La diferenciación puede surgir del conocimiento profundo de determinados
problemas empresariales, de una metodología propia, de la capacidad de
ejecutar y de la experiencia acumulada en proyectos reales.

Una consultora pequeña podría combinar conocimiento especializado,
herramientas de IA, agentes, componentes reutilizables y una red de
colaboradores. Así podría ofrecer capacidades que antes requerían
equipos mucho más grandes.

Un ciclo de trabajo orientado a resultados

Una relación de este tipo podría organizarse en cinco etapas:

Diagnosticar: comprender el negocio, sus procesos, dificultades, costos y oportunidades.
Priorizar: identificar qué problemas conviene resolver primero y qué impacto se espera.
Diseñar e implementar: seleccionar y construir la combinación adecuada de aplicaciones, datos, dashboards, integraciones, automatizaciones y agentes de IA.
Acompañar la adopción: ajustar procesos, capacitar a las personas y facilitar el cambio.
Medir y mejorar: comprobar si hubo ahorro, productividad, más ventas, menos errores o una mejor experiencia del cliente.

Desarrollar software es importante, pero es solo una parte del
recorrido.

¿Cuándo ocurrirá este cambio?

La transición ya está en marcha, aunque no todas las empresas avanzan al
mismo ritmo. Algunas están experimentando con herramientas de IA; otras
están automatizando tareas; y muchas todavía necesitan ayuda para
integrar esas capacidades de manera segura y útil en sus operaciones.

Es razonable esperar una evolución gradual: primero más experimentación,
después mayor presión por demostrar retorno de inversión y,
progresivamente, más demanda de integración, acompañamiento y
especialización.

No se trata de afirmar que desaparecerán los proveedores de software.
Las empresas seguirán necesitando productos, plataformas y
especialistas. La hipótesis es que una parte creciente del valor estará
en conectar esas herramientas con objetivos empresariales concretos.

La oportunidad

La IA puede permitir que profesionales y equipos pequeños ejecuten
proyectos que antes exigían más recursos. Pero la oportunidad no
consiste solamente en producir más software en menos tiempo.

Consiste en utilizar esa capacidad para comprender mejor los negocios,
detectar oportunidades y convertirlas en mejoras reales.

La ventaja competitiva no estará necesariamente en quién puede
desarrollar más software, sino en quién puede identificar mejores
oportunidades de negocio y convertirlas en resultados utilizando
tecnología.

[Spanish] Entrenando un kantoku artificial — Capítulo 3: Nana-Ban, el juego donde vive el kantoku

Christian Gonzales Komiya — Thu, 29 Oct 2026 17:00:17 +0000

Esta serie tiene tres capítulos:

Por qué no usé una red neuronal: qué es el gateball, qué es un kantoku y cómo pensé el kantoku artificial.

Saihai, el agente: cómo se entrenó, qué aprendió, qué desaprendió y cómo terminó siendo un proyecto propio.

Nana-Ban, el juego: el videojuego donde vive el kantoku, la demo y cómo lo construí con Claude Code.

Todo este proyecto empezó por aquí: por las ganas de tener un videojuego de gateball. El kantoku artificial nació después, cuando me di cuenta de que la CPU acertaba pero no pensaba. En este último capítulo cuento cómo es el juego, cómo está hecho y dónde se puede jugar.

¿Qué es Nana-Ban?

Nana-Ban (七番, «el número siete») es un juego de gateball en 2D, con estética de 16 bits, en español, que se juega en el navegador. Está inspirado en los videojuegos de gateball de los años 80, pero todo lo que contiene es propio: el código, los gráficos, los sonidos y los textos.

El logo es una bola roja con el número 7. En el gateball, la bola 7 es roja, porque las rojas son las impares.

Hoy el juego tiene:

Partidos completos de 10 bolas, cinco contra cinco, con las reglas del gateball: las tres puertas, el poste, el touch, el spark, el golpe continuo, las faltas y el reloj de 30 minutos.
Cinco niveles de CPU: cuatro con una CPU sencilla (del «Torneo del barrio» al «Mundial») y el nivel Kantoku IA, donde juega Saihai.
Sonido sintetizado en el navegador, sin archivos de audio.
Una demo que empieza directo en el partido, también en el celular.

Por qué Phaser

El juego está hecho con Phaser 3, un motor de juegos 2D para el navegador, con TypeScript y Vite. La razón principal fue práctica: en Phaser todo es código en texto. No hay un editor visual donde arrastrar objetos, como en Unity o Godot. Eso es justo lo que necesita Claude Code, que trabaja leyendo y escribiendo archivos.

TypeScript atrapa errores antes de que lleguen al juego, y yo lo leo con comodidad por mi experiencia en desarrollo web. Vite hace que cada cambio se vea al instante en el navegador. Y al final, todo el juego se empaqueta en un solo archivo HTML, que se publica en cualquier lado.

La física es propia

Lo que no usé de Phaser fue su motor de física. Escribí una física propia y sencilla, porque el gateball necesita algo muy específico: el pasto.

La primera versión se sentía como billar: la bola rodaba perfecta, como sobre una mesa. Esa fue mi primera crítica como jugador, y de ahí salió un pasto con tres efectos: un freno fijo, un freno que crece con la velocidad y un pequeño desvío aleatorio. Un tiro perfectamente recto se desvía unos 5 cm a 4 metros y unos 23 cm a 14 metros. Así se siente el pasto de verdad: de cerca casi no importa; de lejos, sí.

Dos barras para cada golpe

Cada golpe se decide en tres pasos: apuntas, fijas la fuerza con una barra que se mueve y fijas la precisión con otra. Cada barra tiene una marca: si la detienes ahí, el tiro sale como lo pensaste. Cuanto más lejos el tiro, más rápido se mueve la barra de precisión. Es simple de entender y difícil de dominar, como el gateball.

El juego y el agente

La decisión técnica más importante del proyecto fue separar las reglas del dibujo. Al principio, las reglas del gateball vivían dentro de la escena de Phaser, mezcladas con los gráficos. Las saqué a un motor aparte, sin Phaser, que solo sabe de bolas, puertas, turnos y puntos.

Esa separación lo hizo posible todo:

Entrenar al kantoku sin pantalla. Un partido de CPU contra CPU tarda menos de un segundo en simularse. Así se jugaron los miles de partidos de cada entrenamiento.
Que Saihai piense con las reglas reales. Cuando simula un tiro, usa el mismo motor que el juego, no una aproximación.
Separar a Saihai en su propio proyecto. Hoy el motor y el agente viven juntos en el paquete saihai-gateball, y el juego lo usa como cualquier otra librería.

Así quedó el reparto: Saihai decide y el motor arbitra; el juego dibuja, anima y suena. La escena principal del juego pasó de más de mil líneas a menos de seiscientas.

La demo

Para compartir el juego con amigos, hice una demo: sin menús, empieza directo en el partido, tú con las rojas contra Kantoku IA con las blancas. La tecla R reinicia el partido, y los controles están dibujados en pantalla.

Después la adapté al celular. Se juega en horizontal (si lo pones vertical, te pide girarlo), tocando la cancha para ubicar la bola o mover la mira, con zoom de dos dedos y botones A y B en los costados, como en una consola portátil.

Un detalle que aprendí: en el iPhone, el navegador no permite pantalla completa, así que el botón explica cómo agregar el juego a la pantalla de inicio. La versión táctil la probé en mi Android. Si la juegas en un iPhone, me encantaría saber cómo te va.

Dónde se puede jugar

La demo está publicada en tres lugares:

itch.io, la casa natural de los juegos indie: https://ckomiya.itch.io/nana-ban
Hugging Face, junto al agente: https://huggingface.co/spaces/ckomiya/saihai-gateball-demo
GitHub Pages: https://ckomiya.github.io/gateball-retro/demo/

La publicación es automática: cada vez que subo un cambio al repositorio, GitHub Actions construye el juego y la demo y los publica.

Cómo lo construí con Claude Code

Todo el código de Nana-Ban y de Saihai lo escribí con Claude Code. Pero «escribir con IA» no significa pedirle un juego y esperar. La forma de trabajo fue la parte que más aprendí.

Iteraciones de una sola cosa. Cada iteración tenía un solo objetivo y terminaba en algo jugable. El reparto era claro: yo juzgaba la sensación de juego; Claude Code verificaba que funcionara (que compilara, sin errores, con la mecánica nueva probada). Las fases 1 y 2 del juego, desde el primer tiro hasta las 10 bolas con touch y spark, salieron en unas pocas horas del primer día.

Mi criterio, traducido a código. Mis comentarios eran de jugador, no de programador: «se siente como billar», «me resultó muy fácil ganar», «juega bien, pero una vez se ofreció». Claude Code los convertía en cambios concretos: un pasto más rugoso, un rival más certero, un script que reproducía el turno exacto donde la CPU se ofreció.

Memoria entre sesiones. Claude Code no recuerda las conversaciones anteriores, así que el proyecto tiene sus propios documentos: un CLAUDE.md con las reglas del proyecto, un BACKLOG.md con lo que viene y un HISTORIAL.md con lo que se hizo. Cada sesión empieza leyendo el BACKLOG y confirmando el objetivo antes de escribir código.

Las pruebas como red de seguridad. Hay decenas de escenarios de reglas que se ejecutan con el motor y también con la escena real del juego en el navegador, y deben dar exactamente lo mismo. Hay pruebas que juegan un partido completo con el teclado. Y hay una prueba legal que revisa que ningún texto nombre al juego que me inspiró ni copie nada de él.

Trabajo largo, con punto de parada. La separación de Saihai fue una tarea de varias horas. La planteé como una lista de pasos numerados, con un diario de decisiones y un punto donde detenerse: el último paso, el que publica, era mío. Claude Code hizo los pasos uno a uno, sin supervisión, se detuvo donde debía y me dejó un documento con todo lo que tenía que revisar. Hasta anotó un error propio, un comando que ejecutó por descuido y que corrigió en el acto.

Medir antes de afirmar. Esta frase terminó siendo la regla del proyecto. Cada versión del kantoku se midió y se anotó con honestidad, incluso cuando el resultado era «corrige el caso, no mejora la fuerza».

Lo que viene, sin prisa

Tengo muchas ideas para Nana-Ban, varias inspiradas en esos juegos de los 80:

Una vista de acción, con una cámara en perspectiva que sigue a la bola.
Doce jugadores con atributos propios: unos certeros de cerca, otros de lejos, como en un equipo real. Con eso, Saihai tendrá que aprender a elegir quién tira cada golpe.
Modos de juego y un tutorial, para que cualquiera aprenda gateball jugando.
Arte final y música chiptune.

Pero no tengo prisa. Para mí, por ahora, lo importante era el kantoku: un rival con criterio. El juego completo irá creciendo de a poco, cuando tenga tiempo y ganas, y cada versión nueva de Saihai llegará también a la demo.

Gracias por leer

Esta serie empezó con una pregunta de jugador: ¿puede una máquina dirigir un partido de gateball como un kantoku? Después de 11 días, la respuesta es: todavía no como yo, pero ya me ganó un partido, y cada error suyo me enseña algo sobre mi propia forma de dirigir.

Si juegas la demo, me encantaría saber qué te pareció. Y si eres desarrollador y quieres hacer tu propio juego de gateball, Saihai es libre y está esperando un nuevo partido.

Enlaces

Juega la demo en itch.io: https://ckomiya.itch.io/nana-ban
Juega contra Saihai en Hugging Face: https://huggingface.co/spaces/ckomiya/saihai-gateball-demo
Demo en GitHub Pages: https://ckomiya.github.io/gateball-retro/demo/
Saihai, el agente (código, MIT): https://github.com/ckomiya/saihai-gateball
Saihai, el modelo: https://huggingface.co/ckomiya/saihai-gateball

[Spanish] Entrenando un kantoku artificial — Capítulo 2: Saihai, el agente que aprendió (y desaprendió) a dirigir

Christian Gonzales Komiya — Thu, 29 Oct 2026 16:56:55 +0000

Esta serie tiene tres capítulos:

Por qué no usé una red neuronal: qué es el gateball, qué es un kantoku y cómo pensé el kantoku artificial.

Saihai, el agente : cómo se entrenó, qué aprendió, qué desaprendió y cómo terminó siendo un proyecto propio.

Nana-Ban, el juego: el videojuego donde vive el kantoku, la demo y cómo lo construí con Claude Code.

En el capítulo 1 conté por qué mi kantoku artificial no es una red neuronal, y cómo el primer campeón salió hiperagresivo: atacaba sin parar porque había entrenado contra rivales que nunca atacaban. Ese fue el primer entrenamiento. Este capítulo cuenta todo lo que vino después.

Primero, ¿qué es Saihai?

Saihai (采配) es el nombre del kantoku artificial. En japonés, saihai es la forma de dirigir de un kantoku: sus decisiones tácticas durante el partido.

Técnicamente, Saihai es un agente de IA. Cumple las tres cosas que definen a un agente:

Percibe: lee el estado del partido (dónde está cada bola, a quién le toca, el marcador y el reloj).
Decide: genera decenas de golpes posibles, simula cada uno con la física real del juego (incluido el error del jugador que tira) y evalúa cómo queda la cancha.
Actúa: entrega el tiro (dirección, fuerza y precisión) y el motor lo ejecuta.

Dentro lleva un modelo: los pesos aprendidos por autojuego. Es como un kantoku y su experiencia: el kantoku es el agente; su experiencia es el modelo.

Y una aclaración que hago siempre: no es un modelo de lenguaje ni una red neuronal. Es IA clásica de juegos, de la misma familia que los motores de ajedrez o las IA de billar: búsqueda, simulación y una función de evaluación con parámetros aprendidos, más reglas de experto.

El segundo entrenamiento: menos exposición

Después del campeón hiperagresivo, el objetivo del segundo entrenamiento (el v2) fue que el kantoku dejara de «ofrecerse». Lo había visto en varias partidas: al reentrar a la cancha o al salir de la puerta 1, dejaba su bola justo donde yo podía tocarla.

Cambiamos el entrenamiento por completo. En vez de jugar solo contra los pesos escritos a mano, cada candidato jugaba una liga: contra los pesos a mano, contra el campeón anterior, contra un «salón de la fama» de campeones pasados y contra los otros candidatos. Y le pusimos un piso al riesgo: por más que el optimizador quisiera, exponerse nunca podía valer cero.

Fueron 30 generaciones en 94 minutos. El v2 le ganó el 60 % de los partidos al v1, y las veces que su bola era tocada o sacada al reentrar bajaron del 83 % al 44 %.

Un detalle que me gustó: el peso del riesgo terminó exactamente en el piso que habíamos puesto. Es decir, la máquina no lo descubrió sola: la restricción la pusimos nosotros. Fue la primera señal de algo que se repetiría muchas veces: el criterio humano y el aprendizaje se complementan.

Una bola que se ofreció

Jugando contra el v2 vi una bola de la CPU reentrar y quedar justo al lado de la mía. ¿Por qué, si ahora valoraba el riesgo? Claude Code reprodujo el turno con un script y encontró la causa: el cálculo del riesgo solo miraba a 3 de las 5 rivales. Las que jugaban más tarde no existían para él.

Se corrigió y se continuó el entrenamiento desde donde había quedado, 20 generaciones más. Esa versión le ganó el 69 % al v2.

El efecto techo: cuando ya no se ve la mejora

Después agregué reglas que conozco como jugador: aprovechar la línea de la cancha, cuándo juntarse con una compañera, cómo recoger bolas. Las medí y el resultado fue desconcertante: 51 %, un empate técnico contra el campeón sin esas reglas.

¿No servían? Sí servían, pero no se notaba. El campeón ya les ganaba casi el 98 % de los partidos a los pesos escritos a mano, y al primer rival «tipo humano» que probamos, el 99 %. Cuando ganas casi todo, no queda margen para mostrar que mejoraste. Es el efecto techo: como medir la altura de alguien en una habitación de techo bajo.

La solución fue construir un rival tipo humano cada vez más exigente: una CPU con el error de un buen jugador de gateball (mi referencia: la mitad de los touches a 6 m, uno de cada cinco a 13 m) y que se pasa de fuerza como lo hace una persona. Desde entonces, cada versión se mide también contra ese rival.

El tercer entrenamiento: la máquina tenía razón

Con el v3 pasó algo curioso. El criterio que yo había puesto para adoptarlo decía que el kantoku tenía que pasar la puerta 1 en su primer intento casi siempre. El v3 no lo cumplía: a veces se quedaba esperando en la salida.

Iba a descartarlo, hasta que me di cuenta de que esperar en la salida es una táctica real del gateball: si la cancha está vacía, a veces conviene no entrar todavía. La máquina había descubierto sola una táctica que yo conozco como jugador, y mi criterio de evaluación estaba mal planteado.

Cambiamos el criterio a «espera con sentido» y el v3 pasó a ser el campeón.

La lección: antes de culpar al modelo, revisa la pregunta que le estás haciendo.

El entrenamiento que aprendió a no atacar

El cuarto entrenamiento (le llamamos F) fue el más ambicioso hasta ese momento: unas cinco horas, nueve parámetros nuevos de reglas que yo había agregado jugando, y el rival tipo humano dentro de la evaluación.

El resultado parecía excelente: el candidato le ganaba el 67 % al campeón. Pero una prueba de comportamiento encendió la alarma. En una situación muy clara del gateball (pasas la puerta, ganas un golpe extra y tienes una rival cerca), un kantoku ataca. El candidato no atacaba nunca: 0 de 60 veces.

Había aprendido que podía ganar igual sin atacar en esa situación, así que simplemente dejó de hacerlo. Como estrategia contra las CPU funcionaba; como kantoku, era absurdo.

Lo descartamos y de ahí salió una regla de diseño que sigo usando: lo que un kantoku nunca debe dejar de hacer se programa como regla fija, no como algo que se aprende. El optimizador aprende cuánto vale cada cosa; las convicciones del kantoku no se negocian.

El v4: aprender con examen incluido

Para el siguiente entrenamiento (el v4) cambiamos la forma de evaluar. Además de ganar partidos, cada candidato tenía que rendir una batería de comportamiento: tableros reales de mis partidas, donde se sabe qué haría un kantoku. Así, ganar haciendo absurdos ya no daba puntos.

Fueron 24 generaciones y unas cinco horas. El v4 aprendió algo interesante: cuando va perdiendo, los puntos pesan más. Pero no aprendió que el reloj importa: ese parámetro quedó en cero.

Según el criterio de adopción que habíamos escrito antes de entrenar, el v4 no alcanzaba: tenía que ganarle al menos el 57 % al campeón y llegó al 55,5 %. Contra el rival tipo humano ganaba el 80,5 %, frente al 81,8 % del v3. Pero esas diferencias estaban dentro del ruido de la medición. Lo adopté igual, porque era el primero entrenado con las pruebas de comportamiento dentro de la evaluación, y eso valía más que un punto que podía ser azar.

Desde entonces, Saihai no se ha vuelto a entrenar. Todo lo que mejoró después fueron reglas.

De la máquina al criterio: cinco versiones en un día

El 27 de octubre jugué varias partidas contra el v4 y anoté turno por turno lo que un kantoku habría hecho distinto. Cada observación se convirtió en una regla, y ese día salieron cinco versiones, de la v1.0 a la v1.4.

Versión	Qué aprendió (en simple)	De dónde salió
v1.0	Calcula cuántos turnos le quedan a cada bola según cómo está la cancha, y valora mejor el doble ángulo «bola y puerta»	El parámetro del reloj que el v4 no aprendió
v1.1	Reentradas más cuidadosas: prevé que la rival toque a su compañera y la mande junto a su bola	Siete reentradas de una misma partida mía
v1.2	«Casi siempre se reentra»: quedarse fuera bajó del 10,7 % al 0,4 %	Mi criterio de kantoku
v1.3	En el último turno busca la cadena de golpes que suma más puntos	Un último turno donde solo pasó una puerta
v1.4	El spark ya no saca bolas propias; no arriesga quedar junto a una rival por avanzar si probablemente no vuelve a jugar	Un spark que sacó a su propia compañera
v1.5	Con el partido ya ganado, la última bola intenta el touch lejano para sumar	Una última bola que no intentó nada

Lo honesto: casi ninguna de estas versiones ganó más que la anterior. Corregían el caso que yo había visto, sin empeorar nada. Para mí eso era suficiente, porque el objetivo no era un kantoku más fuerte, sino uno más parecido a un kantoku real.

Y hubo una idea que descarté a propósito: entrenar a Saihai para imitar mis partidas. Cada kantoku tiene su forma de dirigir, y no quería una copia de la mía. Prefiero que descubra su propio estilo a partir de principios, y que yo le corrija los errores de criterio.

Lo que Saihai todavía no entiende

No todas mis observaciones se pudieron resolver, y creo que esa parte es la más interesante.

El puente que no quiso hacer. En un turno, yo habría puesto la bola 2 junto a la 4 para hacerle de puente (tsunagi): facilitar que la 4 pasara su puerta, en un lugar donde la rival que juega antes no tuviera doble ángulo. Saihai la mandó a un sitio tapado. ¿Por qué? Porque veía tres rivales a 13 metros, cada una con un 20 % de acertar, y sumadas le parecían un peligro serio. Para mí, como kantoku, un touch a 13 metros es muy difícil y no condiciona la jugada.

Probamos varias correcciones y ninguna lo resolvió sin trampas. La diferencia de fondo es cuánto pesa una amenaza lejana, y eso no se debe ajustar a mano para que pase una prueba: se va a calibrar con datos de partidas reales en el próximo entrenamiento.

El peor riesgo tapa a los demás. En otra partida, una bola blanca quedó frente a la puerta 2 con un triple ángulo para una rival. Saihai calcula el riesgo de cada rival como su peor amenaza, no como la suma de todas. Como esa rival tenía una amenaza aún mayor en otro lado, mover la bola «no cambiaba nada» para él. Arreglarlo exige reentrenar, porque los pesos aprendieron con esa forma de medir.

El tiro que no existía. Otra vez yo habría dejado la bola pegada a la línea para dominar la zona de la puerta 2. Saihai midió que tenía razón: ahí era más segura. Pero desde donde estaba, los postes de la puerta tapaban ese tiro. No era un error de criterio, sino de opciones.

Todo esto está documentado para la próxima versión grande, la v2.0.

Medir sin engañarse

Si algo aprendí en este proyecto es a desconfiar de los números bonitos.

Con 200 partidos, cada cifra tiene un margen de ±5 a 7 puntos. Una vez, un candidato parecía ganar el 63,5 %, y al medirlo bien bajó a 60 %: era el mejor de 11 mediciones con ruido. Otra vez, un 81,5 % no se pudo reproducir: dio 76,8 %.

La lección más clara llegó con la última versión. Comparé la v1.5 contra la v1.4 y dio 47,8 %, por debajo del 48 % que había puesto como meta. Antes de concluir que era peor, medimos un control: la v1.4 contra sí misma, con las mismas semillas. Dio exactamente 47,8 %. La meta era imposible incluso para dos copias idénticas.

El gráfico mezcla condiciones distintas (certeza, rivales y hasta el grosor del poste), así que no es una serie continua. Lo que muestra es otra cosa: cuánto se mueven los números por razones que no son «mejorar».

De parte del juego a proyecto propio

Al principio, el kantoku vivía dentro del juego. Pero un kantoku artificial de gateball podía servirle a otros: a quien quiera hacer su propio juego de gateball, en otro motor o con otra estética. Así que decidí separarlo en su propio repositorio, sin interfaz, como una librería.

El kantoku «piensa» simulando tiros con las reglas y la física, así que no se podía ir solo: se llevó también el motor de gateball. Hoy el juego usa ese mismo paquete para las reglas y para la IA. Una sola fuente de verdad.

La condición que puse fue estricta: después de separarlo, tenía que jugar idéntico. No «parecido»: idéntico. Se midió todo antes y después con las mismas semillas, y los resultados coincidieron partido por partido, hasta los archivos de referencia byte a byte.

Esa comparación encontró algo que nadie había visto: algunas pruebas leían partidas guardadas solo en mi laptop. En una copia limpia del repositorio, esas pruebas veían la mitad de los datos y pasaban igual, sin avisar. Las 23 partidas quedaron versionadas como parte de las pruebas.

Usar Saihai se ve así:

import { createMatch, Saihai, playShot } from 'saihai-gateball';

const match = createMatch({ seed: 42 });            // partido con azar reproducible
const saihai = new Saihai({ opponent: 'human' });   // juzga a su rival como a una persona

while (match.stage !== 'done') {
  const shot = saihai.chooseShot(match);            // Saihai decide el tiro
  const res = playShot(match, shot);                // el motor lo ejecuta
  console.log(res.events);                          // puertas, touches, sparks, faltas…
  match.proceed();                                  // siguiente golpe o turno
}
console.log(match.teamScore(0), match.teamScore(1));

Sin Phaser, sin navegador: corre en Node o en cualquier juego web. La misma semilla reproduce exactamente el mismo partido, y Saihai puede explicar cada decisión, en español o en inglés.

Para comprobar que de verdad servía a otros, hicimos una prueba de «desarrollador externo»: una carpeta vacía, instalar Saihai desde GitHub y jugar un partido usando solo lo que dice el README. Funcionó, y de esa prueba salieron once mejoras a la documentación.

Saihai en Hugging Face

El último paso fue publicarlo donde la comunidad de IA busca modelos y agentes: Hugging Face. Ahí están los pesos (31 valores aprendidos por autojuego y 14 fijos), una ficha que explica qué es y qué no es, y un Space donde cualquiera puede jugar contra Saihai desde el navegador.

Hugging Face no tiene una categoría de «agentes», así que Saihai aparece como modelo. Es lo habitual con los agentes de juegos: el repositorio de modelo guarda lo que el agente aprendió, y el Space lo muestra funcionando.

Las cifras de hoy

Medida	Saihai v1.5
Contra la versión anterior (200 partidos)	47,8 %, igual que el control
Contra el rival tipo humano (200 partidos)	84,5 %, con 7 puntos de diferencia por partido
Pruebas de comportamiento (tableros de mis partidas)	98 %
Tiempo para decidir un golpe	unos 53 ms en mi laptop
Valores aprendidos	31 (más 14 fijos)

Una advertencia importante: todas son cifras contra rivales simulados. Contra personas reales, por ahora, solo están mis partidas. Y ya me ganó un partido, bien jugado.

Lo que viene

El próximo paso es un nuevo entrenamiento, la v2.0, con una diferencia clave: calibrar el rival humano con mis partidas reales. Mis partidas guardadas registran cada tiro, así que se puede medir cuánto acierto yo de verdad a 6, 9 o 13 metros, en vez de suponerlo. Si a 13 metros acierto menos de lo que Saihai cree, aprenderá solo que esas amenazas pesan poco. Que es justo lo que yo, como kantoku, le habría dicho.

Mientras tanto, sigo jugando y anotando turnos.

Enlaces

Saihai en GitHub (MIT): https://github.com/ckomiya/saihai-gateball
Saihai en Hugging Face: https://huggingface.co/ckomiya/saihai-gateball
Juega contra Saihai (Space): https://huggingface.co/spaces/ckomiya/saihai-gateball-demo
Historial completo del kantoku: https://github.com/ckomiya/saihai-gateball/blob/main/HISTORIAL.md

Próximo capítulo

En el capítulo 3 hablo del juego donde vive Saihai: Nana-Ban. De qué consta, por qué lo hice con Phaser, cómo es la demo (también en el celular), dónde se puede jugar y cómo lo construí con Claude Code, iteración por iteración.

[Spanish] Entrenando un kantoku artificial — Capítulo 1: por qué no usé una red neuronal

Christian Gonzales Komiya — Thu, 22 Oct 2026 01:53:50 +0000

Esta serie tiene tres capítulos:

Por qué no usé una red neuronal : qué es el gateball, qué es un kantoku y cómo pensé el kantoku artificial.

Saihai, el agente: : cómo se entrenó, qué aprendió, qué desaprendió y cómo terminó siendo un proyecto propio.

Nana-Ban, el juego: : el videojuego donde vive el kantoku, la demo y cómo lo construí con Claude Code.

Primero, ¿qué es el gateball?

El gateball es un deporte de equipo que nació en Japón en 1947, en Hokkaido. Se juega en una cancha de pasto de unos 20 × 15 metros, con tres puertas (arcos) y un poste en el centro. Hay dos equipos de cinco bolas, rojas y blancas, y se juega por turnos en orden fijo: bola 1 roja, bola 2 blanca, bola 3 roja, y así hasta la 10.

Cada bola tiene que pasar las tres puertas en orden y luego tocar el poste. Cada puerta da un punto y el poste da dos. Pero lo interesante está en otra parte: si mi bola golpea a otra (un touch), puedo colocar las dos juntas y, con un golpe a la mía, mandar a la otra lejos. Eso es el spark. Con él puedo ayudar a una compañera a avanzar o sacar de la cancha a una bola rival. Un partido dura 30 minutos, y gana el equipo con más puntos.

A simple vista parece un juego de puntería. En realidad es un juego de estrategia.

¿Y qué es el kantoku?

El kantoku (監督) es quien dirige la estrategia del equipo. Decide qué tiene que hacer cada bola en cada turno: avanzar a su puerta, atacar a un rival, acomodarse para ayudar a una compañera o protegerse.

Un buen kantoku no piensa solo en el golpe de ahora. Piensa en qué le deja al rival que juega después, en quién de su equipo es certero de cerca y quién de lejos, en qué zonas de la cancha conviene dominar y en cuánto tiempo queda, porque la forma de dirigir cambia mucho en los últimos minutos.

De dónde salió este proyecto

Todo empezó con un videojuego. Estoy desarrollando Nana-Ban (七番, «el número siete»), un juego de gateball en 2D con estética retro, inspirado en los videojuegos de gateball de los años 80. Lo construyo con Claude Code, en iteraciones cortas.

Llegó un momento en que el juego ya tenía de todo: las 10 bolas, los turnos, el touch, el spark, las faltas y el reloj. La CPU jugaba un partido completo. Pero al jugar contra ella me di cuenta de algo: hacía jugadas sin criterio. Apuntaba a su puerta y poco más. A veces dejaba su bola justo donde yo podía tocarla y sacarla. Otras, volvía a entrar a la cancha poniéndose a mi merced. Acertaba, pero no pensaba.

Ahí entendí que lo que le faltaba no era puntería: le faltaba un kantoku.

¿Es como un jugador de ajedrez?

Mi primera intuición fue esa: un kantoku es como un ajedrecista, alguien que lee el tablero y anticipa al rival. Se parecen en eso, pero hay tres diferencias importantes:

Las jugadas son continuas. En ajedrez hay unas 30 jugadas posibles por turno. En gateball, el ángulo y la fuerza son infinitos.
Hay azar en la ejecución. Puedes elegir el tiro perfecto y fallarlo. El pasto desvía la bola.
Quién juega después importa muchísimo. El orden de turnos es fijo, así que la pregunta clave es: ¿qué le estoy dejando a la bola rival que viene?

Por eso el modelo más parecido no es el ajedrez, sino la inteligencia artificial del billar o del curling: pensar varias opciones, simular cada una y evaluar cómo queda la cancha.

Cómo piensa el kantoku artificial

Hoy ese kantoku tiene nombre: Saihai (采配), que en japonés es la forma de dirigir de un kantoku, sus decisiones tácticas durante el partido. En cada turno, Saihai hace tres cosas:

Piensa opciones: pasar su puerta, hacer touch a un rival, acercarse a una compañera, ir al poste o acomodarse.
Las prueba en su cabeza: simula cada tiro con la misma física del juego, varias veces y con el error propio del jugador que tira, porque no es lo mismo un tirador certero que uno inseguro.
Evalúa cómo queda la cancha: le pone un puntaje a cada situación posible y elige la mejor.

Esa evaluación es el corazón del kantoku. Es una fórmula que suma cosas como:

los puntos ganados,
qué tan bien quedan mis bolas para su siguiente puerta,
cuál es la mejor opción que le dejo al rival que juega después,
si controlo la zona frente a las puertas 2 y 3,
si mis bolas quedan cerca entre sí para encadenar touch y spark.

Cada término tiene un peso: cuánto vale. ¿Vale más sacar una bola rival o asegurar un punto? ¿Cuánto cuesta dejar mi bola expuesta? Ahí está la estrategia.

Que la máquina aprenda los pesos

Al principio, esos pesos los escribí a mano, según mi criterio. Funcionaba, pero eran estimaciones. Entonces me pregunté: ¿y si un kantoku artificial los descubre solo?

La idea es simple:

Se crean 24 kantokus con pesos un poco distintos.
Juegan partidos entre ellos, miles, sin dibujar nada, solo simulando.
El sistema se queda con lo que mejor funciona y genera una nueva generación cerca de los ganadores.
Se repite durante decenas de generaciones.

Al final queda un campeón: un archivo con unos 30 números. Ese es el modelo. Lo que se aprende no es la fórmula, sino cuánto vale cada cosa dentro de ella. Es como una receta: el código dice «lleva harina, azúcar y huevos», y el entrenamiento descubre las cantidades.

Técnicamente es optimización por autojuego con un algoritmo llamado CMA-ES. Corre en mi laptop: el primer entrenamiento tardó 80 minutos, y los más completos, unas cinco horas.

¿Por qué no una red neuronal?

Es la pregunta obvia. Las redes neuronales son la base de la inteligencia artificial moderna, y AlphaZero aprendió a jugar ajedrez y Go mejor que cualquier humano. ¿Por qué no usar una?

	Pesos + fórmula (lo que elegí)	Red neuronal
Partidos para aprender	Miles	Cientos de miles o millones
Equipo	Mi laptop, en horas	GPU y días o semanas
¿Se puede leer?	Sí: «touch al rival vale 4,6»	No: millones de números sin significado claro
Corregir un defecto	Directo	Reentrenar y esperar
Mi conocimiento de kantoku	Entra como términos	La red tiene que descubrirlo sola
Tamaño en el juego	~30 números	Megas de datos en el navegador

La razón más importante para mí fue la última fila. Cuando jugué contra la CPU y dije «hay que dominar la zona frente a la puerta 2 sin darle ángulo de tiro al rival», esa idea se convirtió en un término de la fórmula, y el kantoku empezó a valorarla en el siguiente entrenamiento. Con una red neuronal, esa intuición tendría que descubrirla sola, jugando millones de partidos, sin garantía de lograrlo.

¿Y si le ponemos una GPU?

Pensé que con una GPU todo sería más rápido. No en este caso. Una GPU es excelente cuando el trabajo se puede partir en millones de operaciones simples e iguales, como pintar una cerca de mil tablas con mil personas a la vez. Así son las redes neuronales.

Pero un partido de gateball es una carrera de postas: el choque produce un touch, el touch habilita un spark, el spark define el siguiente golpe. Cada paso depende del anterior. Eso lo hace mejor un procesador normal (CPU), y lo que acelera el entrenamiento es tener más núcleos: cada núcleo juega un partido distinto, como un campeonato con varias canchas.

¿Entonces la red neuronal es peor?

No. En techo, una red neuronal puede llegar más lejos, porque no está limitada a los términos que yo definí y puede descubrir conceptos que a nadie se le ocurrieron. Pero en un videojuego el objetivo no es el kantoku más fuerte del mundo, sino un buen rival, con criterio. Para eso, el enfoque elegido es más rápido, más barato, entendible y fácil de corregir.

Si algún día hace falta más, el siguiente paso no sería una red desde cero, sino una red pequeña que aprenda a partir de los mismos términos que ya definimos.

Lo que aprendí en el primer entrenamiento

El primer campeón ganó el 93 % de sus partidos contra los pesos escritos a mano. Parecía un éxito. Pero cuando jugué contra él, le gané fácil.

¿Qué pasó? El kantoku había aprendido a ser hiperagresivo: hacía touches y sacaba bolas sin parar, y dejó en cero el peso de la exposición. No le importaba dejar sus bolas a mi alcance. La razón: entrenó contra rivales pasivos, que casi nunca atacaban. Contra alguien que no ataca, exponerse no cuesta nada, y eso fue exactamente lo que aprendió.

Es como un equipo que solo juega amistosos contra rivales que nunca tiran al arco: aprende que defender no sirve.

La lección: una máquina aprende el mundo que le das, no el mundo real. Para el segundo entrenamiento cambiamos cuatro cosas:

Rivales más duros, incluido el propio campeón.
Un piso al riesgo, porque en el gateball exponerse siempre cuesta algo.
El desvío real del pasto: el kantoku creía acertar el 98 % de los tiros, y a 9 m se acierta cerca del 60 %.
Mi referencia de jugador: un buen jugador acierta un touch la mitad de las veces a unos 6 m, y a 13 m quizás una de cada cinco.

Ese es el valor de este enfoque: cada observación que hago jugando se puede convertir en algo que el kantoku entiende.

Próximo capítulo

Este fue el capítulo 1: por qué el kantoku artificial es como es. En el capítulo 2 cuento la historia de Saihai: los entrenamientos que siguieron, la vez que aprendió a ganar sin atacar, las reglas de kantoku que salieron de mis propias partidas, lo que todavía no logra entender, y cómo terminó convertido en un proyecto propio, abierto y publicado en Hugging Face.

En el capítulo 3 hablaré del juego, Nana-Ban: de qué consta, por qué lo hice con Phaser, cómo usa a Saihai y dónde se puede jugar.

[Spanish] Un marketplace en producción de costo cero: la arquitectura detrás

Christian Gonzales Komiya — Sun, 18 Oct 2026 17:21:36 +0000

Cómo armé, yo solo y con Claude Code, un sitio de clasificados real usando herramientas gratuitas, y por qué elegí cada pieza.

Hace unos meses me planteé un reto: construir un marketplace de verdad, en producción, con usuarios reales, sin presupuesto. Nada de «prototipo» ni «demo»: registro, login, publicar con fotos, catálogo con filtros, mensajes, moderación, SEO, textos legales y un panel de administración.

El resultado es Rejugado, un clasificado de juegos de mesa usados para Perú. No hay pagos entre usuarios (compradores y vendedores se ponen de acuerdo por su cuenta), lo cual simplifica mucho el negocio y también la arquitectura. Y el único gasto fijo es el dominio.

En este post te cuento qué herramientas usé, por qué las elegí (incluido el famoso «¿por qué Supabase y no Firebase?») y cómo Claude Code me ayudó a llegar hasta aquí siendo una sola persona.

El mapa general

                 ┌─────────────────────────────────────────┐
  Navegador ───▶ │  Cloudflare Workers                     │
  (móvil/PC)     │  Astro (SSR) + islas React              │
                 │  Turnstile · DNS · Email Routing        │
                 └───────────────┬─────────────────────────┘
                                 │
                 ┌───────────────▼─────────────────────────┐
                 │  Supabase (región São Paulo)            │
                 │  Postgres + RLS · Auth · Storage        │
                 └───────────────┬─────────────────────────┘
                                 │
                       Correo (SMTP / Resend)

Cuatro piezas, todas con plan gratuito. Vamos una por una.

Astro + islas de React: velocidad y SEO sin pagar de más

Un clasificado vive de que Google lo encuentre y de que cargue rápido en un celular con datos limitados. Por eso las páginas públicas (catálogo, detalle de cada aviso, tienda del vendedor) se renderizan en el servidor con Astro: el navegador recibe HTML listo, sin esperar a que se ejecute un montón de JavaScript.

Las partes que sí necesitan interacción (formulario de publicar, bandeja de mensajes, el panel de cuenta) son islas de React: componentes que se hidratan solo donde hacen falta. El resto de la página no paga ese costo.

El resultado práctico: el catálogo saca 100 en Lighthouse móvil y el detalle ronda los 95. Eso no es vanidad: una página liviana consume menos ancho de banda y menos ejecución en el servidor, y cuando trabajas con límites gratuitos, cada recurso cuenta.

Cloudflare Workers: el servidor que no administras

La aplicación corre en Cloudflare Workers. No hay máquina que mantener, ni parches de sistema operativo, ni escalado que configurar: el código se despliega en la red de Cloudflare y se ejecuta cerca del usuario.

Lo que más valoro es que todo vive en el mismo panel:

Despliegue del sitio.
DNS y dominio, incluida la redirección de www al dominio principal.
Email Routing: la dirección de contacto del sitio reenvía a mi Gmail personal, sin pagar un servicio de correo corporativo.
Turnstile: un captcha moderno y sin fricción para proteger registro, login, recuperación de contraseña y formularios de contacto. Los usuarios casi nunca ven un desafío, y los bots sí se topan con la pared.

Tener todo junto reduce la cantidad de cuentas, claves y paneles que debo vigilar. Para un proyecto de una persona, esa simplicidad vale oro.

Supabase: el corazón del sistema

Aquí viene la decisión más importante. Supabase me da tres cosas en un solo paquete:

Postgres: la base de datos.
Auth: registro, login, recuperación de contraseña y sesiones por cookie.
Storage: almacenamiento de las fotos de los juegos.

¿Por qué Supabase y no Firebase?

Firebase es excelente y lo he visto funcionar muy bien en muchos proyectos. Pero para este proyecto, Supabase encajaba mejor por varias razones concretas:

1. Mis datos son relacionales.
Un catálogo con filtros (precio, condición, departamento, idioma, tipo de juego), vendedores con sus avisos, listas de «lo que busco» para intercambios, reportes y moderación. Todo eso son tablas que se relacionan entre sí. En SQL, un filtro combinado o una vista es una consulta natural. En una base documental como Firestore habría tenido que duplicar y desnormalizar datos, y mantener esas copias sincronizadas se vuelve una fuente constante de errores.

2. La seguridad vive en la base de datos (RLS).
Con Postgres uso Row Level Security: reglas que dicen, tabla por tabla, quién puede leer, insertar o modificar cada fila. Aunque alguien encuentre mi clave pública de la API, la base se defiende sola. Y como esas reglas son SQL, pude escribir pruebas automáticas para ellas: hoy tengo 343 casos de prueba con pgTAP que verifican que cada política hace lo que debe (por ejemplo, que un usuario no pueda editar el aviso de otro o leer campos privados).

3. Migraciones versionadas en Git.
Cada cambio al esquema es un archivo SQL en el repositorio. Mi regla es estricta: nada de cambios manuales en producción. Si algo se rompe, sé exactamente qué cambió y cuándo; y puedo recrear la base desde cero.

4. Sin encierro tecnológico (lock-in).
Supabase es Postgres estándar y de código abierto. Si mañana quisiera irme, puedo llevarme mi base a cualquier otro proveedor. Es más: en desarrollo, mi entorno de Supabase corre en una Raspberry Pi 5 en mi casa. Costo: cero, y con los mismos servicios que en producción.

5. Costos más predecibles.
Firebase cobra por operaciones (lecturas, escrituras, borrados). Con un catálogo que se consulta mucho, una mala consulta o un bot puede dispararte la cuenta. En Supabase el modelo de precios se parece más a «recursos que usas» (espacio, ancho de banda, usuarios activos), lo que me resulta más fácil de prever.

6. Latencia para mi público.
Creé el proyecto en la región de São Paulo, la más cercana a Perú entre las disponibles, con lo que las consultas responden rápido.

Dónde Firebase gana (seamos honestos)

No quiero venderte humo. Firebase es mejor si:

Haces una app móvil nativa y quieres SDKs muy pulidos.
Necesitas modo offline y sincronización en tiempo real como pilar del producto.
Ya vives en el ecosistema de Google (Analytics, Crashlytics, Cloud Messaging…).
Tus datos son simples, tipo documento, y casi no tienes relaciones.

Y sobre Supabase, ojo con las limitaciones del plan gratuito: los proyectos inactivos pueden pausarse tras un tiempo y hay topes de almacenamiento y de ancho de banda. (Revisa siempre las cifras vigentes en la página de precios; cambian con el tiempo.) Para un proyecto con tráfico que empieza, es más que suficiente; si crece, tocará pasar a un plan de pago, y eso es una buena señal.

Detalles pequeños que ahorran dinero

El costo cero no es solo elegir servicios gratuitos: también es diseñar para gastar poco.

Fotos en WebP, comprimidas en el navegador. Cada aviso admite hasta 3 fotos. Antes de subirlas, el navegador del usuario las convierte a WebP (~150 KB) y genera una miniatura (~20 KB) para el catálogo. El servidor nunca procesa imágenes pesadas, y el almacenamiento rinde muchísimo más.
Correo diferido. Los correos de autenticación salen por SMTP de Gmail durante la beta. Los avisos de «tienes un mensaje nuevo» están apagados hasta que haya volumen que justifique un servicio como Resend. Decidí no pagar por algo que todavía no necesito.
Límites de uso. Mensajes y reportes tienen un tope por hora (por correo, cuenta e IP) y pasan por Turnstile. Menos spam significa menos consumo y menos moderación.

¿Cuánto cuesta realmente?

Pieza	Para qué	Costo en esta etapa
Cloudflare Workers	Hospedaje de la aplicación	Plan gratuito
Cloudflare DNS + Email Routing	Dominio y correo de contacto	Gratis
Cloudflare Turnstile	Antibots / captcha	Gratis
Supabase	Base de datos, Auth, Storage	Plan gratuito
Gmail SMTP	Correos de autenticación (beta)	Gratis
Raspberry Pi 5	Entorno de desarrollo de Supabase	Ya la tenía
Dominio	Nombre del sitio	Único gasto fijo (una vez al año)

¿Qué me haría pagar primero? Probablemente el almacenamiento de fotos o el ancho de banda de Supabase si el sitio crece, y un servicio de correo como Resend cuando quiera activar las notificaciones. Son costos que llegan después de tener usuarios, no antes.

Dónde ayudó Claude Code

Ahora, la parte que más preguntas me genera: ¿cómo se construye todo esto entre una sola persona? Una gran parte de la respuesta es Claude Code, el asistente de programación que trabaja directamente en el repositorio y la terminal. Esto fue lo que más valor me dio:

Un CLAUDE.md como memoria del proyecto.
En la raíz del repositorio mantengo un archivo con el estado del proyecto, el stack y las reglas que no se rompen: RLS activado en todas las tablas, permisos explícitos por tabla, claves secretas solo en el servidor, CSP estricta, etc. Claude Code lo lee al empezar cada sesión, así que no tengo que repetir el contexto ni temer que «olvide» una regla de seguridad.

Migraciones y pruebas escritas juntas.
Cuando le pido una funcionalidad nueva (por ejemplo, el sistema de intercambio de juegos), no escribe solo la migración SQL: escribe también las políticas RLS y sus pruebas pgTAP. Esa disciplina de «ninguna política sin su test» es difícil de sostener a mano cuando estás solo y cansado; con el asistente se vuelve parte del proceso.

Pruebas de integración y revisión de seguridad.
Tengo unos 80 casos de prueba de la API (mensajes, reportes, moderación, SEO, intercambio). Claude Code los escribió, los ejecuta, y cuando algo falla ayuda a diagnosticar la causa raíz en lugar de parchar el síntoma. También lo usé para revisar cabeceras de seguridad, validaciones y casos límite.

Trabajo «aburrido pero crítico».
Documentación técnica, manual de usuario, guía de pruebas manuales, borradores de textos legales, scripts de despliegue. Todo lo que en un proyecto personal suele quedar para «después» y nunca se hace, aquí quedó hecho.

Un despliegue más seguro.
Después de ver el riesgo de compilar con la configuración equivocada, creamos un script de despliegue que aparta el archivo de desarrollo, compila con la configuración de producción y revisa el resultado antes de publicar. Un error humano clásico, convertido en un paso automático.

Lo que Claude Code no hace por ti

Para ser justo, también hay límites:

Necesita tu criterio. Las decisiones de producto, de negocio y, sobre todo, las legales (términos, protección de datos, inscripción en la autoridad) son tuyas. El asistente ayuda a redactar y estructurar, pero tú respondes por el contenido.
Hay que revisar lo que genera. Es como trabajar con un colega muy rápido: puede equivocarse o malinterpretar. Las pruebas automáticas y la revisión de cambios (git diff) son tu red de seguridad.
Funciona tan bien como el contexto que le das. Un buen CLAUDE.md marca la diferencia entre un asistente genérico y uno que conoce tu proyecto.

Lecciones que me llevo

Elige herramientas por el problema, no por la moda. Mis datos eran relacionales; por eso Postgres. Si los tuyos no lo fueran, quizá la respuesta sería otra.
Pon la seguridad lo más cerca posible de los datos. RLS con pruebas automáticas me da tranquilidad que ninguna validación de formulario puede darme.
Posterga lo que no necesitas hoy. Cobros, notificaciones por correo y funciones «de fase 2» pueden esperar. Cada cosa pospuesta es dinero y tiempo ahorrados.
Automatiza los errores que ya te dolieron. Un script de despliegue vale más que una nota que dice «acuérdate de…».
Un asistente de IA multiplica, no reemplaza. Te permite hacer el trabajo de un equipo pequeño, pero sigues siendo quien decide el rumbo.

Para cerrar

Lanzar un proyecto web propio ya no requiere servidores caros, equipos grandes ni meses de trabajo. Con Astro, Cloudflare, Supabase y un buen asistente como Claude Code, una sola persona puede tener un producto serio en producción, con seguridad, pruebas y SEO, gastando prácticamente solo en el dominio.

¿Y tú? ¿Qué stack usas para tus proyectos y por qué? Me encantaría leerte en los comentarios, sobre todo si elegiste Firebase y tienes argumentos que yo no consideré.

Nota: las condiciones de los planes gratuitos (límites, pausas, precios) cambian con frecuencia. Verifica siempre la información vigente en la página oficial de cada proveedor antes de basar tu proyecto en ella.

[Spanish] ¿Cómo deshacer una operación en microservicios? El patrón Saga explicado con Java

Christian Gonzales Komiya — Mon, 12 Oct 2026 12:37:27 +0000

Imagina que compras una laptop por internet. La tienda crea el pedido, reserva una unidad en el inventario e intenta cobrarte. Pero tu tarjeta está vencida.

El cobro falla. ¿Qué pasa con el pedido que ya se creó? ¿Y con la laptop que quedó reservada?

En una aplicación pequeña, quizá todas esas operaciones ocurran dentro de una misma transacción de base de datos. Si algo sale mal, un ROLLBACK puede deshacer los cambios.

En una arquitectura de microservicios, en cambio, cada servicio puede tener su propia base de datos y confirmar sus cambios de forma independiente. El ROLLBACK de un servicio no puede deshacer automáticamente lo que otro ya guardó.

Para resolver este tipo de situaciones existe un patrón conocido como Saga.

1. El problema: una operación de negocio, varios servicios

Supongamos que nuestra tienda tiene tres microservicios:

OrderService: registra y administra pedidos.
InventoryService: reserva y libera productos.
PaymentService: procesa los pagos.

El cliente ve una sola acción —comprar—, pero por detrás ocurren varias operaciones.

flowchart TD
    A["Cliente confirma la compra"] --> B["OrderService<br/>Crea pedido PENDING"]
    B --> C["InventoryService<br/>Reserva la laptop"]
    C --> D["PaymentService<br/>Intenta cobrar"]
    D -->|Pago aprobado| E["OrderService<br/>Confirma pedido"]
    D -->|Pago rechazado| F["Cancelar pedido"]
    F --> G["Liberar reserva"]

El camino feliz es sencillo: se reserva el producto, el pago se aprueba y el pedido queda confirmado.

El problema aparece cuando una operación falla después de que otras ya se completaron. Por ejemplo, si el pago es rechazado, no queremos dejar un pedido aparentemente válido ni mantener una unidad reservada indefinidamente.

2. Por qué no basta con hacer `ROLLBACK`

Una transacción ACID permite agrupar operaciones de base de datos para que se confirmen como una unidad o se reviertan. Pero ese alcance tiene un límite: normalmente es la transacción gestionada por una base de datos.

Si OrderService y InventoryService tienen bases de datos independientes, el ROLLBACK de una no deshace los cambios de la otra.

Paso	Servicio	Resultado
1	`OrderService`	Pedido `ORD-123` creado como `PENDING`
2	`InventoryService`	Una laptop queda reservada
3	`PaymentService`	El pago es rechazado
4	—	Hay que cancelar el pedido y liberar la reserva

La clave es esta: no existe un ROLLBACK local que revierta automáticamente todas las operaciones ya confirmadas en servicios distintos.

3. La idea de Saga: compensar, no viajar al pasado

Una Saga convierte una operación de negocio en una secuencia de pasos locales. Cada paso confirma sus propios cambios. Si uno falla, se ejecutan acciones compensatorias para contrarrestar los pasos anteriores.

flowchart TD
    A["Crear pedido"] --> B["Reservar inventario"]
    B --> C["Procesar pago"]
    C -->|Éxito| D["Confirmar pedido"]
    C -->|Fallo| E["Compensar"]
    E --> F["Cancelar pedido"]
    F --> G["Liberar inventario"]

Una compensación no es necesariamente borrar datos. De hecho, conservar el historial suele ser importante para auditoría y soporte.

Operación original	Posible compensación
Crear un pedido	Cancelar el pedido
Reservar una unidad	Liberar la reserva
Cobrar al cliente	Reembolsar el importe
Reservar una habitación	Liberar la habitación

La compensación debe reflejar las reglas del negocio. Por ejemplo, si el pago se rechazó antes de cobrar, no corresponde hacer un reembolso; basta con cancelar el pedido y liberar la reserva.

4. Un ejemplo con Java y Spring Boot

Para entender el mecanismo, imaginemos un servicio que coordina los pasos del checkout. Los clientes HTTP que aparecen en el ejemplo representan llamadas a los otros microservicios.

El código es ilustrativo: se centra en el flujo de la Saga, no en toda la configuración de Spring Boot.

@Service
public class CheckoutService {

    private final OrderClient orders;
    private final InventoryClient inventory;
    private final PaymentClient payments;

    public CheckoutService(
            OrderClient orders,
            InventoryClient inventory,
            PaymentClient payments) {
        this.orders = orders;
        this.inventory = inventory;
        this.payments = payments;
    }

    public void checkout(String orderId) {
        // El pedido ya existe con estado PENDING.
        inventory.reserve(orderId);

        try {
            payments.charge(orderId);
            orders.confirm(orderId);

        } catch (PaymentRejectedException ex) {
            // Acciones compensatorias.
            orders.cancel(orderId);
            inventory.release(orderId);

            throw ex;
        }
    }
}

El flujo se puede leer así:

El pedido ya fue creado con estado PENDING.
Se reserva el producto.
Se intenta procesar el pago.
Si el pago se aprueba, se confirma el pedido.
Si el pago se rechaza, se cancela el pedido y se libera la reserva.

En un sistema real, OrderClient, InventoryClient y PaymentClient podrían implementarse con WebClient, HTTP Interfaces de Spring o un cliente de mensajería.

¿Cómo sería la compensación en `OrderService`?

Un endpoint puede cambiar el estado del pedido sin borrar el registro:

@PostMapping("/{orderId}/cancel")
public void cancel(@PathVariable String orderId) {
    Order order = repository.findById(orderId)
        .orElseThrow();

    if (order.getStatus() == OrderStatus.CANCELLED) {
        return; // Repetir la petición no vuelve a cancelar.
    }

    if (order.getStatus() != OrderStatus.PENDING) {
        throw new IllegalStateException(
            "El pedido no se puede cancelar"
        );
    }

    order.setStatus(OrderStatus.CANCELLED);
    repository.save(order);
}

Este ejemplo incorpora una comprobación de idempotencia básica: si el pedido ya está cancelado, repetir la petición no vuelve a modificarlo. En producción, las reglas de concurrencia y las transiciones de estado deben protegerse también a nivel de persistencia.

5. ¿Qué pasa si falla la compensación?

Aquí es donde el diseño se vuelve interesante.

Supongamos que el pago es rechazado, pero InventoryService está temporalmente fuera de servicio. El pedido puede cancelarse, pero la reserva sigue activa.

No conviene confiar en que una llamada HTTP tendrá éxito siempre. Una implementación robusta debe contemplar, al menos:

Reintentos controlados: volver a intentar la compensación ante errores transitorios.
Idempotencia: repetir una solicitud no debe liberar dos veces el mismo stock ni duplicar un reembolso.
Persistencia del progreso: registrar qué pasos se completaron y qué compensaciones siguen pendientes.
Observabilidad: contar con logs, métricas y alertas para detectar Sagas atascadas.
Timeouts y recuperación: decidir qué hacer si un servicio no responde o el resultado de una llamada es incierto.

También hay una diferencia importante entre un rechazo de negocio y un error técnico. Una tarjeta vencida es un rechazo claro. Un timeout, en cambio, no demuestra que el cobro haya fallado: el proveedor podría haber cobrado y haberse perdido la respuesta. Antes de reembolsar o repetir el cobro, hay que consultar el estado de la operación o utilizar una clave de idempotencia.

6. Orquestación y coreografía

Hay dos formas habituales de coordinar una Saga.

Orquestación

Un componente coordinador decide qué paso ejecutar y qué compensaciones iniciar.

flowchart TD
    O["Checkout Orchestrator"] --> A["OrderService"]
    O --> B["InventoryService"]
    O --> C["PaymentService"]

La ventaja es que el flujo se puede leer en un lugar. El reto es que el orquestador necesita guardar su progreso y recuperarse después de un fallo.

Coreografía

Cada servicio publica eventos y otros servicios reaccionan a ellos. Por ejemplo, OrderCreated puede iniciar la reserva; PaymentRejected puede provocar la cancelación del pedido y la liberación del inventario.

flowchart LR
    A["OrderService"] -->|"OrderCreated"| B["InventoryService"]
    B -->|"InventoryReserved"| C["PaymentService"]
    C -->|"PaymentRejected"| D["OrderService"]
    D -->|"OrderCancelled"| B

La coreografía evita concentrar toda la coordinación en un único componente, pero puede ser más difícil seguir el flujo completo cuando hay muchos servicios y eventos.

Ningún enfoque elimina la necesidad de gestionar fallos, duplicados y reintentos. La elección depende de la complejidad del proceso y de cómo el equipo quiera mantenerlo.

7. Un detalle práctico: guardar el cambio y publicar el evento

En una Saga basada en eventos aparece otro posible fallo: el servicio guarda un cambio en su base de datos, pero se cae antes de publicar el evento que informa a los demás.

El patrón Transactional Outbox ayuda a resolverlo. El servicio guarda el cambio de negocio y el evento pendiente en la misma transacción local. Otro proceso publica los eventos pendientes y los marca como enviados.

flowchart TD
    A["Una transacción local"] --> B["Actualizar pedido"]
    A --> C["Guardar evento en Outbox"]
    C --> D["Publicador de eventos"]
    D --> E["Broker de mensajes"]
    E --> F["Servicios consumidores"]

El publicador puede enviar un evento más de una vez, así que los consumidores deben ser idempotentes. Outbox ayuda a no perder la publicación entre la escritura local y el envío; no convierte toda la Saga en una transacción ACID global.

8. ¿Cuándo tiene sentido usar Saga?

Saga resulta útil cuando una operación de negocio atraviesa varios servicios independientes y no es viable —o no conviene— compartir una transacción de base de datos entre todos ellos.

No hace falta aplicar el patrón a cada llamada entre microservicios. Si una operación solo consulta información o si un servicio puede completar su trabajo de forma independiente, quizá no necesite una Saga.

Antes de implementarla, conviene responder estas preguntas:

¿Cuáles son los pasos del proceso?
¿Qué puede fallar en cada paso?
¿Qué acción compensa cada paso que ya se completó?
¿Cómo se reintenta una compensación sin duplicar efectos?
¿Cómo se recupera el proceso tras reiniciar un servicio?

Conclusión

En un sistema distribuido, fallar a mitad de una operación es algo que hay que diseñar, no una excepción que se pueda ignorar.

El patrón Saga organiza los pasos de un proceso y define cómo compensar los que ya se completaron si algo sale mal. A cambio, exige pensar en estados intermedios, reintentos, idempotencia y recuperación.

La idea no es que los microservicios carezcan de transacciones. Cada servicio puede usar transacciones ACID en su propia base de datos. Lo que no se obtiene automáticamente es una única transacción ACID que abarque todos los servicios independientes.

La pregunta útil no es solo «¿qué pasa si todo sale bien?», sino también «¿cómo dejamos el negocio en un estado coherente si falla el paso número tres?».

[Spanish] Un sitio de 1000 páginas sin servidor ni base de datos: Astro + Claude Code

Christian Gonzales Komiya — Tue, 06 Oct 2026 02:20:04 +0000

Hace unos meses empecé a ordenar los resultados de gateball en el Perú. Los datos estaban repartidos en más de diez años de entradas del blog Kantokeando: torneos, equipos, jugadores y puestos. Los fui pasando a un Excel a mano y me pregunté si se podía convertir en algo útil para la comunidad, que busca saber quién ganó, cuántos títulos tiene un equipo o cómo le fue a un jugador.

Así nació Gate-Datos: un archivo de consulta con 189 torneos, 203 equipos, 538 jugadores y más de mil resultados, de 2014 a 2026. Es solo de lectura, sin login, sin formularios y sin base de datos en el camino.

La portada: un buscador y el último torneo. Todo es HTML generado de antemano.

La idea: generar todo antes, servir solo archivos

Los datos cambian poco. Se agregan unos 4 a 8 registros cada dos semanas, así que no hace falta consultar nada en tiempo real. Eso me llevó a esta arquitectura:

El Excel es la única fuente de verdad.
Un pipeline en Python (pandas, rapidfuzz) lo valida, normaliza los nombres y exporta JSON.
Astro lee esos JSON y genera el sitio entero como HTML estático.
Cloudflare sirve los archivos.

No hay servidor de aplicación, API ni consultas en cada visita. Cada página ya está construida antes de que alguien la pida.

Cada torneo tiene su página con los podios por categoría. Una página más de las 996 que genera el build.

Por qué Astro

Con los datos actuales, un solo build genera 996 páginas (una por torneo, jugador, equipo, año, tabla de posiciones y más) en unos 11 a 13 segundos. El sitio completo pesa unos 51 MB. Reconstruirlo entero en cada actualización me sale gratis en la práctica, y por eso lo hago a propósito: la normalización de nombres es global, y un registro nuevo puede cambiar datos que ya existían. Un build completo siempre es coherente.

Lo que le ganamos al usuario:

Velocidad: cada página es HTML listo, sin esperar a un servidor ni a que un framework "arme" la pantalla en el navegador.
Poco JavaScript: Astro no envía JS que no pidas. En mi caso solo viaja un índice de búsqueda de unos 90 KB. Los JSON grandes (el de jugadores pesa unos 2 MB) los usa únicamente el build y nunca llegan al navegador.
Hosting barato y robusto: son archivos estáticos. No hay nada que se caiga por exceso de consultas.

La arquitectura de islas, explicada simple

Una página web tradicional con framework suele cargar JavaScript para toda la pantalla, aunque la mayor parte sea texto que nunca cambia. La arquitectura de islas parte de lo contrario: la página es HTML estático (el "mar"), y solo las partes que realmente necesitan interactividad son "islas" con su propio JavaScript. Un botón de tema oscuro o un buscador pueden ser islas, y el resto de la página no paga ese costo.

Un punto de honestidad: en este proyecto casi no usé islas. No metí React ni otro framework de UI. Mi interactividad es mínima: un buscador con sugerencias y un botón de tema claro/oscuro, ambos con scripts pequeños. Con eso, casi todo el sitio es HTML puro. Astro me permitió no pensar en hidratación hasta que de verdad la necesitara, y esa es la gracia: lo estático es el punto de partida y lo interactivo se agrega solo donde hace falta.

La ficha de un equipo: casi todo es HTML estático; el buscador y el botón de tema son las únicas partes con JavaScript.

Cómo lo publico

El sitio vive en Cloudflare Workers con archivos estáticos, en el plan gratuito. Está conectado a mi repositorio de GitHub: cada git push a la rama principal dispara el build y el despliegue en uno o dos minutos. El dominio propio se asocia al mismo proyecto. Hasta ahora he gastado 8 de los 3.000 minutos de compilación gratuitos al mes, y los archivos estáticos no cuentan contra el límite de peticiones.

En el celular: el mismo sitio, sin app aparte.

También agregué sitemap y robots.txt, y envié el sitio a Google Search Console.

Cómo me ayudó Claude Code

Trabajé con Claude Code como compañero de programación durante todo el proyecto, y esto es lo que más me sirvió:

El pipeline de datos. Los nombres en las entradas del blog vienen con variantes: tildes, orden Nombre/Apellido invertido, apodos, tipeos. Claude escribió los scripts que proponen qué nombres son la misma persona, pero la decisión siempre fue mía, y las reglas confirmadas quedaron en archivos de alias. Esa separación (la máquina propone, el humano decide) fue clave para no mezclar a dos personas distintas.
Convertir un diseño en Astro. Partí de un diseño exportado y Claude lo reescribió en componentes de Astro con CSS propio, tokens de color claro y oscuro y sin librerías de UI.
Un archivo de memoria del proyecto. Mantengo un CLAUDE.md con las decisiones: qué se muestra, qué no, cómo se actualiza. Cada sesión nueva parte con ese contexto y no tengo que explicar todo de nuevo.
Revisión visual. Para cambios de diseño, Claude levanta el sitio, saca capturas en escritorio y móvil, y yo veo el resultado antes de dar el visto bueno. Por ejemplo, me di cuenta de que las tarjetas con forma de arco parecían lápidas para un público mayor, y en una sola conversación se rediseñaron en cuatro páginas y se publicaron.
Documentación y despliegue. Los pasos de publicación, los riesgos y las decisiones quedaron escritos en el repositorio, listos para retomar meses después.

Algo que aprendí: la IA rinde mucho más cuando el proyecto tiene reglas claras escritas (la fuente de verdad, qué nunca se toca, cómo se valida). Con eso, en vez de adivinar, trabaja dentro de tus límites.

Lo que me llevo

Para datos que cambian de vez en cuando, generar estático es más simple, más rápido y más barato que un backend.
Astro hace natural ese enfoque: poco JavaScript, builds rápidos y una forma de crecer hacia la interactividad cuando la necesites.
Claude Code acelera mucho, siempre que tú decidas lo que importa: los datos, las reglas y el diseño final.

Si te interesa ver el resultado, está en gatedatos.org.pe, y el código es público en GitHub.

[Spanish] Por qué un agente de IA no calcula probabilidades (aunque debería, en teoría)

Christian Gonzales Komiya — Sun, 30 Aug 2026 01:27:58 +0000

Cada vez que alguien explica cómo "piensan" los agentes de IA basados en LLM, tarde o temprano aparecen tres palabras que suenan intimidantes: POMDP, belief state y regla de Bayes. La buena noticia es que, detrás de la notación, la idea es bastante simple. Vamos a desarmarla con una sola analogía.

La analogía: un detective que nunca ve la escena completa

Imagina un detective investigando un caso. Nunca puede ver la escena del crimen completa de una sola vez — solo va recibiendo pistas sueltas, una por una: un testimonio hoy, una huella mañana, una grabación borrosa la próxima semana. Nunca sabe con certeza absoluta quién es el culpable. Solo puede ir ajustando sus sospechas a medida que llegan nuevas pistas.

Ese es, casi exactamente, el problema que enfrenta cualquier agente de IA.

El problema de fondo: el mundo real está oculto

En la jerga formal, el estado real del mundo (llamémoslo s) — quién es el culpable, en nuestra analogía — está oculto. El agente nunca lo ve directamente. Lo único que recibe son observaciones parciales (o) — las pistas sueltas, incompletas y a veces ruidosas.

Este problema tiene nombre en teoría de decisiones: se llama POMDP (Partially Observable Markov Decision Process, o proceso de decisión de Markov parcialmente observable). Es, simplemente, el marco matemático formal para "tomar decisiones cuando no ves el mundo real, solo pistas parciales".

Formalmente, el mundo se comporta así:

s_{t+1} ~ T(s' | s_t, a_t)
o_{t+1} ~ O(o' | s_{t+1}, a_t)

Traducido: el mundo cambia de un estado oculto a otro (T, el "kernel de transición") como respuesta a la acción del agente, y luego genera una observación (O, el "kernel de observación") a partir de ese nuevo estado — nunca al revés, y nunca de forma perfecta. El símbolo ~ significa "se muestrea de", es decir, es un proceso con algo de azar, no una fórmula que siempre da el mismo resultado. En la analogía: el crimen ya ocurrió y dejó cierta escena (s), pero la pista que le llega al detective (o) es apenas un reflejo parcial y ruidoso de esa escena — nunca la escena completa.

Bayes: la herramienta para actualizar sospechas

Si el detective no puede ver la verdad directamente, ¿qué puede hacer? Mantener una sospecha — una estimación de qué tan probable es cada posible culpable — y ajustarla cada vez que llega una pista nueva. Eso es exactamente lo que hace la regla de Bayes:

Mi nueva sospecha es mi sospecha anterior, reajustada según qué tan bien la pista nueva encaja con cada sospechoso posible.

En la teoría del POMDP, esta sospecha se llama belief state (estado de creencia, b), y esa frase en español es, literalmente, esta fórmula:

b_{t+1}(s') ∝ O(o_{t+1} | s', a_t) · Σ_s T(s' | s, a_t) · b_t(s)

Se lee de derecha a izquierda: parte de la sospecha anterior (b_t), predice a dónde pudo haber llevado la última acción (la suma sobre T, recorriendo todos los sospechosos posibles), y luego reajusta esa predicción según qué tan bien la encaja la nueva pista (el factor O). Es la regla de Bayes, aplicada un paso a la vez, cada vez que llega una observación nueva.

Y una vez que el detective tiene una sospecha, todavía necesita decidir qué hacer con ella — interrogar al mayordomo, pedir una orden de cateo, esperar una pista más. Eso también tiene una fórmula, la ecuación de valor óptimo:

V*(b) = max_{a} [ Σ_s b(s)·R(s,a) + γ · Σ_o P(o|b,a)·V*(b') ]

En español: el valor de tener cierta sospecha (b) es el de la mejor acción disponible — el pago inmediato esperado de esa acción, más el valor de a dónde te lleve después (descontado por γ, porque el futuro vale un poco menos que el presente). Es una fórmula preciosa... y es exactamente la que hace que resolver un POMDP sea computacionalmente brutal: el espacio de posibles sospechas es continuo e infinito, y calcular esta ecuación de forma exacta es tan costoso que se vuelve inviable para cualquier problema del mundo real.

El giro: así NO funciona un agente LLM

Aquí está la parte que sorprende: un agente construido sobre un LLM no hace nada de esto. No calcula sospechas con fórmulas de Bayes. No mantiene una distribución de probabilidad formal sobre el estado del mundo.

En cambio, hace algo mucho más simple — y sorprendentemente efectivo:

a_t = π(h_t)

Traducido: la siguiente acción del agente (a_t) es simplemente el resultado de meterle todo el historial de mensajes (h_t) a la política (π, que en este caso es el LLM).

En otras palabras, el agente no calcula nada — simplemente guarda todas las pistas en un cuaderno de notas completo (el historial de la conversación) y le muestra ese cuaderno entero al LLM cada vez que necesita decidir algo. Confía en que el modelo, al leer todo de una vez, "entienda" la situación razonablemente bien, sin necesidad de un cálculo formal de probabilidades.

Por qué se usa el vocabulario del POMDP de todos modos

Si el agente LLM no ejecuta las matemáticas del POMDP, ¿por qué los libros y artículos técnicos siguen usando palabras como "creencia" u "observación parcial" para describirlo?

Porque son un préstamo útil de vocabulario, no una afirmación de que se estén haciendo los cálculos reales. Es parecido a decir "voy a hacer un backup mental de esto" — tomamos prestada una palabra técnica (backup) para describir algo mucho más simple (memorizar), sin ejecutar ningún proceso técnico real.

De la misma forma, decir que el historial de mensajes (h_t) "aproxima" el belief state (b_t) es una forma útil de explicar por qué guardar y mostrar todo el historial es una buena estrategia — sin necesidad de afirmar que el LLM está calculando probabilidades exactas por debajo.

El mapa completo, en una tabla

Concepto	Qué es	En la analogía del detective
s (estado real)	La verdad oculta del mundo	Quién es realmente el culpable
o (observación)	Lo que el agente sí percibe	Cada pista suelta
POMDP	El problema formal completo	"Resolver el caso solo con pistas parciales"
b (belief state)	La sospecha calculada con Bayes	"70% creo que fue el mayordomo" (cálculo exacto)
h (historia)	Todas las pistas guardadas en crudo	El cuaderno de notas completo
π (política = LLM)	Quien decide la siguiente acción	El detective decidiendo qué hacer
a (acción)	Lo que el agente hace	"Voy a interrogar al mayordomo"

La idea para llevarse

El POMDP y la regla de Bayes describen la forma ideal y matemáticamente perfecta de decidir bajo incertidumbre. Pero es tan costosa de calcular que ningún agente real la ejecuta tal cual.

Un agente LLM toma un atajo pragmático: en vez de calcular una creencia formal, simplemente lee todo el historial de golpe y confía en la capacidad del modelo de lenguaje para captar, de forma implícita, algo parecido a esa creencia — sin necesidad de una sola fórmula de probabilidad.

El vocabulario del POMDP no describe lo que el agente hace. Describe el problema que el agente está tratando de resolver, y por qué la estrategia de "meter todo el contexto al modelo" no es arbitraria — es, en el fondo, una aproximación honesta a un problema que sabemos, matemáticamente, que no se puede resolver de forma exacta.

(Spanish) El nuevo cuello de botella no es escribir código, es confiar en él

Christian Gonzales Komiya — Sat, 25 Jul 2026 19:25:58 +0000

Por qué Scrum no muere con la llegada de los agentes de IA — pero tampoco sobrevive intacto

El punto de partida

Todo el mundo asume que si los agentes de IA escriben el código, los sprints se acortan, los equipos entregan más rápido, y Scrum tal como lo conocemos se vuelve obsoleto por lento. Es una conclusión intuitiva. También es, en mi opinión, parcialmente equivocada.

La generación de código escala con cómputo. La capacidad de un humano para revisar ese código con criterio — para decidir si debe llegar a producción — no escala igual. Si un agente te entrega 500 líneas en dos minutos y te toma diez revisarlas bien, el límite real del sistema nunca fue la velocidad de generación. Es cuántas revisiones de calidad puede hacer un humano por día.

Eso cambia todo el análisis.

Lo que se mantiene: el esqueleto de valores

Scrum, en el fondo, es un marco de tres cosas: transparencia (todos ven el mismo estado real), inspección (revisas seguido, no al final) y adaptación (cambias de rumbo rápido). Nada de esto depende de si quien "hace" el trabajo es humano o agente. Si acaso, la necesidad de iterar corto y revisar seguido se vuelve más importante cuando el volumen de output se dispara.

Lo que muta: las ceremonias se redefinen alrededor del review, no de la escritura

Sprint Planning deja de ser "¿qué historias entran esta iteración?" y pasa a ser "¿qué specs están lo suficientemente claras para que un agente no alucine?". Esto es trabajo nuevo: antes, la ambigüedad la resolvía el dev sobre la marcha mientras codeaba. Ahora tiene que estar resuelta antes, por escrito, o el agente rellena los huecos con suposiciones.

Una spec "lista para agente" necesita, como mínimo:

Un contrato de entrada/salida explícito — no "el endpoint de login", sino el shape exacto del request/response y qué pasa en cada caso límite.
Restricciones de arquitectura ya resueltas: qué patrón usar, qué no tocar. Hoy esto vive en la cabeza del dev senior; con agentes tiene que estar escrito.
Criterios de aceptación como casos de test concretos, no como prosa ("debe validar bien los datos" no sirve).
Contraejemplos explícitos — qué NO hacer — porque los agentes repiten antipatrones si nadie se los marca.

La consecuencia incómoda: el planning probablemente se alarga, no se acorta. El trabajo de pensar se mueve del "durante" (mientras codeas) al "antes" (mientras especificas). Es el mismo total de esfuerzo cognitivo, solo que concentrado al inicio.

Daily se vuelve menos "¿qué hiciste ayer?" y más "¿dónde está atorado el agente, y dónde estoy atorado yo revisando?". El reporte de bloqueo cambia de "trabajo pendiente" a "contexto faltante" o "cola de revisión".

Sprint Review gana peso relativo — es el único punto donde un humano de negocio valida que lo generado realmente sirve, no solo que pasa los tests.

Retro se parte en dos preguntas que hoy están mezcladas: qué mejoramos del proceso humano, y qué mejoramos del contexto/prompts/guardrails del agente. La segunda se parece más a MLOps que a retro tradicional.

Lo que cambia de fondo: la unidad de trabajo

Hoy la unidad es la historia de usuario, dimensionada en story points para que quepa en el sprint de una persona. Con agentes, el tamaño de la tarea deja de estar limitado por cuánto puede teclear un humano en dos semanas. El límite pasa a ser cuánto contexto no ambiguo le puedes dar al agente de una vez.

La consecuencia es contraintuitiva: agentes más capaces no significa tareas más grandes, sino specs más atómicas — porque la ambigüedad se paga cara a escala.

Qué reemplaza a story points

Story points miden esfuerzo relativo de un humano escribiendo código. Si eso deja de ser el cuello de botella, medirlo pierde sentido. Candidatos más coherentes con este nuevo mundo:

Tiempo de revisión estimado, no de generación. Una tarea "grande" ya no es la que tarda en codearse, sino la que tarda en verificar — por superficie de cambio, criticidad, o contexto de negocio que exige.
Densidad de ambigüedad de la spec: cuántas decisiones quedaron sin resolver antes de mandarle la tarea al agente.
Blast radius / criticidad: no es lo mismo tocar una página estática que el módulo de pagos. Esto se parece más a cómo se estima riesgo en seguridad (impacto × probabilidad) que a Scrum clásico.
Tasa de aceptación en primera pasada: qué porcentaje del output del agente pasa review sin cambios mayores. Mide la calidad del sistema (contexto, prompts), no del trabajo puntual — sirve para mejorar el proceso, no para planear el sprint.

El punto de fondo: estimar deja de ser "cuánto esfuerzo humano toma escribir esto" y pasa a ser "cuánto esfuerzo humano toma confiar en que esto está bien". Es una pregunta de naturaleza distinta, y nadie ha formalizado todavía el "planning poker" de esto.

Una nota de cautela sobre las métricas nuevas

Cuidado con métricas tipo "cuántos PRs generó el agente y cuántos aceptó el humano" (agent throughput). En cuanto una métrica se vuelve la meta, la gente optimiza para que suba el número, no para que mejore la calidad — ya lo vimos con "líneas de código" en los 90s. Una métrica más honesta apunta a defectos escapados a producción por sprint, o tiempo de review ponderado por complejidad: mide la calidad del filtro, no el volumen que pasa por él.

Por qué esto no será parejo

CRUD, dashboards, integraciones estándar, proyectos greenfield: ahí la transformación se ve rápido y clara. Pero en legacy sin tests, dominios con reglas de negocio implícitas y nunca documentadas, o contextos regulatorios (fintech, salud, gobierno), el cuello de botella sigue siendo explicarle al agente años de decisiones tácitas que nadie escribió — y eso no lo resuelve el mejor RAG del mercado. Ahí el sprint de dos semanas probablemente sobrevive más tiempo del que la narrativa optimista sugiere, y no por resistencia al cambio sino por razones regulatorias y de auditoría que no son técnicas.

La apuesta

Scrum no muere. Pero dentro de tres a cinco años, lo que hoy llamamos "Scrum" probablemente se parezca más a un framework de gobernanza de agentes con vocabulario ágil prestado, que al Scrum de 2015 enfocado en coordinar humanos escribiendo código a mano.

El dev, mientras tanto, no desaparece — se convierte en el filtro más importante del sistema. Y ese filtro, a diferencia del código que revisa, no se puede generar en dos minutos.

(Spanish) Las 8 expectativas de un Arquitecto de Software

Christian Gonzales Komiya — Tue, 14 Jul 2026 22:32:20 +0000

La figura del Arquitecto de Software suele asociarse con alguien que toma decisiones técnicas importantes o diseña grandes sistemas. Sin embargo, el rol va mucho más allá de elegir tecnologías o dibujar diagramas.

Más que preguntarnos qué es un arquitecto de software, una mejor pregunta sería:

¿Qué se espera realmente de un arquitecto de software?

A continuación comparto ocho expectativas fundamentales que todo arquitecto debería cumplir. Estas ideas están inspiradas en Fundamentals of Software Architecture (2nd Edition) de Mark Richards y Neal Ford, y representan una excelente guía para quienes desean crecer profesionalmente hacia este rol.

1. 🏗️ Tomar decisiones arquitectónicas

Un arquitecto debe definir las decisiones arquitectónicas y los principios de diseño que orientarán las decisiones tecnológicas del equipo, del departamento o incluso de toda la organización.

La palabra clave aquí es orientar, no imponer.

Por ejemplo, decidir utilizar React en un proyecto es una decisión técnica. En cambio, una decisión arquitectónica consiste en establecer que el frontend debe desarrollarse utilizando un framework reactivo, permitiendo que el equipo elija entre Angular, React, Vue u otra alternativa adecuada.

El trabajo del arquitecto consiste en proporcionar el marco de decisión para que los equipos puedan tomar buenas decisiones técnicas.

Naturalmente, existen excepciones. Cuando una característica arquitectónica como la escalabilidad, el rendimiento o la disponibilidad está en riesgo, el arquitecto puede necesitar imponer una tecnología o una restricción específica.

2. 🔍 Analizar continuamente la arquitectura

Una arquitectura nunca está terminada.

Con el tiempo cambian las necesidades del negocio, aparecen nuevas tecnologías y el software evoluciona. Una buena arquitectura debe evolucionar junto con él.

También existe un fenómeno conocido como deterioro estructural (structural decay): pequeñas modificaciones realizadas por distintos desarrolladores terminan afectando características importantes como el rendimiento, la disponibilidad o la escalabilidad.

El arquitecto debe evaluar continuamente si la arquitectura sigue siendo saludable y detectar oportunidades de mejora antes de que los problemas se vuelvan críticos.

3. 🚀 Mantenerse actualizado con las últimas tendencias

Las decisiones arquitectónicas suelen tener impacto durante muchos años.

Por ello, un arquitecto necesita mantenerse actualizado sobre nuevas tecnologías, herramientas y tendencias de la industria.

Esto no significa perseguir todas las modas tecnológicas.

Significa comprender cuáles realmente aportan valor y cuáles simplemente representan una tendencia pasajera.

4. ✅ Garantizar el cumplimiento de las decisiones arquitectónicas

Diseñar una buena arquitectura no basta.

También es necesario asegurarse de que los equipos realmente la implementen.

Si cada desarrollador comienza a ignorar las reglas arquitectónicas, la arquitectura pierde coherencia y deja de ofrecer las características para las que fue diseñada.

La arquitectura requiere gobernanza, además de diseño.

5. 🌐 Comprender tecnologías diversas

No se espera que un arquitecto sea experto en todas las tecnologías.

Lo que sí se espera es que posea una visión amplia del ecosistema tecnológico.

Debe conocer distintos lenguajes de programación, frameworks, plataformas, bases de datos, herramientas de integración y soluciones en la nube para poder seleccionar la alternativa más adecuada para cada contexto.

En arquitectura suele ser más importante la amplitud del conocimiento que la especialización extrema en una única tecnología.

6. 💼 Conocer el dominio del negocio

La mejor solución técnica puede fracasar si no resuelve un problema de negocio.

Un arquitecto necesita comprender:

los objetivos del negocio;
los procesos que soporta el sistema;
las necesidades de los usuarios;
las restricciones de la organización.

Su credibilidad no depende únicamente de su conocimiento técnico, sino también de su capacidad para hablar el lenguaje del negocio.

7. 🤝 Poseer habilidades interpersonales

Una gran parte del trabajo de un arquitecto consiste en trabajar con personas.

Debe:

liderar equipos;
facilitar acuerdos;
comunicar ideas complejas;
resolver conflictos;
formar y mentorizar desarrolladores.

Como decía Gerald Weinberg:

"No matter what they tell you, it's always a people problem."

("No importa lo que te digan, al final siempre es un problema de personas").

Las habilidades técnicas son indispensables, pero el liderazgo y la comunicación son igual de importantes.

8. 🧭 Comprender y desenvolverse en la política organizacional

Las decisiones arquitectónicas casi siempre generan resistencia.

Cada equipo tiene objetivos distintos.

Cada área posee prioridades diferentes.

Y cada decisión importante afecta a varias personas.

Por ello, el arquitecto necesita desarrollar habilidades de:

negociación;
influencia;
comunicación;
construcción de consensos.

Programar implica tomar decisiones sobre el código.

Ser arquitecto implica tomar decisiones que afectan a toda una organización.

Y eso requiere mucho más que conocimientos técnicos.

🎯 Reflexión final

Muchas personas creen que convertirse en arquitecto significa dejar de programar.

En realidad, significa ampliar el alcance de las decisiones que uno toma.

Un arquitecto exitoso combina:

conocimiento técnico;
visión de negocio;
liderazgo;
comunicación;
capacidad de negociación;
aprendizaje continuo.

La arquitectura de software no consiste únicamente en diseñar sistemas.

Consiste en ayudar a que personas, equipos y tecnología trabajen juntos para construir soluciones que sigan siendo valiosas con el paso del tiempo.

📚 Referencia

Este artículo está inspirado en los conceptos presentados en la siguiente obra:

Richards, M., & Ford, N. (2025). Fundamentals of Software Architecture: A Modern Engineering Approach (2nd ed.). O'Reilly Media. ISBN: 978-1-098-17551-1.

El contenido de este artículo corresponde a una síntesis, interpretación y adaptación realizada por el autor con fines de aprendizaje y divulgación técnica. Para una explicación completa y en profundidad, se recomienda la lectura del libro.

✍️ Sobre este artículo

Este artículo forma parte de mis notas de estudio sobre Arquitectura de Software, donde comparto conceptos, aprendizajes y reflexiones obtenidas durante la lectura de libros especializados y mi experiencia profesional.

Mi objetivo es convertir estas notas en contenido práctico que pueda servir tanto a otros ingenieros de software como a mí mismo como material de consulta en el futuro.

(Spanish) Cómo piensa un agente ReAct: por qué el LLM no resuelve todo en una sola llamada

Christian Gonzales Komiya — Mon, 13 Jul 2026 13:32:35 +0000

Cuando empecé a jugar con LangGraph y un agente con tools (add, subtract, multiply), me chocó algo que parecía contraintuitivo: si le pido al LLM 5 + 8/12, el modelo no responde el resultado final de una. Hace una llamada, pide una tool, espera, hace otra llamada, pide otra tool, espera, y recién en una tercera llamada da la respuesta.

Mi primera reacción fue pensar que el modelo era "limitado" o que solo podía resolver la parte para la que tenía una tool a la mano. La explicación real es más simple y más interesante: el modelo no puede escribir una tool call cuyo argumento sea un resultado que todavía no existe. Este post explica esa idea con el ejemplo concreto que usé para entenderla.

El código base

Un agente ReAct minimalista en LangGraph, con tres tools aritméticas:

@tool
def add(a: int, b: int) -> int:
    """Herramienta de suma que agrega dos números."""
    return a + b

@tool
def multiply(a: int, b: int):
    """Función de multiplicación"""
    return a * b

tools = [add, subtract, multiply]
model = ChatDeepSeek(model="deepseek-chat").bind_tools(tools)

def model_call(state: AgentState) -> AgentState:
    system_prompt = SystemMessage(content="Eres mi asistente de IA...")
    response = model.invoke([system_prompt] + state["messages"])
    return {"messages": [response]}

def should_continue(state: AgentState):
    last_message = state["messages"][-1]
    if not last_message.tool_calls:
        return "end"
    else:
        return "continue"

El grafo conecta our_agent → tools → our_agent en bucle, hasta que should_continue ya no encuentra tool_calls en la última respuesta.

La confusión inicial: "resuelve solo una parte porque solo tiene esa tool"

Con el input 5 + 8/12, uno esperaría que el modelo "vea" la expresión completa y la resuelva de un tiro. En cambio, pasa esto:

Llamada 1 → pide divide(8, 12)
Llamada 2 → pide add(5, 0.667)
Llamada 3 → responde en texto

Da la impresión de que el modelo "hizo lo que pudo con la tool que tenía a mano, y no siguió". Pero esa lectura es engañosa. El límite no es la disponibilidad de tools — es la dependencia de datos entre los dos pasos.

La razón real: no se puede prometer un resultado futuro

Una tool call necesita valores concretos, no referencias simbólicas. El modelo no puede generar algo como:

{"name": "add", "arguments": {"a": 5, "b": "resultado_de_divide"}}

Eso no es un valor válido en el esquema de tool calling. Solo puede escribir add(5, 0.667) si 0.667 ya existe como número real en el historial. Y ese número solo existe después de que la tool divide se ejecutó y su resultado volvió como respuesta.

Por eso, en la primera llamada, lo único que el modelo puede pedir es la operación que ya tiene todos sus datos disponibles: la división. No es que "decida" resolver solo esa parte — es la única parte que puede ejecutar con la información que tiene en ese instante.

Analogía: mandarle mensajes a un amigo con calculadora

Imagina que sabes exactamente qué cuenta quieres hacer (5 + 8/12), pero no tienes calculadora — solo puedes escribirle a un amigo que sí tiene una, y esperar su respuesta antes de seguir.

Le escribes: "divide 8 entre 12". Ya sabes que después vas a sumar 5 al resultado — pero no puedes escribir eso en el mismo mensaje, porque tu amigo no interpreta instrucciones encadenadas en lenguaje natural: solo ejecuta funciones con números concretos. Así que lo único que puedes mandar es la operación cuyos números ya tienes: la división. La suma queda para el siguiente mensaje, una vez que tengas la respuesta.

Prueba de que no es "una tool por llamada"

Si el límite fuera "el modelo solo puede usar una tool por llamada", entonces con un input como:

Suma 4+2 y suma 7+8

Debería necesitar dos llamadas. Pero no es así — como ninguna de las dos sumas depende de la otra, el modelo pide ambas tool calls en la misma respuesta:

[
  {"name": "add", "arguments": {"a": 4, "b": 2}},
  {"name": "add", "arguments": {"a": 7, "b": 8}}
]

El ToolNode las ejecuta ambas sin volver a llamar al LLM entre medio. Total: 2 llamadas al LLM, no 3. Esto confirma que la regla real es "no puedo pedir algo cuyo argumento depende de un resultado que aún no existe" — no una limitación arbitraria de cantidad de tools por turno.

Qué pasa cuando falta una tool

Con 5 + 8/12, si el modelo tiene tanto add como divide, ambas operaciones las hace código Python con precisión garantizada, en 3 llamadas. Pero:

Si solo existe la tool add (no hay divide): el modelo calcula la división mentalmente (como cualquier LLM sin tools, con su propio "cálculo interno"), y usa la tool solo para la suma. Total: 2 llamadas.
Si solo existe la tool divide (no hay add): el modelo pide la división como tool call, y luego calcula la suma mentalmente con el resultado. Total: 2 llamadas.

El patrón se mantiene: el número de llamadas depende de cuántos pasos secuenciales con dependencia de datos hay — no de cuántas tools existan en total. Cuando falta una tool para un paso, el modelo simplemente resuelve ese paso con su propio razonamiento en lugar de con código, y sigue adelante.

Lo que el LLM sabe y lo que no sabe desde la primera llamada

Sí sabe, desde el inicio: qué tools tiene disponibles y sus esquemas (nombre, descripción, parámetros). Eso se manda en cada llamada — es literalmente lo que hace bind_tools(tools): adjuntar esa lista de forma fija a cada invocación.

No sabe, ni falta que sepa: cuántas llamadas totales se van a necesitar. El modelo no planea "esto me va a tomar 3 vueltas" — es reactivo, no planificador de antemano. En cada llamada individual mira el historial actual y decide un solo paso siguiente: pedir tool(s) o responder en texto. Quien determina que habrá otra llamada es LangGraph (should_continue + el edge tools → our_agent), no el modelo.

El input y output real de cada llamada

Un punto clave: el LLM nunca ve clases de Python como AIMessage o ToolMessage. Esas son abstracciones de LangChain. Lo que realmente viaja a la API es JSON con un campo role:

Clase de LangChain	`role` real
`SystemMessage`	`system`
`HumanMessage`	`user`
`AIMessage`	`assistant`
`ToolMessage`	`tool`

Así se ve la secuencia completa para 5 + 8/12 (con tools add y divide):

Llamada 1 — input:

[
  {"role": "system", "content": "Eres mi asistente de IA..."},
  {"role": "user", "content": "5 + 8/12"}
]

Llamada 1 — output:

{"role": "assistant", "content": "", "tool_calls": [
  {"id": "call_001", "function": {"name": "divide", "arguments": "{\"a\": 8, \"b\": 12}"}}
]}

Llamada 2 — input (todo lo anterior + el resultado de la tool):

[
  {"role": "system", "content": "Eres mi asistente de IA..."},
  {"role": "user", "content": "5 + 8/12"},
  {"role": "assistant", "content": "", "tool_calls": [
    {"id": "call_001", "function": {"name": "divide", "arguments": "{\"a\": 8, \"b\": 12}"}}
  ]},
  {"role": "tool", "tool_call_id": "call_001", "content": "0.6666666666666666"}
]

Llamada 2 — output:

{"role": "assistant", "content": "", "tool_calls": [
  {"id": "call_002", "function": {"name": "add", "arguments": "{\"a\": 5, \"b\": 0.6666666666666666}"}}
]}

Llamada 3 — input (historial completo hasta ahora):

[
  {"role": "system", "content": "Eres mi asistente de IA..."},
  {"role": "user", "content": "5 + 8/12"},
  {"role": "assistant", "content": "", "tool_calls": [{"id": "call_001", "function": {"name": "divide", "arguments": "{\"a\": 8, \"b\": 12}"}}]},
  {"role": "tool", "tool_call_id": "call_001", "content": "0.6666666666666666"},
  {"role": "assistant", "content": "", "tool_calls": [{"id": "call_002", "function": {"name": "add", "arguments": "{\"a\": 5, \"b\": 0.6666666666666666}"}}]},
  {"role": "tool", "tool_call_id": "call_002", "content": "5.666666666666667"}
]

Llamada 3 — output (ya sin tool_calls):

{"role": "assistant", "content": "5 + 8/12 = 5.666666666666667 (aproximadamente 5.67).", "tool_calls": []}

Nota clave: el tool_call_id (call_001, call_002) es el hilo que conecta cada tool call con su respuesta correspondiente — así el modelo sabe cuál ToolMessage responde a cuál petición suya.

Output del modelo vs. input acumulado: quién arma el historial

Algo que vale la pena separar bien: el output del LLM es solo el mensaje nuevo, no el historial repetido. model.invoke(...) te devuelve únicamente el assistant que acaba de generar.

Quien acumula todo es LangGraph, gracias al reducer definido en el estado:

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]

Cuando el nodo hace return {"messages": [response]}, el reducer add_messages no sobreescribe state["messages"] — hace un append. Así, para la siguiente llamada, state["messages"] ya contiene todo lo acumulado hasta ese momento, y model_call vuelve a mandar la lista completa ([system_prompt] + state["messages"]) en cada invocación.

Es la diferencia entre "el modelo te contesta una carta" y "tú guardas copia de cada carta en una carpeta, y le mandas la carpeta completa junto con la carta nueva la próxima vez".

Resumen: el patrón completo

El modelo recibe todo el historial acumulado hasta ese punto (nunca recuerda nada por sí mismo — no tiene memoria entre llamadas).
Con esa información, decide un solo paso: pedir tool(s) para las que ya tiene todos los datos concretos, o responder en texto si no falta nada.
Cada tool call se ejecuta como código Python normal (ToolNode), sin costo de LLM.
LangGraph vuelve a invocar al modelo con el historial actualizado — y el ciclo se repite hasta que la respuesta ya no trae tool_calls.
El número de llamadas al LLM depende de cuántos pasos secuenciales con dependencia de datos tiene la tarea — no de cuántas tools existan en total. Tools independientes se piden en paralelo, en una sola llamada.

Cada llamada al LLM es una petición HTTP real, facturable en tokens, y el costo de entrada crece en cada vuelta porque se reenvía todo el historial acumulado — algo a tener en cuenta al diseñar agentes con muchos pasos encadenados.

DEV Community: Christian Gonzales Komiya

[Spanish] La IA no reemplaza las metodologías ágiles: cambia la forma en que las integramos para transformar los negocios

Ejemplos de evolución metodológica

1. Design Thinking: descubrir problemas sigue siendo fundamental

2. Lean Startup: experimentar nunca había sido tan accesible

3. Agile: los principios se mantienen, pero la ejecución cambia

4. Change Management: la transformación va más allá de adoptar una nueva herramienta

El verdadero cambio es transversal

Una reflexión final

[Spanish] De desarrollar software a transformar negocios: el verdadero valor de la tecnología en la era de la IA

El software como ventaja competitiva está cambiando

El valor se desplaza hacia el conocimiento del negocio

De proveedor de software a socio estratégico

La consultoría también tendrá que diferenciarse

Un ciclo de trabajo orientado a resultados

¿Cuándo ocurrirá este cambio?

La oportunidad

[Spanish] Entrenando un kantoku artificial — Capítulo 3: Nana-Ban, el juego donde vive el kantoku

¿Qué es Nana-Ban?

Por qué Phaser

La física es propia

Dos barras para cada golpe

El juego y el agente

La demo

Dónde se puede jugar

Cómo lo construí con Claude Code

Lo que viene, sin prisa

Gracias por leer

Enlaces

[Spanish] Entrenando un kantoku artificial — Capítulo 2: Saihai, el agente que aprendió (y desaprendió) a dirigir

Primero, ¿qué es Saihai?

El segundo entrenamiento: menos exposición

Una bola que se ofreció

El efecto techo: cuando ya no se ve la mejora

El tercer entrenamiento: la máquina tenía razón

El entrenamiento que aprendió a no atacar

El v4: aprender con examen incluido

De la máquina al criterio: cinco versiones en un día

Lo que Saihai todavía no entiende

Medir sin engañarse

De parte del juego a proyecto propio

Saihai en Hugging Face

Las cifras de hoy

Lo que viene

Enlaces

Próximo capítulo

[Spanish] Entrenando un kantoku artificial — Capítulo 1: por qué no usé una red neuronal

Primero, ¿qué es el gateball?

¿Y qué es el kantoku?

De dónde salió este proyecto

¿Es como un jugador de ajedrez?

Cómo piensa el kantoku artificial

Que la máquina aprenda los pesos

¿Por qué no una red neuronal?

¿Y si le ponemos una GPU?

¿Entonces la red neuronal es peor?

Lo que aprendí en el primer entrenamiento

Próximo capítulo

[Spanish] Un marketplace en producción de costo cero: la arquitectura detrás

El mapa general

Astro + islas de React: velocidad y SEO sin pagar de más

Cloudflare Workers: el servidor que no administras

Supabase: el corazón del sistema

¿Por qué Supabase y no Firebase?

Dónde Firebase gana (seamos honestos)

Detalles pequeños que ahorran dinero

¿Cuánto cuesta realmente?

Dónde ayudó Claude Code

Lo que Claude Code no hace por ti

Lecciones que me llevo

Para cerrar

[Spanish] ¿Cómo deshacer una operación en microservicios? El patrón Saga explicado con Java

1. El problema: una operación de negocio, varios servicios

2. Por qué no basta con hacer ROLLBACK

3. La idea de Saga: compensar, no viajar al pasado

4. Un ejemplo con Java y Spring Boot

¿Cómo sería la compensación en OrderService?

5. ¿Qué pasa si falla la compensación?

6. Orquestación y coreografía

Orquestación

2. Por qué no basta con hacer `ROLLBACK`

¿Cómo sería la compensación en `OrderService`?