Qualidade é a única variável

O trabalho de um gerente de projetos é equilibrar quatro variáveis: escopo, tempo, custo e qualidade. O clássico triângulo de restrições diz que você pode otimizar duas, mas não as quatro. Quer rápido e barato? A qualidade sofre. Quer bom e rápido? O custo aumenta. O triângulo é um modelo mental útil para ambientes com recursos limitados.

Eu não opero em um ambiente com recursos limitados. Opero com um agente de IA que produz código na velocidade de inferência, uma janela de contexto que comporta uma base de código inteira e um custo de sessão em dólares, não em salários. O triângulo de restrições desmorona.

Quando o agente pode implementar um recurso em minutos, a pergunta não é “podemos nos dar ao luxo de fazer certo?” A pergunta é “por que faríamos errado?”

A eliminação

Remova o tempo da decisão. Não “quanto tempo isso vai levar?”, mas “como isso deveria ficar quando estiver pronto?” A primeira pergunta otimiza pela velocidade de entrega. A segunda otimiza pelo artefato.

Remova o custo da decisão. Uma sessão que produz código correto, limpo e bem testado custa o mesmo que uma sessão que produz código apressado, bagunçado e sem testes. O API cobra o mesmo por token independentemente da qualidade. O custo marginal de fazer certo é zero.

Remova o esforço da decisão. O agente não se cansa. A centésima função é escrita com a mesma capacidade da primeira. Não existe curva de fadiga humana que justifique atalhos no final de uma sessão. A qualidade do resultado é limitada pela qualidade da instrução e pela qualidade do contexto ao redor, não por quantas horas se passaram.

O que resta depois de eliminar tempo, custo e esforço? Qualidade. Qualidade é a única variável restante.

O que isso significa na prática

Quando qualidade é a única variável, várias decisões comuns de engenharia se tornam óbvias:

Escreva o teste. O debate sobre escrever ou não um teste para uma função específica desaparece. O agente escreve o teste em segundos. O custo marginal é zero. O benefício marginal é verificação permanente. Não escrever o teste é escolher aceitar menos qualidade sem nenhuma economia.

Corrija o código adjacente. Ao corrigir um bug, o código ao redor frequentemente tem problemas relacionados: nomenclatura inconsistente, tratamento de erros ausente, padrões desatualizados. Em um ambiente com restrição de tempo, você corrige o bug e deixa o código adjacente para “depois.” Quando qualidade é a única variável, você corrige tudo o que toca. Depois nunca chega. Agora é de graça.

Use a abstração correta. Um hack rápido resolve o problema imediato. A abstração correta resolve a categoria de problemas. Em um ambiente com restrição de tempo, o hack é entregue hoje e a abstração nunca é entregue. Quando o agente pode implementar qualquer um dos dois na mesma sessão, o hack não tem vantagem. Escolha a abstração.

Leia antes de escrever. Em um ambiente com restrição de tempo, engenheiros às vezes modificam código que não leram completamente, confiando em entendimento local. Quando o agente pode ler o arquivo inteiro, entender os padrões e modificar com contexto completo, não há razão para operar com entendimento parcial. Leia o arquivo inteiro. Entenda o padrão. Depois escreva.

Não adie. TODO, FIXME e HACK são marcadores de qualidade adiada. Em um ambiente com restrição de tempo, o adiamento é racional: corrija depois quando houver tempo. Quando qualidade é a única variável, o adiamento é irracional. O agente está aqui. O contexto está carregado. A correção custa o mesmo agora ou depois. Faça agora.

O princípio Jiro

Jiro Ono faz sushi há mais de 70 anos. Seu restaurante tem três estrelas Michelin e dez assentos. Ele não mudou o cardápio nem o método. Ele refinou o método todos os dias durante 70 anos.

Quando alguém pergunta a Jiro se uma peça de sushi está boa o suficiente, a resposta nunca se baseia em quão movimentado o restaurante está, quantos clientes estão esperando ou quão caro foi o peixe. A resposta se baseia em se o sushi atende ao seu padrão. O padrão é absoluto. As circunstâncias são irrelevantes.

Este é o princípio aplicado à engenharia: o padrão é o código, não a sprint. Uma função ou é correta, limpa e bem testada, ou não é. O prazo não muda a avaliação. O orçamento não muda a avaliação. A única pergunta é se o artefato atende ao padrão.

Agentes de IA tornam esse princípio prático pela primeira vez na engenharia de software. Antes dos agentes, o princípio Jiro era aspiracional. O custo humano da perfeição era alto demais. Todo atalho tinha uma justificativa racional: entregamos na quinta, o orçamento acabou, o engenheiro está esgotado. Com agentes, o custo de fazer certo é o mesmo que o custo de fazer errado. Os atalhos perdem sua justificativa.

O teste de orgulho

Após toda mudança não trivial, faço cinco perguntas:

1. Um engenheiro sênior respeitaria isso?
2. O código se explica sozinho?
3. Os casos extremos foram tratados?
4. Este é o nível certo de simplicidade?
5. Deixei a base de código melhor do que encontrei?

As perguntas não são sobre correção. O portão de evidências cuida da correção. O teste de orgulho cuida do ofício. Código correto que ninguém quer manter falha na pergunta 1. Código esperto que precisa de comentários para ser entendido falha na pergunta 2. Código que trata o caminho feliz mas ignora o caminho de erro falha na pergunta 3.

A pergunta 4 é a mais difícil. “O nível certo de simplicidade” não é “o mais simples possível.” Um hack de uma linha é mais simples que uma abstração adequada, mas o hack é o nível errado de simplicidade se o problema vai se repetir. A simplicidade certa é a menor complexidade que resolve o problema real sem resolver problemas hipotéticos futuros.

A pergunta 5 é sobre trajetória. Toda sessão deve deixar a base de código em um estado melhor do que encontrou. Não apenas os arquivos específicos modificados, mas o contexto ao redor: testes atualizados, imports limpos, comentários corrigidos, código morto removido. O padrão não é “completei a tarefa?” O padrão é “o projeto está melhor porque estive aqui?”

O contra-argumento

O contra-argumento óbvio: velocidade importa. Entregar importa. Uma base de código perfeita que nunca é entregue é pior que uma base de código bagunçada que resolve um problema real.

O contra-argumento é correto em um mundo onde qualidade e velocidade são inversamente correlacionadas. Em um mundo onde um agente de IA produz resultados de alta qualidade na mesma velocidade que resultados de baixa qualidade, a correlação se quebra. Qualidade e velocidade se tornam variáveis independentes. Você pode ter as duas.

O trade-off restante é atenção, não tempo. Ler o arquivo inteiro exige atenção. Executar o portão de evidências exige atenção. Aplicar o teste de orgulho exige atenção. O tempo do agente é gratuito. Sua atenção é finita.

Qualidade é a única variável, mas atenção é a restrição sobre a qualidade. A solução não é baixar o padrão. A solução é construir infraestrutura que reduza o custo de atenção para manter o padrão: hooks que capturam falhas comuns automaticamente, skills que codificam fluxos de trabalho de qualidade e sistemas de memória que carregam contexto entre sessões para que você não precise re-derivar decisões.

Isso é contexto composto a serviço da qualidade. Cada peça de infraestrutura reduz o custo de atenção da próxima sessão. Depois de sessões suficientes, o padrão se mantém sozinho.

FAQ

Isso se aplica a todos os projetos de software?

O princípio se aplica mais diretamente a projetos onde agentes de IA fazem a implementação. Em projetos totalmente implementados por humanos, tempo e custo continuam sendo restrições reais. O princípio se torna mais aplicável à medida que a capacidade dos agentes aumenta e o tempo de implementação humana diminui.

E quanto à prototipagem?

Protótipos são descartáveis por definição. O padrão de qualidade para um protótipo é “ele responde à pergunta que estamos investigando?” Se a resposta é sim, o protótipo cumpriu seu propósito independentemente da qualidade do código. O princípio se aplica a código que vai persistir, não a código que será descartado.

Isso não é só perfeccionismo?

Perfeccionismo é um padrão infinito que nada atende. Qualidade é um padrão finito que o portão de evidências define: correto, limpo, testado, livre de regressões e resolvendo o problema real. Atingir o padrão é alcançável. Excedê-lo é desnecessário. O padrão é alto, mas não infinito.

Como você lida com dívida técnica?

Não criando. Dívida técnica é qualidade adiada. Quando qualidade é a única variável, o adiamento perde sua justificativa. O agente está disponível agora. A correção custa o mesmo agora ou depois. Não há taxa de juros sobre dívida técnica produzida por agentes porque não há razão para contraí-la.

Fontes

A filosofia descrita aqui se baseia na tradição Shokunin do artesanato japonês e na experiência de produção documentada ao longo da série AI Engineering. Implementações específicas referenciadas:

• Portão de evidências: seis critérios para verificação de conclusão
• Teste de orgulho: cinco perguntas para avaliação de ofício
• Sistema de hooks: 84 hooks como infraestrutura de qualidade (Every Hook Is a Scar)
• Contexto composto: infraestrutura que reduz o custo de atenção da qualidade (Compound Context)