Programar com IA: como uso no dia a dia sem perder o controle

Todo mundo discute se a IA vai substituir programador. Pouca gente conta, porém, como é programar com IA na rotina de verdade. Eu mantenho vários projetos sozinho, então ela já faz parte do meu trabalho. Mesmo assim, não deixo que ela decida sozinha o que vai para produção.

Neste post, mostro o fluxo que uso, onde a IA ajuda de verdade e onde ela costuma errar.

Fluxo para programar com IA: prompt, código gerado, revisão e produção

Programar com IA começa antes do código: começa no prompt

Meu fluxo quase nunca começa abrindo o editor para escrever código. Em vez disso, começo escrevendo um prompt. Depois, itero nele até a instrução ficar clara, e só então peço a implementação. Ferramentas como Claude e Cursor geram o código a partir dessa descrição.

Esse cuidado evita um problema comum. Quando o pedido é vago, a IA preenche as lacunas com suposições, e nem sempre elas batem com o que eu precisava. Por isso, gasto mais tempo no prompt do que gastava antes na digitação. Se você quer melhorar nessa etapa, a documentação oficial de prompt engineering da Anthropic é um bom ponto de partida.

Onde programar com IA realmente ajuda

Na prática, a IA rende mais em tarefas que são trabalhosas, mas bem definidas. Alguns exemplos:

  • Código repetitivo. Telas de listagem, formulários, rotas CRUD e esquemas de validação saem rápido.
  • Primeira versão de uma funcionalidade. Ela me entrega um rascunho funcional, que eu depois refino.
  • Tradução entre contextos. Converter um trecho de uma abordagem para outra costuma funcionar bem.
  • Exploração de alternativas. Peço duas ou três formas de resolver o mesmo problema e comparo.

Além disso, ela ajuda a manter ritmo. Quando opero vários sistemas ao mesmo tempo, economizar tempo nas partes mecânicas deixa mais energia para as decisões que importam.

Onde programar com IA dá errado

Por outro lado, a IA tem limites claros, e eles aparecem sempre nos mesmos lugares.

Primeiro, ela não conhece o contexto completo do seu projeto. Por isso, pode sugerir uma solução correta em abstrato que quebra o padrão que você já adotou. Segundo, ela erra com confiança. O código parece certo, compila e passa em um teste superficial, mas esconde um caso de borda que só aparece em produção. Terceiro, ela tende a complicar. Muitas vezes entrega mais abstração do que o problema pedia.

Um caso real: sessões que continuavam válidas depois do logout

Esse tipo de erro silencioso aparece mesmo em código que parece correto. Em um dos meus sistemas, implementei a autenticação com dois tokens: um de acesso, válido por 30 minutos, e um de renovação, válido por 7 dias. No uso normal, tudo funcionava. Login, navegação e renovação passavam sem problema. O erro estava no que acontece quando alguém precisa ser expulso.

Durante cerca de cinco semanas, a revogação ficou incompleta em três pontos:

  • Logout: só o token de renovação era invalidado. O token de acesso continuava funcionando até expirar.
  • Troca de senha: nenhuma sessão já aberta era derrubada. Quem tivesse roubado um token de renovação mantinha acesso por até 7 dias, mesmo depois de a vítima trocar a senha.
  • Desativação de usuário: os tokens que ele já tinha continuavam aceitos por até 30 minutos. Isso acontecia porque a API não consultava o banco a cada requisição.

Ou seja, as três ações que alguém usaria para tirar um invasor ou um ex-funcionário do sistema não tinham efeito imediato. Corrigi em três mudanças. O logout passou a revogar também o token de acesso. A troca de senha passou a invalidar todos os tokens emitidos antes dela. Por fim, a API passou a conferir a cada requisição se o usuário ainda está ativo.

A lição vale para qualquer código, seja escrito por você ou gerado por IA. O caminho feliz quase sempre funciona. Os problemas moram nos caminhos de saída: logout, revogação e desativação. Por isso, essas são as partes que mais reviso hoje.

Como reviso o código gerado antes de subir

Como a IA erra com confiança, a revisão virou a parte mais importante do processo. Eu sigo algumas regras simples:

  1. Leio tudo que entra. Nada vai para o projeto sem que eu entenda o que cada trecho faz.
  2. Comparo com os padrões que já uso. Prefiro manter consistência com o resto do projeto a adotar uma ferramenta nova só porque a IA sugeriu.
  3. Testo os casos de borda. Valores vazios, listas grandes e erros de rede são onde o código gerado mais falha.
  4. Peço explicação quando algo parece estranho. Se eu não entendo uma escolha, pergunto o motivo antes de aceitar.

Assim, a IA escreve o rascunho, mas a responsabilidade pelo resultado continua sendo minha.ado por IA. O caminho feliz quase sempre funciona. Os problemas moram nos caminhos de saída: logout, revogação e desativação. Por isso, essas são as partes que mais reviso hoje.

Como reviso o código gerado antes de subir

Como a IA erra com confiança, a revisão virou a parte mais importante do processo. Eu sigo algumas regras simples:

  1. Leio tudo que entra. Nada vai para o projeto sem que eu entenda o que cada trecho faz.
  2. Comparo com os padrões que já uso. Prefiro manter consistência com o resto do projeto a adotar uma ferramenta nova só porque a IA sugeriu.
  3. Testo os casos de borda. Valores vazios, listas grandes e erros de rede são onde o código gerado mais falha.
  4. Peço explicação quando algo parece estranho. Se eu não entendo uma escolha, pergunto o motivo antes de aceitar.

Assim, a IA escreve o rascunho, mas a responsabilidade pelo resultado continua sendo minha.

Programar com IA muda o que vale aprender

Aqui volta aquela dúvida do início: ainda vale aprender a programar? Na minha experiência, sim, e talvez até mais. Para revisar código gerado, é preciso entender o que ele faz. Da mesma forma, para escrever um bom prompt, é preciso saber o que você quer construir e como as peças se encaixam.

Ou seja, a IA diminui o custo de digitar código, mas aumenta o valor de quem entende arquitetura, lê com atenção e decide bem. Se você quer ver como essas decisões aparecem na prática, vale ler o post sobre FastAPI e Angular.

Conclusão: programar com IA é trabalhar com um assistente rápido, não com um piloto automático

No fim das contas, o que funciona para mim é tratar a IA como um assistente muito rápido que precisa de supervisão. Escrevo prompts claros, reviso com cuidado e mantenho as decisões de arquitetura na minha mão. Dessa forma, ganho velocidade sem abrir mão da qualidade.

E você, como tem sido programar com IA na sua rotina? Conta nos comentários onde ela mais ajuda e onde mais atrapalha.

0 Comentários

Deixe um comentário