A IA me substituiu, e eu gostei.

O que aprendi delegando tarefas reais para a IA, e por que não voltaria atrás.

Eu programo desde que me entendo por gente. Não é exagero! Meu primeiro emprego da vida foi, literalmente, como desenvolvedora web, e até hoje abrir um editor de código me dá aquela sensação boa de estar no lugar certo. Durante anos, minha principal vantagem competitiva foi simples: eu gosto disso, eu entendo disso, e eu sou boa nisso.

Um certo dia apareceu a IA generativa.

E, de repente, eu me vi olhando para uma ferramenta que consegue gerar em segundos o que eu levaria horas para escrever. Não porque sou ruim no que faço, mas porque velocidade bruta de geração de texto e código é exatamente onde a máquina não tem concorrência.

Poderia ter ficado na defensiva. Ignorado. Torrado neurônios tentando provar que faço melhor. Escolhi outra coisa: me adaptar. Aprender a usar. E descobrir onde, de fato, isso muda o jogo.

Este artigo é sobre esse processo. Não é um tutorial, não é um benchmark técnico formal. É um relato honesto das primeiras vezes que deleguei trabalho real para a IA: o que funcionou, o que frustrou, o que me surpreendeu, e por que cada vez mais eu pretendo fazer isso com mais frequência e mais confiança.

Os modelos utilizados foram através do Github Copilot.

Primeiro: a IA Generativa é boa se o prompt for bom

Antes de qualquer relato, preciso estabelecer algo que considero fundamental e que frequentemente se perde no hype em torno do tema.

A IA não é uma entidade autônoma. Ela é um meio.

Ela não toma decisões. Ela não entende o seu negócio. Ela não sabe o que é importante no seu contexto, quais são os trade-offs da sua arquitetura, ou o que o cliente realmente precisa (mesmo quando ele disse outra coisa). Ela responde ao que você pergunta, com a qualidade que o seu prompt permite.

Já ouvi desenvolvedores reclamarem que a IA deles “era burra”. Quando eu olhava os prompts, a resposta era óbvia: entrada ruim, saída ruim. A IA é um amplificador, ela amplifica o que você coloca nela. Um prompt vago gera uma resposta genérica. Um prompt preciso, contextualizado, com exemplos e restrições claras? Aí as coisas ficam interessantes.

No passado, programávamos no bloco de notas. Puro. Sem autocomplete, sem highlight de sintaxe, sem nada. Depois vieram as IDEs com sugestões, refatoração automática, navegação inteligente entre classes. Alguém parou de programar porque a IDE “fazia o trabalho”? Não. A IDE virou parte do fluxo. A gente aprendeu a usar e ficou mais produtivo.

A IA é o próximo passo dessa evolução. Não é mais inteligente que você. É mais rápida em algumas coisas específicas. E quando você aprende a orquestrar isso bem, o resultado é diferente de tudo que já experimentei em termos de produtividade.

Dito isso, vamos ao que aconteceu quando comecei a colocar isso em prática de verdade.

A primeira vez que deleguei uma tarefa inteira

A primeira tarefa que decidi conduzir com assistência total da IA era complexa. Puro backend, regras de negócio com várias condicionais, lógica que precisava consultar múltiplas fontes de dados e tomar decisões encadeadas. O tipo de tarefa que você abre, lê duas vezes e já começa a organizar mentalmente antes de escrever qualquer coisa.

Comecei fazendo o que sempre faço: pensei na solução antes de tocar no código. Mapeei mentalmente o que precisaria construir, quais peças seriam necessárias, onde estava a complexidade real. Essa parte não mudou, e não vai mudar. A IA não substitui o raciocínio arquitetural. Ela executa o que você projeta.

Com o design na cabeça, comecei a delegar as partes mecânicas. As arquiteturas de backend costumam ter aquelas camadas que você cria da mesma forma toda vez: a camada que conversa com o banco, a que contém a lógica, a que expõe os dados. Repetitivo, necessário, e curiosamente onde erros bobos mais acontecem. Passei as estruturas necessárias para o modelo e pedi que gerasse. Funcionou, com consistência que o cansaço humano nem sempre garante.

Depois disso, usei uma abordagem que virou meu padrão desde então: TDD assistido por IA. Peguei os casos de uso escritos pelo time de produtos (o documento que descreve o que o sistema deve fazer) enviei ao modelo e pedi os cenários de teste primeiro, antes do código. Revisei cada cenário, removi o que não fazia sentido, acrescentei o que faltava. Só então solicitei a implementação.

O resultado foi bem melhor do que eu esperava para uma primeira vez. A lógica complexa funcionou. Os testes cobriam os cenários. Teve um defeito, que conto mais abaixo, mas no geral foi uma entrega sólida.

O modelo utilizado foi o GPT-4.1, e para o contexto completo e bastante abrangente da tarefa ele tinha um hábito de gerar suposições, mesmo quando eu pedia explicitamente que levantasse dúvidas antes de gerar código, ele ignorava a instrução e avançava com suposições próprias. Às vezes as suposições eram razoáveis. Às vezes ele simplesmente inventava lógica que não existia nos requisitos. Isso gerou fricção e ciclos de correção.

Lição número um: o modelo importa. Muito.

O bug que eu estava com preguiça de investigar

Esse defeito veio com a marcação mais temida: intermitente.

A lógica era de sorteio. Às vezes o número 1 aparecia como sorteado mesmo sem ter sido. Não toda hora. Às vezes. O tipo de coisa que você não consegue reproduzir de forma confiável, que some quando você está olhando e aparece quando você não está.

Cheguei nessa análise já com aquela sensação característica: sabe quando você olha para um problema e já sente que vai ser longo? Decidi mandar para a IA antes começar a analisar. Enviei o código responsável, a descrição do defeito e exemplos concretos de quando havia ocorrido.

O retorno foi cirúrgico. Em segundos, o modelo identificou: estava usando uma busca textual numa string de números, e qualquer número que contivesse o dígito 1 (como 10, 12, 21) era retornado como positivo. A correção foi converter e comparar número a número com equals.

Uma investigação que levaria horas foi resolvida em minutos. O modelo utilizado foi também o GPT-4.1, mas dessa vez com um contexto bem delimitado, ele gerou uma resposta precisa. Um trecho de código específico, um bug específico, exemplos concretos, o modelo performou muito bem. Quanto mais aberto e vasto o contexto, mais ele tende a preencher lacunas com suposições. Calibrar isso é uma habilidade que se desenvolve com o uso.

Lição número dois: a qualidade da resposta é igualmente proporcional a qualidade de definição do contexto.

A reunião que eu estava e o bug que eu não estava

Esse foi o momento em que percebi que as coisas estavam ficando seriamente diferentes.

Era uma semana de entrega crítica, o tipo de semana onde você tem cinco problemas simultâneos, conflitos de código, funcionalidades regredindo, e uma fila de reuniões que não para. No meio disso tudo, um desenvolvedor me reporta que a documentação das APIs havia parado de abrir no ambiente.

Eu estava literalmente na porta da próxima reunião.

Abri o agente de IA no meu editor, escrevi um prompt descrevendo o erro, dei uma hipótese de onde poderia estar o problema e instrui: “pesquise nos arquivos”.

E fui para a reunião.

O agente trabalhou de forma autônoma conforme a minha hipótese, rodando buscas, analisando arquivos, cruzando referências. Eu, dentro da reunião, apenas aceitava as solicitações de execução que apareciam no terminal, sem desviar atenção de onde precisava estar. Quando terminei a ligação, o diagnóstico estava esperando por mim: uma referência apontava para uma chave que não existia no arquivo de configuração correspondente. Corrigi em dois minutos.

Duas entregas. Uma pessoa. Ao mesmo tempo.

Não vou fingir que não senti uma alegria desproporcional naquele momento. No meio de uma semana lotada de problemas diversos, aquilo foi genuinamente motivador. E foi também a primeira vez que eu pensei: isso aqui vai mudar minha forma de trabalhar para sempre.

E foi exatamente nesse momento que o título deste artigo deixou de ser provocação e virou descrição literal.

Lição número três: delegar para a IA não é preguiça é estratégia. Seu tempo e atenção são recursos finitos; saber onde aplicá-los é parte do trabalho.

Entendimento das diferenças entre modelos

Com mais confiança no processo, peguei uma tarefa com complexidade similar à primeira (backend com múltiplas regras de negócio) mas desta vez decidi trocar o modelo. Usei o Claude Sonnet 4.5.

Adotei o mesmo protocolo: primeiro prompt com instrução explícita para levantar dúvidas antes de gerar qualquer código.

A diferença foi imediata e marcante.

O Claude respondeu com uma lista de dez perguntas de esclarecimento. Dez perguntas. Antes de escrever uma linha. Algumas eu respondi na hora. Outras me fizeram perceber que eu mesma tinha pontos que precisavam ser melhor definidos. O que teria gerado retrabalho de qualquer jeito, com ou sem IA. Esse alinhamento prévio é exatamente o que um bom colaborador faz, humano ou não: entende antes de executar.

O código que veio depois foi notavelmente mais aderente ao que era esperado. Sem lógica inventada. Sem suposições incorretas. Sem ciclos desnecessários de correção.

A IA fez o trabalho. Eu dirigi.

Lição número quatro: é importante saber qual modelo é eficiente para cada tarefa.

Documentações e relatórios com qualidade e agilidade

Vou ser honesta: documentação não é meu ponto forte. Nunca foi. Eu gosto de código, de resolver problemas, de desenhar soluções. Escrever documentação formal, estruturar relatórios, transformar um conjunto de informações espalhadas em algo apresentável e coerente, isso custa mais para mim do que qualquer desafio técnico.

E foi exatamente aí que a IA me surpreendeu de um jeito que eu não esperava. Peguei relatos informais, anotações, observações do dia a dia, o tipo de texto que você escreve sem compromisso, só para não perder o raciocínio, e com um prompt bem estruturado, descrevendo o objetivo do documento, a audiência e o tom desejado, o resultado foi um documento organizado, coeso e apresentável. O conteúdo era meu. A estrutura, a fluidez, o formato, a IA apenas organizou.

Mas é extremamente importante nunca abrir mão da revisão. Tudo que a IA gera precisa ser lido, questionado e ajustado. O que muda é o ponto de partida: em vez de começar de uma página em branco, começo de um rascunho que já tem estrutura. E essa diferença, para quem não tem documentação como vocação, é enorme.

Lição número cinco: a IA é especialmente poderosa onde você é especialmente fraco, e não tem nada de errado em assumir isso.

GPT-4.1 vs Claude Sonnet 4.5: o que as experiências mostraram

Ao longo dessas experiências usei dois modelos em contextos comparáveis, e as diferenças foram concretas o suficiente para valer uma análise direta.

A diferença não é sutil. É a distância entre uma ferramenta que você usa com ressalvas e uma que você genuinamente incorpora ao seu fluxo. Avaliar um modelo só pelo custo da licença é o mesmo erro que avaliar um desenvolvedor só pelo salário: o que ele entrega é o que importa.

Então: vamos perder nossos empregos?

Não. A IA é apenas um próximo passo na evolução da nossa profissão. Não é mais inteligente que você, ela não sabe o que é importante, não entende o contexto do negócio, não percebe quando um requisito está errado, não toma decisões arquiteturais. Ela gera texto e código muito rápido, a partir do que você fornece.

O que realmente está mudando é o perfil de habilidades que faz diferença. Saber criar um prompt preciso e contextualizado já é uma habilidade técnica real. Saber orquestrar agentes para trabalhar em paralelo enquanto você está em outra frente também. Saber revisar e validar o que a IA gera, sem aceitar cegamente e sem rejeitar por desconfiança, é o tipo de julgamento que o mercado cada vez mais demandará de nós desenvolvedores.

O desenvolvedor que vai se destacar não é o que resiste à IA. É o que aprende a trabalhar com ela da forma mais inteligente possível.

Desenvolvimento assistido tem seu lugar garantido

Assistir o agente realizar a engenharia reversa de um código legado e apenas validar a saída retornada, na minha opinião é a única maneira plausível de se fazer engenharia reversa hoje em dia. No passado, para refatorar funcionalidades inteiras levamos meses em reuniões com especialistas, esforço coletivo enorme só para entender o que o código fazia, hoje com um prompt e um agente em algumas horas ou até em alguns minutos eu tenho uma funcionalidade inteira revisada e documentada.

Algumas tarefas hoje em dia simplesmente não faz sentido executar sem ajuda de agentes de IA, porque não é produtivo.

• O TDD assistido por IA virou padrão no meu fluxo.
• Delegar investigação de bugs para agentes enquanto estou em outra frente virou rotina.
• Fazer varredura em arquivos e trabalhos repetitivos são exemplos de tarefas que não consigo mais me imaginar fazendo sozinha.
• Delego para a máquina o que ela é boa, enquanto faço o que só eu consigo.

E o ponto que não mudou, e que não vai mudar: tudo isso só funciona pra quem sabe o que está fazendo. A IA não entendeu o código legado: eu entendi, com a IA como instrumento. Ela não validou os testes, eu validei. Ela não tomou nenhuma decisão técnica, eu tomei todas. O que ela fez foi executar rápido o que eu sabia exatamente como pedir.

É a mesma relação que você tem com qualquer ferramenta poderosa. A IDE não te torna um bom desenvolvedor, ela amplifica o desenvolvedor que você já é. A IA funciona exatamente assim. Nas mãos certas, com o contexto e o prompt certo, ela é transformadora. Nas mãos erradas, é só uma fonte elegante de respostas erradas com muita confiança.

Não vamos perder nossos empregos para a IA. Mas podemos perder espaço para desenvolvedores que sabem usá-la melhor do que nós, e essa distinção vale levar a sério.

Eu escolhi aprender. E cada vez mais, estou gostando do que essa escolha produz.

Conclusão

A direção é clara: cada vez mais IA, cada vez mais integrada, cada vez mais deliberada. Não porque é tendência, mas porque, na prática, funciona. E porque trabalhar com uma ferramenta que multiplica o que você consegue entregar é, no fim das contas, simplesmente mais satisfatório.

Descobri que não preciso competir com a IA em velocidade de geração. Preciso ser boa no que ela não consegue fazer: pensar, julgar, contextualizar, decidir, e fazer as perguntas certas.

Por enquanto, essa divisão está funcionando muito bem.

E você? Tem uma experiência parecida, ou completamente diferente? Deixa nos comentários. Esse é exatamente o tipo de conversa que vale ter.