Por favor, no hagan pruebas A/B con mi flujo de trabajo

• Claude Code ejecutó pruebas A/B sin el consentimiento del usuario, cambiando sin aviso el comportamiento del modo plan y reduciendo la eficiencia del trabajo
• En una herramienta profesional por la que se pagan US$200 al mes, que una función clave cambie sin aviso previo es problemático en términos de transparencia y control del usuario
• Una de las pruebas fue una variante agresiva que limitaba el plan a 40 líneas, prohibía secciones de contexto e indicaba dejar solo rutas de archivos en lugar de texto explicativo
• El ingeniero de Anthropic que realizó la prueba explicó que el objetivo era reducir la carga por rate limits, pero dijo que cerraron el experimento al no ver un impacto grande en los resultados iniciales
• Se enfatiza que, para la confiabilidad de las herramientas de IA y un despliegue responsable, el control del usuario y una gestión transparente de los experimentos son esenciales

---

Deterioro de la experiencia de usuario por las pruebas A/B de Claude Code

• Como usuario entusiasta para quien Claude Code cambió por completo su forma de trabajar, el autor cuenta que durante la última semana sufrió un deterioro en su flujo de trabajo
• Anthropic está realizando pruebas A/B en Claude Code, y eso está degradando activamente el flujo de trabajo de los usuarios
• Las pruebas A/B en sí no están mal, y no es que Anthropic busque degradar la experiencia de forma intencional, pero el diseño de la prueba importa; el problema es cambiar, sin explicación, la forma en que se percibe una función central como el modo plan

Exigencia de transparencia en una herramienta de pago

• Como se trata de una herramienta profesional de trabajo por la que se pagan US$200 al mes, hace falta transparencia sobre cómo funciona y capacidad de configuración
• Resulta difícil aceptar que una función clave cambie sin previo aviso o que te incluyan, sin consentimiento, en pruebas disruptivas
• Para dirigir con responsabilidad una herramienta de IA, la transparencia y la posibilidad de configurarla son fundamentales, y se debe permitir que el usuario lo haga
• Todos los días hay ingenieros que se quejan de regresiones en Claude Code, y en algunos casos ni siquiera saben si están dentro de una prueba A/B

Contenido de la prueba y evidencia

• Los planes generados empezaron a volver como listas de viñetas concisas sin contexto
• Al preguntarle a Claude por qué estaba escribiendo planes tan malos, respondió que seguía instrucciones específicas del sistema para poner un límite rígido de 40 líneas al plan, prohibir secciones de contexto y “eliminar la prosa y dejar solo las rutas de archivos”
• Sobre el método concreto de obtención de evidencia, el autor dice que el tema llamó la atención en Hacker News y que eliminó los detalles para evitar que otras personas repitieran el mismo intento
• Señala que este enfoque va en contra de la transparencia y del despliegue/uso responsable de la IA

Reacción en Hacker News y perspectiva de costos

• Un comentario en Hacker News señaló que Anthropic debe tomar decisiones sobre el rendimiento en cada paso de Claude Code, y que si todo se configura al máximo, la pérdida por usuario o la menor ganancia serían mayores
• También se plantea la perspectiva de que US$200 al mes podrían representar en realidad US$400 al mes en costos, y que usar pruebas A/B en cada parte del proceso para encontrar la línea base podría ser mejor que fijar límites de manera arbitraria

Respuesta del ingeniero de Anthropic

• El ingeniero de Claude Code que ejecutó la prueba respondió directamente en el hilo de Hacker News
• El prompt del modo plan no había cambiado mucho desde la serie de modelos 3.x, y los modelos 4.x pueden funcionar correctamente con muchas menos instrucciones
• La hipótesis era que, si el plan se hacía más corto, se podrían lograr resultados similares reduciendo la cantidad de veces que se alcanza el rate limit
• Ejecutaron varias variantes, y el autor del texto, junto con miles de otros usuarios, fue asignado a la variante más agresiva, la que limitaba el plan a 40 líneas
• Como los resultados iniciales no mostraron un gran impacto sobre el rate limit, cerraron el experimento
• La planificación tiene dos propósitos: ayudar al modelo a mantenerse en la dirección correcta y ayudar al usuario a tener confianza en la siguiente acción del modelo; ambos son ámbitos ambiguos, complejos y nada triviales

Conclusión: responsabilidad en los experimentos con herramientas de IA y confianza del usuario

• El autor muestra, a través del caso de Claude Code, que los experimentos en herramientas de IA pueden afectar directamente la experiencia del usuario
• Subraya que una gestión transparente de los experimentos y la garantía de elección para el usuario son esenciales para mantener la confianza en herramientas profesionales
• Reafirma que, aunque el desarrollo de los sistemas de IA continúe, se debe mantener una estructura controlable por los humanos

[GN⁺]

Comentarios en Hacker News

• Me parece exagerado describir las pruebas A/B como "experimentos silenciosos sobre los usuarios" y mencionar a Meta
  Las pruebas A/B en sí no son malas; lo importante es cómo se diseña la prueba
  Aun así, me parece inaceptable hacer experimentos que degraden seriamente el rendimiento de un LLM

  • En el caso de los LLM, creo que hay que verlo distinto
    Ya existen problemas graves de reproducibilidad y confiabilidad, y las empresas están trasladando esa carga a los usuarios
    Si encima una empresa experimenta en secreto en este contexto, la confianza en la investigación se derrumba por completo
    En el caso de Claude Code, incluso si una prueba A/B produce resultados negativos, podría ignorarse con el argumento de que "quizá estabas en el grupo experimental"
    Si este tipo de experimentos se hiciera en áreas sensibles como contratación, los problemas éticos y legales serían muy serios
  • Creo que las empresas tecnológicas todavía no entienden bien el concepto de "consentimiento explícito"
  • No me gustan las pruebas A/B
    De repente cambian la UI o una función, le preguntas a un colega y nadie sabe qué pasó
    Normalmente esos cambios incluso empeoran las cosas, pero igual se imponen en nombre de los "datos objetivos"
  • No entiendo por qué dicen que una prueba A/B no es un "experimento silencioso con usuarios"
    Aunque sea algo menor como el color de un botón, al final sigue siendo un experimento, y en la mayoría de los casos a los usuarios ni siquiera se les informa que están siendo parte de uno
  • El autor del post original dijo que estaba de acuerdo y que iba a cambiar la redacción

• Yo fui quien hizo la prueba directamente
  Estaba probando si al simplificar en el modelo 4.x el prompt de plan-mode que se venía manteniendo desde la serie 3.x se podían obtener resultados parecidos
  Supuse que si el plan era más corto golpearía menos el rate-limit, pero como no hubo una diferencia importante, di por terminado el experimento
  El modo de planificación tiene dos objetivos: ayudar al modelo a orientarse y hacer que el usuario pueda confiar en el resultado

  • Era obvio que el límite de 40 líneas no iba a afectar el rate-limit
    El costo no viene del texto del plan, sino de la fase de exploración (subagent)
    El modo de planificación siempre lanza 3 agentes de exploración y no toma en cuenta el estado de la sesión
    Aunque ya haya archivos cargados, los vuelve a leer, lo que genera desperdicio de tokens
    Cuando la sesión ya está caliente, sería más efectivo tener lógica condicional para saltarse la exploración
  • Como divergent thinker, llevo cientos de horas configurando restricciones en claude.mds, así que me impactó haber sido incluido al azar en uno de estos experimentos
    Un solo comportamiento inesperado puede dejarme inutilizado por días
    No tomar en cuenta ese impacto es irresponsable y agresivo
  • ¿No deberían reembolsar los tokens usados en esta prueba?
  • Hace falta una opción de opt-out para este tipo de experimentos
    Últimamente ha habido comportamientos raros y es muy incómodo pensar que quizá se deban a pruebas
    En vez de usar el canal beta, deberían cambiar a opt-in explícito
  • Gracias por la transparencia
    Personalmente, me importa más la claridad narrativa del plan que el número de líneas
    Necesito un plan donde pueda entender qué se hace y por qué

• Los LLM son gramaticalmente impecables, pero mezclan alucinaciones (hallucination) que confunden a los usuarios
  Aun así, son útiles para tareas boilerplate o para conectar ideas rápidamente
  Pero para usarlos bien, tener conocimientos básicos es indispensable

  • La clave para usar bien un LLM es poder distinguir entre salida útil y basura de IA
  • También hay quien opina que no hay que subestimar la velocidad a la que están mejorando los LLM
  • Al final, algunos lo ven como que la gente con experiencia va a sobrevivir, y la que no la tenga será reemplazada

• La razón por la que el texto termina de golpe es que el autor borró una parte por posible violación de los ToS mientras hablaba de la descompilación del binario de Claude Code
  La discusión relacionada puede verse en este comentario

• Tengo dos ideas

  1. Las herramientas open source resuelven el problema de los experimentos involuntarios y los cambios sin previo aviso
  2. Pero por esa misma razón, quizá al open source le cueste llegar al nivel de calidad de Claude Code
     Porque no puede hacer mejoras guiadas por datos a gran escala mediante pruebas A/B
  • Incluso en open source, no todo es siempre reproducible
    Por ejemplo, pueden aparecer cambios impredecibles como el easter egg de "after midnight" en man-db
    Además hay muchas dependencias, y en la práctica casi nadie audita realmente todo el código
  • También salió el chiste de "vamos a hacer A/B testing con el kernel de Linux"
  • Las pruebas A/B no siempre buscan mejorar la experiencia del usuario
    También pueden ser experimentos de monetización (enshittification) — YouTube es un ejemplo representativo

• Las pruebas A/B en sí no tienen problema, pero plan mode no me gusta
  En la mayoría de los casos da malos resultados
  Eso sí, retiene bien la información entre compactions
  Si registras la conversación en un archivo Markdown y haces que lo consulte en cada compaction, los resultados mejoran mucho

  • Mi experiencia es exactamente la contraria
    plan mode es muchísimo más eficiente, así que lo uso antes de casi cualquier tarea
    La ventaja es poder revisar y discutir el plan antes de que el modelo ejecute nada
  • Ya choqué varias veces con el límite de compaction, y desde entonces trato de evitarlo
    Ahora mismo, plan mode reinicia el contexto al terminar, y eso me gusta porque permite arrancar el siguiente plan de forma limpia

• Es una pena que en el blog hayan borrado los detalles de la descompilación por el tema de los ToS
  Claude supuestamente seguía una instrucción del sistema que decía "limita el plan a 40 líneas, prohíbe las secciones de contexto y elimina la prosa"
  Ojalá se pudiera ver y editar directamente esa configuración

• Una herramienta profesional debería ofrecer confiabilidad y reproducibilidad, pero los LLM no lo hacen
  Las pruebas A/B son solo una prueba más de eso

  • El problema de fondo no es el LLM, sino que la app cambie su comportamiento en secreto
    Sería el mismo problema si Photoshop alterara un poco el tono de color o si Word cambiara el estilo de los títulos como parte de un experimento
    El problema es el A/B testing sin advertencia
  • Anthropic tiene un problema serio de falta de transparencia
    Los límites de cuota y la calidad del modelo son inestables, y antes del lanzamiento de un modelo nuevo suele haber una etapa en la que el modelo anterior se arruina
    Esta prueba también parece más un experimento de reducción de costos que una mejora para la experiencia del usuario
    Si es una herramienta para negocios, hace falta consistencia y confiabilidad
  • Las herramientas con actualizaciones automáticas cambian su comportamiento por naturaleza
    Un profesional debe entender las fortalezas y debilidades de la herramienta y usarla de forma adecuada
    Aceptar ciegamente la salida de un LLM no es profesional, pero eso no significa que un profesional no pueda usar LLM
  • La reproducibilidad es un espectro
    Con un sistema de evaluación suficiente y control de prompts, se puede volver bastante determinista
    Si hasta modelos inestables en finanzas siguen operando, la imprevisibilidad no es una barrera absoluta
  • Si la salida de un LLM fuera completamente determinista, ¿qué haría yo diferente?
    Yo verifico la salida del modelo como si revisara el código de un colega

• A esto desde hace mucho se le llama vendor lock-in
  Si dependes de una herramienta específica, cuando esa herramienta cambia o desaparece, dejas de poder trabajar

• Yo me pasé de CC a opencode
  CC era demasiado cerrado y sus prompts eran demasiado opinionated, lo cual me incomodaba
  Tampoco se podía controlar la ruta de búsqueda web
  Como ahora lo uso solo como hobby, elegí open source, pero si dependiera de esto para trabajar, probablemente decidiría distinto

  • Yo también probé opencode, pero la versión base es mucho más débil que CC
    Solo me sirvió para proyectos pequeños
    Si tienes una configuración decente, estaría bueno que la compartieras