DEV Community: Jesus Corredor

El día que descubrí que mi bot no tenía las protecciones que creía tener

Jesus Corredor — Sun, 04 Oct 2026 21:08:26 +0000

Diario de un bot que opera con dinero real — Entrada #3

Durante varios días, mi bot de trading creyó tener órdenes de stop-loss que en realidad no existían en el exchange.

No fallaban de forma visible. En los registros, cada posición tenía su stop "gestionado". El bot estaba convencido de que cada operación tenía su red de seguridad. Pero esa red no estaba donde debía estar: en Binance.

En ese tiempo, posiciones apalancadas —donde una caída fuerte puede liquidarte— operaron sin la protección que yo creía activa. Si el bot se caía en el momento equivocado, no había nada abajo.

Esta es la tercera entrada de la serie, y la más inquietante. No fue un bug ruidoso ni un componente fantasma. Fue peor: la plataforma cambió las reglas —lo anunció, pero yo no lo vi— y mi bot siguió reportando que todo estaba bajo control mientras, en el exchange, las posiciones corrían desnudas.

El síntoma: un error que no debería existir

Todo comenzó con un mensaje nuevo en los registros al intentar colocar un stop:
HTTP 400 | code: -4120 | Order type not supported for this endpoint.
Please use the Algo Order API endpoints instead.
Mi código enviaba la orden de la forma que, según tutoriales y ejemplos, era la correcta. Entonces, ¿por qué Binance rechazaba algo que medio internet daba por válido?

La pista incómoda: mi código estaba bien escrito, pero el contrato había cambiado. Cuando tu petición es correcta y aun así la rechazan, el problema no está solo en tu lado: está en que las reglas del otro extremo ya no son las mismas.
La investigación: lo que el bot creía vs. lo que pasaba

Binance había migrado las órdenes condicionales (stop-loss, take-profit, trailing stop) al nuevo "Algo Order API". El endpoint viejo quedó bloqueado para esos casos. El cambio estaba en el changelog oficial semanas antes, pero yo no lo vi.

(Nota: no fui el único en chocar con esto. Cuando Binance hizo el cambio —a finales de 2025—, frameworks de trading enteros como Freqtrade y nautilus_trader amanecieron con exactamente este error, documentado en sus repos de GitHub. En mi caso llegué tarde a la fiesta: mi bot empezó a operar después del cambio, así que heredé el problema sin saberlo. Mi código enviaba las órdenes al endpoint viejo —que ya no servía para stops— desde el primer día, y yo creía que las protecciones se colocaban. Hasta que un día revisé de verdad y descubrí que nunca habían estado ahí.)

Lo más grave no era el error -4120 visible. Era lo que pasaba por debajo: el bot sí calculaba y llevaba el stop en su propio estado interno —tenía su nivel de salida bien definido—, pero ese stop vivía solo en la memoria del bot, no en el exchange. En la interfaz de Binance, el campo de protección de esas posiciones decía, literalmente, -- / --. Mientras el bot corriera, la gestión interna disimulaba el problema. Pero un reinicio, una caída, un corte de red en el momento equivocado, y la posición se quedaba sin absolutamente nada que la protegiera. Yo creía tener una red de seguridad en dos capas; en realidad tenía media.
Por qué esto es peor que un bug normal

Un bug propio lo puedes leer, probar y arreglar. Pero cuando dependes de una API externa, una parte de tu sistema vive en un servidor que no controlas. Pueden cambiar un endpoint, un parámetro o una validación, y tu código —sin modificar una sola línea— empieza a comportarse distinto.

El fallo más peligroso no es el error claro, sino la falsa confianza: cuando crees que tienes una protección y en realidad no está donde importa. Un stop que vive solo en tu código, pero no en el exchange, es exactamente eso — una red pintada en el suelo.
El fix: migrar y verificar de verdad

La solución tuvo dos pasos.

Migrar al nuevo endpoint: reescribir la lógica de stops y trailing para usar /algoOrder, con los parámetros que ahora espera. Marqué cada cambio con la etiqueta [ALGO-MIGRATION] para que en el futuro yo —o quien lea el código— sepa qué se movió y por qué. Para las posiciones que ya estaban corriendo sin stop nativo, escribí un script que las recorrió una por una y les colocó retroactivamente la protección que les faltaba.

Verificar la existencia real de la orden: dejar de confiar en que "el bot lo tiene gestionado" o en que "no dio error" signifique que la protección existe. Ahora el bot consulta directamente al exchange si la orden está viva. Solo cuando Binance confirma que el stop está ahí, el bot lo da por colocado. Hay una diferencia enorme entre "mi petición no dio error" y "la orden está viva en el exchange". El bug vivía justo en esa brecha.

La lección para llevarte

"No dio error" no es lo mismo que "funcionó". Verifica el efecto, no la ausencia de queja.

Si construyes sobre APIs de terceros —y hoy casi todo software lo hace—, esta historia deja tres recordatorios:

No controlas tus dependencias externas. El código que llama a una API vive a medias en un servidor ajeno. Pueden cambiar las reglas —a veces lo avisan en un changelog que nadie lee, a veces el aviso pasa desapercibido— y tu código intacto empezará a comportarse distinto. Cuando el comportamiento cambia pero tu código no, mira hacia afuera: al otro extremo de la conexión, y a los canales donde esa plataforma anuncia sus cambios.

Lee los changelogs de tu exchange — no hacerlo es un error muy común. Binance (y cualquier exchange serio) publica sus cambios de API en un changelog oficial, a veces con semanas de aviso. Este cambio estaba anunciado ahí. Pero casi nadie lo lee: montas el bot, funciona, y te olvidas de que del otro lado hay un equipo cambiando cosas. Yo no lo leía. Freqtrade y nautilus_trader tienen equipos enteros y aun así los pilló. La información estaba disponible; solo que nadie la miró a tiempo. Revisar el changelog cada cierto tiempo —o, mejor, automatizar una alerta cuando cambie— convierte una sorpresa silenciosa en un aviso con margen para reaccionar.

Verifica el efecto, no la respuesta. No asumas que algo se hizo porque la llamada no lanzó una excepción, ni porque tu propio código "lo tiene controlado". Si la operación importa —una orden de protección, un pago, un cambio de permisos— confirma que el efecto realmente ocurrió en el sistema externo, no en tu versión de la realidad.

Ese día entendí que lo más frágil de mi sistema no era mi código, sino el supuesto de que la API seguiría igual que la última vez que la revisé —y que mi estado interno reflejaba el del exchange. Ninguna de las dos cosas era cierta. Y mi bot había estado operando con una red de seguridad imaginaria.

En la próxima entrada empieza la parte más incómoda de todo el viaje. Descubrí que mi herramienta de backtest —la que usaba para decidir si una estrategia servía— me estaba mintiendo. Tenía un "edge" fabuloso… en un horario en el que el bot ni siquiera operaba. Cómo una sola línea mal ajustada en el tiempo puede convertir meses de "resultados prometedores" en un espejismo.

¿Alguna vez una API de terceros cambió bajo tus pies y te enteraste tarde? ¿Cómo lo detectaste? Cuéntamelo en los comentarios.

Por qué getenv("X") or default es una trampa

Jesus Corredor — Sun, 13 Sep 2026 20:10:05 +0000

Diario de un bot que opera con dinero real — Entrada #2:

En la entrada anterior conté cómo un componente de mi sistema estuvo meses operando con un capital que nadie le asignó — un "par fantasma" que creía haber eliminado y seguía vivo. Toda la causa cabía en una línea de código. Una línea que probablemente tienes en tu proyecto ahora mismo:

Se ve inofensiva. Se ve hasta responsable — "si la variable no está, uso un valor por defecto y el programa no se rompe". Ese razonamiento es la trampa. Te cuento por qué.

Qué hace ese or

En cristiano: "usa el valor de la variable; si no hay valor, usa 133".

Suena bien. El problema es qué cuenta como "no hay valor". Si por accidente borras esa variable —un despliegue que pisa el archivo, un backup que restauras, un typo en el nombre— el programa no se detiene, no da error, no avisa. Simplemente empieza a usar 133 como si alguien lo hubiera decidido.

En mi caso, ese 133 era el capital con el que un bot operaba con dinero real. La variable que debía definirlo desapareció en un restore, y el default la reemplazó en silencio. El sistema no falló ruidosamente. Falló callado — que es peor, porque no deja rastro y lo descubres meses después.

La parte que engaña de verdad: el valor cero

Aquí está el detalle que casi me muerde. Supón que quieres desactivar ese componente poniendo su valor en cero. Lo natural: defines la variable como 0. Pues bien — dependiendo de dónde pongas el or, obtienes cosas opuestas:

En el segundo caso pusiste 0 y el programa te devolvió 133. ¿Por qué? Porque para el or, el número 0 cuenta como "vacío" (en jerga: es falsy). Entonces el or lo descarta y salta al default. Intentaste apagar algo poniéndolo en cero, y conseguiste justo lo contrario.

Lo peligroso: este bug solo aparece con el valor cero. Todos tus tests con valores normales pasan. El fallo espera callado hasta que alguien prueba el caso límite.

La lección de fondo, en una frase: or no distingue entre "no hay valor" y "el valor es cero". Para configuración, esas dos cosas son totalmente distintas — pero or las trata igual. Ahí vive el bug.

No es solo Python

Si usas otro lenguaje, el mismo patrón te espera con otra cara. En JavaScript, process.env.VAR || "133" tiene el problema idéntico con 0, "" y false. (Por eso JS moderno introdujo ??, el nullish coalescing, que solo cae al default cuando el valor es realmente nulo — creado justo para arreglar esto.) En Go se disfraza de if val == "" { val = "133" }, mezclando "no existe" con "cadena vacía".

El patrón es universal porque el impulso que lo crea es universal: quiero un valor sensato si la config falla. Buena intención. Mala ejecución.

Qué hacer en su lugar

La regla: si un valor es importante, su ausencia no debe ser silenciosa. Tres opciones, de más a menos estricta:

1. Si es obligatorio, que el programa grite. No inventes default; exige que exista.

Un programa que se niega a arrancar sin su config es mucho más seguro que uno que arranca con un valor fantasma.

2. Si quieres un default, usa el argumento correcto (no or*)*.

El segundo argumento de getenv solo actúa cuando la variable no existe — no cuando vale cero. Que es lo que de verdad querías.

3. Si el default es a propósito, hazlo visible.

Así, si un restore borra la variable, no tienes un bug silencioso: tienes una línea en el log que te dice exactamente qué pasó.

Esto no es solo trading

Mi caso fue un bot con capital real, pero el patrón vive en cualquier sistema donde un valor equivocado importa: un límite de acceso que cae a un default permisivo, una configuración de seguridad que desaparece y se reemplaza sin avisar, un umbral que silenciosamente vuelve a un valor de fábrica. En todos, un default silencioso convierte "se borró la config" en "el sistema hace algo que nadie pidió" — sin dejar rastro.

La lección para llevarte

Un default silencioso cambia un fallo que ves por uno que no ves.

El getenv("X") or default parece robustez, pero es fragilidad disfrazada: en vez de detenerse y avisarte cuando falta algo, sigue adelante con un valor que nadie decidió.

Un programa que se niega a arrancar te cuesta cinco minutos. Uno que arranca con el valor equivocado te cuesta encontrarlo cuando ya hizo daño. En mi caso, ese cambio de una línea fue la diferencia entre semanas de fuga silenciosa y un arranque limpio.

Los valores por defecto no son gratis. Son una decisión sobre qué pasa cuando el mundo no es como esperabas — y esa decisión merece más que un or al final de una línea.

En la próxima entrada cambio de escenario: Binance movió silenciosamente uno de sus endpoints de la API, y mi bot llevaba días colocando órdenes de protección que en realidad no existían. Cómo se detecta que una plataforma de la que dependes cambió las reglas sin avisar — y cómo migrar sin quedarte expuesto.

¿Cuál es el default silencioso más peligroso que has encontrado en código ajeno (o propio)? Los leo en los comentarios.

"El par fantasma: cómo un bot operaba con capital que nadie le asignó"

Jesus Corredor — Sat, 29 Aug 2026 02:52:20 +0000

Diario de un bot que opera con dinero real — Entrada #1:

Hace unos meses eliminé un par de trading de mi bot de futuros. O eso creía.

La semana pasada, durante una auditoría de rutina, encontré ese mismo par abriendo posiciones, reservando capital, y bloqueando a los demás. No lo había resucitado. Nunca se había ido.

Esta es la primera de una serie de historias reales sobre un sistema que opera con dinero de verdad — donde los bugs no son un test que falla, sino capital moviéndose. Empiezo por esta: un bug silencioso que vivió meses en producción, y por qué "eliminar" algo de una forma frágil es peor que no eliminarlo.

El síntoma

Estaba revisando los logs del bot cuando una línea me detuvo:

[PAR-X] SNAP | ... | cap=135.34 | lev=3× | pos=FLAT

Ese par no debía estar ahí. Lo había sacado de la operación hacía meses. Y sin embargo, ahí estaba, con un capital asignado de ~$135 que yo no recordaba haber configurado. Peor: un par de ciclos después, otro par intentó abrir una posición y falló:

[PAR-X] ENTRY SKIP | USDT insuficiente: free=130.98 < needed=138.04

El par fantasma estaba acaparando capital, y por su culpa los pares que sí debían operar se quedaban sin fondos. Un componente que creía muerto competía por recursos con los vivos.

La investigación

Lo primero fue ir a la fuente de configuración. El bot lee el capital de cada par desde un archivo de entorno (.env). Busqué la variable de ese par:

Vacío. La variable no existía en el .env. Entonces, ¿de dónde salían los $135?

La respuesta estaba en el código. El bot arma su lista de pares desde un diccionario de configuración, y cada par lee su capital así:

Ahí estaba el problema. os.getenv("PAR_X_USDT") devuelve None cuando la variable no existe. Y None or "133" evalúa a "133". El bot, al no encontrar la variable en el .env, caía a un valor por defecto hardcodeado de $133 que alguien (yo, meses atrás) había dejado en el código como fallback.

La causa raíz — y aquí está la lección real

El bug no era solo el fallback. Era cómo había "eliminado" el par meses atrás.

En su momento, para desactivarlo, había puesto su capital en cero en el .env (PAR_X_USDT=0). Funcionó… hasta que un día restauré un backup del código por otra razón. Ese backup era anterior a mi cambio, o el .env se sobrescribió en el proceso. La variable desapareció. Y sin la variable, el código volvió a caer al fallback de $133.

El par nunca estuvo eliminado de verdad. Seguía en el diccionario de configuración que el bot recorre en cada ciclo. Yo solo le había bajado el capital por una vía frágil — una variable de entorno — que un restore podía borrar. La eliminación real habría sido sacarlo del diccionario de configuración, en el código. No lo hice. Y el sistema, silenciosamente, lo revivió.

El fix

La corrección definitiva fue eliminar el bloque del par directamente del diccionario de configuración en el código, no del .env. Con el protocolo de siempre:

Verificar que el par no tuviera posición abierta (revisar su archivo de estado).
Backup del archivo con timestamp.
Eliminar el bloque de configuración.
Validar la sintaxis (python3 -c "import ast; ast.parse(...)").
Confirmar con grep que el par ya no aparecía en ningún lado.
Reinicio manual.

Tras el reinicio, el banner de arranque lo confirmó: el bot ahora recorría solo los pares correctos. El fantasma se había ido de verdad.

El cuerpo del delito

Quedó un detalle que cierra la historia. Tras eliminar el par, su archivo de estado local quedó huérfano en el directorio. Lo abrí. Ahí seguía, congelado, con su última sesión registrada:

initial_capital: 133. La evidencia física del fallback, escrita en disco. El par había estado operando todo ese tiempo con un capital que ningún archivo de configuración le asignó — solo un valor por defecto olvidado en una línea de código.

La lección para llevarte

Antes de las lecciones técnicas, la pregunta que me perseguía mientras lo corregía: ¿cómo sobrevivió esto a las auditorías anteriores? Había revisado este bot varias veces. ¿Cómo no lo vi?

La respuesta me pareció más valiosa que el bug en sí. No lo detecté antes porque estaba auditando el código, y el código estaba bien. El fallback or "133" no es un error de sintaxis, ni una excepción, ni nada que un grep de "bug" encuentre. Es una línea perfectamente válida que hace exactamente lo que dice — el problema no vivía en el código, vivía en la brecha entre el código y la configuración. El .env decía una cosa (nada), el código asumía otra (un default), y ninguna revisión de un solo lado podía ver la contradicción, porque cada lado, por separado, era correcto.

El bug solo era visible cruzando ambos contra lo que el sistema hacía en vivo — leyendo los logs de ejecución real y preguntándose "¿por qué este par tiene capital si yo no se lo di?". Lo encontré no porque revisara mejor el código, sino porque miré lo que el bot realmente estaba haciendo y no cuadraba con lo que yo creía haber configurado.

Esa es la lección de fondo: una auditoría que solo lee el código estático nunca atrapa un bug de configuración fantasma. Los sistemas mienten por omisión. La verdad no está en el código ni en la config por separado, sino en el comportamiento observado. Si algo opera distinto de como crees haberlo configurado, esa discrepancia es el bug, aunque cada archivo por separado se vea impecable.

De ahí, tres trampas concretas que me llevo:

Los defaults hardcodeados son deuda oculta. Un os.getenv("X") or "133" parece defensivo, pero convierte la ausencia de configuración en un valor silencioso. Si la variable desaparece, el sistema no se detiene ni avisa: sigue con un número que nadie decidió.

Desactivar por la vía frágil no es desactivar. Bajar un valor en un .env es reversible por accidente — un restore, una sobrescritura, un despliegue. Si algo debe estar fuera, sácalo de la estructura que el sistema recorre, no de un parámetro que la alimenta.

Un backup puede resucitar tus bugs. Restaurar código viejo no solo revierte features; revierte fixes. Cada restore debería venir con la pregunta: ¿qué correcciones posteriores estoy deshaciendo con esto?

El par fantasma no me costó dinero — estaba en FLAT cuando lo encontré. Pero pudo haberlo hecho. Y lo más inquietante no es el bug en sí, sino cuánto tiempo vivió sin que ninguna auditoría lo viera. A veces lo más peligroso no es lo que falla ruidosamente, sino lo que funciona en silencio haciendo algo que no autorizaste.

En la próxima entrada desarmo la línea exacta que causó todo esto ese inocente os.getenv("X") or default — y te muestro por qué es una trampa que probablemente tienes en tu propio código ahora mismo. Incluido el caso que casi me muerde a mí: cómo intentar apagar algo poniéndolo en cero puede encenderlo.

¿Te ha pasado encontrar un componente haciendo algo que juraste haber desactivado? Cuéntamelo en los comentarios — colecciono estas historias.

Empecé este bot por desconfianza, no por avaricia.

Jesus Corredor — Sat, 22 Aug 2026 15:13:11 +0000

Diario de un bot que opera con dinero real — Entrada #0: el origen

Todo empezó con un tuit.

Uno de esos que seguramente también has visto: una captura de una wallet, "$100 convertidos en $10.000 en 24 horas con este bot de trading", flechas verdes, emojis de cohetes, y un "sígueme para más". Debajo, cientos de likes y gente pidiendo el enlace.

Mi primera reacción no fue "quiero eso". Fue "eso es mentira".

Y no hace falta ser matemático para verlo. Un retorno del 10.000% en un día no es una estrategia — es un billete de lotería premiado que alguien presenta como si fuera un método repetible. Si de verdad tuvieras un sistema que multiplica tu dinero por cien cada 24 horas, no lo estarías publicando en X pidiendo likes. Lo estarías usando en silencio hasta comprar una isla. El que regala el mapa del tesoro es porque el tesoro no existe — el verdadero producto que se vende en esos tuits no es el bot: eres tú, tu like, tu follow, tu atención.

Así que no le di like. Pero me quedé pensando.

La pregunta que sí valía la pena

Descartado el humo, quedaba una pregunta honesta debajo: despojado de la mentira del 10.000%, ¿hay algo real ahí?

Porque los bots de trading existen. La automatización de estrategias es legítima. Los mercados operan 24/7 y un programa no duerme ni entra en pánico. La idea de fondo —dejar que un sistema ejecute una estrategia con disciplina, sin la emoción que arruina las decisiones humanas— no es una estafa. La estafa es el número. La estafa es prometer un retorno imposible para vender seguidores.

Entonces me hice la pregunta que inició todo esto: ¿qué pasa si alguien escéptico construye un bot de trading de verdad, con expectativas sobrias, y documenta la verdad completa — incluida la parte donde todavía no sabe si funciona?

Esa es la serie que estás empezando a leer.

Lo que es, y lo que no es

Para que no haya malentendidos, porque tú y yo ya sabemos cómo suele terminar este tipo de contenido:

Esto no es un tutorial de "hazte rico". No voy a mostrarte una wallet inflada. No hay enlace de afiliado, no hay curso al final, no voy a decirte que copies mi estrategia y te retires en un año.

Esto sí es el registro honesto de construir un sistema real que mueve dinero real: los bugs que encontré (algunos que me pusieron los pelos de punta), las auditorías, las decisiones tomadas con datos en vez de con ilusión, y los errores que documenté justamente para no repetirlos.

Y aquí viene la parte que ningún tuit de captura de wallet te va a decir jamás: al momento de escribir esto, mi bot no ha demostrado que gane dinero de forma sostenida. Tiene meses de trabajo de ingeniería sólida detrás, sobrevive a fallos que tumbarían a otros, y hay evidencia de que su estrategia podría tener una ventaja real. Pero "podría" no es "tiene". Estoy en pleno proceso de validar, con dinero real y en vivo, si esa ventaja existe de verdad o si es un espejismo de los datos históricos.

Eso es lo más honesto que puedo ofrecerte, y es exactamente lo contrario del tuit que me trajo aquí. El estafador te vende certeza que no tiene. Yo te ofrezco un proceso honesto cuyo desenlace ni yo conozco todavía.

Por qué escribo esto

Porque el espacio está tan lleno de humo que la verdad, por aburrida que sea a veces, es refrescante.

Cada entrada de esta serie es un post-mortem real: algo que salió mal, cómo lo investigué, qué aprendí. No hay finales felices garantizados. Hay un componente que operó meses con dinero que nadie le asignó. Hay protecciones que el bot creía tener y no tenía. Hay una fuga silenciosa que tardé meses en detectar. Y hay decisiones —como cerrar proyectos que no funcionaban— tomadas sin dejar que el orgullo o el dinero ya invertido nublaran el juicio.

Si buscabas el bot que convierte $100 en $10.000, esta no es tu serie, y con cariño te digo que esa serie no existe en ningún lado — solo existe el tuit que te la promete.

Pero si te interesa cómo se construye de verdad un sistema que opera con dinero, con toda la honestidad de sus errores y la incertidumbre honesta de su resultado, quédate. Empecé esto por desconfianza. Y resulta que la desconfianza, bien usada, es el mejor punto de partida para construir algo real.
En la próxima entrada empieza lo bueno: cómo encontré un componente de mi bot operando con un capital que nadie le asignó — un "par fantasma" que creía haber eliminado meses atrás, y que seguía vivo, acaparando recursos, escondido a plena vista.

¿Tú también llegaste a los bots de trading a través de una promesa que sabías que era falsa? ¿Qué te hizo dudar? Cuéntamelo en los comentarios.