Zombamos do “slop” da IA enquanto organizações humanas gigantes produzem o delas há décadas.
Anda havendo muito lamento por causa do “slop” gerado por IA.
Sites gerados por IA. Código gerado por IA. Conteúdo gerado por IA. Interfaces que parecem mais ou menos certas até você tentar usá-las. Funcionalidades que existem tecnicamente, mas que claramente ninguém pensou direito. Produtos que dão a sensação de que alguém digitou um prompt, deu uma olhada no resultado e publicou.
Boa parte dessa crítica é merecida. Mas os humanos vêm produzindo software lixo há décadas, e às vezes fazem isso com recursos que uma startup de IA mal conseguiria imaginar.
Encontrei recentemente um exemplo especialmente bonito na Enbridge, uma empresa cuja capitalização de mercado girava em torno de US$ 110 bilhões quando fui verificar.
A capitalização da Enbridge no dia em que tentei pagar minha conta de gás.
Pare um instante nesse número.
Cento e dez bilhões de dólares.
Imagine o que você poderia construir com acesso a uma fração mínima dos recursos de uma organização desse porte. Poderia contratar engenheiros de elite de qualquer lugar do mundo. Poderia manter times dedicados de produto, design, segurança, acessibilidade, QA, infraestrutura e experiência do cliente. Poderia testar cada fluxo em todos os navegadores, dispositivos, redes de pagamento e métodos de autenticação relevantes. Poderia fazer estudos de usabilidade até enjoar.
Poderia construir um site extraordinário.
Em vez disso, a Enbridge construiu um que não me deixa usar uma senha com mais de 13 caracteres.
Isso é HumanSlop.
Minha empresa de gás “modernizou” o site
Fui parar no novo site da Enbridge porque recebi um aviso de que o pagamento online da minha conta pelo banco havia sido cancelado. Eu já tinha um jeito perfeitamente funcional de pagar o gás, mas a Enbridge mudou algo do lado dela e me obrigou a migrar.
Tudo bem. Sistemas mudam.
Entrei no site novo, tentei criar minha conta e fui recebido com isto:
A senha não pode ter mais de 13 caracteres.
A resposta que o meu gerenciador de senhas recebeu.
Treze caracteres.
Em 2026.
Passamos anos dizendo às pessoas para usarem gerenciadores de senhas, gerarem senhas longas e aleatórias e pararem de reutilizar credenciais curtas e memorizáveis. Meu gerenciador fez exatamente o que devia e gerou uma senha forte. O sistema novinho da Enbridge respondeu, em essência:
Calma, calma. Seguro assim não.
Isto não é uma aplicação antiga de tela verde pendurada num mainframe. É o novo site voltado ao cliente de uma das maiores empresas de infraestrutura de energia da América do Norte.
De novo, considere os recursos envolvidos. Uma empresa desse tamanho pode bancar infraestrutura de identidade sofisticada, testes de intrusão, consultores de segurança, suítes de testes automatizados, engenheiros de segurança dedicados e qualquer fornecedor de autenticação que quiser.
Em algum ponto de toda essa maquinaria, a resposta final foi:
Tamanho máximo da senha: 13. Pode subir.
E ainda tem o design
Antes mesmo de esbarrar nos bugs, o site parece resgatado de uma migração de SharePoint em 2003.
Olhe para ele.
Um cabeçalho cinza gigante. Campos de formulário minúsculos. Links azuis sublinhados. Uma caixa lateral com “Entrar” e “Fale conosco”. Blocos densos de instruções. Bordas duras. Botõezinhos. Decisões de layout que lembram menos um portal moderno de clientes e mais algo usado para solicitar benefícios numa repartição municipal em 1998.
E a página ainda anuncia com orgulho:
“Bem-vindo à sua nova experiência online!”
Essa frase talvez seja a parte mais engraçada de tudo.
Nova em comparação com o quê? Com o Telnet?
Esta é uma empresa que vale cerca de US$ 110 bilhões, e sua “nova experiência online” parece o tipo de site onde você espera ver uma tag <marquee> piscando e um selo de “Melhor visualizado no Internet Explorer 6” no rodapé.
O problema não é que todo site corporativo precise parecer com o da Apple. Não precisa. Um portal de faturamento de serviço público deveria ser chato. Deveria ser limpo, rápido, óbvio, acessível e praticamente impossível de estragar.
Mas isto não é chato no bom sentido. Parece velho porque a arquitetura de informação, a tipografia, a hierarquia, os espaçamentos, os controles e os padrões de interação são todos antigos.
E de novo:
US$ 110 bilhões.
Imagine ter um bilhão de dólares para construir software.
Você poderia contratar alguns dos melhores designers de produto do mundo. Poderia construir um design system que funcionasse em todos os pontos de contato com o cliente. Poderia testar o portal com milhares de clientes reais. Poderia tornar o login trivial. Poderia fazer a interface de faturamento funcionar lindamente no desktop e no celular. Poderia se obcecar por acessibilidade, desempenho e usabilidade até não sobrar praticamente nada a melhorar.
Claro que você não precisaria de um bilhão para nada disso. Poderia construir uma versão drasticamente melhor desta página com uma fração ínfima desse valor.
É isso que torna tudo tão engraçado.
Esta não é a história de uma empresa sem recursos.
É a história do que acontece quando os recursos deixam de ser o fator limitante e a qualidade organizacional passa a ser.
E então o site parou de funcionar
Depois de contornar a exigência de senha, comecei a receber falhas genéricas:
“Há um problema do nosso lado. Aguarde alguns minutos e tente novamente.”
A outra coisa que a “nova experiência online” faz.
Isso é irritante em qualquer site, mas o contexto piora tudo. Eu não me inscrevi voluntariamente para testar a empolgante nova experiência digital da Enbridge. Meu fluxo de pagamento antigo funcionava. A Enbridge o removeu e me mandou para o substituto.
Se você vai forçar uma migração aos clientes, o substituto deveria funcionar.
Isso não deveria ser uma filosofia de produto polêmica, ainda mais quando a empresa que força a migração vale onze dígitos.
A empresa de US$ 110 bilhões que esqueceu como o American Express funciona
Finalmente cheguei ao formulário de cartão de crédito. A Enbridge exibia American Express como bandeira aceita, então preenchi meus dados do Amex.
Aí cheguei ao campo do código de segurança.
O American Express usa um código de quatro dígitos.
O formulário da Enbridge permitia três.
Digitei três números e tentei o quarto. Nada aconteceu. O campo simplesmente recusou.
Esse é o meu bug favorito por ser lindamente descomplicado.
Não há um caso limite sofisticado para depurar. Não há condição de corrida escondida num sistema distribuído. Não há incompatibilidade obscura de navegador que só aparece às terças quando Mercúrio está retrógrado.
Cartões American Express têm código de segurança de quatro dígitos.
Se você diz que aceita American Express, seu formulário precisa aceitar quatro dígitos.
É esse o requisito inteiro.
Um desenvolvedor júnior entenderia. Um testador pegaria. Um teste de integração automatizado pegaria. Um gerente de produto pagando o almoço com um Amex pegaria.
Ainda assim, esse bug atravessou toda a maquinaria de engenharia, fornecedores, design, QA, segurança, deploy e aprovações que existe dentro de uma corporação de US$ 110 bilhões e saiu vivo do outro lado.
Isso dá trabalho.
Sério, imagine o que dá para construir com um bilhão de dólares
Um bilhão de dólares é um número tão grande que vira abstração, então esqueça por um momento os US$ 110 bilhões de valor de mercado da Enbridge.
Imagine que alguém te entregue um bilhão de dólares e diga:
Construa a melhor experiência de cliente de serviços públicos da Terra.
O que você conseguiria construir?
Você poderia contratar 500 engenheiros excepcionais a US$ 250 mil por ano e mantê-los por oito anos.
Poderia montar times dedicados de design de produto, frontend, backend, segurança, acessibilidade, confiabilidade, mobile, pagamentos, pesquisa com clientes, analytics, QA e infraestrutura.
Poderia construir ambientes de teste em escala real espelhando produção.
Poderia testar todos os meios de pagamento. Todos os navegadores. Todos os celulares. Todos os cenários de acessibilidade. Todos os fluxos de autenticação.
Poderia pagar clientes reais para passarem o dia tentando quebrar o site. Poderia rodar estudos de usabilidade com todos os perfis que você atende. Poderia contratar especialistas justamente para garantir que pessoas com deficiência visual, limitações motoras ou pouca experiência técnica conseguissem pagar a conta de gás sem frustração.
Poderia fazer um app. Poderia fazer uma experiência web de primeira linha. Poderia construir APIs. Poderia criar previsões de fatura em tempo real, análise de consumo, informações de interrupção, controles de débito automático, compartilhamento de conta, alertas, notificações e integrações com todas as carteiras digitais relevantes.
Provavelmente poderia reconstruir a plataforma inteira várias vezes.
E depois de tudo isso, ainda sobrariam centenas de milhões.
Agora lembre: a Enbridge vale cerca de 110 vezes esse valor.
Obviamente valor de mercado não é dinheiro em caixa. A Enbridge não tem US$ 110 bilhões num cofre esperando alguém gastar em campos de senha. Não é esse o ponto.
O ponto é escala.
Não estamos falando de um fundador com US$ 40 mil na conta tentando manter os servidores de pé.
Estamos falando de uma corporação enorme com acesso praticamente ilimitado ao tipo de expertise necessária para resolver esses problemas.
E o resultado é um site que parece ter décadas, recusa senhas modernas, devolve erros genéricos de servidor e afirma aceitar American Express enquanto recusa um CVV do American Express.
Isso não é um problema de recursos.
Isso é Human Slop.
Mais processo não produz necessariamente software melhor
Uma das suposições mais estranhas do desenvolvimento de software é que mais processo organizacional leva naturalmente a mais qualidade.
Uma empresa gigante presumivelmente tem gerentes de produto, gerentes de projeto, engenheiros, designers, times de segurança, times de QA, fornecedores externos, consultores, processos de conformidade, ambientes de homologação, procedimentos de deploy, sistemas de chamados e cadeias de aprovação. Em tese, tudo isso deveria tornar algo como um formulário de pagamento mais confiável.
Mas complexidade também dilui responsabilidade.
O time de autenticação é dono de um pedaço. O fornecedor de pagamentos, de outro. Um time de frontend é dono do formulário. Um design system dita o componente. Segurança tem requisitos. Produto escreveu os critérios de aceite. QA testou os casos documentados. Um terceirizado construiu parte disso.
Todo mundo pode fazer corretamente a tarefa atribuída e o produto final continuar ruim.
Essa é a parte que acho interessante.
Nenhuma pessoa em particular necessariamente decidiu construir algo burro. A organização produziu burrice coletivamente.
Um sistema pode passar por camadas de revisão humana, planejamento, reuniões, testes, compras e aprovações e ainda assim chegar à produção incapaz de aceitar o código de segurança de um dos cartões que diz aceitar.
Dinheiro compra talento, mas não garante responsabilidade.
Dinheiro compra processo, mas não garante julgamento.
Dinheiro compra times de QA, mas não garante que alguém tenha testado o óbvio.
Às vezes todo esse processo só torna o slop mais caro.
O slop da IA pelo menos tem desculpa
É por isso também que acho parte da indignação com software gerado por IA divertida. Estamos julgando uma tecnologia que existe há poucos anos contra organizações humanas de software que tiveram décadas para resolver isso.
Claro que a IA às vezes produz código ruim. Claro que um agente pode entender errado um requisito. Claro que interfaces geradas podem conter suposições estranhas. São problemas legítimos, e software gerado por IA deve absolutamente ser testado antes de chegar aos usuários.
Mas qual é exatamente a desculpa quando centenas ou milhares de humanos, práticas maduras de engenharia, orçamentos enormes e décadas de conhecimento institucional produzem o mesmo resultado?
Se um agente de código de IA produzisse um formulário Amex que só aceita três dígitos, eu provavelmente poderia dizer a ele:
American Express usa CVV de quatro dígitos. Corrija isso e adicione um teste de regressão.
Há uma boa chance de o problema estar resolvido alguns minutos depois.
A gigantesca organização humana conseguiu levar o bug até a produção.
O problema de verdade são os incentivos
Há outra razão pela qual minha experiência com a Enbridge me incomodou mais que um site ruim comum: o que exatamente eu vou fazer a respeito?
Se um varejista online torna o checkout miserável, compro em outro lugar. Se um SaaS piora, cancelo. Se um restaurante me atende mal sempre, paro de ir.
A concorrência cria um ciclo de feedback brutal, mas eficaz:
Faça o cliente sofrer por tempo suficiente e você acabará perdendo-o.
Serviços públicos funcionam de outro jeito.
Não posso exatamente anunciar que estou decepcionado com a experiência da Enbridge e pedir a outra empresa que conecte a rede concorrente de gás natural à minha casa.
Qual é a minha alavanca aqui?
“Conserte seu site ou levo meus canos de gás subterrâneos para a concorrência”?
Quando o cliente não pode sair com facilidade, some um dos mecanismos mais fortes para punir software ruim.
Isso não significa que alguém na Enbridge decidiu deliberadamente que a experiência do cliente não importa. Tenho certeza de que muita gente lá se importa muito em fazer um bom trabalho. Mas incentivos importam mesmo quando ninguém fala explicitamente deles.
Se você não pode perder o cliente, a pressão para encantá-lo é simplesmente diferente.
E às vezes dá para sentir essa ausência no produto.
Esses não são problemas difíceis
Talvez seja isso que mais me incomoda.
Nenhuma das minhas reclamações envolve engenharia difícil.
Não estou pedindo à Enbridge que resolva a fusão nuclear.
Estou pedindo que ela:
- Permita senhas de tamanho moderno.
- Mantenha o site funcionando.
- Aceite quatro dígitos num campo de quatro dígitos.
- Construa um portal de cliente que não pareça ter décadas.
- Teste o sistema de faturamento antes de forçar os clientes a migrar para ele.
São problemas resolvidos.
Um desenvolvedor competente conseguiria corrigir alguns antes do almoço. Um time de design competente conseguiria modernizar a interface inteira sem reinventar nada. Um processo de QA competente deveria pegar o bug do Amex imediatamente.
E ainda assim tudo isso sobreviveu até a produção numa empresa que vale dezenas de bilhões.
Isso deveria nos fazer repensar a suposição de que a principal ameaça à qualidade de software são desenvolvedores inexperientes armados com IA.
Às vezes o desenvolvedor inexperiente com um agente de IA é justamente quem notaria o problema do CVV de quatro dígitos.
Humanos não têm passe livre de qualidade
Estou empolgado com o desenvolvimento de software assistido por IA. Também acho que devemos ser extremamente críticos com o lixo que ele pode produzir. As duas posições são totalmente compatíveis.
Código gerado precisa de revisão. Agentes precisam de testes. Interfaces criadas por IA precisam de usuários reais. Empresas não deveriam publicar lixo apenas porque gerá-lo ficou mais barato.
Mas o padrão precisa valer nos dois sentidos.
Software não deveria ganhar isenção de qualidade só porque um modelo ajudou a construí-lo.
E software não deveria ganhar isenção de qualidade só porque humanos o construíram.
Se vamos zombar de sistemas de IA por gerarem formulários quebrados, UX sem sentido, erros de segurança e funcionalidades claramente não testadas, deveríamos aplicar exatamente o mesmo padrão às organizações tradicionais de software.
Talvez até um padrão mais alto.
O slop da IA é produzido por uma tecnologia que ainda estamos entendendo.
O slop humano é produzido depois de décadas sabendo como fazer melhor.
Na próxima vez que alguém me mostrar um aplicativo ridículo gerado por IA como prova de que não se pode confiar em máquinas para construir software, vou lembrar da empresa que vale cerca de US$ 110 bilhões, cujo novo site de faturamento achou minha senha segura longa demais, cuja “nova experiência online” parecia ter sobrevivido ao bug do milênio e cujo formulário de pagamento achou que meu CVV de quatro dígitos do American Express deveria caber em três.
Imagine o que você poderia construir com um bilhão de dólares.
Depois imagine ter acesso aos recursos de uma organização que vale 110 vezes isso e publicar isto.
