Não é sobre código mais rápido. É memória que não esquece, auditoria antes de tocar, e limite claro do que a IA não decide sozinha.
memória granular · auditar antes de tocar · protocolo em produção · hardening ≠ decisão de negócio
A gente já escreveu sobre usar IA pra montar um SaaS do zero. Esse post é outro: é sobre o dia a dia normal — dez projetos de cliente abertos ao mesmo tempo, cada um com stack e regra de negócio diferente, e a pergunta real não é “quão rápido a IA escreve uma função”, é “como não misturar o contexto do cliente A com o do cliente B”.
O ganho que importa não é velocidade de digitação. É rotina: memória que sobrevive entre sessões, disciplina de auditar antes de mexer, e separar o que é melhoria técnica do que é decisão de negócio. Isso é o que muda quando você roda IA em produção, todo dia, em vários projetos — não um demo.
Toda sessão de trabalho termina do mesmo jeito: o que foi decidido, o porquê e qualquer gotcha novo viram um arquivo — um fato por arquivo, não um log gigante que ninguém relê. Da próxima vez que alguém mexer naquele sistema, a lição já está carregada antes da primeira pergunta.
Essa memória específica é a razão pela qual um bug que dois clientes corrigiram cada um pela metade virou visível como padrão em vez de continuar sendo dois incidentes desconectados. Sem o registro, a segunda correção teria sido só mais um bug fix — não a descoberta de que faltava um padrão.
Regra: memória errada é pior que memória nenhuma. Todo fato tem data e contexto, e é revisado — não empilhado pra sempre.
Documentação descreve o que deveria estar rodando. Só o código real, o que está de fato deployado, diz o que está rodando. Antes de qualquer mudança em sistema de cliente em produção, a regra é ler o arquivo real primeiro — mesmo quando existe doc dizendo o que “deveria” estar lá.
Foi assim que achamos, semana passada, um bug de perda silenciosa que já tinha sido corrigido em dois clientes diferentes — mas que continuava intacto num terceiro havia quatro meses, porque ninguém tinha comparado o código real dele com o padrão que já existia em outro lugar. A doc dizia uma coisa. O deploy dizia outra.
Regra: “a doc diz que funciona assim” não é evidência. Evidência é ler o arquivo que está deployado, ou rodar a query contra o banco real.
Mudança sem risco pode sair direto. Mudança em produção segue um protocolo fixo: entender o estado real, propor um plano por escrito, migração sempre aditiva, deploy só pelo canal oficial — nunca um atalho — e validação ao vivo depois, não só confiar na mensagem de “sucesso” da ferramenta.
Pra decisão que carrega peso de verdade — mexer em dado que alimenta otimização de campanha ativa, por exemplo — vale trocar de motor: pedir a análise pro modelo mais forte disponível, especificamente pra essa decisão, em vez de deixar o mesmo fluxo do dia a dia decidir de passagem.
Regra: quanto maior o raio de impacto da mudança, mais devagar e mais checado o caminho até ela — não o contrário.
Toda melhoria técnica passa por um filtro antes de subir: ela só muda robustez, ou ela também muda o que o sistema decide ou reporta? Se um campo pertence a outro sistema, ou um número específico roteia pra um time específico, isso é regra do cliente — não unifica porque “ficaria mais limpo”.
Quando a mudança técnica esbarra numa decisão de negócio — por exemplo, mudar quando um evento de conversão dispara — ela vira dois passos: a parte que só deixa o sistema mais confiável sobe já; a parte que muda o que é reportado fica documentada, medida, e só sobe com aprovação explícita.
Regra: hardening nunca é desculpa pra decidir por conta própria algo que muda o comportamento de negócio. Se a linha é cinza, ela vira pergunta — não vira suposição.
cada lição vira 1 arquivo com data, porquê e como aplicar — pra não corrigir o mesmo bug do zero duas vezes.
ler o código real deployado, não a documentação. Doc descreve intenção; o deploy é o que roda de fato.
plano por escrito, migração aditiva, deploy só pelo canal certo, validação ao vivo — sempre, sem atalho em produção.
melhoria técnica nunca decide regra de negócio sozinha. Linha cinza vira pergunta explícita, não suposição silenciosa.
IA na rotina de desenvolvimento não é escrever código mais rápido. É rodar o mesmo rigor todo dia, em todo projeto, sem cansar — memória que não esquece, auditoria que não confia de graça, e disciplina que separa o que é robustez do que é decisão.