Como uso IA no desenvolvimento web (sem hype)

O cenário real

Uso ferramentas de IA no meu fluxo de desenvolvimento diário. Cursor, Claude, GitHub Copilot. Não porque é tendência. Porque economiza tempo em tarefas específicas.

O discurso “IA vai substituir programadores” é tão exagerado quanto era “WordPress vai acabar com devs” em 2015. Não aconteceu. Não vai acontecer. O que aconteceu com WordPress foi: devs que faziam só instalação de tema perderam espaço. Devs que faziam trabalho real continuaram trabalhando. Com IA vai ser a mesma coisa.

O que mudou: a barra de produtividade subiu. Quem usa bem produz mais. Quem não usa fica mais lento em comparação. Mas “usar bem” é a parte que ninguém explica.

Onde IA acelera de verdade

Boilerplate e código repetitivo

Criar componente React com TypeScript, configurar Supabase client, montar estrutura de API route, criar hook customizado com tipos corretos. Coisas que eu sei fazer de olho fechado mas que tomam 10-15 minutos de digitação. IA faz em segundos.

Exemplo concreto: no AutoPars, cada integração (Asaas, Melhor Envio, Zapi, Resend, Cloudflare) precisava de um client com configuração de headers, token, base URL e tipagem. São 5 arquivos quase idênticos em estrutura. IA gerou os 5 em minutos. Eu ajustei os detalhes específicos de cada API.

Testes

Escrever testes unitários pra funções existentes é onde IA mais me poupa tempo. Ela lê a função, entende o que faz e gera os edge cases. Eu reviso, ajusto o que não faz sentido, e adiciono cenários que ela perdeu.

O ganho real não é a IA escrever testes melhores que eu. É tirar a barreira de inércia. Escrever teste é a tarefa que todo dev adia. Com IA gerando o esqueleto, eu ajusto em 5 minutos o que levaria 20 pra escrever do zero.

Um padrão que funciona bem: escrevo o teste mais importante manualmente, pra definir o estilo e a estrutura. Depois peço pra IA gerar os próximos 5-10 cenários seguindo o mesmo padrão. Ela mantém a consistência e cobre os edge cases que eu ia deixar pra depois (e “depois” geralmente significa “nunca”).

Documentação

Gerar JSDoc, comentários de função, README de projeto, changelog. A parte do trabalho que todo dev adia até o momento de entregar, e aí faz correndo e mal feito. IA faz documentação competente sem reclamar e sem procrastinar.

Pesquisa e debugging

Em vez de abrir 5 abas do Stack Overflow, pergunto direto. “Essa query tá lenta no Supabase, o que pode ser?” e recebo hipóteses pra investigar: falta de índice, N+1, policy de RLS pesada. Não substitui entender o problema, mas acelera o diagnóstico.

Isso é especialmente útil com APIs que não conheço. Quando integrei o Melhor Envio pela primeira vez no AutoPars, usei IA pra entender a estrutura da API, os endpoints necessários e o fluxo de autenticação. O que levaria uma tarde de leitura de docs levou 30 minutos de conversa com a IA + validação na documentação oficial.

Migração e refatoração

Converter arquivo JS pra TypeScript, mudar padrão de imports, atualizar API deprecated, renomear variáveis em 30 arquivos. Trabalho mecânico que IA faz bem e rápido. Num projeto recente, migrei 40 arquivos de JavaScript puro pra TypeScript com tipagem estrita. A IA inferiu os tipos corretos em uns 80% dos casos. Os 20% restantes precisaram de ajuste manual, mas ainda assim levou um terço do tempo que levaria fazendo tudo na mão.

CSS e styling

Gerar classes Tailwind pra um layout que eu descrevo, converter design mental em código CSS. IA é particularmente boa nisso porque CSS é repetitivo e previsível. “Card com padding 24, borda sutil, border-radius 12, fundo escuro com hover levantando 2px” — IA traduz pra código imediatamente.

Responsividade também. Pedir “agora faz isso funcionar em mobile com stack vertical e font menor” gera o resultado correto em 90% das vezes. O ajuste fino de breakpoints e espaçamentos ainda é manual, mas o grosso do trabalho sai pronto.

Onde IA atrapalha

Arquitetura de sistema

IA não sabe qual é o contexto do seu negócio, qual a escala esperada, quais são as restrições reais, qual é o orçamento de infra, e quais são as competências do time que vai manter o código.

No AutoPars, a decisão de separar o marketplace React da LP Astro foi minha. IA teria sugerido fazer tudo em Next.js com SSR. Funcionaria? Tecnicamente sim. Seria a melhor decisão? Não. O marketplace precisa de SPA pra interatividade, e a LP precisa de SSG pra SEO. Duas stacks, dois deploys, cada um otimizado pro que faz. Essa decisão veio de experiência com os trade-offs de cada abordagem, não de um prompt.

Código que parece certo mas não é

Esse é o risco mais perigoso. IA gera código que compila, passa lint, e parece correto. Mas a lógica pode estar errada de formas sutis.

Já aceitei sugestão de IA que implementava um filtro de produtos com a lógica invertida — mostrava o que deveria esconder e escondia o que deveria mostrar. O código era limpo, bem tipado, sem erros de sintaxe. O bug só apareceu quando testei com dados reais.

O problema: quando você para de prestar atenção e confia no output sem revisar linha por linha, o bug vai pra produção. IA não sabe se o resultado tá certo. Ela sabe se parece certo. A diferença entre os dois é onde mora o risco.

Regra de negócio complexa

“Se o vendedor tiver plano premium e o comprador for PJ, aplica desconto escalonado por volume mas só se o frete for tipo X e a região de entrega for Y.” Isso é lógica que precisa de conversa com o cliente, não de prompt.

IA pode até implementar a regra se você descrever com precisão. Mas a parte difícil não é implementar — é descobrir qual é a regra. Isso vem de reunião, pergunta incômoda, e entendimento do negócio que nenhuma IA tem.

Segurança

IA não pensa em SQL injection, XSS, CSRF ou RLS. Gera código que funciona, não código que é seguro. No Supabase, RLS (Row Level Security) é a camada de segurança mais importante — e IA consistentemente gera policies de RLS que são permissivas demais ou restritivas demais. A responsabilidade de segurança continua sendo do dev.

Já peguei sugestão de IA expondo endpoint sem autenticação, retornando dados de outros usuários numa query mal filtrada. O código rodava, os tipos batiam, o lint passava. Mas qualquer pessoa autenticada conseguia ver dados de qualquer conta. Esse tipo de falha não aparece em teste unitário — aparece quando alguém mal intencionado testa a API manualmente.

Código que ninguém entende

IA pode gerar soluções “criativas” que funcionam mas são impossíveis de manter. Regex de 200 caracteres, one-liners com 4 ternários encadeados, abstrações desnecessárias. Código que resolve o problema hoje e cria três amanhã.

Como uso na prática

Meu fluxo com IA tem 5 regras:

1. Penso na solução antes de pedir qualquer coisa. Se eu não sei como resolver o problema, IA vai gerar algo que eu não consigo avaliar. Primeiro entendo o que precisa ser feito, depois uso IA pra acelerar a execução
2. Uso IA pra implementar partes que eu já sei como resolver. O “como” eu sei, quero que a IA faça a digitação
3. Reviso tudo que IA gera antes de commitar. Linha por linha. Se não entendo por que uma linha tá ali, reescrevo
4. Nunca uso IA pra decisão de arquitetura ou regra de negócio crítica. Essas decisões precisam de contexto humano
5. Uso muito pra pesquisa e exploração de APIs que não conheço. É como ter um par programando que já leu a documentação

IA acelera a execução. O raciocínio continua sendo meu.

O que isso muda pro cliente

Projetos ficam mais rápidos. O que antes levava 6 semanas pode levar 4. Não porque a qualidade caiu, mas porque o tempo gasto em tarefas mecânicas diminuiu.

O app Mariah (controle de encomendas) saiu em menos de 4 horas. Parte disso é experiência com a stack (React + Supabase + Tailwind). Parte é IA acelerando o boilerplate. Os dois juntos.

Mas atenção: dev junior com IA não vira dev sênior. Vira dev junior mais rápido, o que é perigoso: gera mais código com menos julgamento. O ganho real está no dev sênior usando IA, porque experiência e julgamento continuam sendo o que separa código que funciona de código que sobrevive em produção. Pro cliente, isso significa que contratar dev experiente que usa IA é o melhor cenário — combina velocidade com qualidade de decisão.

O futuro (sem hype)

IA vai ficar melhor. Os modelos vão entender mais contexto, gerar menos bug, e lidar melhor com complexidade. Mas ainda vai precisar de alguém que entende o problema do negócio, toma decisão técnica com trade-offs reais, e assume responsabilidade pelo resultado.

A ferramenta muda. O trabalho muda de forma. A responsabilidade não.

O dev que vai se dar bem nos próximos anos é o que trata IA como ferramenta de produtividade e não como substituto de conhecimento. Saber pedir pra IA é útil. Saber avaliar o que ela entrega é o que separa profissional de amador. E saber quando não usar é o que evita os problemas mais caros.