Por qué Claude se vuelve "más tonto" cuanto más lo usas: El precio oculto de "ahorrar dinero" es una factura de API 100 veces mayor
Por qué Claude se vuelve "más tonto" cuanto más lo usas: El precio oculto de "ahorrar dinero" es una factura de API 100 veces mayor
Hace unos días, Stella Laurenzo, directora de IA de AMD, publicó un problema técnico muy específico en el repositorio oficial de Claude Code: "Claude Code es inútil para tareas de ingeniería complejas con las actualizaciones de febrero." Esta no fue una queja superficial. Fue un análisis cuantitativo basado en 6.852 sesiones, 17.871 bloques de pensamiento y 234.760 llamadas a herramientas recopiladas en flujos de trabajo reales. Puedes leer el informe original aquí: GitHub issue #42796.
Si trabajas en criptomonedas, deberías prestar atención, porque la "ingeniería compleja" es prácticamente la configuración predeterminada en Web3: los contratos inteligentes son inmutables, las superficies de ataque son componibles y un solo cambio alucinado puede convertirse en una explotación. Lo que parece un tropiezo del producto de IA es, en la práctica, un riesgo en la cadena de suministro de software y una trampa de costos.
1) Los datos incómodos: calidad a la baja, costo al alza (muy al alza)
El informe vincula una regresión visible en la calidad con cambios en la configuración del lado del servidor relacionados con el pensamiento extendido y la redacción de pensamientos (notablemente el despliegue etiquetado como redact-thinking-2026-02-12). La afirmación clave no es solo que "los resultados empeoraron", sino que el comportamiento del modelo cambió mediblemente de investigar primero a editar primero, la dirección exactamente opuesta para la ingeniería de alto riesgo.
Aquí hay una instantánea simplificada basada en las métricas del hilo del problema:
Fuente: la telemetría original y el apéndice de costos en el problema de GitHub.
La lección más relevante para cripto es contraintuitiva: limitar el razonamiento no siempre reduce el gasto. En tareas de larga duración, un agente más débil puede desencadenar más reintentos, correcciones y llamadas a herramientas, aumentando tu factura hasta más de 100 veces y, aun así, entregando una menor fiabilidad.
2) Por qué esto afecta a los equipos de blockchain más que a los equipos de software típicos
Los contratos inteligentes no toleran el "suficientemente cerca"
En Web2, una regresión puede ser parcheada y redeployada. En Web3, una suposición errónea puede ser inmortal.
La documentación de Ethereum es contundente: el código desplegado es difícil de cambiar y las pérdidas a menudo son irrecuperables; consulta la documentación de seguridad de contratos inteligentes de Ethereum y las directrices de seguridad generales.
Ahora conecta eso con la telemetría de Claude Code: menos lecturas de archivos, ediciones más apresuradas, detenciones más prematuras. Ese es exactamente el patrón que produce:
- Verificaciones incompletas (autorización, protección de repetición, separación de dominios)
- Invariantes rotas entre módulos
- Falta de manejo de casos extremos en torno a decimales de tokens, tarifas de transferencia, redondeo
- Llamadas externas inseguras o actualizaciones de estado mal ubicadas
En DeFi e infraestructura de cadena, "casi correcto" es a menudo lo mismo que explotable.
Las tendencias de complejidad 2025-2026 amplifican el radio de explosión
Dos cambios en la industria hacen que la historia de la "regresión del agente de IA" sea más peligrosa en cripto de lo que parece:
-
La abstracción de cuentas y las cuentas inteligentes se están generalizando, aumentando la cantidad de lógica crítica de seguridad que reside en los contratos en lugar de en las EOAs. Si tu producto toca AA, empieza con ERC-4337 y la documentación práctica del ecosistema en Documentación ERC-4337.
-
Las estafas asistidas por IA y la ingeniería social se están escalando. Chainalysis señala que las estafas vinculadas a proveedores de IA extraen materialmente más por operación en promedio; consulta su análisis sobre estafas en el Informe de Crimen Cripto 2026. Cuando los usuarios finales preguntan cada vez más a la IA "¿Es seguro firmar esto?", la fiabilidad del modelo se convierte en un problema de protección al consumidor, no solo en una preferencia de ingeniería.
3) La conclusión real: los LLM son ahora una dependencia de producción—trátalos como tales
Los equipos de cripto ya aprendieron (de la manera difícil) a versionar dependencias críticas: versiones del compilador, proveedores de RPC, módulos de custodia, bibliotecas de firma. Los agentes LLM ahora pertenecen a esa misma categoría.
Un manual práctico de Web3:
A) Crea "pruebas de regresión de LLM" como creas suites de pruebas de protocolo
- Captura tareas representativas: flujos de actualización de contratos, mensajería entre cadenas, rellenado de indexadores, refactorizaciones de matemáticas de tarifas.
- Ejecuta las mismas indicaciones semanalmente; compara los resultados.
- Controla las fusiones con comprobaciones deterministas: pruebas unitarias, invariantes, simulación y análisis estático.
Si despliegas Solidity, la página de directrices de Ethereum hace referencia explícita a herramientas como flujos de trabajo de análisis estilo Slither / Echidna; empieza desde Directrices de seguridad de contratos inteligentes.
B) Elimina la "aceptación automática de ediciones" de los repositorios críticos
El informe de problemas señala flujos de trabajo donde los cambios se aceptaron automáticamente. Eso es una victoria de productividad, hasta que un agente cambia silenciosamente de cuidadoso a imprudente.
Para contratos inteligentes, trata la IA como a un colaborador junior:
- requiere revisión de código humana
- requiere pasar pruebas y simulación local
- requiere aprobación explícita para cambios de permisos, nuevas llamadas externas o cambios en el diseño del almacenamiento
C) Establece un límite máximo estricto para el atasco (el control de costos es un control de seguridad)
Cuando la calidad disminuye, el agente se compensa haciendo más: más llamadas a herramientas, más reintentos, más quema de tokens. Necesitas disyuntores:
- reintentos máximos por tarea
- llamadas a herramientas máximas por sesión
- crecimiento máximo del contexto
- alertas sobre "costo por PR fusionado" o "costo por ticket resuelto"
Así es como evitas que "ahorrar cómputo" se convierta en una sorpresa de factura de 100x.
D) Utiliza un modelo de amenazas de LLM, no solo una plantilla de indicaciones
Si estás creando agentes que tocan claves de producción, puntos finales de RPC o flujos de firma, alinéate con marcos de seguridad como el OWASP Top 10 para Aplicaciones de Lenguaje de Modelo Grande y trata la inyección de indicaciones / el uso indebido de herramientas como riesgos de primera clase.
4) Para usuarios cotidianos: la IA puede ayudarte a entender cripto, pero no debe controlar tus claves
A medida que los asistentes de IA se convierten en la interfaz predeterminada para billeteras, operaciones y soporte al cliente, el modo de falla más probable no es la "generación de código incorrecto", sino las decisiones de firma incorrectas, especialmente bajo presión de phishing.
Dos puntos no negociables:
- Nunca pegues frases semilla en ningún chat de IA, "bot de soporte" o formulario del navegador.
- Separa "consejo" de "autorización": deja que la IA resuma, pero exige confirmación física para mover fondos.
Esa separación es exactamente donde una billetera de hardware demuestra su valor.
5) Dónde encaja OneKey: haz que la IA sea opcional, haz que la firma sea explícita
Si tu flujo de trabajo (o tus usuarios) depende cada vez más de la IA, ya sea para explicaciones de transacciones, interacciones de contratos o automatización de "agentes" en cadena, la arquitectura más segura es:
- La IA puede proponer
- tu aplicación puede simular
- tu billetera de hardware debe aprobar
El valor práctico de OneKey en una pila cripto saturada de IA es simple: ayuda a mantener las claves privadas fuera de línea y fuerza un paso de firma explícito, reduciendo la posibilidad de que un modelo degradado, una indicación envenenada o un convincente mensaje de "soporte" de deepfake se conviertan en una pérdida irreversible en cadena.
Pensamiento final: "Razonamiento más barato" no es más barato, especialmente en cripto
El informe de AMD es un regalo poco común: convierte un miedo vago ("el modelo se siente peor últimamente") en un comportamiento medible del sistema y una curva de costos difícil. En blockchain, donde la corrección es dinero y los errores son permanentes, la lección es sencilla:
No optimices por costo de tokens por solicitud. Optimiza por corrección por decisión.
