🎭 El mito de «piensa por sí solo para siempre»
¿Eres nuevo aquí? Autocorrección es la capacidad del agente para detectar un error e intentarlo de nuevo con un ajuste, sin que tengas que decirle exactamente qué corregir. Es real, pero a menudo se presenta (en videos y anuncios de productos) como algo más grande de lo que es: la idea de una IA que «piensa por su cuenta para siempre» y lo corrige todo, todo el tiempo y sin límites. Este módulo separa los hechos técnicos de la exageración de marketing.
La verdad tiene una línea divisoria muy clara: hay una fase en la que el agente realmente intenta, se equivoca y corrige de forma flexible, y una fase siguiente en la que empieza a comportarse como cualquier automatización tradicional, siguiendo un script fijo. Confundir las dos fases es el origen de la mayoría de las expectativas incumplidas sobre la «IA que se cuida sola».
💡 Concepto principal
La autocorrección tiene un lugar y un momento: ocurre DURANTE la creación, bajo tu control. Después de publicar, el comportamiento queda fijo.
¿Por qué convence tanto esa exageración? Porque la demostración más impresionante que existe es justamente ver al agente equivocarse y recuperarse por sí solo, en vivo, frente a ti. Es un efecto casi mágico —y es real, lo que hace fácil generalizar demasiado a partir de él. El error no está en creer que la autocorrección existe; está en creer que es una propiedad permanente del sistema publicado, cuando en realidad es una propiedad de la sesión de trabajo (el período en que Claude Code está abierto, funcionando, con un agente activo que lee tus mensajes y decide los siguientes pasos).
Piensa en dos situaciones cotidianas de alguien que usa este curso. En la primera, estás creando un workflow que descarga facturas de un portal y las organiza en una hoja de cálculo; el portal cambia el texto de un botón de «Baixar» a «Download» en medio de la prueba, el agente intenta usar el texto anterior, falla, lee el error, vuelve a intentarlo con el texto nuevo y sigue adelante: todo esto en segundos, mientras tú observas. En la segundo, ese mismo workflow ya está publicado y se ejecuta cada madrugada, sin que nadie lo supervise; meses después, el portal vuelve a cambiar y el workflow simplemente deja de funcionar, sin avisar, sin intentar un texto alternativo, sin «arreglárselas». Las dos situaciones implican el mismo tipo de cambio. El resultado es opuesto porque el contexto es opuesto.
🔨 Durante la construcción: lo intenta, falla, corrige
Mientras estás creando algo en Claude Code —como en los módulos «Build» de este curso—, el agente está, de hecho, en un modo flexible: intenta un paso, si hay un error lee el mensaje, ajusta el enfoque y vuelve a intentarlo. Esto puede ocurrir varias veces en la misma sesión hasta que el resultado quede bien. Esta fase es la que alimenta la fama de la «IA que se corrige sola» y, en este contexto, es verdad.
Ejemplo de lo que sucede "por debajo" durante la construcción:
1ª tentativa: comando falha (arquivo não encontrado)
→ agente lê o erro, percebe o nome do arquivo estava errado
2ª tentativa: corrige o nome, comando roda
→ resultado bate com o esperado
→ segue para o próximo passo🔍 Por dentro
- Ensayo-error-corrección: el mismo ciclo del módulo 1.2, pero centrado en recuperarse de un error específico.
- Con tú al mando: esta fase todavía es supervisada: estás ahí, mirando y con la posibilidad de interrumpir.
- Costo por intento: cada nuevo intento consume tiempo de procesamiento (y, si usas una API paga, dinero); por eso el agente no lo intenta infinitas veces: se detiene cuando el resultado coincide o cuando parece que quedó atrapado en un bucle.
- Tú eres el límite de seguridad: si los intentos empiezan a ir por un camino equivocado (por ejemplo, borrando archivos que no debería), eres tú, presente en la sesión, quien interrumpe. Una vez publicado, ese freno humano en tiempo real deja de existir.
Un ejemplo real de autocorrección que salva el día, todavía durante la construcción: imagina que le pides al agente que monte una automatización que lee correos de un proveedor y extrae el valor de la factura. En el primer intento, trata de abrir el correo más reciente y falla, porque ese correo en particular no tenía una factura adjunta (solo era un aviso de entrega). Lee el error, se da cuenta de que el filtro tomaba cualquier correo del proveedor en vez de solo los que tienen un archivo PDF adjunto, ajusta el filtro y vuelve a intentarlo — esta vez funciona. Ocurrió en segundos, sin que tuvieras que explicar el problema. Ese tipo de recuperación en vivo es 100% real — y es exactamente lo que este tema te enseña a reconocer.
📦 Después de publicar: se convierte en automatización tradicional
Cuando el workflow está listo y lo pones a funcionar solo —programado o activado por un disparador, sin Claude Code interactivo abierto (tema de las Trilhas 4 y 6)—, el comportamiento cambia. Deja de «pensar» libremente y pasa a ejecutar el workflow establecido, exactamente como cualquier automatización tradicional (como una macro o un script programado): sigue los pasos escritos, sin inventar otros nuevos.
Esto es una buena noticia, no una limitación: tú quiere previsibilidad en una automatización que se ejecuta todos los días a las 7h sin que nadie la supervise. Una automatización de producción que "pensara por sí sola" y cambiara su comportamiento cada vez sería, en la práctica, demasiado imprevisible para confiar en ella.
¿Eres nuevo aquí? Workflow aquí significa la secuencia de pasos que el agente escribió y probó durante la construcción: el "guion" que sigue después. Publicar no cambia el guion; publicar solo saca al actor (el agente que piensa en tiempo real) de escena y deja que el guion se ejecute solo, punto por punto, como una grabación.
Un ejemplo concreto del otro lado de la moneda: esa misma automatización de correo de un proveedor, ya publicada y funcionando todos los lunes por la mañana. Tres meses después, el proveedor cambia su sistema de correo y el asunto de los mensajes empieza a llegar en otro formato. El workflow publicado no va a «darse cuenta» ni a ajustarse como lo hizo durante la construcción — simplemente no encontrará ningún correo que coincida con el patrón guardado, y o bien fallará en silencio (sin procesar nada ni avisar) o generará un error que solo alguien que revise los logs (el registro de lo que hizo la automatización) notará. Esto no es un bug del sistema — es el comportamiento esperado de una automatización fija. La autocorrección «se gastó» durante la construcción; en producción, simplemente ya no está ahí para actuar.
📊 Dónde está la línea: construcción × producción
La línea divisoria no tiene que ver con «qué tan inteligente es el agente» — tiene que ver con dónde está en ejecución. Dentro de Claude Code, interactivo, contigo presente: modo flexible. Publicado y programado (el tema de las Rutas 4 y 6): modo fijo. La tabla de abajo resume directamente la diferencia.
Leyenda: a la izquierda, la fase de construcción, en la que el agente ajusta su propio camino; a la derecha, la fase de producción, en la que repite el workflow guardado sin desviarse: la línea entre ambas es la publicación.
Al poner las tres fases en una línea de tiempo —construcción, publicación, producción— es más fácil identificar, en cualquiera de tus proyectos, en qué punto exacto el juicio en tiempo real del agente deja de actuar. Es esa transición, y no una caída de «inteligencia», la que cambia el comportamiento.
Leyenda: la flecha avanza desde la construcción (verde, flexible) hasta la producción (cian, fija), pasando por el hito de publicación. No existe una cuarta fase en la que el agente "vuelve a pensar por su cuenta" sin que vuelvas a abrir Claude Code.
✓ Antes de la publicación
- ✓El agente lee los errores y ajusta el enfoque por su cuenta
- ✓Estás presente, puedes interrumpir y redirigir
- ✓El resultado puede variar entre intentos hasta que aciertes
✗ Después de la publicación
- ✗Un error nuevo no se convierte en "intento 2": se registra como falla
- ✗Nadie está mirando en tiempo real para interrumpir
- ✗El mismo paso a paso se repite hasta que vuelvas y lo edites
📣 Por qué el marketing exagera
Los videos y materiales de venta suelen mostrar solo la fase de construcción —la parte más impresionante, con el agente corrigiendo errores en el momento— y dar a entender que esto continúa indefinidamente después de publicado. No es mentira sobre lo que ocurrió en la demostración; es una generalización exagerada sobre lo que pasa después. Entender esta diferencia evita dos frustraciones comunes: creer que una automatización publicada va a «cuidarse sola» para siempre o desconfiar de todo el curso cuando eso no sucede.
⚠️ Atención
Una automatización publicada que empieza a fallar (por ejemplo, porque un sitio cambió de estructura) NO se corregirá sola: fallará de la misma manera cada vez hasta que alguien (tú, en Claude Code) vuelva y ajuste el workflow. Esto es esperable, no un defecto.
Quienes están empezando suelen caer en tres trampas mentales, y vale la pena nombrar cada una:
Error 1 — "Lo corrigió una vez, así que está garantizado para siempre"
Ver al agente recuperarse de un error durante la construcción no es evidencia de que vaya a recuperarse del próximo error, en producción, por sí solo. Cada corrección durante la construcción se hizo contigo presente: ninguna de ellas «queda guardada» como una habilidad permanente del workflow publicado.
Error 2 — Publicar sin probar la ruta de error
Es común probar solo el «camino feliz» (cuando todo sale bien) antes de publicar y nunca probar qué ocurre cuando falta un dato, un sitio está fuera de servicio o un archivo no existe. En producción, sin autocorrección, justamente ese camino de error decide si la automatización falla bien (avisándote) o falla mal (bloqueándose o borrando algo en silencio).
Error 3 — Creer que ya no hace falta comprobar después de publicar
Como la fase de construcción fue tan «inteligente», es tentador tratar la automatización publicada como si siguiera cuidándose sola. No es así: la revisión periódica (Trilha 4, observabilidad) reemplaza, en producción, el juicio en tiempo real que existía durante la construcción.
💡 Consejo práctico
Antes de publicar cualquier workflow, provoca al menos un error a propósito (borra un dato, desconecta el Wi-Fi, indica un archivo que no existe) y observa qué sucede. Si se queda bloqueado sin avisar, ajusta el workflow para que te notifique, mientras todavía estás en la fase en que puedes corregirlo fácilmente.
🎯 Qué esperar en la práctica
En la práctica, usa la fase de construcción para hacer que el workflow sea robusto: ahí vale la pena probar variaciones y casos límite, y dejar que el agente itere hasta acertar. Después de publicarlo, monitorea (Ruta 4, módulo de observabilidad) para saber cuándo algo cambió fuera y el workflow necesita mantenimiento, pero no esperes que se corrija automáticamente en ese momento.
💡 Consejo práctico
Trata la fase de construcción como el "entrenamiento" y la publicación como la "prueba". Dedica tiempo de sobra a probar en el entrenamiento: ahí la autocorrección trabaja a tu favor gratis.
Una forma sencilla de fijar este hábito: cada vez que termines de construir un workflow y antes de publicarlo, pídele al propio agente que enumere, por escrito, «qué puede salir mal aquí en producción y qué pasa en cada caso». No necesitas saber programar para entender la respuesta — solo decidir si cada escenario que enumera es aceptable (el workflow se detiene y te avisa) o peligroso (el workflow continúa y hace algo mal en silencio). Si haces esta solicitud mientras el agente aún te supervisa en la sesión, esta es la última oportunidad para que la autocorrección real actúe a tu favor antes de la publicación.
Pídele esto al agente antes de publicar (copia y pega):
Antes de eu publicar este workflow, liste os pontos onde ele pode
falhar em produção (site fora do ar, dado faltando, formato mudou)
e diga, para cada um, se o workflow para com um aviso claro
ou continua rodando de um jeito que pode causar erro silencioso.Cuando una automatización publicada y programada falla, va a...