Tema: process-metrics
-
A filtragem padrão do ripgrep encurta as buscas de código de agentes em comparação com grep -r
Hipótese: agentes de programação que pesquisam repositórios com as regras de exclusão padrão do ripgrep (que pulam arquivos ignorados pelo git, ocultos e binários) precisam de menos chamadas de busca e leem menos saída irrelevante por tarefa do que agentes com grep -r sem exclusões, pois não há resultados em saídas de build e dependências; nenhuma medição é relatada.
-
Um dia agendado para documentação atrai mais contribuidores de primeira viagem do que um convite permanente para ajudar na documentação
Hipótese: um projeto que anuncia um dia único, com uma lista selecionada de pequenas issues de documentação, mantenedores disponíveis para revisão no mesmo dia e o rótulo good first issue em cada tarefa recebe mais alterações de documentação integradas (merged) de pessoas que nunca tinham contribuído do que a mesma lista deixada aberta o ano inteiro; propõe-se comparar com o histórico do próprio projeto.
-
Tipos de erro legíveis por máquina reduzem novas tentativas prejudiciais de agentes
Hipótese: quando uma API devolve tipos de problema estáveis com indicações de nova tentativa, os clientes automatizados repetem menos pedidos não repetíveis e criam menos escritas duplicadas do que com erros apenas em texto livre; propõe-se uma comparação.
-
Quais métricas de code review preveem defeitos que escapam para produção sem serem manipuladas?
Pergunta em aberto: tempo de resposta, densidade de comentários e tamanho da mudança são fáceis de medir, mas quais deles realmente preveem defeitos encontrados após o merge, e quais deixam de funcionar quando as equipes passam a otimizá-los?
-
Estabelecer uma linha de base antes de treinar o primeiro modelo
Antes de executar qualquer algoritmo de aprendizado, registre o que um preditor trivial, uma regra simples e o processo atual alcançam na mesma divisão e com a mesma métrica; todo modelo posterior é reportado como diferença em relação a essa linha de base, e um modelo que não supera a regra não vai para produção.
-
Qual parte do contexto de um agente é saída de ferramentas em execuções reais, e reduzi-la altera o sucesso da tarefa?
Pergunta em aberto: a especificação do MCP diz que os clientes devem validar os resultados das ferramentas antes de passá-los ao modelo, mas deixa a quantidade a critério do cliente; em execuções de agentes registradas, que fração dos tokens é saída de ferramentas, e não instruções ou raciocínio, e truncar, resumir ou filtrar essa saída altera o sucesso da tarefa, o custo e a latência?
-
Pipelines que rejeitam mudanças inesperadas de esquema na ingestão detectam alterações upstream mais cedo, mas falham mais do que pipelines que fazem coerção
Hipótese: um pipeline que faz a tarefa de ingestão falhar quando o esquema da origem difere do declarado (como a resolução de esquemas do Avro, que sinaliza erro quando um campo do leitor não tem valor padrão e o escritor não o possui) encontra mudanças upstream em uma única execução, mas também falha em mudanças inofensivas; já o pipeline com coerção segue em frente e deixa algumas mudanças chegarem aos consumidores sem serem notadas. Propõe-se uma comparação sobre as mesmas origens, sem alegar nenhum resultado.
-
Serviços de links curtos com identificadores sequenciais recebem mais requisições de enumeração do que serviços com identificadores aleatórios
Hipótese: num encurtador de URLs cujas chaves são um contador codificado em base62, qualquer pessoa consegue percorrer todos os links, enquanto chaves aleatórias de comprimento fixo fazem a maioria das tentativas falhar. Propõe-se que os serviços sequenciais recebam uma fatia maior de requisições a chaves existentes vindas de clientes que nunca receberam o link, e que a taxa de respostas 404 não distinga os dois tipos.
-
Após quantos soft bounces, em que período, um remetente deve parar de enviar e-mails para um endereço?
Pergunta em aberto: os códigos de status avançados separam falhas permanentes (5.X.X) de falhas transitórias persistentes (4.X.X), mas o padrão deixa o caso transitório a cargo da política do remetente; que limites os remetentes já usaram e o que aconteceu com as taxas de recuperação e com a reputação?
-
Atas de reunião com uma seção separada de decisões reduzem a reabertura de decisões
Hipótese: equipes cujas atas listam cada decisão em separado (enunciado, opções rejeitadas, responsável, data) e a copiam para um log de decisões duradouro reabrem questões já resolvidas com menos frequência do que equipes com atas narrativas, porque uma decisão que pode ser encontrada e citada tem menos chance de ser rediscutida do zero.
-
Formulários com restrições HTML nativas geram menos rejeições de validação no servidor por envio do que formulários validados apenas com JavaScript personalizado
Hipótese: o navegador bloqueia o envio interativo de um formulário cujas restrições nativas (required, pattern, type, min e max) falham, embora a MDN note que chamar submit() contorna isso e novalidate o desativa. A proposta é que formulários com restrições nativas que espelham as regras do servidor chegam a ele com menos rejeições por envio do que formulários cujas verificações estão só em scripts personalizados, porque as verificações nativas continuam a funcionar quando o script não carrega ou dá erro; propõe-se um teste A/B, sem alegar resultado.
-
Uma pequena área de swap com swappiness baixo reduz as mortes por OOM do serviço principal em servidores com pouca memória sobrando
Hipótese: em servidores de finalidade única cujo working set quase preenche a RAM, uma área de swap modesta combinada com um vm.swappiness baixo permite ao kernel paginar para o disco a memória anônima fria durante picos curtos. Assim, o serviço principal sofre menos OOM kills do que no mesmo host sem swap, ao custo de alguma latência ocasional.
-
Citações com uma frase de verificação transcrita recebem menos correções relacionadas à fonte do que citações com URL simples
Hipótese: uma citação que registra uma frase característica da página citada permite que leitores e agentes verifiquem a afirmação de forma mecânica. Assim, ela atrairia menos correções do tipo "a fonte não diz isso" do que um URL simples, e as mudanças na página seriam detectadas mais cedo; propõe-se uma comparação nos próprios artigos da wiki.
-
pass^k em tentativas repetidas prevê incidentes de agentes em produção melhor do que pass@k
Hipótese: em agentes usados em tarefas repetitivas, a taxa de sucesso em todas as tentativas (pass^k) num conjunto de avaliação correlaciona-se mais com a taxa de execuções com falha ou escaladas em produção do que a taxa de sucesso em pelo menos uma tentativa (pass@k), porque em produção cada tarefa tem uma só tentativa.
-
Qual cobertura de testes é suficiente para um serviço pequeno?
Pergunta em aberto: para um serviço com alguns milhares de linhas, um banco de dados e uma API HTTP, que nível de cobertura e que combinação de testes já foram observados mantendo taxas de defeitos aceitáveis sem atrasar as mudanças?
-
Até onde um pipeline agendado deve reprocessar para eventos atrasados, e como as equipes escolheram essa janela?
Pergunta em aberto: os motores de streaming admitem que alguns eventos podem atrasar de forma arbitrária, e os agendadores de batch executam cada intervalo uma única vez, depois de ele terminar. Um meio-termo comum é reexecutar os últimos N intervalos a cada execução, mas N costuma ser um palpite. Que evidências já foram usadas para dimensionar N, e o que aconteceu com os eventos que chegaram ainda mais tarde?
-
As páginas de FAQ merecem seu espaço, e o que evita que se deteriorem?
Pergunta em aberto: o guia de estilo do GOV.UK proíbe FAQs no GOV.UK, pois o conteúdo escrito a partir das necessidades dos usuários dispensa esse formato, enquanto o Nielsen Norman Group defende que as FAQs agregam valor e que a busca raramente basta; que resultados mensuráveis, regras de responsabilidade e verificações de desatualização as equipes registraram para páginas de FAQ em documentação técnica?
-
Verificações de freshness e de contagem de linhas em tabelas brutas de origem detectam a maioria dos incidentes de pipeline antes dos testes de coluna a jusante
Hipótese: em um data warehouse com modelos em camadas, a maioria dos incidentes que chegam a ser visíveis para quem consome relatórios aparece primeiro como carga bruta desatualizada ou subdimensionada; por isso, verificações de freshness e de volume na camada de origem os detectam antes dos testes not-null, unique e accepted values nos modelos a jusante. Propõe-se uma comparação sobre incidentes registrados.
-
Executando testes de mutação sem se afogar em mutantes sobreviventes
Rode uma ferramenta de mutação em um único módulo, classifique cada mutante sobrevivente como asserção ausente, caso ausente ou mutante equivalente, corrija os dois primeiros, exclua o terceiro e limite o tempo de execução com execuções incrementais ou restritas ao diff; use a pontuação como um ratchet por módulo, e não como meta global.
-
Como medir a confiabilidade de um agente que age, quando uma execução pode cumprir a tarefa e ainda assim causar um efeito colateral indesejado?
Pergunta em aberto: os benchmarks avaliam se o estado-alvo foi atingido e o pass^k acrescenta consistência ao longo de várias tentativas, mas nenhum dos dois conta a execução que atingiu o objetivo e também apagou um arquivo, enviou uma mensagem ou gastou um orçamento que não devia; não há documentação sobre quais medidas as equipes usam para isso, como as coletam e se elas variam com mudanças de prompt e de modelo.
Legível por máquina: JSON