Como Manter um Sistema Feito com IA Depois do Lançamento

Por que o sistema "para de funcionar sozinho" se ninguém mexeu nele

É a pergunta mais comum de quem lançou algo com IA e voltou meses depois. A resposta é que o sistema não vive sozinho: ele depende de peças que continuam se mexendo por baixo dele.

• Bibliotecas (pedaços de código prontos que seu sistema usa) recebem atualizações e as versões antigas param de ser mantidas.
• Serviços externos mudam: a API de pagamento ganha uma nova versão, o serviço de e-mail exige autenticação diferente, a integração do WhatsApp muda de endpoint.
• O servidor atualiza a versão do PHP, do Node ou do Python. Um comando que existia some, e o que rodava perfeitamente vira erro 500.
• Certificado SSL (o cadeado do navegador) vence. Normalmente renova sozinho, mas quando não renova o site inteiro aparece como inseguro.
• O banco de dados cresce. Uma consulta que respondia instantaneamente com 300 registros começa a demorar com 300 mil.

Nada disso é culpa da IA. Acontece com sistema feito por agência, por freelancer ou por time interno. A diferença é que quem tem um desenvolvedor por perto percebe antes. Quem lançou sozinho descobre pelo cliente reclamando.

A rotina mínima de manutenção de sistema web

Você não precisa de um plano de manutenção corporativo. Precisa de uma rotina curta que caiba na sua semana. Sugestão de calendário realista para um sistema pequeno ou médio:

O item que quase todo mundo pula é o trimestral. Backup que nunca foi restaurado não é backup, é esperança. Já vi arquivo de backup gerado religiosamente por meses e corrompido desde a primeira semana. Ninguém sabia porque ninguém tentou usar.

O que "atualizar dependências" significa na prática

Dependência é uma biblioteca de terceiros que seu sistema usa para não reinventar a roda: uma para gerar PDF, outra para enviar e-mail, outra para o login. Elas recebem correções de segurança. Quando uma falha grave aparece em uma biblioteca popular, ela vira alvo de ataque automatizado em poucos dias.

Existem duas categorias e elas merecem tratamento diferente:

• Atualização de correção/segurança: aplique. Risco de quebrar é baixo, risco de não aplicar é alto.
• Atualização de versão maior (o número da frente muda, tipo de 3 para 4): pode quebrar seu código. Só faça com backup fresco, num momento em que você tem tempo de reverter.

Backup e monitoramento sem virar profissional de TI

Backup útil precisa de três coisas: ser automático, ficar em outro lugar e ser testado.

Fora do servidor é o ponto crítico. Backup salvo dentro da mesma hospedagem que pode falhar não protege contra o cenário que mais assusta: a conta suspensa, o servidor comprometido, o provedor com problema. Guardar uma cópia num serviço de armazenamento em nuvem separado, ou até baixada para uma máquina sua, resolve.

Quantas cópias manter? Uma regra prática que funciona bem: 7 diárias, 4 semanais, 12 mensais. Dá cerca de um ano de histórico sem ocupar absurdo, e cobre o caso de você só descobrir um dado corrompido semanas depois.

Monitoramento pode começar simples. Um serviço gratuito de uptime (que fica pingando seu site de minuto em minuto e avisa quando ele cai) já resolve o pior cenário, que é o sistema fora do ar por dois dias sem ninguém saber. O nível seguinte é receber alerta quando o sistema gera erro para o usuário, não só quando cai por completo. Um sistema que carrega a página mas falha em salvar o pedido continua "no ar" para qualquer monitor básico.

Vale monitorar também:

• Espaço em disco (banco cheio derruba tudo de uma vez);
• Vencimento do SSL e do domínio;
• Falhas de envio de e-mail e de webhook (avisos que serviços externos mandam para o seu sistema);
• Tempo de resposta das páginas mais usadas.

Quando a IA não entende mais o próprio código antigo

Aqui está o problema específico de quem construiu com assistente de IA. Você volta seis meses depois, cola o arquivo, pede um ajuste e recebe uma sugestão que ignora metade da lógica ou quebra outra parte. Não é bug do modelo. São três causas concretas:

1. Falta de contexto. A IA vê o arquivo que você mostrou, não o sistema. Se a regra de desconto está espalhada em três lugares e você mostrou um, a resposta vai estar errada nos outros dois. Ela não sabe o que não foi mostrado.

2. Convenções mudaram. Modelos novos sugerem padrões novos. Você misturou duas maneiras diferentes de fazer a mesma coisa dentro do mesmo projeto, e o código vira uma colcha de retalhos que nem você nem a IA leem com segurança.

3. Ninguém documentou as decisões. Por que aquele campo aceita valor vazio? Por que aquela rotina roda de madrugada? A IA não adivinha intenção. Ela vai "corrigir" o que parece errado e quebrar algo que existia por um motivo.

O que reduz isso de forma real:

• Um arquivo de contexto no projeto. Um texto simples explicando o que o sistema faz, quais são as regras de negócio esquisitas, o que nunca pode ser alterado. Você cola isso junto do pedido, ou deixa na raiz do projeto se sua ferramenta lê automaticamente. É o item de maior retorno por esforço em manutenção de sistema web feito com IA.
• Comentários de "por quê", não de "o quê". "Este bloco existe porque a transportadora rejeita CEP sem hífen" vale mais que dez comentários explicando o óbvio.
• Um pedido por vez. "Ajuste o cálculo do frete" funciona. "Modernize o sistema" gera uma reescrita que você não consegue revisar.
• Peça o diagnóstico antes da correção. Mande a IA explicar o que o código faz antes de mudar. Se a explicação estiver errada, o conserto também estaria.

O ciclo seguro para mexer em algo que já está no ar

A regra de ouro é nunca editar direto no servidor de produção, aquele que seus clientes usam. Sequência que funciona mesmo para quem não programa:

• Backup antes de qualquer coisa. Banco e arquivos. Guarde com a data no nome.
• Trabalhe numa cópia. Pode ser um ambiente local no seu computador ou um subdomínio de teste. Custa pouco e evita a maioria dos desastres.
• Use controle de versão. Git registra cada alteração e permite voltar exatamente ao estado anterior. É o botão de desfazer que salva projeto.
• Teste o caminho do dinheiro. Antes de publicar, refaça manualmente o fluxo que gera receita: cadastro, carrinho, pagamento, confirmação, e-mail.
• Publique em horário de baixo movimento e fique olhando por trinta minutos.
• Tenha o plano de volta pronto. Se der ruim, você reverte em minutos, não improvisa em pânico.

Quando o sistema mexe com dados sensíveis, cobrança recorrente ou informação de saúde, some a isso um cuidado extra: mudanças assim merecem revisão de alguém que programa, mesmo que só uma hora de consultoria pontual. Não porque a IA erra sempre, mas porque o custo do erro nesses casos é desproporcional.

Quanto isso custa e quando vale pagar alguém

Manter tem custo fixo, mesmo que o sistema não mude. Hospedagem, domínio, armazenamento de backup, serviços de e-mail transacional e eventuais créditos de API de IA. Para um sistema pequeno, isso normalmente cabe numa faixa de poucas dezenas a algumas centenas de reais por mês, dependendo muito de tráfego e das integrações. Vale mapear esses valores por escrito, porque cobrança esquecida no cartão é como sistema morre em silêncio.

Sinais de que chegou a hora de ter apoio profissional, seja mensal ou por demanda:

• Você deixou de mexer no sistema por medo de quebrá-lo, e ele está travando o crescimento do negócio;
• Já existem clientes pagando e uma queda de meio dia gera prejuízo mensurável;
• O sistema guarda dado pessoal de terceiros e você não sabe responder onde ele está e quem acessa;
• Toda alteração pequena vira três dias de tentativa e erro;
• Você não consegue explicar para outra pessoa como o sistema funciona.

Vibe coding (construir descrevendo o que você quer para a IA, sem escrever o código na mão) é excelente para tirar a ideia do papel e provar que existe demanda. O que ele não elimina é a fase de operação. Continuar sozinho depois que o sistema virou parte da operação da empresa costuma ser mais caro do que contratar manutenção, só que o custo aparece de forma difusa: no seu tempo, nos clientes perdidos e no dia em que algo não volta.