¿Qué tan larga debería ser una respuesta de un LLM? Cómo derivar un presupuesto de longitud a partir de la capacidad de lectura humana

Todos los ingenieros que conozco tienen la misma queja sobre los modelos de frontera de 2026: las respuestas son demasiado largas. Haces una pregunta acotada y recibes un ensayo. Revisas el informe de un agente y, por ahí de la tercera pantalla, te das cuenta de que dejaste de leer y empezaste a buscar patrones.

La respuesta habitual es una preferencia de estilo: «sé conciso». En la práctica, eso falla porque no tiene una cifra asociada. ¿Conciso en comparación con qué? Un revisor no puede hacer cumplir una impresión subjetiva, y un system prompt tampoco.

Así que pongámosle una cifra. Tanto la velocidad de lectura como la capacidad de revisión humanas se han medido repetidamente en muestras grandes. Los adultos leen textos de no ficción en inglés a 238 palabras por minuto, así que treinta segundos de atención alcanzan para unas 120 palabras, o 160 tokens de salida. Cinco minutos alcanzan para 1,200. Decide cuánto tiempo de una persona merece la respuesta y la aritmética te dará el límite.

A continuación presento esa derivación: un presupuesto para cada clase de respuesta, las cuatro condiciones que justifican superarlo y lo que hace falta para aplicarlo en producción. La parte incómoda es lo que muestra la evidencia sobre revisión acerca del punto en el que los lectores dejan de prestar atención sin decir nada.

¿Demasiado larga para quién y para hacer qué?

No se puede responder a la pregunta «¿Esta respuesta es demasiado larga?» tal como está planteada. La versión que sí se puede responder es: ¿demasiado larga para la atención de quién, para hacer qué tarea y con cuántos segundos disponibles? Eso convierte una discusión de gustos en aritmética. El límite se deriva de dos cantidades medidas: qué tan rápido lee la gente y cuánto tiempo dedica antes de detenerse.

No pude encontrar mediciones publicadas de la longitud promedio de salida por modelo para los modelos de frontera actuales, incluido Claude Opus 5. La queja de que son demasiado verbosos es generalizada y coincide con mi experiencia, pero aquí la trato como una observación de quienes trabajamos con ellos, no como un hecho establecido. Esa ausencia es parte del problema: medimos obsesivamente la calidad de los modelos y casi nunca su verbosidad.

Lo que cuesta leer en realidad

La cifra fundamental proviene del metaanálisis de Marc Brysbaert de 2019 en el Journal of Memory and Language, que abarca 190 estudios y 18,573 participantes. El promedio de lectura silenciosa de textos de no ficción en inglés es de 238 palabras por minuto, y la mayoría de las personas se sitúa entre 175 y 300. Eso es alrededor de un 20% menos que las 300 palabras por minuto que suelen citarse en publicaciones de divulgación, una diferencia que Brysbaert atribuye a muestras pequeñas y métodos inconsistentes.

Eso nos da la conversión básica. A 238 palabras por minuto, un minuto de atención alcanza para unas 238 palabras. La documentación del tokenizer de OpenAI estima que, en inglés, hay aproximadamente tres cuartos de palabra por token, así que un minuto de atención equivale a unos 315 tokens de salida.

Pero la velocidad de lectura es el límite optimista, porque supone que la persona lee. Y no lo hace. Un análisis de Nielsen Norman Group de 2008 sobre datos de visitas a páginas encontró que los usuarios tienen tiempo para leer como máximo el 28% de las palabras de una página promedio. Ese límite supone que pasan toda la visita leyendo, por lo que la cifra realista está más cerca del 20%. Su modelo calcula directamente el costo en atención: unos 25 segundos de tiempo fijo, más 4.4 segundos por cada 100 palabras adicionales. Tómalo como una referencia aproximada, ya que mide el comportamiento en páginas web, no en chats, y precede al contexto actual de lectura por casi dos décadas.

La cifra más útil de ese estudio es esta: los lectores solo llegan a la mitad del contenido en páginas de 111 palabras o menos. Por encima de eso, la proporción que consumen cae rápidamente.

Así que el cálculo tiene dos capas: la velocidad de lectura indica cuánto cabe en el tiempo disponible, y el comportamiento de lectura en diagonal indica qué fracción llega a leerse.

Cómo derivar el presupuesto de longitud

Elige el tiempo que un lector dedicará de forma realista a la respuesta, multiplícalo por 238 palabras por minuto y luego divide entre 0.75 para obtener los tokens de salida.

La respuesta rutinaria de 30 segundos llega a unas 120 palabras, cerca del umbral de 111 palabras de Nielsen Norman Group para el contenido que los lectores realmente terminan de leer. Es una comprobación útil de plausibilidad, más que una corroboración independiente —yo elegí el presupuesto de 30 segundos—, pero sí sugiere que el nivel corto está en un rango razonable.

El nivel de 12 minutos tampoco es arbitrario. Mis propias herramientas de legibilidad en este repositorio señalan que cualquier texto de más de unas 2,500 palabras o 12 minutos de lectura puede causar fatiga por longitud.

Si mido este artículo frente a ese umbral, la respuesta depende de lo que cuente. Solo la prosa del cuerpo suma apenas menos de 3,000 palabras, unos 12 minutos a 238 palabras por minuto. Si agrego las fuentes y los enlaces relacionados, son unas 3,600. Si agrego las tablas y el código, son unas 4,000. Las tres cifras exceden el nivel, pero por entre 60 palabras y bastante más de mil. Ese es precisamente el tipo de detalle que un presupuesto de longitud debe definir antes de que signifique algo. Más adelante en el artículo fijo esa regla en código.

Por qué los revisores se rinden antes de quejarse

Las cifras de lectura explican la fatiga. La literatura sobre revisión explica algo peor: una salida larga no solo cansa a los revisores, sino que oculta defectos de manera medible.

La evidencia más clara proviene de Fregnan y sus colegas en ESEC/FSE 2022. Analizaron comentarios de revisión en 219,476 pull requests de 138 proyectos Java y descubrieron que los archivos mostrados antes reciben más comentarios que los mostrados después, incluso tras controlar los factores de confusión. Luego realizaron un experimento controlado con 106 desarrolladores, introduciendo dos defectos no relacionados en archivos distintos y cambiando sus posiciones. Un tipo de defecto no mostró ningún efecto de posición. Para el otro, un defecto en un caso límite, los participantes tuvieron un 64% menos de probabilidades de identificarlo cuando su archivo aparecía al final en vez de al principio.

Interpreto eso como una señal sobre la longitud de las respuestas, y vale la pena aclarar que trasladar el resultado es una inferencia. Fregnan midió la posición de archivos en una revisión de código, no la posición de párrafos en prosa generada, y no he encontrado ningún estudio que pruebe directamente ese salto. Pero el mecanismo es el mismo: atención finita que se consume en orden. Cuando tu agente entierra una advertencia crítica en el párrafo catorce, asume que, en la práctica, la ha ocultado.

Las cifras relacionadas refuerzan la idea:

• En Google, el cambio mediano es de 24 líneas, entre aproximadamente nueve millones de cambios revisados. La revisión mediana tiene un revisor y se aprueba en menos de cuatro horas. Las unidades pequeñas son las que hacen viable la revisión.
• En Microsoft, un análisis de 570 comentarios de revisión encontró que solo alrededor del 14% identificaba realmente defectos, pese a que encontrarlos era la principal motivación declarada. La atención disponible para revisar es más escasa de lo que sugiere la actividad de revisión.
• El trabajo de Google en Tricorder estableció umbrales explícitos de fatiga por alertas. Los analizadores cuyos resultados se marcan como no útiles el 10% de las veces o más entran en un período de prueba, y el 25% es motivo para desactivarlos. Cuando una cuarta parte es ruido, las personas dejan de confiar en un canal.

Nada de eso describe a lectores que carecen de disciplina. Describe el consumo de un recurso finito.

El costo también aparece a nivel organizacional. Una encuesta de BetterUp Labs y Stanford Social Media Lab a 1,150 trabajadores de oficina de Estados Unidos, publicada en Harvard Business Review en September 2025, encontró que el 40% había recibido «workslop» generado por IA en el mes anterior. Cada incidente costó en promedio poco menos de dos horas. Son datos autodeclarados, así que interprétalos como percepción, no como una medición. Compáralos con el ensayo controlado aleatorizado de METR, que encontró que los desarrolladores experimentados eran un 19% más lentos con herramientas de IA de principios de 2025, aunque creían haber sido un 20% más rápidos. METR no midió la verbosidad, pero ambos resultados apuntan al mismo punto ciego: las personas más cercanas al trabajo generado por IA subestiman su costo.

Una salida verbosa no falla de forma evidente. Falla al ser aprobada.

Las cuatro condiciones que justifican ampliar una respuesta

Reducir la longitud por defecto es solo la mitad de una política. La otra mitad consiste en saber cuándo corresponde una respuesta más larga.

El consejo habitual es ampliar cuando la tarea es «de alto riesgo», lo que resulta demasiado impreciso para actuar porque cada ingeniero cree que su tarea es de alto riesgo. La versión operativa es una comparación: amplía cuando el costo de pasar por alto un detalle supera el costo del tiempo de lectura. Esa prueba se descompone en cuatro condiciones, y cada una sube la respuesta exactamente un nivel en la tabla anterior.

Las condiciones en sí no son sorprendentes y seguramente ya has visto versiones de ellas. Lo importante es la tercera columna, porque un presupuesto solo es operativo si indica en qué se permite gastar las palabras del nivel adicional.

Si una respuesta más larga no usa sus palabras adicionales para ese contenido específico, no está ampliando: está rellenando. Las reservas innecesarias, reformular la pregunta, resumir lo que se acaba de decir y enumerar advertencias que no cambian la acción no pasan la prueba.

flowchart TD
    Start["Respuesta lista para enviar"] --> Class{"¿Qué clase de respuesta?"}
    Class -->|"Estado / rutinaria"| Short["Presupuesto: 20-120 palabras"]
    Class -->|"Explicación"| Mid["Presupuesto: ~475 palabras"]
    Class -->|"Decisión / enseñanza"| Long["Presupuesto: 1,200-2,850 palabras"]

    Short --> Test{"¿Aplica alguna condición<br/>para ampliar?"}
    Mid --> Test
    Long --> Test

    Test -->|"Acción irreversible"| Expand["Ampliar: subir un nivel"]
    Test -->|"El lector reproduce el razonamiento"| Expand
    Test -->|"El artefacto es evidencia"| Expand
    Test -->|"El lector carece del esquema conceptual"| Expand
    Test -->|"Ninguna aplica"| Enforce["Mantener el presupuesto"]

    Expand --> Layer["Primero la respuesta,<br/>los detalles más abajo"]
    Enforce --> Ship["Enviar"]
    Layer --> Ship

Observa lo que hace la ruta de ampliación: sigue poniendo la respuesta primero.

Cómo aplicar el presupuesto: lo que funciona y lo que solo parece funcionar

Los equipos recurren a tres mecanismos. No todos son igual de eficaces.

Pedirlo en el prompt no es confiable. Yuan y sus colegas crearon versiones de AlpacaEval 2 y MT-Bench con instrucciones de longitud y midieron directamente las tasas de incumplimiento. GPT-4 (0409) excedió el límite indicado en el 49.3% de las respuestas de AlpacaEval-LI y en el 44.2% de las de MT-Bench-LI. Los modelos más pequeños ajustados para seguir instrucciones lo hicieron mejor —Llama3-8B-Instruct incumplió en el 7.0% y el 20.0%, respectivamente—, pero una tasa de cumplimiento equivalente a lanzar una moneda en un modelo de frontera significa que el texto del prompt por sí solo no es un control. Este no es un problema que haya quedado resuelto en 2024. En un estudio de ACL de 2026, GPT-5 obtiene 95.9% en IFEval, pero en las restricciones de cantidad de palabras específicamente, su consistencia baja del 96.0% al 88.0% cuando la misma solicitud se reformula de diez maneras. Los modelos más débiles se desploman: Qwen3-32B cae del 83.1% al 40.0%. El mismo trabajo encontró que el fallo es frágil de una manera inquietante: cambiar una restricción de «como máximo 600» a «como máximo 610» hace que muchos casos que antes pasaban dejen de hacerlo. Ese no es el comportamiento de un sistema que entiende el límite.

max_tokens es un límite de seguridad, no un control de longitud. No hace que el modelo escriba una respuesta más corta; detiene la generación a mitad del proceso. Anthropic devuelve stop_reason: "max_tokens" y documenta que se debe elevar el límite o continuar la respuesta; OpenAI señala lo mismo con finish_reason: "length". Ambos devuelven HTTP 200, así que una respuesta truncada llega al usuario con la misma apariencia que una completa, a menos que revises el campo. Para la salida estructurada es peor que inútil: obtienes JSON inválido.

Los controles de verbosidad son la herramienta realmente útil, dentro de ciertos límites. La familia GPT-5 de OpenAI expone verbosity (low, medium, high) dentro de text en la Responses API, junto con reasoning.effort. Su documentación dice explícitamente que la verbosidad «influye en el nivel de detalle, pero no en los límites estrictos»: desplaza la distribución, pero no impone un máximo.

Así que el patrón que funciona tiene varias capas. Configura el control de verbosidad, indica el presupuesto en el system prompt y establece un límite generoso de max_tokens como protección frente a una generación descontrolada. Después verifica lo que recibes.

type ResponseClass = "status" | "routine" | "explanation" | "decision" | "teaching";

// Derived from 238 wpm (Brysbaert 2019) at ~0.75 words per token.
const WORD_BUDGET: Record<ResponseClass, number> = {
  status: 20,
  routine: 120,
  explanation: 475,
  decision: 1200,
  teaching: 2850,
};

const FENCE = new RegExp("`{3}[\\s\\S]*?`{3}", "g");

// Prose only: code blocks and tables carry their own budget.
const countWords = (text: string) =>
  text
    .replace(FENCE, " ")
    .split("\n")
    .filter((line) => !line.trim().startsWith("|"))
    .join(" ")
    .trim()
    .split(/\s+/)
    .filter(Boolean).length;

export function checkBudget(text: string, cls: ResponseClass) {
  const words = countWords(text);
  const ceiling = WORD_BUDGET[cls];

  return {
    words,
    ceiling,
    tokenCeiling: Math.round(ceiling / 0.75),
    overBy: Math.max(0, words - ceiling),
    violated: words > ceiling,
    readingMinutes: +(words / 238).toFixed(1),
  };
}

Déjalo por escrito, porque un presupuesto que no se puede calcular es uno que nadie hace cumplir.

Cómo medir si se cumple el presupuesto

Trata la longitud como cualquier otra regresión: mide una tasa.

La tasa de incumplimiento es la métrica principal, y el trabajo sobre benchmarks con instrucciones de longitud te da tanto el método como un punto de referencia. Ejecuta la distribución de prompts de producción, clasifica cada respuesta, compara su cantidad de palabras con el presupuesto y reporta el porcentaje que lo supera. Para tener una referencia, GPT-4 estaba cerca del 49% en ese benchmark en 2024, e incluso GPT-5 pierde ocho puntos de consistencia en la cantidad de palabras al reformular las instrucciones en 2026. Elige tu propia meta; yo uso el 10% como una línea arbitraria pero estable.

Dos comprobaciones secundarias mantienen honesta la métrica, porque es fácil optimizar solo la longitud de una forma que engañe a la medición:

• Cobertura. Pide a un modelo evaluador que verifique que los datos necesarios sobrevivieron a la compresión. Longitud sin cobertura es solo truncamiento, y ahí es donde comprimir demasiado realmente perjudica.
• Posición de la respuesta. Comprueba que la conclusión aparezca al principio. El resultado de Fregnan sugiere que el contenido al comienzo de la respuesta es el que realmente se lee, así que enterrar la respuesta es un defecto incluso cuando se cumple el límite de palabras.

Haz seguimiento de la tasa de incumplimiento y la cobertura en conjunto. Cualquiera de las dos por sí sola puede llevarte por mal camino.

La brecha en mis propias herramientas

Escribir esto dejó al descubierto una inconsistencia en mi propia configuración.

Este repositorio ejecuta una auditoría de legibilidad sobre cada artículo que publico. Calcula un Read Difficulty Index, el nivel Flesch-Kincaid, Gunning Fog, SMOG, la longitud promedio de las oraciones, la proporción de oraciones de más de 25 palabras y el tiempo de lectura a 200 palabras por minuto. Los umbrales son concretos: Read Difficulty por debajo de 55, nivel escolar de 10 a 13, oraciones con un promedio de 15 a 22 palabras y una alerta de fatiga por longitud por encima de unas 2,500 palabras.

Así que la prosa que escribo a mano pasa por un control cuantitativo de longitud. La prosa que un modelo genera para mí no pasa por ninguno.

Esa asimetría está en todas partes. Hemos pasado dos años construyendo evals de precisión, seguridad y uso de herramientas, y casi ninguno para determinar si la salida tiene el tamaño adecuado para quien la lee. El problema de medición no es difícil: el código anterior es una tabla de consulta y un conteo de palabras. Simplemente nunca lo hemos tratado como una dimensión de calidad.

Una salvedad, ya que dependo de esas fórmulas: Flesch-Kincaid y sus variantes se crearon para textos escolares clasificados por nivel, no para documentación técnica. Premian las oraciones cortas y las palabras cortas, así que una respuesta puede mejorar su puntuación mientras empeora. Úsalas como una alarma de desviación, no como una meta.

Cómo cerrar la brecha: una skill que cuenta y un agente que evalúa

Así que construí el control que faltaba. Son dos archivos, y la separación entre ellos es todo el diseño.

El script cuenta. El agente decide qué significa el conteo. Nunca dejes que un modelo mida su propia salida. La evidencia anterior explica por qué: GPT-5 pierde ocho puntos de consistencia en la cantidad de palabras al reformular las instrucciones, y Qwen3-32B cae a la mitad. Un modelo que no puede obedecer de forma confiable una restricción de longitud tampoco puede auditarla de forma confiable. Así que la cifra proviene de 150 líneas de Python sin dependencias, y el modelo solo se encarga de razonar sobre ella.

La skill se encarga de medir

.claude/skills/response-budget/scripts/budget.py recibe un archivo o stdin y una clase de respuesta:

python3 .claude/skills/response-budget/scripts/budget.py --class routine reply.md

Response budget - class: routine
==============================================
  Verdict        : OVER BUDGET
  Words          : 148 (ceiling 120)
  Over by        : 28
  Reading time   : ~0.6 min at 238 wpm (budgeted 30s)
  Token ceiling  : ~160
  Opening para   : 8 words
  WARNING        : opens with preamble, not the answer
  ACTION         : cut 28 words, or justify the overage with an expansion trigger

Cuenta solo la prosa y excluye los bloques de código y las filas de las tablas, porque no son oraciones e incluirlos hace que la cifra pierda sentido. Reporta el párrafo inicial por separado, ya que esa es la parte cuya lectura está garantizada. Señala las respuestas que empiezan con relleno en vez de con la respuesta. Y termina con el código 1 cuando se supera el presupuesto, que es todo lo que necesita un job de CI.

El agente se encarga de evaluar

.claude/agents/response-budget-auditor.md sitúa esa cifra dentro de la decisión que el script no puede tomar. Clasifica la respuesta antes de medirla, de modo que no se pueda elegir la clase después para hacer desaparecer un incumplimiento. Ejecuta el script, confirma que la conclusión esté al principio y luego contrasta cualquier exceso con las cuatro condiciones de ampliación y sube la respuesta como máximo un nivel.

Su regla más útil consiste en rechazar dos justificaciones: «el tema es complejo» y «el usuario podría querer más detalles». Ninguna de las dos se puede refutar, y ambas son formas en las que los presupuestos terminan desapareciendo sin que nadie lo note.

Integración en un workflow

• Claude Code detecta .claude/agents/ y .claude/skills/ automáticamente. Pide el auditor de presupuesto de respuesta por su nombre para cualquier artefacto generado, o invoca la skill directamente cuando solo quieras la cifra.
• Cursor no tiene una detección automática equivalente, así que el mismo rol existe como plantilla de prompt en .cursor/subagents/response-budget-auditor.md, que se pega en un subagente de propósito general. El script es compartido, por lo que ambos clientes miden de la misma manera.
• CI no necesita ningún agente. El código de salida es el control: budget.py --class decision generated-report.md hace fallar el job cuando un artefacto generado supera la capacidad de lectura prevista para su destinatario.

Lo más honesto es ubicarlo como un paso de revisión, no de generación. La longitud es una propiedad de la salida terminada, y aplicar el control al final es lo que evita que el presupuesto se convierta en otra instrucción que el modelo cumple a medias.

Qué dice sobre este artículo

Al ejecutarlo sobre este artículo, clasificado como teaching, devuelve que supera el presupuesto por unas 800 palabras. Es un resultado real y lo dejo visible, porque de él se desprenden dos cosas.

La primera es que fijar la regla de conteo en código resuelve la ambigüedad anterior. El script cuenta las fuentes y los enlaces relacionados como prosa y excluye el código y las tablas. Esa es ahora la regla, no un criterio que vuelvo a decidir cada vez, y por eso la cifra del script es mayor que la cifra de prosa del cuerpo que cité antes.

La segunda es que un exceso de más de una cuarta parte tiene que superar mi propio criterio. Creo que lo hace por la cuarta condición: un lector que todavía no conoce este método no puede reconstruir una versión comprimida, y las palabras adicionales se destinan a las definiciones y los ejemplos desarrollados que exige esa condición. También es la más fácil de usar indebidamente de las cuatro, así que vale la pena decir qué me haría cambiar de opinión. Si esas palabras se destinaran a reservas innecesarias, repeticiones o un segundo ejemplo que no enseñara nada nuevo, la condición no aplicaría y tendría que recortar el texto.

La versión práctica

Si te quedas con una sola idea: elige primero el presupuesto de tiempo del lector y deja que la longitud se derive de ahí. Treinta segundos son 120 palabras. Cinco minutos son 1,200. La aritmética no es la parte difícil.

La parte difícil es aceptar lo que dice la evidencia sobre revisión. Está demostrado que la segunda mitad de una respuesta larga recibe menos revisión, así que una advertencia que pongas ahí queda oculta, no comunicada. Cuando un modelo responde con 2,000 palabras y bastarían 200, no ha sido exhaustivo: te ha trasladado el costo de su incertidumbre, y lo pagarás al aprobar algo que no leíste. Elige el presupuesto de tiempo antes de que el modelo lo elija por ti.

Lecturas relacionadas

• Por qué funcionan mejor las respuestas concisas de IA — el argumento de carga cognitiva a favor de la concisión y la divulgación progresiva, al que este artículo pone cifras.
• ¿Está generando la IA un mundo de código basura? — el mismo argumento sobre la capacidad de revisión aplicado al volumen de código generado.
• Cómo revisar respuestas generadas por IA — la rúbrica para evaluar lo que sí lees.

Fuentes

• Brysbaert, M., ¿Cuántas palabras leemos por minuto? Una revisión y metaanálisis de la velocidad de lectura, Journal of Memory and Language 109, artículo 104047, December 2019 - 190 estudios y 18,573 participantes; 238 palabras por minuto en lectura silenciosa de textos de no ficción en inglés, con un rango habitual de 175-300 palabras por minuto.
• Nielsen, J., ¿Qué tan poco leen los usuarios?, Nielsen Norman Group, May 6, 2008 - como máximo se lee el 28% de las palabras por visita promedio; el 20% es más realista; los lectores solo terminan la mitad del contenido cuando hay 111 palabras o menos.
• Fregnan, E., Braz, L., D’Ambros, M., Çalıklı, G., y Bacchelli, A., El primero en llegar es el primero en ser atendido: el impacto de la posición de los archivos en la revisión de código, ESEC/FSE 2022 - 219,476 pull requests más un experimento controlado con 106 participantes; un 64% menos de probabilidades de detectar un defecto en un caso límite cuando su archivo se muestra al final. El segundo tipo de defecto introducido no mostró ningún efecto de posición.
• Sadowski, C., Söderberg, E., Church, L., Sipko, M., y Bacchelli, A., Revisión de código moderna: un estudio de caso en Google, ICSE-SEIP 2018 - aproximadamente nueve millones de cambios revisados; tamaño mediano del cambio de 24 líneas, mediana de un revisor y tiempo mediano hasta la aprobación inferior a cuatro horas.
• Bacchelli, A., y Bird, C., Expectativas, resultados y desafíos de la revisión de código moderna, ICSE 2013 - análisis de 570 comentarios de revisión; aproximadamente el 14% identificó defectos pese a que encontrarlos era la principal motivación declarada.
• Sadowski, C., van Gogh, J., Jaspan, C., Söderberg, E., y Winter, C., Tricorder: construcción de un ecosistema de análisis de programas, ICSE 2015, páginas 598-608 - umbrales de gestión de fatiga por alertas; una tasa de resultados no útiles igual o superior al 10% coloca a un analizador en período de prueba, y por encima del 25% puede desactivarse.
• Yuan, W., Kulikov, I., Yu, P., Cho, K., Sukhbaatar, S., Weston, J., y Xu, J., Cumplimiento de restricciones de longitud en instrucciones, prepublicación en arXiv, June 2024 - GPT-4 (0409) incumplió límites explícitos de longitud en el 49.3% de las respuestas de AlpacaEval-LI y el 44.2% de las de MT-Bench-LI; Llama3-8B-Instruct incumplió en el 7.0% y el 20.0%.
• Dong, J., Zhang, Y., Liu, Y., Zhong, Z., Wei, T., Zhang, C., y Qiu, H., Una nueva mirada a la confiabilidad de los modelos de lenguaje al seguir instrucciones, ACL 2026, páginas 7784-7812 - un estudio piloto con 10,944 prompts instanciados (Qwen3-8B) que muestra que un pequeño cambio en la cantidad de palabras solicitada, como pasar de «como máximo 600» a «como máximo 610», hace que muchos casos que antes pasaban dejen de hacerlo. Para la restricción number words, la caída de precisión con un solo prompt a reliable@10 en diez reformulaciones es de 96.0 a 88.0 para GPT-5 y de 83.1 a 40.0 para Qwen3-32B. Ten en cuenta que esto mide la consistencia entre reformulaciones, no una tasa bruta de incumplimiento.
• OpenAI, Cómo controlar la longitud de las respuestas de los modelos de OpenAI - el control verbosity de GPT-5 acepta low, medium y high, e «influye en el nivel de detalle, pero no en los límites estrictos»; reasoning.effort se documenta por separado.
• OpenAI, Cómo entender y contar tokens - reglas prácticas oficiales para el inglés: un token equivale aproximadamente a cuatro caracteres, aproximadamente a tres cuartos de palabra, y 100 tokens equivalen aproximadamente a 75 palabras.
• Anthropic, Cómo manejar las razones de detención - stop_reason: "max_tokens" indica una respuesta truncada; la solución documentada es elevar max_tokens o continuar la respuesta.
• METR, Medición del impacto de la IA de principios de 2025 en la productividad de desarrolladores experimentados de código abierto, July 10, 2025 - ensayo controlado aleatorizado con 16 desarrolladores en 246 tareas; una reducción de velocidad del 19% frente a un aumento de velocidad previsto del 24% y una percepción posterior de un aumento del 20%. METR ahora marca esta página como desactualizada y remite a un seguimiento de February 2026. Trata el 19% como un resultado sobre las herramientas de principios de 2025, no sobre las actuales.
• Niederhoffer, K., Kellerman, G. R., Lee, A., Liebscher, A., Rapuano, K., y Hancock, J. T., El «workslop» generado por IA está destruyendo la productividad, Harvard Business Review, September 22, 2025 - encuesta de BetterUp Labs y Stanford Social Media Lab a 1,150 trabajadores de oficina de Estados Unidos; el 40% recibió workslop en el mes anterior. Son datos de encuesta autodeclarados, útiles como percepción más que como medición. El texto principal de HBR está detrás de un muro de pago. El tamaño de la muestra, el 40% y el costo de tiempo están confirmados en la página pública de investigación de BetterUp, que lo expresa como «2 hrs». La cifra más precisa de 1 hora y 56 minutos solo circula en cobertura secundaria, por lo que no se usa aquí.