O custo de dizer sim mudou: GitHub relança o debate sobre o verdadeiro gargalo

Um bilhete do GitHub Engineering de 17 de julho coloca a decisão de "aceitar/recusar um ticket" no centro: a IA derrubou o custo de produção, mas multiplicou o custo dos maus "sim".

Em termos simples

Codificar não é mais o gargalo. Decidir sim/não — para um ticket, uma funcionalidade ou um flag — é. Um post do blog do GitHub recoloca a troca de prioridades no centro: a IA derrubou o custo de produção, mas aumenta o custo dos "sins".

Contexto

Em 17 de julho de 2026, a GitHub Engineering publicou « The cost of saying yes has changed » (O custo de dizer sim mudou). A essência: o custo marginal de escrever uma funcionalidade caiu drasticamente, mas cada "sim" adicionado ao escopo expande uma superfície que não encolhe — bugs, dependências, dívida técnica de operações, superfície de ataque.

Os dados

O post não se baseia em benchmarks quantitativos, mas em uma observação de equipe: os tickets "aceitáveis" explodem quando a produção é barata. A proposta central: reintroduzir um custo de decisão explícito, julgando cada "sim" como se o código já estivesse escrito — o que resta são os custos de ownership (bugs, dependências, operações, superfície de ataque).

Análise

A mudança é estrutural. Há quinze anos, o debate sobre DX focava na velocidade de execução — CI, monorepo, revisão de código. A IA inverte o problema: a velocidade de execução é oferecida, a velocidade de decisão se torna rara. É um deslocamento do gargalo do trabalho braçal para o julgamento. Corolário para a arquitetura: cada abstração adotada vira uma hipótese a defender por dez anos, não mais uma compensação pelo custo de desenvolvimento.

Cenários

• Disciplina reconquistada: equipes que tratam o "sim" como uma decisão de arquitetura, não como resposta a uma necessidade de usuário, terminam com uma base mais enxuta e legível.
• Proliferação: aquelas que deixam a IA gerar sem filtro veem sua dívida técnica dobrar com orçamento constante, com custo de manutenção explodindo antes que um CFO note (veja o threadtoken-budget-caps).
• Meio-termo: a maioria se acomoda em um status quo onde a IA acelera o existente, mas não altera a doutrina de escopo.

E então?

Para um CTO: reescreva sua definição de "pronto" e "feito" antes do fim do ano. Para um engenheiro: o novo alavancador não é "produzir", é "recusar", e isso nunca é explicitado em uma descrição de cargo. Para um executivo: o próximo ganho de produtividade com IA está bloqueado não pela stack, mas por um processo de priorização que data da era em que a escassez era o código.