Criei um produto com IA — como melhorá-lo sem estragar o que funciona

Saiba mais sobre como trabalhar com modelos na documentação da Ailoot.

Porque é que o trabalho mais dispendioso começa depois do lançamento?#

Criou uma aplicação numa noite, publicou um link e enviou-o aos amigos. Funciona. Depois, uma semana mais tarde, aparece a primeira pessoa a usá-la a sério, clica em algo da forma errada e metade das funcionalidades deixa de funcionar. Pede ao Claude que corrija o problema — ele corrige uma coisa e estraga outra. Soa-lhe familiar?

É aqui que surge a questão principal: o que fazer depois de lançar um produto, quando a euforia do primeiro protótipo funcional já passou e ainda tem de o manter de alguma forma? Poderíamos chamar-lhe vibe coding para adultos. Criar é entusiasmante e rápido. A manutenção exige cabeça fria: percebe o que está a alterar e mantém tudo sob controlo. A maioria das pessoas falha nesta segunda parte porque ninguém a prepara para isso.

Um estudo do setor analisou mais de um milhão de alterações de código de 2 444 equipas e calculou para onde vai realmente o dinheiro gasto no desenvolvimento com IA. Eis o panorama:

O guia «O custo oculto do vibe coding» explica estes valores com mais detalhe. Aí, a questão era aquilo por que está a pagar. Aqui, a questão é diferente: 44 cêntimos de cada dólar vão para a correção de erros — e este artigo inteiro é sobre impedir que essa parcela aumente. O trabalho de a manter sob controlo chama-se manutenção.

A diferença entre alguém que faz vibe coding para adultos e alguém que se limita a tomar conta de uma rede neuronal torna-se visível depois do lançamento. A base de código da primeira pessoa cresce, são feitas melhorias e nada se estraga. Um mês depois, o produto da segunda transformou-se numa geringonça cheia de fugas em que tem medo de mexer. A seguir, explico como ficar no primeiro grupo.

O que se estraga realmente: 5 desastres após o lançamento#

São análises públicas de incidentes reais de produtos criados com IA, com números e datas. Pense nelas como um mapa de um campo minado — cada mina já explodiu para alguém e sabe-se como contorná-la.

Os cinco casos têm a mesma causa fundamental. Por predefinição, a IA faz com que as coisas funcionem agora, não com segurança daqui a um mês, sob carga. Não consegue ver a diferença enquanto desenvolve no seu computador. Ela torna-se evidente quando aparece o primeiro desconhecido com más intenções.

O problema não é não escrever o código à mão — muitas pessoas trabalham assim. O problema é não perguntar: «A base de dados está segura?» A seguir, vou mostrar-lhe um prompt que faz essa pergunta por si.

A primeira rede de segurança é o git e a reversão para «como estava ontem»#

Quando o Claude estraga alguma coisa, precisa de um botão para «voltar a pôr tudo como estava ontem». Tecnicamente, esse botão chama-se git e é mais simples do que parece.

Há três termos que uma pessoa que não programa precisa de compreender:

1. Repositório — a pasta do projeto guardada na nuvem (normalmente no GitHub). Uma cópia de todo o seu código que não está apenas no seu computador.
2. Commit — um ponto de regresso. Na prática, está a dizer ao código: «guarda neste estado». Cada commit é um marco ao qual pode voltar.
3. Deploy — uma transferência. O código estava localmente, no seu computador, e só funcionava para si. O deploy envia-o para um servidor externo, para que funcione para todos.

Desde que tenha pontos de regresso recentes, pode reverter qualquer problema com uma frase. Literalmente.

Estraguei alguma coisa — ontem tudo funcionava, mas hoje já não funciona. Encontra o último commit em que estava tudo bem, mostra-me o que mudou desde então e reverte o projeto para esse estado.

Duas regras a pôr em prática imediatamente, antes de outras pessoas verem o produto:

• O repositório tem de ser privado. Não público. Caso contrário, qualquer pessoa pode ler o seu código e tudo o que está nele.
• Coloque o ficheiro de segredos na lista de ficheiros ignorados. As chaves, as palavras-passe e as credenciais de acesso à base de dados ficam num ficheiro separado (normalmente .env), e esse ficheiro nunca entra no repositório. Adicione uma linha para .env ao .gitignore, e os segredos ficam consigo.

Existe um guia separado sobre como reverter alterações em segurança no Claude Code: Como reverter alterações no Claude Code. Sem pontos de regresso, está a andar numa corda bamba sem rede de segurança e, mais cedo ou mais tarde, vai cair.

O que é que /rewind reverte e o que não reverte?#

O Claude Code cria um instantâneo do estado antes de cada alteração que faz. O comando /rewind (ou carregar duas vezes em Esc) reverte os ficheiros e a conversa para um ponto selecionado. É prático: se estragou uma funcionalidade há cinco minutos, pode voltar cinco minutos atrás.

Mas há uma armadilha que leva os principiantes a perder dados. /rewind não reverte tudo:

A própria Anthropic explica-o claramente: os instantâneos são um botão local para «anular», enquanto o git é o histórico permanente. Os instantâneos complementam o controlo de versões, mas não o substituem.

A lição prática para quem não programa: /rewind vai salvá-lo de uma situação como «o Claude acabou de estragar uma funcionalidade». Mas, se ele tiver conseguido apagar uma linha da base de dados ou carregar código para a nuvem, só o git e uma cópia de segurança da base de dados o poderão recuperar. Por isso, mantenha as duas camadas: instantâneos para reversões rápidas e commits para o histórico permanente do projeto.

Como melhorar sem estragar o que já funciona?#

Uma em cada duas pessoas acaba presa neste ciclo. Pede à IA que corrija um pequeno erro. Ela sugere uma alteração razoável. Essa alteração estraga outra coisa. Pede-lhe que corrija o novo problema e surgem mais dois. E assim sucessivamente.

O ciclo acontece porque o vibe coding é não determinístico. O mesmo prompt dá-lhe código diferente duas vezes. Por isso, cada edição pode alterar discretamente a lógica envolvente: o limite do desconto passa de 10 para 12 por cento ou uma regra de validação muda de comportamento — sem que faça verificações nem receba um único aviso. A isto chama-se desvio lógico, e prejudica silenciosamente precisamente aquilo que gera dinheiro: preços, acesso e pagamentos.

Há uma regra para prevenir esse desvio, simples o suficiente para a pôr na parede: não faça commit de código que não conseguisse explicar a outra pessoa, palavra por palavra.

Na prática, isto transforma-se num procedimento pronto a usar antes de qualquer alteração ao código funcional. Faz com que a IA avance em pequenos passos e lhe mostre exatamente o que mudou.

Antes de alterares o código, faz o seguinte:

Guarda o estado funcional atual como um ponto de regresso separado (commit).

Descreve por palavras exatamente o que planeias alterar e em que ficheiros.

Faz a alteração mais pequena possível — apenas o que resolve a minha tarefa, sem nada extra.

Mostra-me o que mudou e explica cada alteração de forma que eu a consiga explicar a outra pessoa.
Não mexas na lógica de preços, acesso ou pagamentos, a menos que te peça.

Outro princípio que poupa semanas é a disciplina na definição dos limites das tarefas. Um problema, uma alteração, uma implementação rápida. Não peças à IA que reescreva metade do projeto num único prompt. Por vezes, programadores profissionais começam a construir um Uber inteiro quando só precisavam de um botão — e arrastam o projeto durante meses. Não precisa disso.

Tudo o que descrevo assenta numa coisa: a gestão do contexto. Para impedir que a IA estrague a lógica adjacente, precisa de conhecer as regras do seu projeto.

Como verificar uma alteração antes de a publicar?#

Entre «funciona no meu computador» e «funciona para toda a gente» existe uma etapa intermédia que os principiantes ignoram: uma cópia de teste. É uma cópia separada do ambiente de produção, onde verifica uma alteração antes de as pessoas reais a verem. O ciclo de trabalho é o seguinte:

1. Desenvolva e verifique a alteração (desenvolvimento).
2. Faça deploy em staging — uma cópia da produção, mas sem utilizadores reais.
3. Percorra os cenários principais e confirme que nada mudou.
4. Só então faça deploy para produção.

Porque é que isto importa após o lançamento: cada versão traz riscos. Uma pequena alteração de código pode impedir o início de sessão na conta. Uma definição em falta pode deitar abaixo todo o produto. O staging deteta estes problemas sem consequências; em produção, perde clientes.

Para não ter de verificar tudo manualmente de cada vez, dê à IA um prompt para comparar o comportamento da nova versão com o da antiga nas áreas críticas.

Estou prestes a fazer deploy de uma alteração. Percorre os cenários principais do produto pela ordem indicada e verifica se cada um continua a funcionar como antes:

Registo e início de sessão de um novo utilizador.

Pagamento e concessão de acesso após o pagamento.

Direitos de acesso — um utilizador normal não consegue ver os dados de outra pessoa nem a área de administração.

Os valores principais da lógica de negócio (preços, descontos, limites) não mudaram.
Se alguma coisa se comportar de forma diferente da versão anterior, para e mostra-me exatamente o que mudou.

Onde estão os seus segredos? A maior falha de segurança de um principiante#

Vou explicar detalhadamente a maior mina, porque derruba mais produtos do que qualquer outra. Quando a IA escreve código, o mais fácil é pôr uma chave onde funcionará de imediato — diretamente no código da página que se abre no navegador. Não vai notar a diferença durante o desenvolvimento. Mas qualquer pessoa pode ler tudo o que chega ao navegador abrindo as ferramentas de desenvolvimento.

O fundador cujos clientes foram cobrados $87,500 disse mais tarde que um único prompt poderia ter evitado o problema. As cobranças foram finalmente anuladas, mas as taxas não reembolsáveis e a perda de tranquilidade mantiveram-se. Eis o prompt.

Verifica todo o projeto e confirma que nenhuma chave secreta vai parar ao navegador:

Encontra todas as chaves da base de dados, do sistema de pagamentos e dos serviços externos.

Confirma que cada uma está guardada apenas no servidor, em variáveis de ambiente, e não no código da página.

Verifica o histórico do projeto — alguma chave foi parar lá por engano anteriormente?
Mostra-me uma lista de todos os locais onde encontraste segredos e o que é preciso fazer em cada caso.

A mina seguinte, que fica por perto, é verificar as permissões de acesso apenas no navegador. Se o seu produto decidir no código da página se deve «mostrar a área de administração», qualquer pessoa pode contornar essa decisão. As permissões de acesso têm de ser sempre verificadas no servidor. A base de dados só deve devolver dados a quem tem direito a eles — é para isso que serve a segurança ao nível das linhas (RLS), que tem de estar ativada em todas as tabelas.

Antes de vender o acesso ou deixar entrar outras pessoas, faça uma auditoria de segurança geral ao produto.

Analisa o projeto como um atacante e encontra falhas de segurança:

Há chaves secretas guardadas em código que vai para o navegador ou no histórico do projeto?

A segurança ao nível das linhas (RLS) está ativada em todas as tabelas da base de dados e as permissões de acesso são verificadas no servidor, e não apenas no navegador?

Está configurada uma cópia de segurança automática da base de dados e já verifiquei se a consigo restaurar?

A base de dados de produção está isolada do ambiente onde o agente de IA é executado?
Para cada ponto, diz-me se está tudo bem ou exatamente o que precisa de ser corrigido.

Existe um guia completo separado sobre a segurança do vibe coding: Como proteger uma aplicação criada com vibe coding. A regra é simples: considere tudo o que a IA fez por predefinição como não seguro até verificar o contrário.

Onde alojar o produto: a escada do alojamento#

Não precisa de alugar já um servidor próprio e configurá-lo manualmente — no início, é uma tarefa complicada que lhe vai consumir tempo. Pode subir uma escada à medida que o produto cresce:

1. Alojamento gratuito (por exemplo, Vercel) — para si, para testes e para projetos pequenos. Funciona se a plataforma estiver disponível para o seu público e não guardar dados pessoais das pessoas.
2. Plataforma com deploy através de um único comando (Railway) — quando tem um backend e uma base de dados. Faz deploy com um comando e não precisa de configurar um servidor. A barreira de entrada é mínima.
3. Servidor dedicado próprio — quando a carga é elevada e precisa de controlo total. Mude para esta opção mais tarde, quando atingir o limite da plataforma.

Para quem não programa e acabou de lançar um produto, a opção mais fácil é uma plataforma com deploy através de um único comando, sem configuração manual do servidor. Passe para o seu próprio servidor mais tarde. Se quiser seguir este percurso com um exemplo concreto, consulte o guia sobre como fazer deploy de um projeto criado com vibe coding no seu próprio servidor com o Coolify.

Quando deve separar a aplicação, a base de dados e as cópias de segurança?#

Há três coisas que não devem estar todas no mesmo cesto: a aplicação, a base de dados e as cópias de segurança. Enquanto há poucos utilizadores, tudo fica junto, e não há problema. Mas há um sinal claro de que chegou a altura de as separar.

• Coloque a aplicação e a base de dados em computadores diferentes. O sinal: na carga de pico, a utilização do CPU e da memória mantém-se acima de 70–80 por cento, os pedidos ficam mais lentos e a aplicação e a base de dados disputam os mesmos recursos. Depois de as separar, pode reforçar a base de dados sem mexer na aplicação, e vice-versa.
• Siga a regra de cópias de segurança 3-2-1. Três cópias dos dados, em dois tipos de suporte diferentes, com uma fora do local. Isto protege contra falhas de hardware e ransomware. O essencial é que as cópias de segurança sejam automáticas.

A frequência das cópias de segurança depende do custo de perder dados de várias horas. Num serviço de subscrição online em que perder uma hora de registos de pagamento seja inaceitável, o intervalo entre cópias tem de ser inferior a uma hora, ou precisa de registos de transações verificados e recuperação num ponto no tempo (PITR). Escolha o intervalo pela perda máxima tolerável e teste separadamente o tempo necessário para repor o serviço. Para um blogue, basta uma por dia. A lógica é simples: decida quanto dados pode perder e configure as cópias de segurança em conformidade.

Ajuda-me a decidir se está na altura de transferir o meu produto para uma infraestrutura mais robusta. Verifica e pergunta-me sobre cada ponto:

Qual é a utilização do CPU e da memória nos períodos de pico — mantém-se acima de 70–80 por cento ou não?

A base de dados e a aplicação estão no mesmo computador ou em computadores diferentes?

Está configurada uma cópia de segurança automática da base de dados e testei o restauro a partir dela?

Existe uma cópia separada do ambiente (staging) para fazer verificações antes do deploy?
Com base nos resultados, dá-me uma recomendação clara: o que deixar como está, o que separar primeiro e porquê.

Há ainda uma questão: base de dados gerida ou própria. Para uma equipa pequena, a gerida é quase sempre melhor: a própria custa menos em hardware, mas consome horas de manutenção. Se está por sua conta e o seu produto não é infraestrutura, essas horas custam mais do que a diferença no preço do servidor.

Como pôr a manutenção em piloto automático?#

A manutenção manual é extenuante. Pode tirá-la das suas mãos de duas formas: monitorização e um agente de ronda.

A monitorização utiliza duas ferramentas diferentes para duas tarefas diferentes:

1. «O site está operacional?» — um monitor de disponibilidade (por exemplo, UptimeRobot). Verifica o produto de poucos em poucos minutos e envia um alerta se ficar indisponível. Tem um plano gratuito.
2. «O que se estragou exatamente?» — um monitor de erros (por exemplo, Sentry). Recolhe erros dentro da aplicação e mostra onde e por que motivo algo falhou.

O primeiro deteta que o produto ficou indisponível. O segundo mostra que funcionalidade falhou e porquê. Em conjunto, respondem à pergunta: «Vou saber que houve uma falha antes de um cliente escrever ao suporte?»

O segundo nível do piloto automático é um agente de ronda. Imagine uma agência imobiliária: às sete da manhã, um agente de IA lê os pedidos enviados pelo site, percebe que o formulário de reserva está avariado, encontra a causa no código e traz-lhe uma correção pronta, acompanhada de uma explicação. Revê-a e diz «sim» — ela é implementada. A ordem importa: primeiro resolva o problema do utilizador (conceda acesso, peça desculpa) e depois investigue a causa e o dinheiro.

Mais uma regra sobre o acesso da IA à base de dados de produção: dê-lhe um utilizador apenas de leitura e oculte os dados pessoais atrás de uma camada intermédia, para que o agente veja «nome» em vez do nome verdadeiro de uma pessoa. Assim, mesmo que cometa um erro, não poderá apagar nem corromper fisicamente os dados de produção. O incidente da tabela acima, em que um agente apagou a base de dados de produção, é precisamente sobre a falta desta restrição. O guia O que fazer se a IA apagou a sua base de dados explica o que fazer se o desastre já aconteceu.

Quando é que está na altura de encerrar um produto?#

A parte mais subestimada da manutenção é saber quando deixar de a fazer. Quem cria muito tem um cemitério de projetos: criou um, experimentou mexer nele e depois abandonou-o. É normal e não é um fracasso. O fracasso é arrastar durante meses algo que ninguém usa por lamentar o tempo que investiu.

Pode usar estes limites para tomar uma decisão:

1. Duas semanas — tempo suficiente para perceber se a ideia funciona. Se os primeiros utilizadores reais voltarem, continue. O silêncio é uma resposta.
2. Três meses — o limite máximo rígido. Se o produto não tiver arrancado em três meses, encerre-o. Com a rapidez do vibe coding, passar seis meses a testar uma ideia é demasiado tempo.

É psicologicamente difícil encerrar um projeto, por isso trate-o como uma decisão, não como um sentimento. Desistir de um projeto em que investiu é como despedir um funcionário que não consegue fazer o trabalho: é desagradável, mas mantê-lo custa mais do que deixá-lo ir.

A manutenção é o trabalho feito para manter um produto vivo e útil para as pessoas. Tudo o resto — git, cópias de segurança, monitorização — é apenas uma ferramenta que o ajuda a chegar ao ponto em que o produto começa a trabalhar para si todos os dias.

Criar um produto com IA numa noite é metade do trabalho. Mantê-lo vivo e seguro à medida que cresce — isso é o que significa vibe coding para adultos.

Para o seu próximo passo — Ailoot.