O custo de dizer sim mudou: decisões técnicas na era da IA

Resumo rápido

• Ferramentas de IA reduziram drasticamente o custo de escrever código, mas o custo de manter, revisar e ser dono desse código não mudou.
• A engenheira Dalia Abuadas, do GitHub, propõe em The Cost of Saying Yes Has Changed um critério prático: pedir um artefato concreto antes de debater escopo, e avaliar custo de posse, não custo de produção.
• Adoção de ferramentas de IA no desenvolvimento já passa de 80% entre desenvolvedores segundo o Octoverse 2025 do GitHub, o que torna esse critério de decisão urgente para qualquer equipe.

Você já deve ter sentido isso: pedir para a IA gerar uma função, um componente ou até uma tela inteira, e receber o resultado em minutos. O que antes levava um dia de trabalho agora sai de um prompt bem escrito. Isso muda a forma como você decide o que aceita no seu código, e a maioria dos times ainda não ajustou o critério de decisão para essa nova realidade.

Essa é a tese central de um artigo publicado no GitHub Engineering Blog por Dalia Abuadas, engenheira do time de Copilot Agent Control Plane do GitHub. O argumento é direto: o custo de escrever código caiu, mas o custo de possuir esse código não caiu junto. E é justamente essa lacuna que precisa entrar na sua régua de decisão técnica.

A ilusão da produtividade infinita

Com IA, você consegue gerar funções, componentes e até arquiteturas inteiras em minutos. O que antes exigia horas de digitação agora acontece com alguns prompts. Isso cria uma tentação perigosa: aceitar mais features, mais mudanças, mais complexidade, porque “escrever” ficou barato, então por que não?

O problema está no que vem depois. Cada linha de código aceita no seu projeto carrega um compromisso de longo prazo:

• Manutenção contínua: bugs precisam ser corrigidos, testes precisam ser atualizados, documentação precisa refletir as mudanças.
• Custo cognitivo: você e o resto do time precisam entender esse código, carregar esse contexto mental e considerar suas implicações em mudanças futuras.
• Débito técnico: código gerado rapidamente por IA com frequência precisa de refatoração depois.
• Dependências: bibliotecas e frameworks adicionados precisam ser atualizados e ter vulnerabilidades monitoradas.

A IA mudou a primeira etapa desse ciclo, escrever, mas não alterou nenhuma das demais. Na prática, ao facilitar a escrita, ela pode até aumentar o custo total de propriedade do código se você não tiver critérios rígidos para aceitar mudanças.

O framework real: artefato concreto antes de debate de escopo

No artigo original, Abuadas descreve algo que qualquer tech lead reconhece: reuniões longas debatendo se vale a pena implementar uma mudança pequena, quando o próprio esforço de escrever o código já seria menor que o tempo gasto discutindo se deveria escrever. Segundo ela, essa é hoje a parte mais cara de muitos pedidos de feature, não a implementação, mas a reunião sobre se deve implementar.

O framework proposto tem três movimentos práticos:

1. Peça um artefato concreto antes de debater escopo

Em vez de discutir abstratamente se uma mudança é boa ideia, peça para a IA gerar um patch sob restrições claras. Isso transforma argumentos vagos em evidência tangível que todo mundo pode avaliar. Você troca “acho que isso é complexo” por um diff real na sua frente.

2. Avalie custo de posse, não custo de produção

A pergunta certa não é “quanto tempo leva para escrever isso”, mas “alguém consegue revisar e assumir a responsabilidade por esse código com confiança”. Uma mudança só é barata se um humano conseguir entendê-la, revisá-la e mantê-la, não apenas se a IA conseguiu gerá-la rápido.

3. Distinga o que é barato de escrever do que é barato de possuir

Nem toda mudança gerada rapidamente é de fato barata. Refatorar um helper bem testado costuma ser barato dos dois lados. Já mudanças que tocam autenticação, retenção de dados, privacidade, cobrança ou compliance continuam caras, independente de quão rápido a IA consiga gerar o código para elas.

Exemplos concretos citados no artigo original

O próprio artigo do GitHub traz dois exemplos que ajudam a fixar a diferença:

• Expor um campo já existente, como um timestamp de last_active_at, numa tela de configurações costuma ser um diff de poucas linhas e uma mudança razoável de aceitar, mesmo sendo gerada por IA.
• Uma mudança que toca o middleware de autorização não é pequena, mesmo que a IA gere o código em segundos, porque o risco e o esforço de revisão estão na complexidade de entender as implicações, não na quantidade de linhas escritas.

Repare que em nenhum dos dois casos o tempo de geração do código é o que define se a mudança é cara ou barata.

Implicações práticas para quem toma decisões técnicas

Para arquitetos de software, tech leads e desenvolvedores seniores, esse contexto exige uma postura mais rigorosa:

Dizer não ficou mais difícil de justificar, e isso é o ponto. Quando escrever código era caro, o próprio esforço de implementação servia como filtro natural contra mudanças desnecessárias. Hoje, esse filtro sumiu. O critério “não, porque dá muito trabalho escrever” perdeu força. Você precisa aplicar critérios de arquitetura, manutenibilidade e alinhamento estratégico com mais disciplina, não menos.

Code review precisa mudar de foco. Verificar se o código funciona é cada vez menos o gargalo, a IA costuma acertar isso. O foco deve estar em: esse código é necessário, está no lugar certo, adiciona complexidade justificável, vai ser compreensível daqui a seis meses.

Documentação de decisões arquiteturais fica mais crítica. Com código sendo gerado rapidamente, o porquê de certas decisões se perde ainda mais fácil. Registros de decisão arquitetural e contexto documentado importam mais do que nunca.

Princípios de design viram âncoras. SOLID, YAGNI, DRY e separação de responsabilidades são seus guardrails quando a IA torna tecnicamente possível fazer quase qualquer coisa em poucos minutos.

Se você quer aprofundar como essas mudanças de fluxo de trabalho vêm acontecendo de forma mais ampla, vale ler como a IA está transformando a programação e o desenvolvimento de software.

Por que isso importa agora: a adoção de IA já é maioria

Não é um cenário hipotético e distante. Segundo o relatório Octoverse 2025 do GitHub, a adoção de ferramentas de IA no desenvolvimento passou de 80% entre novos desenvolvedores já na primeira semana de uso, e pesquisas do setor apontam algo entre 84% e 91% de adoção geral entre desenvolvedores profissionais. Isso significa que a maioria dos times já está gerando código nesse ritmo acelerado, com ou sem um critério de decisão ajustado para lidar com isso.

Quando esse volume de código gerado encontra um time sem critério de posse bem definido, o resultado costuma ser acúmulo de complexidade silenciosa, o tipo de problema que só aparece meses depois, quando alguém precisa mexer numa parte do sistema que ninguém mais entende direito. Se você já passou por um projeto assim, vale comparar com este estudo de caso de IA salvando projetos de programação falhos, que mostra o outro lado dessa mesma moeda.

Um exemplo do dia a dia

Imagine que seu time propõe adicionar uma nova camada de abstração no sistema de autenticação para suportar um caso de uso específico. Com IA, implementar essa camada pode levar poucas horas.

A pergunta antiga era: vale a pena o esforço de desenvolvimento?

A pergunta nova deveria ser: essa abstração adicional justifica o custo mental permanente de mantê-la? Quantas pessoas vão precisar entender essa camada? Ela resolve um problema recorrente ou é otimização prematura? Existe uma solução mais simples que reaproveita estruturas que já existem?

Note que o tempo de implementação praticamente não entra mais nessa conta.

Perguntas frequentes

A IA realmente reduziu o custo de manter código, ou só o custo de escrever? Só o custo de escrever, segundo o argumento central do artigo do GitHub. Manutenção, revisão e entendimento de longo prazo continuam exigindo o mesmo esforço humano de antes.

Isso significa que devo recusar mais mudanças agora? Não necessariamente recusar mais, e sim aplicar um critério diferente. A recomendação prática é pedir um artefato concreto (um patch gerado sob restrições) antes de debater escopo em abstrato, e avaliar se alguém consegue revisar e assumir a responsabilidade por aquele código.

Que tipo de mudança continua cara mesmo com IA? Mudanças que tocam autorização, retenção de dados, privacidade, cobrança ou compliance. O risco está na complexidade de entender as implicações, não na velocidade de gerar o código.

Isso vale só para times grandes ou também para projetos pequenos e solo? Vale para qualquer tamanho de time. Quanto menor a equipe, menos gente sobra para carregar o contexto mental de código mal avaliado, o que torna o critério de posse ainda mais importante, não menos.

Conclusão: propriedade importa mais que autoria

A IA democratizou a capacidade de escrever código, mas não mudou o que significa possuir código: carregar a responsabilidade de mantê-lo, evoluí-lo e eventualmente descomissioná-lo.

O desenvolvedor ou líder técnico que quer decidir bem nesse cenário precisa treinar um músculo novo: dizer não baseado em custo de propriedade, não em custo de autoria. Em um mundo onde escrever código virou trivial, saber quando não escrever código desnecessário virou uma das competências mais valiosas que existem. Se esse tipo de decisão também pesa na sua carreira, este texto sobre emprego vs. carreira no mindset de quem trabalha com desenvolvimento complementa bem essa reflexão.

Como resume o próprio artigo do GitHub: o custo de dizer sim mudou, e com ele, a responsabilidade de quem toma decisões técnicas ficou maior.