Blog
Escritos sobre backend, arquitectura y desarrollo de producto.
Construí un sistema que decide si una migración industrial se puede cotizar a precio fijo. Sus suites estuvieron en verde durante días sobre datos que ningún usuario podría haber producido. Cuatro formas de aprobar sin haber revisado nada.
Construí un medidor local para saber qué me cuestan los agentes de IA. Las cuatro trampas que encontré no eran de IA: eran de contabilidad. Acumulados que no se suman, caché contada dos veces y filtros que cortan por el sitio equivocado.
Un backend transaccional no falla el día que se cae. Falla el día que funciona dos veces. Idempotencia, doble partida y consistencia cuando una operación cruza tres sistemas que no comparten transacción.
El script terminó en verde, el archivo llegó a tiempo y cada fila decía "desconocido". No hubo excepción, no hubo log rojo. El fallo peor es el que no se queja.
No puedes pedirle a un negocio que deje de cobrar un fin de semana mientras reescribes su núcleo. Shadow-first: el camino nuevo corre en paralelo, sin tocar nada, hasta que demuestra que coincide.
Empecé con la robótica como descanso del trabajo. Resultó ser el mismo problema con otra ropa: un motor que ya giró y un pago que ya salió tienen exactamente el mismo botón de deshacer, que es ninguno.
El módulo estaba construido y probado. Solo faltaba encenderlo. La pregunta que no estaba en el ticket era qué se mueve en la primera corrida.
Un helper decidió que el punto de "1.500" era separador de miles. El error se multiplicó por mil en un camino de dinero. Y había un test verde que garantizaba ese comportamiento.
Construyo sistemas de pagos con agentes de IA todos los días. Lo que más me ha enseñado no es lo que pueden hacer, sino dónde no los dejo decidir.
Los payouts dejaron de despacharse. No hubo excepción, ni alerta, ni una sola línea roja en los logs: la flag que los gobernaba apuntaba a una key que ya no existía.
Un cliente tenía el 97% de su saldo bloqueado y cero operaciones abiertas. No era un bug de saldo: era un bug de definición.
El proveedor decía que le debíamos seis cifras. Nuestros sistemas decían que no le debíamos nada. La deuda no existía en ninguna parte.
Cómo uso Python para leer sensores, decidir y mover un robot — del bucle de control a la simulación.
La robótica enseña a pensar en sistemas, a fallar rápido y a respetar la realidad. Habilidades que uso cada día.
El valor no está en el modelo, está en la decisión que habilita. Mi enfoque práctico de ciencia de datos con Python.
De píxeles a decisiones: cómo la visión por computación permite a un robot entender el mundo.
Estado, riesgos y proyección: las tres señales que reviso para que un proyecto llegue a tiempo sin sorpresas.