O que a maioria das pessoas ainda não entendeu sobre IA no desenvolvimento de software

Eu uso IA no meu processo de desenvolvimento praticamente o tempo todo. Às vezes para escrever código, às vezes para validar uma ideia, às vezes só para explorar possibilidades de implementação antes de eu decidir qual caminho faz mais sentido.

Meu uso inicial de IA (logo quando surgiu em 2022~2023) era basicamente algo que lembra muito a dinâmica da série dr. House. Na série, a equipe ajuda o House com o diagnóstico diferencial: alguém sugere uma hipótese, outro rebate, outra possibilidade aparece, eles vão eliminando caminhos no quadro até sobrar o que ainda faz sentido.

E eu usava a IA basicamente assim. Afinal, não gostava de tab-completes, tinha a sensação de que meu raciocinio era sequestrado para ler a sugestão da IA, que na maioria das vezes estava imprecisa ou errada.

E ainda uso assim IA, como brainstorming. Eu uso para levantar opções, testar linhas de implementação, confrontar abordagens e trazer ângulos que talvez eu não tivesse considerado de primeira, mas como o House, eu não terceirizo as decisões para a IA, a decisão final é minha.

Entretanto, isso começou a mudar quando os modelos ficaram melhores em contexto, planejamento e execução de tarefas mais longas. Com a chegada de modelos como o GPT-5.2-Codex e como Claude Opus 4.5, passou a ser plausível delegar para a IA uma grande parte da implementação, e em alguns momentos, até 100% do código de uma tarefa específica. Ela finalmente ficou boa o bastante para ser uma alavanca real.

Hoje, um bom desenvolvedor, usando IA direito, trabalha mais rápido. Muito mais rápido.

No cenário atual vejo muito medo entre os desenvolvedores de serem substituidos por agentes de codificação. Eu não acho que seja isso que está acontecendo.

Na prática, o maior ganho que eu vejo com IA não é pedir um sistema inteiro num prompt e receber um produto pronto. Esse imaginário do one-shot prompt é bonito em vídeo curto, mas não resiste ao contato com projeto real. O que funciona é outra coisa: usar a IA como um par de programação, alguém que digita rápido, explora alternativas rápido, prototipa rápido, refatora rápido, mas ainda precisa de direção, contexto e intervenção humana. Foi exatamente esse tipo de uso que o Akita descreveu ao relatar um projeto levado do zero à produção em uma semana: não como mágica, e sim como engenharia disciplinada, com iteração, testes, small releases e supervisão constante. No relato dele, a lição central é clara: IA “programando sozinha” é receita para desastre; o que funciona é pair programming com o agente.

Esse é o ponto que eu acho que a maioria das pessoas ainda não entendeu. A IA acelera a execução, mas não elimina a necessidade de engenharia. Na verdade, quanto mais ela acelera, mais importante a engenharia fica.

Alguém ainda precisa ter responsabilidade sobre o que está sendo construído, sobre o que vai ser entregue em produção. Será um código quebrado, lento? Ou um código funcional com performance razoável?

E essa será a responsabilidade do desenvolvedor. Ele, trazendo uma analogia da construção civil, passará a trabalhar mais como engenheiro do que como pedreiro. Ele será o responsável por decidir o que entra e o que não entra, avaliar trade-offs, avaliar requisitos, entender por que uma solução aparentemente boa o suficiente hoje pode explodir em custo, complexidade ou se tornar impossível de manter no futuro.

Ferramentas como Lovable ou V0 da Vercel são ferramentas extraordinárias para MVP's, validações rapidas de ideias. Ela permite explorar mais caminhos, matar ideias ruins mais cedo e chegar numa versão utilizável sem o atrito de escrever tudo manualmente. Isso é valioso demais para ser ignorado.

Só que o jogo muda quando o software precisa durar.

Quando o produto precisa escalar, ser mantido por outras pessoas, acomodar novas regras de negócio, receber observabilidade, suportar incidentes, sobreviver a refactors, lidar com segurança, custos, concorrência, latência, consistência, legibilidade e evolução arquitetural, a conversa deixa de ser “como fazer funcionar” e passa a ser “como fazer isso continuar funcionando sem destruir o sistema no caminho”.

Eu percebo a incapacidade da IA de desenvolver sozinha uma solução escalável e minimamente sustentável justamente quando uso ela como pair programming. É impressionante a quantidade de atalhos, abstrações desnecessárias e redundâncias que ela cria. Muitas vezes eu preciso de várias iterações até chegar na implementação que eu realmente considero boa.

E esse é um ponto importante: muita coisa aí passaria despercebida por alguém não técnico ou sem experiência suficiente. O agente tem uma preocupação central: fazer o código funcionar. Não necessariamente fazer da melhor forma.

Agora imagine isso acontecendo em várias features, uma em cima da outra, com erros sendo construídos em cima de erros. É a receita perfeita para um desastre.

Se isso já é um problema no desenvolvimento tradicional, com devs humanos com vários débitos ténicos construídos ao longo dos anos. Imagine o mesmo cenário em um ambiente onde uma equipe com IA consegue entregar features duas ou três vezes mais rápido. A velocidade de entrega aumenta, mas a capacidade de julgamento não aumenta na mesma proporção, então a chance de acelerar na direção errada dispara.

Por isso eu não compro a narrativa de que estamos vendo a substituição do desenvolvedor. O que estamos vendo é a substituição de parte da digitação, de parte da implementação mecânica, de parte do trabalho braçal. Isso é muito diferente.

E existe ainda um problema mais profundo: a IA não entende de verdade as consequências do que está fazendo. Yann LeCun (vencedor do Prêmio Turing, ex-Cientista Chefe de IA da Meta) vem insistindo num ponto que considero relevante:

Como pode um sistema planejar uma sequencia de ações se ele não pode predizer as consequências? Abordagens baseadas em prever a próxima palavra ou o próximo token não bastam, por si só, para produzir agentes amplamente capazes de raciocinar e planejar em contextos complexos do mundo real.

Outro ponto que pouca gente percebe: conforme a geração de código fica mais barata, o gargalo sobe.

O problema deixa de ser “quem consegue implementar?” e passa a ser “quem consegue definir direito o produto?”, “quem consegue revisar com critério?”, “quem consegue fazer QA de verdade?”, “quem consegue evitar que o sistema apodreça por dentro enquanto continua entregando por fora?”.

A IA pode aumentar muito a produção de código, mas não elimina a necessidade de clareza de produto, revisão técnica, validação e controle de qualidade. Na verdade, ela aumenta a importância dessas coisas.

"Ah, mas isso vai ser resolvido com modelos cada vez mais inteligentes.”

Eu não compro essa ideia. Acho precipitado assumir que os modelos vão continuar melhorando em ritmo acelerado a ponto de resolver esses problemas sozinhos. A própria indústria já discute limitações dos métodos atuais e busca outros caminhos para continuar avançando.

Pode ser que aconteça um breakthrough nos próximos anos. Mas esperar, que os modelos atuais fiquem cada vez mais inteligentes de forma exponencial e infinita é , hoje, muito mais crença do que análise.

Então, para mim, a conclusão é muito menos dramática e muito mais útil.

IA ajuda, sim. E ajuda muito.

Ela acelera exploração, implementação, refatoração, documentação, testes e prototipagem. Ignorar isso é negar a realidade.

Mas desenvolvimento de software continua sendo um processo que precisa ser guiado.

Guiado para evitar que soluções rápidas virem problemas sistêmicos..
Guiado para manter simplicidade.
Guiado para garantir que rapidez não vire desordem.
Guiado para que a produtividade de hoje não se transforme na dívida técnica de amanhã.

E esse tipo de guia não vem de prompt mágico. Vem de experiência.

Vem de anos vendo o que funciona e o que não funciona.
Vem de entender arquitetura e suas consequências.
Vem de saber quando abstrair e quando não abstrair.
Vem de perceber antipattern cedo.
Vem de escolher bem onde usar a IA e onde freá-la.
Vem de saber que “funcionou” não é o mesmo que “ficou bom”.

Na era da IA, o diferencial do desenvolvedor não será digitar código na velocidade da luz.

O diferencial será saber pensar.
Saber decidir melhor.
Saber revisar melhor.
Saber simplificar melhor.
Saber assumir responsabilidade.

Para mim, esse é o ponto que muita gente ainda não entendeu: a IA não torna o desenvolvedor irrelevante. Ela amplifica o impacto de um ótimo desenvolvedor.