Programar com um assistente de IA deixou de ser aposta e virou rotina: este blog, o portal de treinamentos e o robô que monitora sites oficiais nasceram com um assistente no teclado. O que essa rotina ensinou cabe numa frase: a IA amplifica o que já existe no processo. Onde há disciplina, ela vira velocidade; onde há pressa, ela vira estrago em escala. As seis práticas abaixo estão em uso hoje, e cada uma nasceu de um tropeço real.

1. Código que a IA entrega “pronto” está apenas proposto

A regra mais barata de todas: nada está pronto até um teste executar de verdade. Explicação confiante do próprio autor não é prova — é o réu jurando inocência. Aqui, todo post e toda mudança passam por uma bateria de nove verificações que roda de ponta a ponta antes de qualquer publicação; o que não dá para executar vira um “não testado” declarado, nunca um “passou” de fachada.

O caso que fixou a regra: uma troca de fontes que parecia perfeita no Windows reprovou no gate de layout rodando em Linux, onde a fonte substituta era outra. Nenhuma leitura de código pegaria isso — só o teste executado no ambiente real pegou.

2. API citada pelo modelo não é API que existe

Modelo de linguagem inventa método, parâmetro e biblioteca com a mesma cara de quando acerta. A regra da casa é dura: o assistente não pode citar API sem mostrar a documentação real — ou apresenta a fonte, ou declara por escrito que está supondo. Suposição declarada se confere em um minuto; suposição escondida vira erro de produção com assinatura de quem confiou.

3. Contrato executável no meio do caminho

Confiança não escala; contrato, sim. Cada post deste site passa por um contrato de conteúdo executável que valida título, descrição, categoria e tags contra regras fechadas — e derruba o build quando algo foge. Ele já barrou uma tag fora da lista e uma descrição que estourou o limite por um caractere. A propriedade que importa: o contrato não distingue se quem errou foi o humano ou a IA. É por isso que protege dos dois lados.

4. Diff pequeno, lido por gente, com gate onde o erro custa caro

Volume é o novo risco: com IA, produz-se mais código por hora, e revisão superficial vira aprovação automática com outro nome. As práticas que seguram isso aqui são simples: mudança pequena o bastante para uma revisão honesta, descrição de PR dizendo o que muda e como foi verificado, e nada chega à produção sem aprovação humana. O gate fica onde o erro é caro — antes do merge, um erro custa minutos; depois, custa credibilidade.

5. Verificar no mundo real, não no relatório

Bateria verde não encerra o trabalho. A verificação final é no ambiente de verdade: a página publicada aberta, o retorno do servidor conferido, a imagem olhada com olho humano. O tropeço que ensinou isso: um seletor de estilo genérico venceu a regra específica de um componente e desalinhou um selo na página — sem nenhum erro em teste algum. Automação prova estrutura e geometria; acabamento só aparece para quem olha o resultado publicado.

6. Regras da casa por escrito, contexto que sobrevive à sessão

Boas práticas que vivem só na cabeça não sobrevivem ao próximo dia de trabalho — nem à próxima sessão do assistente. As convenções do projeto ficam em arquivo versionado que a IA lê antes de começar, e o que se aprende vira memória de projeto consolidada. Com uma hierarquia clara: o que está gravado orienta, mas a instrução de agora sempre vence — e conflito entre os dois se declara, nunca se resolve em silêncio.

O checklist antes de aceitar o que a IA escreveu

  1. Um teste executou este código, ou só o autor explicou que funciona?
  2. Cada API citada existe na documentação real, ou tem suposição escondida?
  3. O que barra o erro antes da produção é código ou boa intenção?
  4. O diff cabe numa revisão honesta, ou está grande demais para ler de verdade?
  5. Alguém olhou o resultado no ambiente publicado, não só no relatório do teste?
  6. O que foi combinado está escrito onde a próxima sessão encontra?

Se alguma resposta for “não”, a prática que falta é exatamente a que evitaria o próximo incidente.

Boas práticas de programação com IA não são apenas as boas práticas de sempre — são as de sempre com o volume mais alto, porque cada hora produz mais código, mais confiança aparente e mais chance de o erro escalar junto. A disciplina que já valia dobrou de valor.

Fontes

  • Peça baseada em experiência própria: as práticas descritas estão em uso nos projetos do autor citados no texto, com os incidentes relatados documentados neste site (verificado em 2026-07-31). Nenhum número ou alegação de terceiros foi citado.