A Normalização de Falhas Inexplicáveis
Software e dispositivos conectados falham cada vez mais de maneiras que usuários e até desenvolvedores não conseguem explicar, desde quedas opacas de serviços em nuvem até erros enigmáticos em carros modernos, fomentando uma cultura de “essa coisa idiota é uma porcaria” em vez de responsabilidade clara e análise de causa raiz. Os comentaristas relacionam essa mudança a sistemas probabilísticos e ferramentas movidas por IA, à pressão da gestão por velocidade em detrimento do rigor e à menor ênfase em práticas tradicionais de engenharia, alertando que normalizar essas falhas inexplicáveis corrói a confiança e a confiabilidade em toda a pilha. Outros argumentam que, com avaliação, testes e uso restrito em domínios críticos para a segurança, a IA ainda pode ser um auxílio poderoso em vez de uma fonte de caos.
Escopo das “falhas inexplicáveis”
- Os comentaristas veem falhas opacas, difíceis de depurar, como cada vez mais comuns em:
- Serviços em nuvem e APIs que intermitentemente retornam 5xx, com “é só tentar de novo” como norma.
- Dispositivos de consumo (especialmente carros) mostrando avisos vagos e conectividade instável, sem diagnóstico claro.
- Comportamento cotidiano de software/SO em que “desliga e liga de novo” é a correção de fato.
- Alguns argumentam que isso sempre foi assim; outros acham que “mova-se rápido e quebre coisas”, a implantação contínua e a redução de QA pioraram isso de forma perceptível.
Determinismo, sistemas probabilísticos e IA
- Sistemas determinísticos são elogiados por modos de falha previsíveis e contratos claros; sistemas probabilísticos/ baseados em LLM são vistos como poderosos, mas difíceis de entender ou garantir.
- Preocupação: normalizar comportamento probabilístico em bibliotecas centrais, infraestrutura e compiladores pode corroer a confiabilidade de toda a pilha.
- Contraponto: até código gerado por IA continua sendo determinístico depois de escrito; o verdadeiro problema é a manutenibilidade e a qualidade do design, não a probabilidade em si.
Cultura de engenharia, qualidade e responsabilidade
- Há discordância sobre se “bugs são inevitáveis”:
- Um lado: bugs são em grande parte uma escolha de negócio; “sem bugs” é possível, mas caro demais para a maioria.
- Outro lado: pilhas profundas e sistemas distribuídos complexos tornam algumas falhas efetivamente inevitáveis; deve-se projetar para imperfeição e resiliência (por exemplo, chaos testing).
- Histórias de:
- Debates entre superengenharia e YAGNI, com casos de borda descartados até morderem.
- Empresas encobrindo problemas sistêmicos com reinicializações por cron e tolerância a latências de cauda horríveis.
- Vários relacionam a “inexplicabilidade” à falta de responsabilidade: a culpa pode ser empurrada para fornecedores, nuvens ou agora “a IA”.
Experiência do usuário e relatórios de erro
- Diálogos de erro opacos (“algo deu errado”) são amplamente criticados.
- Muitos prefeririam mensagens detalhadas, até técnicas, e logging adequado em vez de alertas vagos.
- O design minimalista de “simplesmente funciona” é visto como tendo um “gêmeo maligno”: “simplesmente não funciona, e você não consegue ver por quê”.
Domínios de alto risco e tolerâncias diferentes
- Banco tradicional e aviação são citados como domínios que ainda exigem baixas taxas de erro e comportamento rastreável, embora haja contraexemplos e falhas bancárias visíveis para consumidores.
- O argumento é que a exposição a tais domínios elevaria os padrões dos desenvolvedores; outros enfatizam que os incentivos da gestão (velocidade, custo) superam as preocupações com qualidade.
LLMs, desenvolvimento agentivo, Jev e evals
- Muitos usam LLMs intensamente e relatam que eles:
- Aceleram o desenvolvimento, incluindo testes.
- Podem tanto introduzir quanto corrigir bugs rapidamente, se combinados com forte cultura de testes e de determinismo/reprodutibilidade.
- Preocupações:
- OSS e software de negócios “programados no feeling” (vibe-coded): mais recursos, mas UX incoerente, problemas de desempenho e comportamentos difíceis de depurar.
- Gestores usando IA para entregar mais, mais rápido, normalizando taxas de falha silenciosas de 10% como “bom o suficiente”.
- Serviços de classificação como Jev:
- Alguns relatam ter validado seus escores de confiança e encontrado desempenho forte e custo-efetivo.
- Outros enfatizam que essa validação (evals, benchmarks, testes A/B) é exatamente o que muitas vezes falta; confiar na própria confiança da ferramenta sem evals independentes é apontado como perigoso.
- Consenso amplo: bons evals são difíceis, mas essenciais. Sem eles, demonstrações empolgantes de IA podem ocultar desempenho medíocre no mundo real e aprofundar a cultura de falhas inexplicáveis.