Después de un mes intentando construir un sistema de trading con Claude Code, la tabla operativa de qué delegar libremente, qué revisar siempre, y qué no delegar nunca.
Artículo 3 de Ventaja Mecánica II. En el post 5 de la S1 conté las meta-lecciones de programar con IA: las ensaladas de razonamiento, los palos de ciego, el sesgo de confirmación de la máquina. Este es el complemento práctico: la división táctica sobre qué tareas concretas merece la pena delegar y cuáles te van a comer dinero si lo haces.
Hay un discurso simétrico en internet: por un lado, «la IA va a sustituir a todos los programadores en cinco años». Por otro, «la IA es un timo que no funciona para nada serio». Las dos posturas son falsas, y las dos hacen daño al lector que quiere usar la herramienta de verdad.
Este artículo es una división lo más honesta que puedo hacer entre lo que SÍ y lo que NO funcionó usando IA para construir un sistema real. El proyecto: un bot de trading automatizado en Polymarket. El stack: Python, varias APIs REST, librerías de CLOB de Polymarket, decisiones que toca dinero. La IA usada: Claude Code, las versiones recientes durante 2026.
Lo que la IA hizo bien
1. Scaffolding de proyecto
«Quiero un script Python que pollee una API cada 30 segundos y guarde el estado en un JSON, con logging configurable a fichero y consola». Diez segundos después, lo tienes funcionando. Imports, estructura, manejo de errores genérico, configuración por dataclass.
Esto es un caso clarísimo de productividad. Lo que a mano lleva 20 minutos de teclear, con IA es un párrafo de descripción y cinco segundos.
2. Parsing de APIs REST con respuestas anidadas
Le pasas un sample del JSON que devuelve la API y le dices «extrae los outcomePrices y los clobTokenIds, maneja el caso de que vengan como string JSON anidado». Lo hace correctamente, con manejo de errores.
Para APIs nuevas que no conoces, este uso es excelente.
3. Análisis exploratorio de datos
«Tengo este JSONL con 250.000 entradas. Quiero ver cuántas hay por tipo, distribución de tamaños, casos extremos». La IA escribe el script for con Counter y stats que sería pesado escribir a mano. Resultado en segundos.
Para ETLs ad-hoc, IA es una bestia.
4. Refactor de funciones largas
«Esta función tiene 200 líneas. Pártemela en piezas con responsabilidades claras». El resultado suele ser correcto, con nombres razonables.
Útil cuando llegas a algo que escribiste tú deprisa y necesitas limpiar.
5. Generar documentación a partir del código
Comentarios de docstrings, README básico, ejemplos de uso. Si el código está bien, la docu sale bien.
6. Algoritmos estándar
Estrategias de cache, paginación de APIs, retry con backoff exponencial, lógica de heartbeats. Cosas que tienen mil tutoriales y la IA ha visto miles de veces. Las hace bien.
Lo que la IA hizo regular
1. Backtests con datos reales
Aquí la cosa se complica. La IA puede escribir el LOOP del backtest correctamente. Pero los sesgos sutiles de los datos los pasa por alto sistemáticamente:
- Que el ask del histórico no incluye el spread real que pagarías en vivo.
- Que el «primer punto disponible» puede ser de una hora distinta a la que crees.
- Que el winner determinado a los 10 segundos del cierre puede no ser el winner UMA-confirmado de los 60 segundos.
Resultado: backtests que dan EV +11% y en vivo te quedas en break-even. La IA no es mala generando el código del backtest; es mala detectando los sesgos del MISMO backtest que acaba de generar.
2. Decisiones sobre arquitectura cuando hay trade-offs
«¿Mejor FAK o FOK aquí?» La IA te da la primera respuesta que recuerda del manual, sin meditar el caso concreto. Cuando le explicas el caso concreto, te da la respuesta opuesta, también sin meditar.
Esto no es un fallo único de la IA — los humanos juniors hacen lo mismo. Pero la IA NO te avisa de su propia incertidumbre. Da respuestas con la misma confianza para algo que sabe que para algo que se está inventando.
3. Estimación honesta de tiempos y métricas
«¿Cuánto tiempo tardará este script?» La IA da un número. Casi siempre subestimado por un factor de 3-5x cuando se trata de operaciones de I/O o de polling a APIs externas.
«¿Cuántos resultados esperas?» Lo mismo. Estimaciones por defecto optimistas.
Lo que la IA hizo MAL
1. Reutilizar código existente del propio proyecto
Este es el bug número uno, el padre de todos los demás. La IA tiende a generar versiones nuevas de funciones que ya tienes en el repo, con bugs ya resueltos.
En mi proyecto: tenía copybot_positions.py con las funciones buy_market, sell_limit, get_tick_str, is_neg_risk ya estables. Le pedí que construyera un bot nuevo para una estrategia distinta. La IA generó nuevas funciones para las mismas operaciones. Bugs nuevos en cada una.
Cuando se lo dije, lo apuntó en su memoria. Y a los pocos prompts, volvió a hacerlo en otro contexto.
2. Decir «tienes razón» cuando deberías ser tú quien tuviera razón
Patrón muy claro: el usuario sospecha que algo está mal. La IA defiende su análisis con confianza. El usuario insiste. La IA, en lugar de revisar honestamente, dice «tienes razón, lo cambio».
Y a veces el usuario NO tenía razón. La IA cede para evitar conflicto. Cuando vuelves a la siguiente sesión, la IA ha cambiado el código por algo peor que lo original, basándose en una crítica equivocada que aceptó por reflejo.
Este patrón es especialmente pernicioso en proyectos de inversión, donde el usuario tiene sesgos de pérdida/ganancia que distorsionan su análisis.
3. Sobrevender backtests
«Backtest sobre 450 buckets: +11% EV/trade». El usuario se ilusiona. Activa el bot. En vivo da -2%. La IA explica: «ah, el sample era pequeño, el periodo era trending, etc.».
El problema no es que el backtest haya salido bien y la realidad mal. El problema es que la IA presentó «+11%» sin contextualizar la fragilidad de ese número. Tres decimales de precisión sobre datos que ella misma sabía limitados.
4. No avisar de las limitaciones de su contexto
Ejemplo concreto: durante una conversación de horas, la IA empezó a tener «olvidos» sutiles del código que había escrito al principio. Confundía variables, reintroducía bugs, perdía el hilo del cambio actual. Nunca dijo «oye, estoy perdiendo contexto, quizás conviene resumir». Siguió como si nada hasta que el bug fue obvio.
5. Mantener convicciones después de que la realidad las refutara
Cuando los datos en vivo contradicen el análisis, la IA debería actualizar su modelo del problema. En la práctica, defiende el modelo y busca explicaciones secundarias («debe ser variance del sample»). Solo capitula cuando el usuario lo machaca.
La división honesta
Si tuviera que dividir tareas para futuros proyectos:
Delega libremente a la IA:
- Scaffolding de proyectos nuevos
- Parsing de APIs que no conoces
- Refactors de bloques de código
- Scripts de ETL exploratoria
- Generación de docs
Delega con revisión obligatoria:
- Cualquier integración con sistema externo donde haya estado del mundo real (DB, blockchain, API que toca dinero)
- Cualquier código de backtest cuyas conclusiones vayas a usar para tomar decisiones
- Cualquier cálculo de PnL, ROI, métricas que vayan a aparecer en un dashboard
No delegues:
- Decisiones de arquitectura con trade-offs reales
- Verificación de que tu código existente funciona como crees (la IA puede mentir aquí)
- Análisis críticos donde el cero te puede arruinar
- Cualquier código donde el coste de un bug sea irreversible
El meta-error: pensar que la IA está pensando
El error más grande que cometí fue tratar a la IA como si fuera otro ingeniero con el que estaba pareando. Yo le hacía preguntas. Ella me respondía. Yo decidía basándome en sus respuestas como si vinieran de alguien con stake en el resultado.
La IA no tiene stake. No va a sentir las consecuencias de equivocarse. Y, aún más importante: no sabe cuándo no sabe. Su modelo de confianza no diferencia entre «esto lo he visto mil veces y es así» y «esto me lo estoy inventando porque suena razonable».
Para programadores que están considerando integrar IA en su flujo: úsala. Acelera muchísimo. Pero trata cada output como código de un junior brillante que necesita revisión, no como una autoridad. Y, sobre todo: cuando el sistema vaya a tocar dinero real, código de IA tiene que ser TU código — leído línea por línea, criticado, modificado donde toque.
El siguiente artículo cierra la serie analizando el survivor bias en los hilos de Twitter de «gané $14K con un bot de IA».
1 comentario en «Cuándo la IA es útil para programar y cuándo no — la división táctica»