BLOG
Tecnologia, código, experimentos e algumas opiniões não solicitadas.
ActivitySource gera os traces, Meter gera as métricas, e o exportador OTLP manda tudo isso para o backend de observabilidade escolhido, sem acoplar o código da aplicação a um fornecedor específico.
Modelo mais capaz custa mais e responde mais devagar. Modelo mais rápido e barato erra mais. Não existe ponto que otimize os três eixos ao mesmo tempo, só existe qual trade-off faz sentido para cada c …
Linha executada não é a mesma coisa que comportamento verificado. Um teste sem asserção relevante ainda conta como cobertura, e é exatamente aí que a métrica engana quem só olha o número final.
Shingeki no Kyojin e Fate/Zero não dividem o conflito entre herói e vilão. Dividem entre visões de mundo incompatíveis, cada uma coerente por dentro, e é isso que torna as duas difíceis de largar.
Usar um modelo para avaliar outro resolve o problema de escala e cria um novo: quem garante que o próprio julgador está certo? Calibração contra avaliação humana continua sendo necessária.
Testcontainers sobe um Postgres, Redis ou LocalStack de verdade em container Docker durante a execução dos testes, e derruba tudo no final, sem deixar rastro no ambiente local.
Senioridade deveria significar melhores perguntas, não certeza automática. Confundir as duas coisas é fácil, e o custo de confundir normalmente aparece tarde demais para corrigir barato.
Mudar um prompt e testar na mão umas cinco perguntas antes de subir para produção não prova nada sobre os outros cem casos que ninguém olhou. Regressão automatizada existe para isso.
Uma suíte inteira de testes unitários com repositório, banco e API externa mockados pode passar 100% verde e ainda assim não provar que o sistema funciona quando essas peças de verdade entram em cena.
Usar um modelo para avaliar a resposta de outro modelo escala revisão que seria inviável fazer manualmente, mas carrega vieses conhecidos, como preferir a primeira opção ou a resposta mais longa.