Um ano usando IA no desenvolvimento: o que mudou de verdade
Em janeiro deste ano, pedi para a IA me ajudar a dividir um PDF de 1.000 páginas em quatro arquivos menores. O script funcionou em 15 minutos. Pensei: “legal, uma ferramenta útil”. Em dezembro, estava usando a mesma ferramenta para diagnosticar gargalos de performance em queries SQL que rodavam sobre milhões de linhas no Posseidon ERP. A diferença entre os dois momentos não é de tecnologia. É de quanto eu aprendi a confiar, a questionar e a decidir o que pedir.
Esse artigo é um mapa dessa jornada. Não uma lista de vitórias. Um registro de como a confiança no uso de inteligência artificial no desenvolvimento de software cresce quando você coloca a ferramenta sob pressão crescente — e o que acontece quando ela falha no pior momento possível.
Fase 1: automação sem risco, confiança sem custo
Todo desenvolvedor tem uma fila de tarefas que nunca chegam à frente do backlog. São problemas reais, com solução técnica clara, mas cujo custo de implementação sempre superou o benefício imediato. Para mim, eram os scripts de automação.
O primeiro script e o que ele revelou
O PDF de 1.000 páginas era um relatório que precisava ser enviado por partes, já que vários sistemas que processavam o arquivo tinham limite de tamanho. A solução era simples: dividir em quatro arquivos de 250 páginas. O problema era que eu nunca tinha tocado em manipulação de PDF com Python.
Descrevi o problema para a IA. Especifiquei: Python 3.11, biblioteca PyPDF2, arquivos de saída nomeados sequencialmente, tratamento do caso em que o total de páginas não é divisível por quatro. Em menos de 15 minutos, o script estava funcionando.
O risco de falha era zero. Nenhum banco de dados em produção, nenhum usuário dependendo do resultado em tempo real, nenhum impacto no negócio se o script precisasse ser reescrito. Ou seja, era o ambiente perfeito para aprender como a IA responde quando você especifica bem.
⚠️ O que aprendi logo ali: a qualidade do output depende diretamente da qualidade do input. Com um prompt vago — “divide esse PDF em partes menores” — o código gerado não tratava o caso de arquivos com número de páginas ímpar. Com um prompt preciso, o código estava correto na primeira tentativa.
40 scripts e uma mudança de mentalidade
Ao longo dos meses seguintes, repeti esse padrão mais de 40 vezes. Redimensionador de imagens em lote usando Pillow, com controle de aspect ratio e qualidade de compressão configurável. Conversor de formatos de arquivo. Extrator de dados de planilhas com estruturas inconsistentes. Cada script resolvia um problema específico que antes ficava na fila indefinidamente.
Por isso, minha relação com automação mudou. Antes, eu avaliava se um problema valia o esforço de automatizar. Após esses meses, passei a automatizar quase tudo que se repete mais de duas vezes, porque o custo de criação caiu radicalmente.
No entanto, esse período de baixo risco também criou um hábito perigoso: eu estava aceitando o código gerado com pouca revisão, porque ele sempre funcionava. Além disso, o código simples raramente falha em edge cases. Essa falsa sensação de segurança cobrou o preço na fase seguinte.
Fase 2: decisões que custam refatoração
Landing pages e aplicativos móveis têm algo em comum: os erros de arquitetura que você comete no início custam semanas de refatoração depois. Por isso, essa fase foi onde a relação com a IA ficou mais complexa.
Landing pages: velocidade com ressalvas
Ao longo do ano, criamos várias landing pages para a DPSistemas. O processo com a IA é eficiente: descrevo o objetivo da página, o público-alvo, o produto ou serviço, e solicito uma estrutura inicial em HTML e CSS. O resultado é um ponto de partida sólido que ajusto, refino e personalizo.
O problema apareceu em uma das páginas quando percebi, semanas depois da publicação, que o código JavaScript gerado para o formulário de contato não tratava corretamente o caso de campos com caracteres especiais comuns em nomes brasileiros. O formulário simplesmente descartava a submissão sem feedback para o usuário. Além disso, o erro não aparecia no console do navegador de forma óbvia.
💡 A lição aqui é que o código gerado por IA funciona no caso feliz. Ou seja, funciona quando o usuário faz exatamente o que o desenvolvedor imaginou. Testar edge cases — o nome com acento, o e-mail corporativo com subdomínio, o campo deixado em branco depois de preenchido — ainda é responsabilidade humana.
Flutter e a escolha que ninguém faz duas vezes
Desenvolvi três aplicativos usando Flutter, com publicação no iOS e no Android. Flutter é um framework do Google que permite escrever uma única base de código em Dart e compilar para múltiplas plataformas, o que teoricamente reduz o trabalho de desenvolvimento mobile pela metade.
O ponto crítico dessa fase foi a escolha de gerenciamento de estado. Em Flutter, você pode usar Provider, Riverpod ou BLoC, entre outras abordagens. Cada uma tem trade-offs reais de verbosidade, testabilidade e curva de aprendizado. Escolher errado significa refatorar a arquitetura inteira do aplicativo depois que ele já tem código de negócio acoplado à camada de estado.
Pedi para a IA avaliar as três opções para o meu contexto específico: aplicativo de médio porte, time pequeno, necessidade de testabilidade razoável sem overhead excessivo. A análise que recebi era boa. Porém, o código de exemplo que a IA gerou para validar a abordagem escolhida usava uma API do Riverpod que havia sido depreciada na versão 2.0 do pacote.
⚠️ O aplicativo compilava. Os testes passavam. Em produção, no entanto, o comportamento era inconsistente em dispositivos iOS com versão de sistema anterior à que eu tinha usado para testar. O bug levou dois dias para ser rastreado até a causa raiz: o código gerado assumia comportamento da versão 1.x do Riverpod, e a incompatibilidade só se manifestava em condições específicas de ciclo de vida do widget.
Dessa forma, aprendi que a IA não sabe em qual versão de framework você está trabalhando a menos que você informe explicitamente. Além disso, ela não sabe que a documentação que ela usou no treinamento pode estar desatualizada. Isso é responsabilidade sua.
O que o debug entre plataformas ensina sobre especificação
A segunda fase de bugs no Flutter foi de comportamento diferente entre iOS e Android para a mesma lógica. Animações que funcionavam perfeitamente no Android renderizavam com atraso no iOS. Inputs de texto que aceitavam o teclado corretamente no iOS ignoravam o foco programático no Android.
Nesses casos, a IA foi mais útil do que eu esperava, porque ela conhece as peculiaridades de cada plataforma. No entanto, ela só consegue ajudar se você descrever o comportamento observado com precisão. “O input não funciona no Android” não é uma especificação. “O TextField perde o foco programático após FocusNode.requestFocus() em dispositivos Android com API level 30 ou inferior quando o teclado já está visível” é uma especificação com a qual a IA trabalha de verdade.
Fase 3: produção de verdade, onde a falha tem preço
A otimização de queries SQL no Posseidon ERP foi a fase onde o custo de um erro deixou de ser “precisa refatorar” e passou a ser “o sistema está lento para todos os usuários em horário de pico”.
Quando a IA explica e não só resolve
Uma parte significativa do trabalho aconteceu em queries que rodavam sobre tabelas com volume crescente de registros. O problema clássico: uma query que funciona bem com 10.000 linhas começa a degradar com 500.000 e se torna inaceitável com 5 milhões.
O que diferenciou a IA de uma busca no Stack Overflow foi o seguinte: ela não apenas sugeria como reescrever a query. Ela explicava por que a versão anterior era mais lenta. Assim, aprendi sobre a diferença entre index scan e sequential scan no PostgreSQL, sobre quando um índice composto faz sentido e quando ele aumenta o custo de escrita sem benefício proporcional na leitura, e sobre como o query planner toma decisões baseadas em estatísticas de distribuição de dados.
Por isso, o aprendizado foi real. Não copiei soluções. Entendi os princípios.
O risco que a IA introduz em produção
No entanto, aqui está o ponto mais importante desta seção: em uma das otimizações, a IA sugeriu adicionar um índice parcial numa coluna de status. A sugestão fazia sentido para o padrão de consulta que eu descrevi. O que não descrevi — porque não considerei relevante — era que aquela coluna específica recebia atualizações em lote toda madrugada por um processo de sincronização.
O índice parcial melhorou a performance das queries de leitura em 60%. Além disso, aumentou o tempo do processo de sincronização noturna em 40%, porque cada atualização em lote precisava recalcular o índice. Esse processo, por sua vez, mantinha locks nas tabelas por mais tempo do que o aceitável, causando timeouts em jobs paralelos que rodavam na mesma janela.
⚠️ A IA não sabia do processo de sincronização. Eu não informei. O erro foi meu, não da ferramenta. No entanto, esse caso cristalizou uma regra que sigo desde então: antes de aplicar qualquer sugestão de otimização de banco de dados em produção, mapeio todos os processos que escrevem naquela tabela, não apenas os que leem.
Modelagem e as perguntas que a IA faz melhor que eu
Um benefício inesperado foi na revisão de modelagem de dados. Quando descrevo uma estrutura de tabelas para a IA e pergunto sobre potenciais problemas de performance, ela levanta questões que eu não teria feito sozinho: “O que acontece com essa query de agregação quando essa tabela tiver 10 milhões de linhas e você precisar filtrar por um campo que não está indexado?” Ou: “Essa relação many-to-many está normalizada, mas o padrão de acesso que você descreveu faz joins frequentes nessas três tabelas. Considerou uma view materializada?”
Essas perguntas valem mais do que as respostas. Elas treinam o olhar para problemas que só aparecem em escala.
O que mudou na minha forma de pensar, não só de trabalhar
Esse é o ponto que os artigos sobre IA geralmente deixam de lado.
O backlog que ficou possível
Antes, eu priorizava o que era viável dentro das minhas restrições de tempo. Automatizações úteis ficavam na fila. Features que agregariam valor ao Posseidon ERP ficavam em backlog indefinidamente porque o custo de implementação superava o tempo disponível. Melhorias de infraestrutura eram adiadas porque exigiam dias de estudo que eu não tinha.
Com a IA, o custo de implementação caiu o suficiente para que boa parte desse backlog se tornasse viável. Consequentemente, passei a construir mais. Mais rápido. Em mais frentes simultaneamente.
O erro que a velocidade cria
Em determinado momento, construí uma feature completa para o Posseidon ERP em dois dias. Banco de dados modelado, lógica de negócio implementada, tela responsiva, integração com o módulo existente. Do zero ao funcionando em 48 horas.
Uma semana depois, descartei tudo.
Não porque o código estava errado. O código estava correto. Descartei porque a feature resolvia um problema que eu tinha assumido que os usuários tinham, mas que eles não tinham. Falei com dois usuários reais depois de pronta e descobri que o fluxo que eu automatizei era feito assim por razões que o sistema não conseguia capturar. Mudar o fluxo criava um problema maior do que o que resolvia.
A IA me deu velocidade na direção que eu apontei. Porém, a direção estava errada. E com velocidade maior, cheguei ao lugar errado mais rápido.
Por isso, a conclusão que carrego deste ano não é sobre a ferramenta. É sobre o que a ferramenta deixa evidente: quando o custo de construir cai, o custo de construir a coisa errada sobe. Não em esforço de implementação, mas em custo de oportunidade, dívida técnica de código que ninguém usa e tempo gasto mantendo algo que não deveria existir.
O que ainda é humano
Arquitetura de software ainda é humana. Não porque a IA não consiga sugerir arquiteturas — ela sugere, e às vezes bem. Mas porque a decisão de qual problema vale a pena resolver, qual feature realmente serve o usuário e qual otimização faz sentido para o negócio depende de contexto que a ferramenta não tem acesso a menos que você forneça.
A IA não conhece seus usuários. Não conhece as decisões que foram tomadas antes de você, os compromissos que não estão documentados, as restrições que existem por razões que não aparecem no código. Além disso, ela não vai te dizer quando parar de construir.
O gargalo desta era não é a capacidade de gerar código. É a capacidade humana de formular os problemas certos com precisão suficiente para que a solução valha o custo de existir.
Aprendi, sobretudo, que a inteligência artificial comprimiu meu tempo de execução. No entanto, não comprimiu — e nunca vai comprimir — o tempo de pensar se o que estou executando deveria existir.
Esse espaço ainda é todo meu.
💬 Para reflexão: Quando construir ficou mais barato, decidir o que construir ficou mais caro. A vantagem competitiva migrou da sintaxe para o julgamento.
FAQ
A inteligência artificial substitui o desenvolvedor de software?
Não. A IA implementa bem o que é especificado com clareza e contexto suficiente. No entanto, ela não decide o que deve ser construído, não conhece o contexto de negócio e não avalia se o problema certo está sendo resolvido. Essas decisões continuam sendo responsabilidade humana, e são justamente as que definem se o software tem valor real.
Como formular prompts eficazes para geração de código?
Forneça contexto antes da especificação: linguagem, versão exata, framework, restrições existentes e o que já existe no sistema. Depois descreva o comportamento esperado com precisão, incluindo os casos de erro que precisam ser tratados. Um prompt vago gera código genérico. Um prompt com contexto completo gera código que funciona no seu ambiente específico.
O código gerado por IA pode ir direto para produção?
Não sem revisão e testes. Além de possíveis inconsistências com versões mais recentes de frameworks e bibliotecas, o código gerado funciona no caso principal mas frequentemente falha em edge cases que só surgem com dados reais ou condições específicas de ambiente. Testes automatizados e revisão de código são obrigatórios antes de qualquer deploy.
Como usar IA para otimização de queries SQL sem introduzir novos problemas?
Antes de aplicar qualquer sugestão de otimização em produção, mapeie todos os processos que escrevem nas tabelas envolvidas, não apenas os que leem. Além disso, informe para a IA o volume de dados atual e projetado, o padrão de acesso completo e os processos concorrentes que rodam na mesma janela de tempo. Otimizações de leitura podem degradar escritas de formas que só aparecem em ambiente real.
Quanto tempo leva para usar IA de forma produtiva no desenvolvimento?
Algumas semanas de uso consistente são suficientes para entender como formular perguntas e como revisar o output. O ganho de produtividade em tarefas de baixo risco começa rápido. Por outro lado, a calibração para tarefas críticas — saber quando confiar, quando questionar e quando o contexto que você não forneceu pode invalidar a sugestão — leva meses e vem com erros reais.
