Um app construído rapidamente com ajuda de IA pode funcionar muito bem em uma demo e ainda estar longe de pronto para clientes pagantes. Este checklist de prontidão para produção é para fundadores e CTOs que têm um app de vibe coding rodando na AWS, ou prestes a rodar, e querem saber o que precisa ser verdade antes que cheguem usuários e dados reais. Cada item é concreto e verificável, e cada um aponta para a documentação da AWS ou do mercado que o sustenta.

Por que apps de vibe coding precisam de um checklist

Andrej Karpathy cunhou o termo em fevereiro de 2025 para descrever um jeito de programar em que você “fully give in to the vibes” (se entrega por completo às vibes) e “forget that the code even exists” (esquece que o código sequer existe). É uma ótima forma de explorar uma ideia. Vira problema quando o resultado vai para produção sem alterações, porque as partes do software que mantêm um negócio seguro são justamente as que uma demo nunca exercita: falha, abuso, recuperação e custo.

As ferramentas de código com IA tendem a otimizar para “rodar”. Elas colocam sem cerimônia uma chave de API em um arquivo de configuração, abrem um banco de dados para a internet para resolver um erro de conexão ou pulam as verificações de autorização em um endpoint porque o prompt não as mencionou. Nada disso aparece quando você clica pelo app por conta própria. Tudo isso aparece, cedo ou tarde. A maioria dos problemas de segurança em vibe coding não são ataques exóticos; são padrões comuns que ninguém revisou.

O checklist abaixo está agrupado por área e serve como um modelo de checklist de prontidão para produção que você pode copiar para o seu gerenciador de tarefas. Você não precisa concluir todos os itens antes do lançamento, mas deve saber quais estão em aberto e por quê.

1. Segredos

Nenhum segredo no repositório, inclusive em commits antigos. Pesquise todo o histórico do Git, não só os arquivos atuais. O secret scanning do GitHub consegue sinalizar formatos de token conhecidos.
Rotacione toda chave que já foi commitada, mesmo que você a tenha apagado depois. Apagar um arquivo não o remove do histórico nem de quem clonou o repositório.
Guarde os segredos no AWS Secrets Manager ou no SSM Parameter Store e carregue-os em tempo de execução.
Nenhum segredo no código de front-end. Tudo o que vai para o navegador é público. As chamadas a APIs pagas, incluindo provedores de LLM, passam pelo seu back-end.

2. IAM e acesso à conta

Não use o usuário root no dia a dia e proteja-o com MFA. As boas práticas de segurança do IAM da AWS cobrem isso e os itens abaixo.
Privilégio mínimo para a aplicação. A role do app deve conceder apenas as ações que ele usa, nos recursos que ele usa. Uma política com "Action": "*" que uma ferramenta de IA sugeriu para contornar um erro de permissão é um achado comum.
Nenhuma chave AWS de longa duração no CI. Use OpenID Connect para que o GitHub Actions possa acessar a AWS sem guardar credenciais como segredos de longa duração.
Separe a produção de todo o resto, de preferência em uma conta AWS própria, para que um erro em um ambiente de teste não consiga tocar nos dados dos clientes.

3. Exposição de dados e segurança da aplicação

O banco de dados não é acessível publicamente. Ele deve ficar em sub-redes privadas, alcançável apenas pela aplicação.
Os buckets do S3 bloqueiam o acesso público, a menos que um bucket seja público de propósito. A AWS oferece as configurações do S3 Block Public Access no nível da conta e do bucket.
Todo endpoint verifica a autorização no servidor. O controle de acesso quebrado lidera a lista de riscos de aplicações web do OWASP Top 10. Teste diretamente: faça login como o usuário A e peça os registros do usuário B pelo ID.
As entradas são validadas e as queries ao banco são parametrizadas.
As dependências são verificadas em busca de vulnerabilidades conhecidas, com pull requests automáticos de atualização ativados.

4. Backups e recuperação

Os backups automáticos do banco estão ativos, com recuperação para um ponto no tempo e um período de retenção escolhido de propósito. Os backups automáticos do RDS permitem restaurar para qualquer ponto dentro desse período.
Você já testou uma restauração. Um backup que nunca foi restaurado é uma esperança, não um backup. Restaure para uma nova instância, confira os dados e cronometre quanto tempo levou.
A proteção contra exclusão está ativa no banco de dados de produção.
Os uploads de usuários no S3 estão protegidos com versionamento ou um plano de backup.

5. Monitoramento e alertas

O app expõe um health check que confirma que ele alcança suas dependências, e não apenas que o processo está no ar.
Existem alarmes para o que o cliente sente: taxa de erro, latência e disponibilidade, e não só CPU.
Os alarmes chegam a uma pessoa. Um alerta que cai em uma caixa de entrada que ninguém lê é o mesmo que nenhum alerta. Decida quem é acionado à noite e como.
Cada alarme tem um runbook curto: o que ele significa, como verificar e o que fazer primeiro.

6. Logs e auditoria

Os logs são estruturados (JSON com IDs de requisição) para que você consiga acompanhar uma requisição pelo sistema.
Nenhum segredo nem dado pessoal sensível nos logs. Confira o que o seu framework registra por padrão nos erros.
A retenção de logs está definida. Por padrão, o CloudWatch Logs armazena os dados de log indefinidamente, o que aumenta o custo e pode entrar em conflito com compromissos de privacidade.
O AWS CloudTrail está ativo para que você veja quem mudou o quê na conta.

7. CI/CD

Todo deploy em produção passa por um pipeline, nunca a partir de um notebook e nunca editando recursos no console.
O pipeline executa testes e reprova o deploy quando eles falham. Mesmo uma suíte pequena nos caminhos críticos (cadastro, login, pagamento) pega muitas regressões introduzidas pela IA.
A infraestrutura é definida em código (Terraform, CloudFormation ou CDK) para que os ambientes possam ser recriados e revisados.
As mudanças são revisadas por uma pessoa antes de chegarem à produção, inclusive as geradas por IA.

8. Rollback

Você consegue voltar à versão anterior em minutos. Mantenha as imagens de contêiner anteriores com tag e saiba o comando ou o botão.
Rollback automático em deploys que falham, onde a sua plataforma oferecer. No ECS, o deployment circuit breaker pode reverter um deploy com falha para o último concluído.
As migrações de banco são retrocompatíveis, de modo que o código antigo continue funcionando com o novo schema enquanto você faz o rollback.

9. Rate limiting e abuso

Os endpoints públicos têm rate limit. As regras baseadas em taxa do AWS WAF contam requisições e limitam as origens que as enviam rápido demais.
Login, cadastro e redefinição de senha têm limites mais rígidos para frear credential stuffing e a criação de contas falsas.
Os endpoints caros têm teto por usuário, principalmente os que chamam uma API de LLM, enviam e-mail ou SMS, ou disparam jobs pesados em segundo plano. São os endpoints em que o abuso se converte direto na sua conta.

10. Alarmes de custo

Um AWS Budget com alertas definido em um nível que o surpreenderia. O AWS Budgets pode enviar um e-mail ou uma notificação quando o gasto real ou previsto passa de um limite.
O Cost Anomaly Detection está ativo, para que um gasto fora do normal em um serviço seja sinalizado mesmo que o total ainda esteja dentro do orçamento.
Os limites de gasto de APIs de terceiros estão definidos, especialmente com provedores de LLM, em que um loop ou um usuário abusivo pode gerar cobranças rapidamente.
Os recursos têm tags por ambiente, para que você veja quanto custa a produção em comparação com todo o resto.

A versão curta

Se você só tem um dia, comece por estes: rotacione os segredos que foram commitados, feche o acesso público ao banco e aos buckets, verifique a autorização em cada endpoint, ative e teste os backups do banco, defina um alerta de orçamento e garanta que pelo menos um alarme de erros chegue a uma pessoa. Esses seis cobrem as falhas mais difíceis de reverter: dados vazados, dados perdidos e uma conta fora de controle.

Depois, trabalhe o restante como parte da sua sprint normal. A prontidão para produção não é uma barreira única. Novas funcionalidades trazem novos endpoints, novos segredos e novos custos, então vale repetir o checklist toda vez que o app mudar de forma.

Do checklist à revisão de prontidão para produção

Organizações de engenharia maiores transformam esse tipo de lista em uma etapa formal. No Google, os times de SRE fazem um Production Readiness Review, descrito como “a process that identifies the reliability needs of a service based on its specific details” (um processo que identifica as necessidades de confiabilidade de um serviço com base em suas particularidades), antes de assumir a responsabilidade por um serviço em produção. Um time pequeno não precisa da cerimônia, mas o hábito se transfere bem: antes de um lançamento importante, percorra o checklist com quem vai carregar o pager e combinem quais itens em aberto são aceitáveis.

Perguntas frequentes

O que é um checklist de prontidão para produção?

Um checklist de prontidão para produção é uma lista de condições concretas e verificáveis que uma aplicação deve cumprir antes de atender usuários e dados reais. Para um app na AWS, isso costuma abranger segredos, IAM, exposição de dados, backups, monitoramento, logs, CI/CD, rollback, rate limiting e alarmes de custo. O valor dele está em que cada item em aberto é conhecido e tem um motivo, em vez de ser descoberto durante um incidente.

O que é prontidão para produção?

Prontidão para produção significa que uma aplicação consegue lidar com as condições que uma demo nunca exercita: falhas, abuso, recuperação e custo. Um app pronto para produção mantém os segredos fora do código, pode ser restaurado a partir de um backup testado, avisa uma pessoa quando os usuários são afetados, faz deploy e rollback por um pipeline e não vai gerar uma conta sem limite. Não é uma barreira única, porque cada nova funcionalidade muda o cenário.

O que é uma revisão de prontidão para produção?

Uma revisão de prontidão para produção é um percurso estruturado por um serviço antes do lançamento, em que o time que vai operá-lo confere as necessidades de confiabilidade dele contra uma lista como a acima. Os times de SRE do Google usam uma como pré-requisito antes de assumir um serviço. Para uma startup, uma revisão de uma hora com o checklist e a pessoa de plantão já traz a maior parte do benefício.

Ajuda com prontidão para produção

Se você quer que o próprio app seja construído e mantido por um time, é isso que a nossa marca irmã Avanti Studio faz.

Se o app já existe e o que você precisa é do lado AWS deste checklist feito e mantido, é isso que a Webera faz. A Webera é uma assinatura de DevOps para times de SaaS na AWS: engenheiros seniores trabalhando ao lado de nove agentes de IA, incluindo o Guardian para segurança, o Sentinel para observabilidade, o Conductor para CI/CD, o Optimizer para FinOps e o Forge para prontidão de aplicações. Os agentes fazem o monitoramento, o direcionamento e a primeira análise o dia todo e a noite toda; os engenheiros tomam as decisões e entregam as correções.

O Pro custa US$ 4.999 por mês, com solicitações ilimitadas (duas em andamento por vez), monitoramento 24/7 e resposta a incidentes, e prazo de entrega médio de 36 horas. O Elite (US$ 9.999) e o Platform (US$ 14.999) acrescentam um engenheiro designado, suporte a compliance e um time dentro das suas sprints. Todos os planos têm mínimo de três meses e depois seguem mês a mês, e todo o código é seu. Não sabe em que ponto está? Avalie seu time primeiro ou compare os planos na nossa página de preços.

Checklist de prontidão para produção de um app de vibe coding na AWS