DEV Community: Jesus Corredor

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.