Acho que esse é um dos pontos que mais tenho refletido ultimamente.
Na empresa onde estou hoje, entrei em um contexto de negócio novo, com uma dinâmica de trabalho diferente da que eu estava acostumado. Além disso, tenho reuniões em espanhol e inglês uma atrás da outra, o que por si só já exige bastante adaptação. Quando somo esse contexto de aprender melhor dois idiomas, entender uma nova área de atuação e ainda acompanhar as novidades quase semanais do mundo de IA, às vezes bate uma certa ansiedade sobre o que usar, como usar e quando realmente vale a pena mudar o fluxo.

Um exemplo recente disso é o Claude Fable 5, que parece reagir aos prompts de uma forma bem diferente dos modelos anteriores. Como desenvolvedores, acho que já estamos acostumados com a ideia de estudar continuamente e nos revalidar o tempo todo. Mas, no caso de IA, tenho a impressão de que a velocidade está ainda mais difícil de acompanhar. Vejo colegas de trabalho com a mesma sensação: não é só aprender uma ferramenta nova, é entender modelos, custos, janelas de contexto, formas de prompt, agentes, MCPs, skills, compressão de contexto, segurança e por aí vai.
No fim, acredito que ainda estamos nos adaptando de fato a esse novo cenário.

Sobre o Headroom, pelo que vi por cima, ele parece estar em uma linha parecida com o RTK AI que eu tinha citado anteriormente, pelo menos no objetivo geral de tentar reduzir ruído e otimizar o que chega ao contexto do modelo. Ainda não testei nenhum dos dois com profundidade, então não tenho uma opinião fechada, mas acho bem interessante esse movimento de criar uma camada mais controlada entre o ambiente de desenvolvimento e o LLM.

Sobre o ponto de usar o mesmo harness e o mesmo prompt para avaliar modelos, eu concordo parcialmente.
Para uma primeira métrica comparativa, acho que faz bastante sentido. Se a ideia é criar uma baseline controlada, usar o mesmo cenário, o mesmo harness e o mesmo prompt ajuda a reduzir variáveis e comparar consumo de tokens, tempo, custo e qualidade final de uma forma mais objetiva.
Por outro lado, não sei se isso mede necessariamente o melhor uso possível de cada modelo. Cada modelo parece reagir de forma bem diferente ao mesmo tipo de instrução. Por exemplo, tenho a sensação de que um prompt mais curto e com pouco contexto pode funcionar razoavelmente bem em um modelo, mas gerar resultados bem piores em outro. Em alguns casos, o modelo parece precisar de mais estrutura; em outros, funciona melhor com instruções mais diretas.
Por isso, gosto da ideia de separar duas etapas: primeiro uma homologação padronizada, para ter uma comparação mais justa entre modelos; depois uma etapa de adaptação, tentando entender qual é o melhor formato de prompt e fluxo para extrair o melhor daquele modelo específico.

Vejo isso de forma parecida com linguagens de programação. Dá para resolver muitos problemas comuns em várias linguagens diferentes, mas isso não significa que todas terão a mesma ergonomia, performance, produtividade ou custo de manutenção para aquele contexto. Com LLMs, tenho sentido algo parecido: dá para usar o mesmo modelo para quase tudo, mas isso não significa que ele será igualmente eficiente em planejamento, implementação, revisão, debugging ou escrita técnica.

Então, no meu caso, ainda defendo a ideia de testar cada modelo considerando o contexto em que ele será usado. Não só “qual modelo responde melhor ao mesmo prompt?”, mas também “qual modelo entrega melhor quando usado da forma mais adequada para ele?”.

No fim, acho que a grande dificuldade está em equilibrar padronização e adaptação. Sem padronização, fica difícil medir. Sem adaptação, talvez a gente acabe descartando um modelo bom simplesmente porque tentou usá-lo com um fluxo que não combina tanto com ele.

E concordo bastante com seu ponto final: parece ser uma disciplina em construção. Ter uma etapa de homologação sistematizada deve ajudar muito, principalmente porque o cenário muda rápido demais. Um modelo novo, um harness melhor ou uma estratégia diferente de compressão de contexto podem mudar bastante a conclusão de um mês para o outro.