YAGNI (You Aren't Gonna Need It)

YAGNI é o princípio do Extreme Programming que manda implementar apenas o que um requisito
atual exige, e não o que uma previsão sugere que será exigido. Formalizado por Kent Beck no
contexto do XP, o acrônimo funciona como contrapeso à tendência natural do engenheiro de
projetar para o futuro imaginado. Em produção, o princípio protege o recurso mais escasso do
time, que é capacidade de entrega, porque cada capacidade especulativa consome testes,
revisão, monitoração e manutenção desde o dia em que entra. O raciocínio central é
econômico: construir antes da hora costuma custar mais que construir depois, porque os
requisitos reais corrigem as hipóteses erradas. YAGNI não é preguiça disfarçada; é uma
política de decisão sobre escopo baseada na informação disponível.

O custo de antecipar requisitos

Capacidade especulativa tem quatro custos que se somam. O primeiro é o custo de construção,
que inclui código, testes e documentação para um requisito que ninguém confirmou. O segundo
é o custo de carrego: todo recurso extra precisa ser monitorado, mantido e explicado a cada
novo membro do time, mesmo sem gerar valor. O terceiro é o custo de oportunidade: a sprint
gasta em um hook de extensão é sprint que não vai para o requisito que existe. O quarto, e
mais perverso, é o custo de desvio: a arquitetura construída para a demanda imaginada
condiciona as decisões seguintes, e desfazê-la é mais caro do que tê-la evitado.

Casos reais abundam. Sharding de banco implementado antes dos primeiros dez mil clientes,
suporte a multi-tenancy antecipado que nunca teve segundo tenant, camada de eventos para um
domínio sem auditoria relevante. Na maioria desses casos, a demanda real chegou em formato
diferente do previsto, invalidando o investimento inteiro. O padrão se repete porque
previsão de demanda é a atividade em que engenharia erra com mais confiança, e o erro é pago
em código, e não em PowerPoint.

Decisões reversíveis versus irreversíveis

O critério prático para aplicar YAGNI é a reversibilidade da decisão. Decisões de duas
portas são as que podem ser desfeitas com custo baixo: escolher banco relacional hoje,
monólito modular, postergar cache. Nessas, postergar é quase sempre correto, porque a
informação futura melhora a escolha. Decisões de porta única são as de reversão cara:
formato de dado persistido, contrato público de API, tratamento de dados pessoais e política
de retenção. Nessas, a antecipação de flexibilidade razoável é investimento legítimo, porque
a correção posterior envolve migração de dados, quebra de consumidores ou exposição
regulatória.

A disciplina recomendada é registrar essa classificação no ADR. O que é reversível fica
barato de mudar, e o que não é recebe design cuidadoso desde o início. Essa separação evita
os dois erros simétricos: construir tudo como se fosse permanente, o que paralisa a entrega,
e postergar tudo, o que produz sistema frágil em pontos sem retorno.

A relação com lean e o último momento responsável

YAGNI compartilha a lógica do lean manufacturing: feature sem consumidor é estoque, e
estoque é desperdício, porque consome capital e esconde problemas. O conceito complementar é
o último momento responsável: adie a decisão até o ponto em que adiar mais custaria
informação ou flexibilidade necessárias. Antes desse ponto, adiar economiza; depois, atrasa.
Essa disciplina exige que o time mantenha o sistema preparado para receber a mudança, e não
que construa a mudança antecipadamente. A diferença é fina e importante: manter o modelo de
dados flexível é preparação; implementar o segundo método de pagamento inexistente é
especulação.

O lean também traz a métrica de fluxo. Cada item especulativo em andamento aumenta o lead
time dos itens reais, porque divide a atenção do time e engorda a fila de integração.
Reduzir trabalho em progresso e adiar decisões são movimentos da mesma família: ambos trocam
a ilusão de progresso por entregas verificáveis.

YAGNI e feature flags

Feature flags são o instrumento que reduz o risco de postergar: permitem entregar a
capacidade mínima, expor a uma fração de usuários, medir e decidir com dado real. O fluxo
compatível com YAGNI é construir a versão enxuta atrás de flag, validar a hipótese e só
então investir na generalização que a adoção pedir. O risco simétrico é o acúmulo de flags
mortas, que multiplicam combinações de configuração não testadas e viram dívida silenciosa.
Por isso, flag precisa de data de criação, dono e critério de remoção registrados; flag sem
plano de remoção é capacidade especulativa com outro nome. Em produção, o custo de
manutenção de flags antigas é real: bugs aparecem apenas em combinações específicas, e
testar todas é inviável, então o estoque de flags precisa ser tratado como estoque lean
mesmo.

O que o YAGNI não autoriza ignorar

YAGNI fala de capacidade, e não de qualidade. Alguns requisitos não funcionais são caros de
retrofitar e baratos de acertar no início, e por isso não entram na regra de postergação:
criptografia em repouso e em trânsito, autenticação com padrões consolidados, chaves de
idempotência em operações de pagamento, observabilidade básica com logs estruturados e
métricas, backup testado e política de retenção. A distinção útil é entre flexibilidade
especulativa, como suportar qualquer banco imaginável, e robustez fundamental, como não
corromper dinheiro do cliente. A primeira é candidata a YAGNI; a segunda é requisito desde a
primeira linha de código. Times que confundem as duas categorias usam YAGNI para justificar
sistema frágil, que é o oposto da intenção do princípio.

Exemplo prático: decisão registrada

# ADR 014: postergar arquitetura multi-região
decisao: "deploy em única região com RTO e RPO documentados"
status: aceito
reversibilidade: "porta dupla; migração estimada em 6 semanas"
gatilhos_de_revisao:
  - metrica: usuarios_ativos_mensais
    limite: 50000
  - metrica: receita_perdida_por_hora_de_indisponibilidade
    limite: "USD 12000"
plano_quando_gatilho_disparar:
  - "replicação cross-region no PostgreSQL gerenciado"
  - "front door com health check e failover automático"
custo_da_postergacao: "RTO atual de 4 horas aceito pelo produto"

O registro transforma YAGNI em decisão rastreável: fica claro o que foi postergado, por
quanto tempo, com que gatilho de revisão e com qual custo aceito. Sem esse registro,
postergação vira omissão, e o debate volta a cada incidente com menos informação do que no
dia da decisão original.

YAGNI no nível de arquitetura

Em nível de sistema, YAGNI aparece como recusa a adicionar tecnologia antes do requisito
operacional. Cada componente novo, fila, cache, segundo banco, orquestrador, entra com custo
de operação permanente, então a barreira de entrada é requisito medido, e não cenário
imaginado. O monólito modular é a expressão arquitetural do princípio: fronteiras de módulo
disciplinadas hoje, extração de serviço quando o número de times e a cadência de deploy
pedirem. A extração planejada é barata quando as fronteiras existem; a extração corretiva,
feita sob incidente, é cara e arriscada.

O mesmo filtro vale para padrões. Mensageria, CQRS, event sourcing e cache distribuído
resolvem problemas reais e específicos; adotados sem problema, viram custo estrutural
permanente. A pergunta de barreira é sempre a mesma: qual problema medido este padrão
resolve aqui, e qual é o plano de reversão se a hipótese falhar?

Erros comuns e boas práticas

• Usar YAGNI como desculpa para ignorar requisito existente: o princípio vale para demanda futura imaginada, e não para demanda presente documentada.
• Postergar decisões de porta única: contrato público, formato de dado persistido e tratamento de PII exigem design cuidadoso imediato.
• Acumular feature flags sem data de remoção: trate flag como estoque com validade, com dono e critério de retirada.
• Confundir preparação com especulação: modelo flexível é preparação; implementação de caso de uso inexistente é especulação.
• Não registrar a decisão postergada: ADR com gatilho de revisão e custo aceito evita relitigar a escolha a cada incidente.
• Avaliar YAGNI isoladamente: combine com teste de hipótese e métricas de adoção; postergar só é econômico quando a informação futura realmente chega.

Comparativo de posturas de escopo

A tabela contrasta as posturas típicas de escopo com seus custos e riscos observados em
produção.