O custo de dizer “sim” mudou: o que a era da IA está fazendo com as tarefas pequenas em software

Tem uma discussão que está começando a aparecer com mais honestidade em times de produto e engenharia: o código ficou mais barato de produzir, mas não ficou mais barato de entender, revisar e sustentar.

Essa virada aparece com clareza num texto recente do GitHub Blog, “The cost of saying yes has changed”. A tese é simples e forte: em muitos pedidos pequenos, o trabalho mais caro já não é escrever a primeira versão do código. O trabalho mais caro pode ser a conversa interminável para decidir se vale a pena tentar.

Não é um argumento para aceitar qualquer demanda. Nem para terceirizar decisão para IA. É um argumento para mudar onde o time mede risco.

o patch inicial ficou barato, a responsabilidade não

O exemplo do texto é direto: alguém pede uma mudança aparentemente pequena, como exibir um campo que já existe no backend em uma tela de configurações. Em outro momento, isso podia virar uma longa discussão sobre escopo, prazo, risco escondido e impacto em áreas vizinhas.

Segundo a autora, esse tipo de debate fazia mais sentido quando a tentativa inicial era cara. Era preciso parar o que estava sendo feito, puxar contexto, implementar manualmente, testar e só então descobrir se a mudança realmente era simples.

Com assistentes e agentes de código, parte dessa conta mudou. Um primeiro patch restrito pode surgir rápido o bastante para funcionar como checagem de preço, não como entrega final.

Essa é a melhor leitura do post: a IA não elimina o julgamento humano. Ela pode baratear a etapa de transformar uma dúvida abstrata em um diff concreto.

o problema é que muita equipe ainda discute como se 2024 não tivesse acabado

Na prática, muita conversa de escopo continua presa ao velho reflexo: barrar cedo porque qualquer nova linha de código parece automaticamente cara demais.

Só que, para uma classe específica de mudanças, isso já não descreve a realidade inteira. Se o primeiro rascunho do patch sai rápido, a pergunta útil deixa de ser apenas “isso está em escopo?” e passa a ser algo mais operacional:

onde está o custo real desta mudança?

O custo pode estar em pontos bem diferentes:

na revisão;
no risco de quebrar contrato de produto;
na dificuldade de testar;
no impacto em autenticação, billing, privacidade ou compliance;
na obrigação de alguém sustentar aquele comportamento daqui a seis meses.

É uma diferença importante. Código barato de gerar não é código barato de possuir.

Na era da IA, a tarefa pequena deixou de ser só “dá para fazer?” e virou “dá para revisar, testar e assumir sem criar dívida escondida?”.

o patch gerado deveria ser tratado como sonda, não como produto

Esse talvez seja o ponto mais útil para quem lidera time ou participa de priorização.

No texto do GitHub, a primeira versão gerada por IA não deve ser tratada como solução pronta. Ela serve como artefato de inspeção. Com um diff na mesa, a conversa melhora porque sai do campo das impressões e entra no campo da evidência.

A partir daí, dá para fazer perguntas melhores:

tocou só nos arquivos esperados ou espalhou mudança demais?
os testes ficaram óbvios ou o comportamento resistiu à validação?
a alteração preserva a abstração atual ou cria exceção nova?
existe uma decisão de produto escondida dentro do pedido técnico?
alguém do time toparia carregar esse comportamento sem arrependimento daqui a alguns meses?

Quando a resposta é boa, o time economiza uma discussão longa. Quando a resposta é ruim, a IA também ajudou — porque mostrou cedo que a suposta tarefa pequena não era pequena.

isso muda menos o código e mais a forma de decidir

A grande mudança não é técnica; é gerencial.

Durante muito tempo, a disciplina de escopo ficava concentrada antes da implementação, porque implementar era caro. Agora, parte dessa disciplina pode migrar para mais perto da revisão, desde que a tentativa seja restrita, inspecionável e reversível.

O próprio enquadramento sugerido no artigo é bem pragmático:

produzir o menor patch possível;
evitar mudar contrato público sem necessidade;
manter a mudança atrás de flag, quando fizer sentido;
adicionar ou atualizar testes;
listar claramente os arquivos tocados;
apontar o que parece arriscado.

Se nem assim sai algo limpo, já apareceu o custo oculto. Se sai, o time ganha uma forma mais barata de decidir.

onde a tese acerta — e onde ela pode virar desculpa ruim

Eu acho que o texto acerta em cheio ao separar duas coisas que muita gente está misturando:

custo de produzir um candidato de solução;
custo de validar e assumir essa solução.

É aí que muita empresa pode se enrolar em 2026. Porque o primeiro custo caiu rápido. O segundo continua humano, político e operacional.

Então o risco não é só dizer “não” para mudanças que ficaram baratas de explorar. O outro risco é começar a dizer “sim” para tudo porque o patch apareceu em minutos.

Essas duas armadilhas convivem.

Uma mudança continua cara quando mexe em autorização, retenção de dados, cobrança, privacidade, compliance ou comportamento sensível de produto — mesmo que o diff pareça elegante. A IA não reduz automaticamente o preço de errar nessas áreas.

o novo valor está em precificar incerteza mais rápido

Talvez a melhor frase implícita no artigo seja esta: o time forte não vai ser o que aprova tudo nem o que rejeita tudo. Vai ser o que aprende a precificar incerteza com mais velocidade.

Isso significa perceber quando um pedido é pequeno de verdade e quando ele só parece pequeno porque chegou vestido de detalhe técnico. Também significa entender quando revisar será mais difícil do que escrever.

Para quem trabalha com software, esse raciocínio importa bastante porque mexe no dia a dia real: backlog, pedido urgente, ajuste “rápido”, exceção comercial, detalhe visual, campo extra, automação marginal, regra de negócio escondida.

Em muitos desses casos, a pergunta central já não é “a IA consegue gerar isso?”. A pergunta mais madura é:

quem vai entender, validar e bancar isso depois?

o que vale levar para o time na segunda-feira

Se eu tivesse que resumir a utilidade prática dessa leitura, levaria quatro pontos:

nem todo pedido pequeno merece debate longo antes de um teste restrito;
um diff gerado pode servir para reduzir chute, não para eliminar revisão;
aceitar código rápido sem dono continua sendo caro;
a habilidade que ficou mais valiosa é distinguir escrita barata de manutenção cara.

O post do GitHub não vende uma fantasia de automação total. E justamente por isso ele funciona. Ele descreve uma mudança concreta no custo de explorar possibilidades, sem fingir que governança, revisão e responsabilidade sumiram.

Para muita equipe, isso já basta para melhorar a conversa sobre escopo. Não porque tudo ficou simples — mas porque a parte que era puro palpite ficou mais fácil de testar.