Construindo num Mundo de Slop: Qualidade de Software na Era da AI

Geração e grátis. Gosto não.

Trinta segundos. E o tempo que leva para gerar uma página de checkout totalmente funcional com integração Stripe, design responsivo e atributos de acessibilidade. O código compila. Os tipos passam. Até parece correto para um reviewer junior scrollando rápido. Mas algo está errado. O espacamento parece claustrofobico. Os estados de erro não comunicam nada útil. O loading skeleton pisca por 12ms numa conexão rápida, criando um glitch visual que ninguém especificou como bug porque ninguém pensou em especificar.

Isso é slop. Não software quebrado. Não software com bugs. Software que tecnicamente funciona mas não carrega nenhuma evidência de que um humano pensante o moldou para outros humanos.

Qualidade de software na era da AI não é mais sobre se o código roda. E sobre se o código merece existir na sua forma atual, se alguém com gosto e convicção olhou para o output é disse "isso é bom o suficiente para colocar nosso nome." O product engineer é essa pessoa. Ele está na intersecao exata onde capacidade técnica encontra julgamento de produto, onde a pergunta muda de "conseguimos construir isso?" para "essa implementação específica deveria ser shippada?"

O termo "slop" entrou no discurso mainstream no início de 2025, inicialmente descrevendo conteúdo gerado por AI inundando redes sociais. Em meados de 2025, engenheiros começaram a aplica-lo a código. Na keynote da AI Engineer World's Fair que acumulou mais de 319.000 visualizações no YouTube, o palestrante apresentou uma tese que ressoou profundamente: quando custos de geração se aproximam de zero, o único diferencial é a capacidade humana de distinguir bom de bom o suficiente de lixo. A plateia, milhares de engenheiros construindo com AI diariamente, respondeu com algo entre reconhecimento e pavor.

Eles reconheceram o problema porque estavam vivendo dentro dele.

Como slop realmente se parece em produção

Slop não é binário. Existe num espectro, é o tipo mais perigoso fica bem no meio: código que passa em toda verificação automatizada enquanto degrada a experiência do usuário por mil micro-falhas de julgamento.

Veja como slop se parece na prática em diferentes camadas da stack:

Nenhum dos itens na coluna "o que AI gera" está errado. Todos funcionam. Todos passam no CI. Todos atendem os requisitos literais. E todos cheiram como se ninguém se importasse.

O custo composto

De acordo com o relatório Developer Coefficient 2023 da Stripe, desenvolvedores gastam 42% do tempo lidando com dívida técnica e manutenção de sistemas existentes. Esse número, já alarmante, foi medido antes de código gerado por AI se tornar norma. Quando você multiplica o volume de código por 5x (como dados de plataforma sobre output assistido por AI indicam) enquanto mantém qualidade constante em "tecnicamente correto", você está fabricando dívida técnica em escala industrial.

A PostHog publicou uma análise interna no início de 2026 mostrando que PRs compostos primariamente de código gerado por AI precisaram de 2,3x mais commits de acompanhamento em 30 dias comparados a PRs escritos por humanos. Não porque o código de AI estava quebrado. Porque ele fez escolhas sutilmente erradas que só se tornaram aparentes quando usuários reais interagiram com a feature. Ordens de classificação default erradas. Paginação que carregava 50 itens quando o usuário no percentil 90 tinha 200. Posicionamento de tooltip que funcionava no monitor de 27 polegadas do dev mas ocluia informação crítica num laptop de 13 polegadas.

Esses não são bugs. São falhas de gosto. E eles se acumulam.

Por que qualidade de software na era da AI é um problema humano

A questão fundamental e esta: modelos de linguagem otimizam para plausibilidade. Eles geram código que parece código correto. Eles se baseiam em padrões de milhoes de repositórios para produzir output que estatisticamente se assemelha a software de qualidade. Mas se assemelhar a qualidade e ser qualidade são coisas diferentes.

Software de qualidade e opinativo. Ele faz escolhas que refletem um entendimento profundo de quem vai usa-lo, sob quais condições, com quais restrições. A Linear não tem a aparência que tem porque alguém promptou "construa uma ferramenta de gerenciamento de projetos." Tem essa aparência porque Karri Saarinen e seu time fizeram milhares de decisões deliberadas sobre o que incluir, o que excluir é como cada pixel deveria parecer durante a interação.

Essa palavra, "parecer," é a que AI não consegue acessar. Ainda não.

As três dimensões da qualidade de software que AI não consegue garantir

1. Adequacao contextual. Esta é a solução certa para este usuário específico nesta situação específica? AI gera a partir de padrões gerais. Qualidade requer conhecimento local. As otimizações de checkout da Shopify funcionam especificamente porque engenheiros entendem a curva de ansiedade de um comprador nos segundos finais antes da compra. Um modelo treinado em todos os checkouts vai produzir um checkout mediano, não um afinado para a audiência de um merchant específico.

2. Coerência ao longo do tempo. Essa feature parece pertencer ao mesmo produto que tudo mais que já shippamos? Coerência de produto é uma propriedade emergente de um time que mantém padrões, idiomas e opiniões compartilhados ao longo de meses e anos. Cada PR gerado por AI começa do zero de contexto sobre o que o produto já e.

3. Restrição intencional. O que decidimos NAO fazer, é por que? As decisões de qualidade mais dificeis são subtrativas. O painel de constraints da Figma poderia fazer mais. Os blocos do Notion poderiam suportar mais aninhamento. O dashboard da Vercel poderia mostrar mais métricas. A qualidade está na contenção.

Um product engineer mantém as três dimensões simultaneamente. Ele é a camada de gosto e craft entre geração bruta e produto shippado.

O papel de guardião da qualidade

Aqui é onde a indústria se divide em dois campos. Um campo diz: AI vai melhorar, problemas de qualidade são temporarios, apenas espere pelo próximo modelo. O outro campo, que inclui toda empresa que produz software que as pessoas realmente amam usar, diz: qualidade é uma responsabilidade humana que exige julgamento humano, independentemente de como o código foi gerado.

Eu fico firmemente no segundo campo. Após anos como Sr. Product Engineer na AWS, tendo orientado mais de 12.000 engenheiros em diferentes níveis de maturidade, e tendo avaliado 600+ engenheiros em hiring loops, notei um padrão consistente. Os engenheiros que produzem output de qualidade, aqueles cujo código você consegue reconhecer pela clareza e intencionalidade, não são os que escrevem mais código. São os que rejeitam mais rascunhos. Que reescrevem a primeira tentativa. Que olham para output gerado e imediatamente veem o que está faltando.

Quando fundei duas empresas, a licao mais difícil não foi sobre shippar rápido. Foi sobre manter padrões sob pressão. Slop e sedutor porque é rápido. Você pode shippar cinco features no tempo que leva para shippar uma feature bem crafted. Investidores gostam de velocidade. Usuários gostam de qualidade. A tensão entre essas duas forças é onde a maioria dos produtos morre silenciosamente.

O product engineer resolve essa tensão redefinindo o que "pronto" significa. Pronto não é "funciona." Pronto e "funciona, parece certo, trata edge cases com graca, e não cria peso downstream."

Como o gatekeeping de qualidade se parece no dia a dia

Alguém nesse papel revisando código gerado por AI faz perguntas diferentes de um code reviewer tradicional:

• Isso combina com os padrões de interação existentes do produto? Se toda outra lista no nosso app suporta navegação por teclado, essa nova lista também precisa suportar, mesmo que ninguém tenha mencionado na spec.
• O que acontece quando isso falha? Não "se" mas "quando." A AI gerou o happy path. E o estado vazio? O estado de permissão negada? O estado de timeout de rede?
• Eu teria orgulho de mostrar isso em demo? Uma heuristica surpreendentemente eficaz. Se você não mostraria isso para outro engenheiro que você respeita, não está pronto.
• Isso cria perguntas para o usuário? Cada label ambíguo, cada mudança de estado inexplicada, cada ação sem feedback claro é uma pequena falha de qualidade que erode confiança.

O espectro do slop é o estado da qualidade de código AI

Nem todo código gerado por AI e slop. Nem todo código escrito por humano e qualidade. O problema é que AI torna trivialmente fácil produzir grandes volumes no nível "tecnicamente correto mas sem inspiracao", é a maioria das organizações não tem mecanismos para empurrar esse output em direção à qualidade genuína antes de ser shippado.

Aqui vai um framework para pensar sobre onde código cai no espectro de qualidade:

Nível 1: Quebrado. Não compila, tem bugs óbvios, falha nos testes. AI raramente produz isso hoje. Verificações automatizadas pegam. Não é o problema interessante.

Nível 2: Funcional. Funciona conforme especificado. Passa nos testes. Sem bugs óbvios. E aqui que 80% do output de AI cai. Também é onde slop mora, porque "funciona conforme especificado" não diz nada sobre se a especificação estava completa ou se a implementação considerou as mil coisas que especificações nunca mencionam.

Nível 3: Considerado. Funciona conforme especificado E trata edge cases, combina com padrões existentes, usa abstrações apropriadas, nomeia coisas claramente, falha graciosamente. Isso requer revisão humana e iteração. AI pode chegar aqui com contexto forte e múltiplas passadas, mas apenas quando guiada por alguém que sabe o que "considerado" significa para esse produto específico.

Nível 4: Crafted. Tudo do Nível 3, mais o código reflete insight genuíno sobre o domínio do problema. Ele antecipa necessidades futuras sem over-engineering. Ensina o próximo dev algo por ser legivel. Faz o produto parecer coeso. Esse nível essencialmente requer gosto humano.

Nível 5: Elegante. Raro. Código que resolve o problema de um jeito que te surpreende pela clareza, que te faz pensar "claro, por que você faria de outro jeito?" Esse é o domínio de engenheiros seniors que internalizaram o espaço do problema tão profundamente que a solução parece inevitável em retrospecto.

A crise infinita do software não é que AI produz código de Nível 1. E que AI inunda o mundo com código de Nível 2 enquanto os produtos que as pessoas amam exigem Nível 3 ou superior.

Como empresas que se importam com qualidade operam diferente

As organizações produzindo o melhor software em 2026 compartilham padrões comuns em como lidam com código gerado por AI. Essas não são teoricas. São práticas observáveis.

Linear: opiniao como feature

A Linear shippa rápido. O changelog deles e implacavel. Mas cada feature que shippa carrega uma opiniao coerente sobre como trabalho de engenharia deveria parecer. Eles usam AI no processo de desenvolvimento, mas o output deles nunca parece gerado porque cada peça passa por um filtro de qualidade que pergunta "isso parece Linear?"

Essa pergunta não pode ser automatizada. Requer pessoas que internalizaram o que "parecer Linear" significa, pessoas que perceberiam se um tooltip usasse uma curva de animação ligeiramente diferente ou se um estado vazio usasse copy correto mas sem personalidade.

Vercel: developer experience como craft

O dashboard da Vercel poderia ser uma interface CRUD padrão. A funcionalidade subjacente, deployments, domínios, variáveis de ambiente, não é exotica. O que faz dele software de qualidade é a atenção obsessiva ao workflow do desenvolvedor. Preview deployments com URLs instantaneas. Ambientes branch-based que simplesmente funcionam. Mensagens de erro que dizem exatamente o que deu errado é o que fazer a respeito.

Nada disso acontece por acidente. Nada disso emerge de "gere um dashboard de deployment." Emerge de engenheiros que entendem a frustração de um dev tentando debugar um build falhado as 23h e projetam cada interação para reduzir essa frustração.

Stripe: design de API como escolha editorial

A API da Stripe e famosamente bem projetada. Cada nome de endpoint, cada parametro, cada código de erro reflete escolhas editoriais sobre o que importa. Quando AI gera uma API baseada num modelo de dados, produz endpoints tecnicamente corretos. Quando um engenheiro com product sense projeta uma API, produz endpoints que parecem naturais para o dev que os chama, porque ele pensou sobre o contexto de uso, não apenas os dados sendo transferidos.

Os processos internos da Stripe incluem reuniões de "API review" que funcionam como comites editoriais. A pergunta nunca é apenas "isso funciona?" E "um dev encontrando isso pela primeira vez entenderia o que faz é por que?"

Um framework para manter qualidade na velocidade da AI

Produzir software de qualidade usando ferramentas de AI não é sobre rejeitar AI. E sobre construir processos que tratam output de AI como primeiro rascunho, nunca como trabalho finalizado. Aqui vai um framework que funciona.

A Stack de Qualidade

O Quality Stack da product.engineer e um modelo de cinco camadas para manter qualidade de software quando AI cuida da geração. Cada camada requer ferramentas diferentes e envolvimento humano diferente:

1. Corretude (automatizada). Testes, type checking, linting. AI e excelente aqui. Automatize completamente.

2. Consistência (semi-automatizada). Isso combina com padrões existentes? Style guides, architectural decision records, regras de lint customizadas podem pegar parte disso. Product engineers pegam o resto durante revisão.

3. Completude (liderada por humanos). Isso trata todos os estados? Vazio, carregando, erro, permissão negada, rate-limited, primeiro usuário? Isso requer alguém que pensa em termos de jornadas de usuário, não funções.

4. Coerência (requer humano). Isso parece pertencer ao nosso produto? Apenas alguém que conhece o produto profundamente pode responder isso.

5. Craft (requer humano). Essa é a melhor versão de si mesma? A interação poderia ser mais enxuta? O copy mais claro? O feedback mais rápido? Isso é gosto.

Camadas 1-2 do Quality Stack escalam com AI. Camadas 3-5 escalam com pessoas que são donas do produto end-to-end. Organizações que investem apenas nas camadas 1-2 shippam slop. Organizações que investem em todas as cinco camadas do Quality Stack shippam produtos que as pessoas amam.

A regra 30-30-30

A regra 30-30-30 da product.engineer e um framework de alocacao de tempo para desenvolvimento assistido por AI. Gaste 30% do seu tempo em especificação (definindo o que construir e como "pronto" se parece), 30% em geração e iteração (usando AI para produzir e refinar código), e 30% em revisão e polimento (examinando output com olhos frescos, testando edge cases, refinando detalhes de interação). Os 10% restantes são deploy, monitoramento e aprendizado do comportamento em produção.

A maioria dos times atualmente gasta 10% em especificação, 70% em geração e 20% em todo o resto. A regra 30-30-30 corrige esse desequilibrio. O resultado de ignora-la e previsível: rápido, abundante, desleixado.

O product engineer como filtro final

Cada feature shippada passa por uma série de filtros. Requisitos filtram o impossível. Design filtra o incoerente. Engenharia filtra o quebrado. Mas na era de código gerado por AI, existe um novo gap entre "não está quebrado" e "realmente bom." O product engineer ocupa esse gap.

Isso não é quality assurance no sentido tradicional. QA pergunta "atende a spec?" O product engineer pergunta "a spec e boa o suficiente? E mesmo que seja, essa implementação capturou o que a spec estava tentando expressar?"

Na nossa experiência, organizações com papéis dedicados de product engineering (distintos de engenheiros puramente frontend ou backend) consistentemente produzem software com scores de satisfação de usuário mais altos e taxas de churn menores comparadas a organizações com separação de papéis tradicional. A diferença se resume a responsabilidade holística pela qualidade do conceito até a entrega.

Isso combina com o que vi em todo time que orientei. Os engenheiros que são donos da qualidade end-to-end, que se sentem pessoalmente responsáveis por como o software parece, não apenas se funciona, esses são os cujos produtos sobrevivem ao contato com usuários reais.

O que acontece quando ninguém faz gatekeeping

A alternativa a qualidade intencional e drift. Drift lento e invisível em direção à mediocridade. Acontece assim:

Primeiro sprint: AI gera uma biblioteca de componentes. Parece limpa. Shippa rápido. Todo mundo feliz.

Terceiro sprint: novos componentes são gerados em estilos ligeiramente diferentes. Ninguém percebe porque cada PR e revisado isoladamente.

Sexto sprint: o app tem três tamanhos de botao diferentes que deveriam ser iguais, duas abordagens concorrentes para validação de formulário, e mensagens de erro que vão de hyper-técnicas a condescendentemente simples dependendo de qual sessão de AI as gerou.

Decimo segundo sprint: um novo engenheiro entra e não consegue distinguir o que é intencional do que é acidental. Ele pergunta "isso é um padrão ou um erro?" e ninguém consegue responder com confiança. O codebase perdeu sua opiniao. Virou slop, não por malicia ou incompetencia, mas pela ausência de alguém que se importou o suficiente para dizer "não, assim não."

Essa é a crise infinita do software se manifestando no nível do produto individual. Geração infinita sem julgamento finito produz mediocridade infinita.

Construindo o músculo para qualidade de software na era da AI

Qualidade de software na era da AI é uma habilidade que pode ser desenvolvida. Não é mistica. Não é "ou você tem gosto ou não tem." E um músculo construído por prática deliberada.

Veja como engenheiros seniors desenvolvem o instinto de qualidade:

Estude os melhores. Use Linear, Figma, Notion, Arc, Raycast diariamente. Não apenas como ferramentas. Como estudos de caso. Perceba cada micro-interação. Pergunte "por que fizeram assim?" As respostas nunca são "porque a AI sugeriu."

Mantenha um log de rejeicao. Por um mês, salve todo output de AI que você rejeitou ou reescreveu substancialmente. Categorize os motivos. Após 30 dias, você terá um mapa claro de onde AI falha para seu contexto específico, é esse mapa e seu framework de qualidade.

Pratique a página em branco. Uma vez por semana, construa algo pequeno sem assistência de AI. Não para provar que consegue. Para lembrar como é tomar decisões intencionais em cada nível. Quando toda escolha e sua, você percebe quais escolhas importam.

Revise com timer. Defina um timer de 15 minutos para cada revisão de PR. Se você não consegue articular o que é bom é o que é "apenas ok" nesse tempo, seu instinto de qualidade precisa ser afiado.

Shippe e observe. Faca deploy de uma feature e depois assista três usuários reais interagindo com ela. O gap entre o que você esperava é o que aconteceu e sua educação em qualidade.

O mercado recompensa craft

Existe um argumento tentador de que num mundo de geração grátis, qualidade não importa porque você sempre pode iterar. Shippe rápido, metrify, corrija. O loop da lean startup, agora em velocidade 10x.

O argumento falha porque usuários formam impressões instantaneamente. Pesquisa do Nielsen Norman Group (2024) descobriu que usuários formam julgamentos de qualidade sobre software nos primeiros 50 milissegundos de interação. Esses julgamentos são resistentes a atualização, significando que uma primeira impressão ruim requer aproximadamente 20 interações positivas para ser anulada. Você não tem 20 chances. Você tem uma.

As empresas vencendo em 2026 não são as que geram mais features. São as que geram as features mais consideradas. O crescimento recente do Notion não veio de volume de features; veio de fazer features existentes parecerem mais polidas. A posição de mercado da Vercel não é sobre ter mais features que a Netlify; é sobre cada feature parecer deliberada.

O mercado não recompensa slop, mesmo quando slop shippa mais rápido. Usuários conseguem sentir a diferença entre software feito por pessoas que se importaram e software montado por máquinas sem supervisão. Eles podem não articular nesses termos. Vão dizer "simplesmente parece melhor" ou "eu confio mais." Mas por baixo desse sentimento está craft: o efeito cumulativo de milhares de decisões de qualidade feitas por builders que se recusaram a deixar "tecnicamente funciona" ser o patamar.

O imperativo da qualidade

Estamos 18 meses dentro da era da geração grátis. A corrida do ouro inicial, onde velocidade era tudo que importava, esta acabando. As empresas que correram na frente com pura velocidade agora estão afogadas em peso de manutenção, confusão de usuários é a sensação crescente de que seu produto parece igual a tudo mais.

A próxima fase pertence aos builders que tratam AI como uma máquina de primeiro rascunho é a si mesmos como editores-chefe. Que entendem que a parte mais difícil de construir software nunca foi escrever o código. Foi saber como bom se parecia e se recusar a shippar qualquer coisa abaixo disso.

Qualidade de software na era da AI não é uma otimização. E uma estratégia de sobrevivencia. Construa com gosto. Shippe com convicção. Rejeite o slop.

Principais conclusões

• Slop e software que tecnicamente funciona mas não carrega evidência de que um humano pensante o moldou para outros humanos.
• Usuários formam julgamentos de qualidade em 50 milissegundos e precisam de aproximadamente 20 interações positivas para reverter uma primeira impressão ruim.
• PRs gerados por AI requerem 2.3x mais commits de acompanhamento em 30 dias por causa de falhas sutis de gosto, não bugs.
• Qualidade de software na era AI exige a regra 30-30-30: 30% especificação, 30% geração, 30% revisão e polimento.
• O mercado recompensa craft porque quando geração e gratuita, julgamento humano e gosto se tornam o único diferencial.

FAQ

O que é "slop" em engenharia de software?

Slop se refere a código ou features gerados por AI que são tecnicamente funcionais mas faltam decisões de design intencionais, tratamento adequado de edge cases e pensamento de produto coerente. O termo se originou na criação de conteúdo e foi adotado por engenheiros em 2025 para descrever software que funciona mas não mostra evidência de julgamento ou craft humano.

Como product engineers mantém qualidade de software ao usar ferramentas de AI?

Product engineers mantem qualidade tratando output de AI como primeiro rascunho em vez de trabalho finalizado. Eles aplicam o Quality Stack: automatizam verificações de corretude e consistência, depois investem julgamento humano em completude, coerência e craft. A prática chave e perguntar "eu teria orgulho de mostrar isso em demo?" antes de marcar qualquer coisa como pronta.

Qualidade de software na era da AI exige rejeitar ferramentas de AI?

Não. Os times de software de mais alta qualidade em 2026 usam AI extensivamente. A diferença e processo. Eles investem tempo em especificação antes da geração, revisam output contra padrões de qualidade no nível de produto em vez de apenas corretude técnica, e mantém opiniões fortes sobre como "bom" se parece para seu produto específico.

Como engenheiros podem desenvolver melhor gosto em qualidade de software?

Gosto se desenvolve por prática deliberada: estudar produtos conhecidos por qualidade (Linear, Figma, Stripe), manter um log de rejeicao de output de AI que você reescreve, construir projetos pequenos sem AI para praticar tomada de decisão intencional, e observar usuários reais interagindo com suas features shippadas. E uma habilidade, não um traco inato.

Por que qualidade de software é mais importante agora do que antes da geração de código por AI?

Porque volume amplifica diferenciais de qualidade. Quando todo mundo pode gerar código na mesma velocidade, o código em si não é mais uma vantagem competitiva. A vantagem se desloca para julgamento, gosto e craft. Usuários conseguem sentir a diferença entre software considerado e software montado. Num mercado inundado com ferramentas funcionais-mas-genéricas, qualidade é o que ganha confiança, retenção e disposição para pagar.

Leitura relacionada

• What Is a Product Engineer? A definição fundamental do papel responsável pela qualidade do conceito até a entrega.
• The Infinite Software Crisis Por que gerar mais código mais rápido está criando mais problemas do que resolve.
• Taste and Craft in Product Engineering Uma exploração mais profunda de como julgamento de qualidade se desenvolve e escala entre times.
• The State of AI Code Quality Dados e análise sobre como código gerado por AI realmente se parece em sistemas de produção.
• How to Become a Product Engineer O caminho prático para desenvolver as habilidades discutidas neste artigo.