El 1 de julio de 2026, Anthropic envió Claude Code 2.1.198 con una sorpresa: si no respondías a una pregunta del agente en 60 segundos, el agente decidía por su cuenta y continuaba. Sin mención en el changelog, sin flag documentado para desactivarla. El usuario que la descubrió abrió un issue que reunió 384 👍 y 143 comentarios en menos de 48 horas.

Anthropic corrigió el comportamiento tres días después con la versión 2.1.200, pero la pregunta persiste: ¿cómo llegó a producción una feature así sin documentación ni opción de opt-out? Olaf Alders condujo una investigación técnica pública usando Claude Code para reconstruir el trail de commits, y descubrió que no hay rastro público del código que introdujo la feature. El changelog solo menciona la marcha atrás.

En paralelo, Simon Willison lanzó LLM cliché highlighter, una herramienta que destaca los tics lingüísticos típicos del output generado: “no X, no Y”, “sit with that”, “you already know”. El timing no es casual: Claude Code produce commit messages y notas que traicionan su origen generado, y la comunidad está construyendo herramientas para reconocerlo.

Por qué te afecta. Si usas agentes de coding en producción, este incidente plantea tres preguntas concretas: ¿quién firmó esa feature? ¿Cómo verificas que un agente no introduzca comportamientos inesperados en tu código? Y cuando tu output suena “escrito por IA”, ¿qué credibilidad pierdes?

En detalle

El contexto: qué había antes.

Claude Code ya era conocido por pedir confirmación antes de acciones de alto impacto. La versión 2.1.196 del 29 de junio funcionaba así: pregunta, espera, ninguna acción sin respuesta. Dos días después, la 2.1.198 invirtió el comportamiento sin avisar.

El descubrimiento y la reacción.

Aleksey Nogin abrió el issue #73125 el 2 de julio a las 02:54 UTC. En 51 minutos, otro usuario reportó la escape hatch no documentada: la variable de entorno CLAUDE_AFK_TIMEOUT_MS. Anthropic envió la 2.1.199 ese mismo día, pero sin tocar el comportamiento. Solo el 3 de julio, con la 2.1.200, se removió el auto-continue. Issue cerrado el 4 de julio.

La escala de la reacción (384 👍, 143 comentarios en 48 horas en un issue técnico) dice que el problema tocó un nervio: la confianza en agentes que modifican código.

La investigación de Alders: ¿dónde está el commit?

Alders usó Claude Code para interrogar el repositorio público de Claude Code. Resultado: el commit que introduce la feature no existe en el log público. El único rastro es el bot commit que actualiza CHANGELOG.md en la release 2.1.198 (commit 75709ea, 1 de julio 20:45 UTC). Lo mismo para la corrección: solo el changelog cambia.

Alders planteó las preguntas que un revisor humano se haría: ¿firmó un humano? ¿Revisionó un humano? ¿Difó la release un release manager? Y concluye: “Si me dijeras que Claude Code construyó la feature, la envió, la aprobó y luego la consideró indigna de documentación, estoy más inclinado a creerlo”.

La herramienta de Willison y el problema más amplio.

Simon Willison lanzó LLM cliché highlighter el mismo día en que Alders publicó su investigación. La herramienta destaca diez patrones lingüísticos típicos del output generado: las antítesis de efecto (“not X, but Y”), las tripletas mecánicas, las preguntas retóricas, los cierres de tema motivacional.

Willison escribe: “Estoy harto de leer otro artículo lleno de clichés de escritura LLM”. La herramienta nació con Fable 5 en una tarde, y sirve para hacer lo que todos hacemos manualmente: reconocer cuándo un texto traiciona su origen generado.

Las implicaciones para quienes construyen.

Si un agente escribe código o commit messages que suenan “generados”, el problema no es estético: es de credibilidad y verificabilidad. Un commit message lleno de clichés señala que nadie lo revisó. Una feature enviada sin rastro en el log público señala que el ciclo de revisión tiene agujeros.

La convergencia entre la investigación de Alders y la herramienta de Willison no es casual: ambos abordan el mismo problema desde ángulos diferentes. Cuando el output de un agente entra en producción sin filtro humano, se traiciona a sí mismo. Y cuando se traiciona a sí mismo, pierde la batalla más importante: la de la confianza.

Qué sabemos y qué no.

Sabemos que la feature llegó, fue retirada, y que no hay rastro público del código. No sabemos:

• Si un humano escribió, revisionó o aprobó la feature
• Si el auto-continue era intencional o un efecto secundario
• Por qué el changelog no la mencionó al entrar pero sí al salir
• Si otros comportamientos no documentados fueron enviados de la misma manera

Anthropic no ha comentado públicamente el incidente más allá de la corrección.

El límite práctico.

Los agentes de coding prometen velocidad. Pero velocidad sin verificabilidad produce deuda técnica disfrazada de productividad. Si tu agente escribe código que suena generado, si envía features sin dejar un audit trail legible, si el changelog está desconectado del log de commits, no has ganado tiempo: has movido el costo de la verificación aguas abajo, donde cuesta más.

Como contamos el 14 de julio, la comunidad está construyendo herramientas para compensar los límites de UX de los agentes (notificaciones sonoras, replay de sesiones). Ahora también está construyendo herramientas para reconocer cuándo el output de un agente no pasó por el filtro humano. Es una señal de dónde estamos: los agentes producen rápido, pero la cadena de verificación aún está por construirse.