Escrever código ficou barato. Julgar ficou caro.

Eu baixei a guarda

Minha primeira versão do site tinha sido feita com Hugo, há uns anos. Não estava com a minha cara. Funcionava, mas parecia um site que eu tinha construído — não um site que dizia alguma coisa sobre mim. Eu sabia disso há tempo. Só não tinha conseguido resolver.

Aí resolvi tentar de novo.

Passei um bom mês só concebendo a ideia, no chat. Conceito, marca, slogan, personalidade, tom de voz, identidade visual, estrutura, protótipos, cores, conteúdo, tudo — boa parte desse trabalho de base foi feito falando com Claude e ChatGPT. Quando finalmente cheguei em uma versão que olhei e pensei "essa bagaça ficou com a minha cara", comprei o domínio e comecei a construir de verdade.

Aí tentei codar com o Copilot. Não andou. Foi aí que migrei pro OpenCode — e o setup apareceu de verdade.

Eu estava usando OpenCode como harness do projeto e, conforme o tempo passava, fui construindo contexto, documentação, instruções e processos para os agentes trabalharem melhor.

No começo, eu revisava tudo com lupa.

Depois de um tempo, comecei a perceber que precisava revisar menos. Não porque a IA tinha virado perfeita, mas porque ela já conhecia o projeto.

Conhecia a estrutura. Conhecia minhas decisões. Conhecia o tom. Tinha acesso ao contexto que eu mesmo tinha construído durante todo o processo.

Então fui afrouxando as rédeas.

Até que o site ficou estável e eu comecei a fazer aqueles últimos incrementos que parecem simples.

Melhorar indexação para agentes de IA.

Criar uma página para developers.

Criar uma página de privacidade.

Criar uma página de contato.

Eu pensei: ela já conhece esse projeto. Já tem contexto suficiente. É coisa pequena.

Deixei fazer e revisei superficialmente.

Depois subi.

Só fui ler de verdade quando já estava em produção.

A página de privacidade tinha o campo para a data da última atualização, mas não tinha data nenhuma.

Na página de contato, existia uma espécie de FAQ dizendo que eu fazia palestras.

Nunca fiz.

Dizia que eu fazia mentorias e 1:1.

Não faço.

Falava que eu tinha agenda para isso.

Também não.

Até comportamento meu em relação a convites de recrutadores foi deduzido e colocado como se fosse uma informação real sobre mim.

Nada daquilo era absurdo.

Esse era justamente o problema.

Tudo parecia plausível.

Até você conhecer a pessoa sobre quem aquilo estava falando.

Quando eu vi aquilo em produção, pensei:

Mano. Como eu pude baixar a guarda com o meu próprio projeto?

A IA não tinha deixado de funcionar.

Eu é que tinha parado de desconfiar.

E fiquei pensando no que teria acontecido se aquele projeto não fosse o meu site. Se fosse uma aplicação de produção. Se fosse um sistema financeiro. Se fosse uma alteração que passasse nos testes, não quebrasse nada imediatamente e, ainda assim, executasse uma operação errada.

Aí a brincadeira muda de figura.

Eu trabalho com Internet Banking.

Nesse contexto, "parece certo" não é critério suficiente.

Foi aí que comecei a pensar que talvez a grande mudança provocada pela IA não seja exatamente sobre escrever código.

O código ficou barato

Eu gosto de usar IA.

Gosto mesmo.

Na verdade, eu quero que ela escreva mais código.

Muito mais.

Se eu tenho uma máquina capaz de fazer uma tarefa mecânica mais rápido do que eu, por que eu faria questão de continuar fazendo aquilo manualmente?

Eu consigo levantar um carro sozinho se precisar.

Mas existe um macaco ali.

Eu vou pegar o carro no braço só para provar que consigo?

Não.

Código, hoje, está ficando cada vez mais parecido com isso.

Digitar deixou de ser a parte mais interessante do trabalho. Escrever código continua sendo uma habilidade importante. Mas produzir código minimamente bom ficou barato, rápido e abundante.

E eu não vejo problema nenhum nisso.

Pelo contrário.

Se a IA consegue escrever em minutos algo que eu levaria horas para digitar, revisar e ajustar, ótimo.

Eu não quero preservar trabalho mecânico só para provar que ainda sou necessário.

É para isso que ferramenta serve.

Por que eu vou reinventar a roda se ela já está ali?

O problema começa quando a gente confunde executar com decidir.

Eu posso entregar para um agente uma especificação bem construída, dividir uma feature em tarefas menores, definir critérios de aceite, dar o contexto necessário e deixar ele trabalhar. Ele pode implementar enquanto eu faço outra coisa. Pode testar. Pode revisar. Pode corrigir. Pode abrir um PR.

Eu não preciso ficar olhando a IA digitando cada linha.

Na verdade, se eu precisar fazer isso, não estou delegando.

Estou só trocando o teclado por uma interface de chat.

Mas no final eu ainda quero olhar.

Sempre.

Por menor que seja a alteração.

Porque existe uma diferença enorme entre confiar na execução e terceirizar o julgamento.

E é aí que onde começa a ficar perigoso.

O recorte errado

Uma coisa que eu aprendi usando agentes é que eles podem fazer um trabalho excelente olhando para o lugar errado.

Pensa em uma arquitetura de microfrontends.

Um MFE não conhece necessariamente os outros MFEs.

Não conhece o root.

Front e BFF podem estar em times diferentes.

Existem contratos, importmaps, versões de bibliotecas, design system, integrações e uma série de decisões que estão espalhadas por vários repositórios.

Agora imagine colocar um agente dentro de um desses projetos e pedir:

"Implemente essa feature."

Ele pode fazer um trabalho impecável.

O código pode estar bonito.

Os testes podem passar.

A aplicação pode rodar perfeitamente localmente.

E ainda assim ele pode ter tomado uma decisão completamente errada para o sistema.

Pode usar MUI diretamente quando deveria usar o nosso design system. Pode gravar alguma coisa no localStorage que deveria vir da sessão. Pode atualizar uma versão de biblioteca que funciona isoladamente e quebra quando o MFE é integrado via importmap. Pode alterar um contrato que outro sistema consome sem sequer saber que esse consumidor existe.

E não necessariamente porque o agente é ruim.

Ele simplesmente não estava olhando para o sistema inteiro.

Uma IA pode fazer tudo certo dentro do recorte errado.

Esse, para mim, é um dos problemas mais interessantes dessa nova forma de desenvolver software.

Porque é muito fácil olhar para uma feature isolada e dizer:

"Está funcionando."

Mas software raramente é isolado.

Existe sempre alguma coisa do outro lado.

Outro MFE.

Outra BFF.

Outro serviço.

Outro contrato.

Outro time.

Outro sistema.

Outro cara que tomou uma decisão seis meses atrás e que agora depende exatamente daquele comportamento que você acabou de alterar.

No nosso caso, para um agente realmente ter uma visão completa de um Internet Banking, seria necessário colocar na mesa dezenas de aplicações, BFFs, serviços, integrações e decisões que vivem em lugares diferentes.

Não existe um prompt mágico que transforme um recorte local em conhecimento absoluto do sistema.

Contexto não é conhecimento absoluto.

Você pode dar muito contexto para uma IA.

Pode construir um harness inteiro.

Pode documentar o projeto.

Pode criar regras.

Pode criar agentes especializados.

Pode construir feedback loops.

Tudo isso aumenta muito a qualidade do trabalho.

Mas ainda existe uma diferença entre conhecer o recorte e conhecer o mundo em volta dele.

E talvez seja justamente por isso que eu me preocupe tão pouco com a ideia de "IA substituir o desenvolvedor" e muito mais com a ideia de desenvolvedores substituírem o próprio julgamento pela IA.

Ferramenta, não cérebro

Eu trato IA como ferramenta.

No máximo, como um braço direito.

Como ferramenta, sou eu que uso ela.

Eu sei o que quero fazer.

Sei onde quero chegar.

Sei qual problema estou tentando resolver.

Sei quais restrições existem.

Sei qual resultado espero.

A IA me ajuda a chegar lá mais rápido.

Quando a tarefa é maior, eu planejo.

Escrevo uma especificação.

Divido em fases.

Quebro o trabalho em tarefas menores e mais objetivas.

Defino o que entra, o que precisa acontecer e o que espero receber de volta.

Depois deixo os agentes executarem.

Isso não significa que eu esteja abrindo mão do controle.

É justamente o contrário.

Eu estou criando condições para poder delegar sem precisar acompanhar cada passo.

É a diferença entre:

"Faça isso e me diga quando terminar."

e:

"Este é o problema. Este é o contexto. Estas são as restrições. Este é o resultado esperado. Agora execute."

A primeira é confiança cega.

A segunda é delegação.

E existe outra coisa que eu evito: usar a IA como meu cérebro principal.

Não quero perguntar para ela o que eu deveria pensar.

Quero usar ela para pensar comigo.

Parece uma diferença pequena.

Não é.

Se eu pergunto:

"Como resolvo isso?"

e aceito a primeira resposta, estou terceirizando uma decisão.

Se eu pergunto:

"Estou pensando em resolver assim. Quais problemas você enxerga nessa abordagem?"

estou usando a IA para ampliar meu próprio julgamento.

Essa diferença, para mim, é enorme.

Porque uma coisa é usar a IA para acelerar, expandir e enriquecer o seu pensamento.

Outra é usar a IA para substituí-lo.

E, sinceramente?

Se você chegou ao ponto em que não consegue mais decidir nada sem perguntar para um modelo, talvez o problema não seja a IA estar inteligente demais.

Talvez seja você ter parado de pensar.

O que ainda é nosso

Eu não tenho medo de que a IA substitua desenvolvedores.

Acho até meio engraçado esse discurso.

Já disseram que a calculadora acabaria com a matemática.

Que as planilhas acabariam com os contadores.

Que toda ferramenta que automatiza uma parte do trabalho necessariamente acabaria com a profissão inteira.

Não acho que seja isso que está acontecendo.

Acho que estamos eliminando uma parte do trabalho que era necessária simplesmente porque era cara.

Digitar código ficou barato.

E tudo bem.

Quero gastar meu tempo entendendo o problema.

Entendendo o negócio.

Entendendo a arquitetura.

Tomando decisões.

Questionando soluções.

Percebendo riscos.

E olhando para o que foi produzido e perguntando:

Isso deveria existir?

Porque essa pergunta continua difícil.

A IA pode gerar uma solução para um problema que não deveria ser resolvido. Pode criar uma arquitetura perfeita para uma feature que deveria ter sido muito mais simples. Pode escrever um teste que passa e não testa absolutamente nada. Pode explicar uma decisão com tanta segurança que você quase esquece de perguntar se aquilo faz sentido.

E é aí que eu acho que começa a aparecer uma diferença importante entre um desenvolvedor que usa IA e um desenvolvedor que depende dela.

O primeiro continua pensando.

O segundo começa a perguntar para a máquina o que deveria pensar.

E isso é uma diferença muito maior do que parece.

A fronteira da autonomia

Eu quero que meus agentes sejam cada vez mais autônomos.

Quero entregar uma especificação e ir tomar café.

Quero voltar e encontrar um PR pronto.

Quero que eles pesquisem, implementem, testem, revisem e corrijam.

Quero delegar.

Mas existe uma coisa que não quero automatizar:

a decisão sobre se aquilo deveria ser feito daquela forma.

Se nem para um desenvolvedor do meu próprio time eu "ponho a mão no fogo" sem revisar o que ele fez, por que eu faria isso com uma IA?

Ela não vai para a reunião quando der problema.

Não vai explicar a decisão para o negócio.

Não vai responder pelo incidente.

Não vai estar no plantão.

Não vai sentir o peso de ter colocado uma coisa errada em produção.

Eu vou.

E isso muda a forma como eu enxergo autonomia.

Autonomia não significa ausência de supervisão.

Significa que eu não preciso controlar cada passo da execução porque existe um critério claro para avaliar o resultado.

Eu posso deixar a IA trabalhar sozinha.

O que eu não posso fazer é deixar de pensar porque ela está trabalhando.

Talvez essa seja a fronteira.

A autonomia da IA começa onde termina a nossa capacidade de explicar o que ela faz.

Se eu não consigo explicar por que aquele código existe, o que ele faz, qual problema resolve e quais são as consequências daquela decisão, talvez eu não tenha delegado uma tarefa.

Talvez eu tenha delegado o meu julgamento.

O preço do julgamento

Acho que é aqui que a conversa fica realmente interessante.

Durante muito tempo, uma parte enorme do valor de um desenvolvedor estava em conseguir transformar uma ideia em código.

Agora estamos construindo ferramentas capazes de fazer uma parte cada vez maior dessa transformação.

Ótimo.

Que façam.

Escrever código ficou barato.

Gerar ficou barato.

Experimentar ficou barato.

Delegar ficou barato.

O que não pode ficar barato é o nosso julgamento.

Porque quanto mais barato fica produzir código, mais código vamos produzir.

Quanto mais fácil fica experimentar, mais soluções vamos experimentar.

Quanto mais autônomos ficam os agentes, mais coisas eles vão fazer sem a gente olhando.

E quanto mais isso acontece, mais importante fica ter alguém capaz de olhar para o resultado e dizer:

"Não."

Não porque não compila.

Não porque o teste falhou.

Não porque a IA não conseguiu.

Mas porque, mesmo funcionando, aquilo não deveria existir daquela forma.

Eu não quero uma IA que escreva menos código.

Quero uma IA que escreva muito mais.

Quero entregar uma especificação e deixar uma máquina fazer em uma hora o que eu levaria um dia.

Quero parar de gastar meu tempo digitando coisas que uma ferramenta consegue fazer melhor.

Quero delegar.

Só quero continuar sendo capaz de olhar para o que ela escreveu e saber quando confiar.

E quando não confiar.

Porque talvez o maior risco da IA não seja ela ficar inteligente demais.

Talvez seja a gente ficar confortável demais.

Preguiçoso demais.

Dependente demais.

Até chegar ao ponto em que a resposta parece boa simplesmente porque foi a IA que respondeu.

E aí está o verdadeiro perigo.

É a gente ficar burro demais para perceber quando ela está errada.