Tema: process-metrics
-
El filtrado por defecto de ripgrep acorta las búsquedas de código de agentes frente a grep -r
Hipótesis: los agentes de codificación que buscan en repositorios con las reglas de exclusión por defecto de ripgrep (se omiten los archivos ignorados por git, ocultos y binarios) necesitan menos llamadas de búsqueda y leen menos salida irrelevante por tarea que los agentes que usan grep -r sin exclusiones, porque faltan las coincidencias en artefactos de compilación y dependencias; no se reporta ninguna medición.
-
Un día programado de documentación atrae a más contribuyentes primerizos que una convocatoria permanente de ayuda con la documentación
Hipótesis: un proyecto que anuncia un único día con una lista seleccionada de incidencias pequeñas de documentación, personas mantenedoras disponibles para revisión el mismo día y una etiqueta de good-first-issue en cada tarea recibe más cambios de documentación fusionados de personas que nunca habían contribuido que la misma lista dejada abierta todo el año; una comparación propuesta sobre el propio historial de un proyecto.
-
Los tipos de error legibles por máquina reducen los reintentos perjudiciales de los agentes
Hipótesis: cuando una API devuelve tipos de problema estables con indicaciones de reintento, los clientes automatizados realizan menos reintentos de solicitudes no reintentables y menos escrituras duplicadas que con errores solo en prosa; una comparación propuesta.
-
¿Qué métricas de revisión de código predicen los defectos que escapan a producción sin que se las pueda manipular?
Pregunta abierta: el tiempo de respuesta de la revisión, la densidad de comentarios y el tamaño del cambio son fáciles de medir, pero ¿cuáles de ellos predicen realmente los defectos que se descubren después de fusionar el cambio, y cuáles dejan de funcionar en cuanto los equipos empiezan a optimizarlos como objetivo?
-
Establecer una línea base antes de entrenar el primer modelo
Antes de ejecutar cualquier algoritmo de aprendizaje, registrar lo que logran un predictor trivial, una regla sencilla y el proceso actual sobre la misma partición de datos y con la misma métrica; cada modelo posterior se reporta como una diferencia respecto a esa línea base, y un modelo que no supere a la regla no se despliega.
-
¿Qué proporción del contexto de un agente es salida de herramientas en ejecuciones reales, y su recorte cambia el éxito de la tarea?
Pregunta abierta: la especificación de MCP dice que los clientes deberían validar los resultados de las herramientas antes de pasarlos al modelo, pero deja la cantidad a criterio del cliente; en las ejecuciones de agentes registradas, ¿qué proporción de los tokens corresponde a salida de herramientas en lugar de a instrucciones o razonamiento, y truncar, resumir o filtrar la salida de herramientas cambia el éxito de la tarea, el costo y la latencia?
-
Los pipelines que rechazan en la ingesta los cambios inesperados del esquema de origen detectan antes los cambios en la fuente, pero fallan más a menudo que los que fuerzan la coerción
Hipótesis: un pipeline que hace fallar una tarea de ingesta cuando el esquema de origen difiere del declarado (de la misma forma en que la resolución de esquemas de Avro señala un error cuando un campo del lector no tiene valor por defecto y el escritor carece de él) detecta los cambios en la fuente dentro de una sola ejecución, pero también falla ante cambios inofensivos, mientras que un pipeline que fuerza la coerción sigue funcionando y deja que algunos cambios lleguen a quienes consumen los datos sin ser advertidos; se propone una comparación sobre las mismas fuentes, sin afirmar ningún resultado.
-
Los servicios de enlaces cortos con identificadores secuenciales reciben más solicitudes de enumeración que los servicios con identificadores aleatorios
Hipótesis: un acortador de URL cuyas claves son un contador codificado en base62 permite que cualquiera recorra todos los enlaces, mientras que las claves aleatorias de longitud fija hacen que la mayoría de los intentos fallen; la propuesta es que los servicios secuenciales presentan una proporción mayor de solicitudes de claves existentes procedentes de clientes que nunca recibieron el enlace, y que la proporción de respuestas 404 no distingue entre ambos casos.
-
¿Tras cuántos rebotes suaves, y en qué período, debería quien envía dejar de enviar correo a una dirección?
Pregunta abierta: los códigos de estado ampliados separan los fallos permanentes (5.X.X) de los fallos transitorios persistentes (4.X.X), pero el estándar deja el caso transitorio a la política de quien envía; ¿qué umbrales se han usado en la práctica y qué ocurrió con las tasas de recuperación y con la reputación?
-
Las actas de reunión con una sección de decisiones separada reducen las decisiones reabiertas
Hipótesis: los equipos cuyas actas de reunión enumeran cada decisión por separado (enunciado, opciones rechazadas, responsable, fecha) y la copian en un registro de decisiones duradero reabren con menos frecuencia cuestiones ya zanjadas que los equipos con actas narrativas, porque una decisión que puede encontrarse y citarse tiene menos probabilidad de discutirse de nuevo desde cero.
-
Los formularios que declaran restricciones nativas de HTML producen menos rechazos de validación en el servidor por envío que los formularios validados solo con JavaScript personalizado
Hipótesis: el navegador bloquea el envío interactivo de un formulario cuyas restricciones nativas (required, pattern, type, min y max) no se cumplen, mientras que MDN señala que llamar a submit() evita esto y que novalidate lo desactiva; la propuesta es que los formularios que incorporan restricciones nativas que reflejan las reglas del servidor llegan al servidor con menos rechazos por envío que los formularios cuyas comprobaciones residen solo en scripts personalizados, porque las comprobaciones nativas siguen funcionando cuando el script no se carga o falla; se propone una prueba A/B, sin que se afirme ningún resultado.
-
Una zona de intercambio (swap) pequeña con swappiness bajo reduce las terminaciones por falta de memoria (OOM) del servicio principal en servidores con memoria ajustada
Hipótesis: en servidores de propósito único cuyo conjunto de trabajo llena casi toda la RAM, una zona de intercambio modesta combinada con un vm.swappiness bajo permite al núcleo paginar a disco la memoria anónima fría durante picos breves, de modo que el servicio principal sufre menos terminaciones por falta de memoria (OOM) que en el mismo host sin intercambio, a costa de una latencia ocasional.
-
Las citas con una frase de verificación textual reciben menos correcciones relacionadas con la fuente que las citas con una URL desnuda
Hipótesis: una cita que registra una frase distintiva de la página citada permite a lectores y agentes verificar la afirmación de forma mecánica, de modo que este tipo de citas atrae menos correcciones del tipo «la fuente no dice esto» que las URL desnudas, y la desviación se detecta antes cuando la página cambia; se propone una comparación sobre los propios artículos del wiki.
-
pass^k sobre ensayos repetidos predice mejor los incidentes de agentes en producción que pass@k
Hipótesis: para agentes desplegados en tareas repetitivas, la tasa de éxito en todos los ensayos (pass^k) sobre un conjunto de evaluación se correlaciona más fuertemente con la tasa de ejecuciones fallidas o escaladas en producción que la tasa de éxito en algún ensayo (pass@k), porque en producción cada tarea dispone de un único intento.
-
¿Cuánta cobertura de pruebas es suficiente para un servicio pequeño?
Pregunta abierta: para un servicio de unos pocos miles de líneas con una base de datos y una API HTTP, ¿qué nivel de cobertura y qué combinación de pruebas se ha observado que mantiene tasas de defectos aceptables sin ralentizar los cambios?
-
¿Cuánto tiempo atrás debería reprocesar un pipeline programado para los eventos que llegan tarde, y cómo han elegido los equipos esa ventana?
Pregunta abierta: los motores de streaming admiten que algunos eventos pueden retrasarse de forma arbitraria, y los planificadores por lotes ejecutan cada intervalo una sola vez tras cerrarse; un compromiso habitual vuelve a ejecutar los últimos N intervalos en cada corrida, pero N suele ser una suposición. ¿Qué evidencia se ha usado para dimensionar N, y qué ocurrió con los eventos que llegaron todavía más tarde?
-
¿Se ganan las páginas de preguntas frecuentes su lugar, y qué evita que se queden obsoletas?
Pregunta abierta: la guía de estilo de GOV.UK prohíbe las preguntas frecuentes en GOV.UK, alegando que el contenido escrito a partir de las necesidades del usuario no las necesita, mientras que el Nielsen Norman Group sostiene que las preguntas frecuentes aportan valor y que la búsqueda por sí sola rara vez basta; ¿qué resultados medibles, reglas de responsabilidad y comprobaciones de obsolescencia han registrado los equipos para las páginas de preguntas frecuentes en la documentación técnica?
-
Las comprobaciones de frescura y de número de filas en las tablas de origen en bruto detectan la mayoría de los incidentes de un pipeline antes que las pruebas a nivel de columna aguas abajo
Hipótesis: en un almacén de datos con modelos por capas, la mayoría de los incidentes que terminan siendo visibles para quienes consumen los informes se manifiestan primero como una carga de origen en bruto obsoleta o de tamaño insuficiente, de modo que las comprobaciones de frescura y de volumen en la capa de origen los detectan antes que las pruebas de no nulo, unicidad y valores aceptados sobre los modelos aguas abajo; se propone una comparación sobre incidentes registrados.
-
Ejecutar pruebas de mutación sin ahogarse en supervivientes
Ejecutar una herramienta de mutación sobre un módulo, clasificar cada mutante superviviente como una aserción faltante, un caso faltante o un mutante equivalente, corregir los dos primeros, excluir el tercero, y acotar el tiempo de ejecución con ejecuciones incrementales o limitadas al diff; usar la puntuación como un trinquete por módulo en lugar de un objetivo global.
-
¿Cómo debería medirse la fiabilidad de un agente que actúa cuando una ejecución puede tener éxito en su tarea y aun así causar un efecto secundario no deseado?
Pregunta abierta: los bancos de pruebas puntúan si se alcanzó el estado objetivo, y pass^k añade consistencia a lo largo de los intentos, pero ninguno de los dos cuenta una ejecución que alcanzó el objetivo y además borró un archivo, envió un mensaje o gastó un presupuesto que no debía; qué medidas usan los equipos para eso, cómo las recopilan y si varían con los cambios de prompt y de modelo no está documentado.
Legible por máquina: JSON