Como Levar um Protótipo de IA para Produção

Para levar um protótipo de IA para produção, fecha-se a distância entre «funciona quando o experimento» e «continua a funcionar quando outras pessoas o usam». Na prática, são cinco coisas: testar os fluxos principais sempre que altera algo, bloquear quem pode ver e alterar o quê, garantir que ouve falar dos erros antes de os seus utilizadores lhe dizerem, fazer cópias de segurança dos dados e provar que consegue restaurá-los, e manter a app suficientemente rápida num telemóvel. Nada disto exige reescrever tudo — é uma lista de verificação que percorre com a mesma IA que criou o protótipo.

Protótipo vs produção: o que muda na prática

Um protótipo tem um único utilizador cuidadoso: você. Sabe em que botões carregar, escreve entradas sensatas e, se algo falhar, encolhe os ombros e pede à IA para corrigir. A produção tem muitos utilizadores descuidados, alguns curiosos e, ocasionalmente, um hostil. O código não precisa de se tornar «empresarial»; precisa de lidar com as situações que um protótipo nunca encontra.

O resto deste guia percorre cada linha.

Passo 1: Fixe o âmbito e escreva os fluxos principais

Antes de reforçar seja o que for, decida o que é a versão um. Liste de três a seis fluxos que mais importam — por exemplo, «registar-se, criar um projeto, convidar um colega, pagar». Estes passam a ser o seu guião de testes, os alvos da monitorização e aquilo que verifica após cada alteração.

Tudo o que não estiver na lista ou é cortado ou fica claramente identificado como beta. É muito mais fácil tornar quatro fluxos fiáveis do que catorze.

Passo 2: Teste como um estranho e depois torne o teste repetível

Os criadores com IA são bons a produzir código que funciona no caminho feliz. Os problemas de produção vivem nos caminhos infelizes. Teste cada fluxo principal com:

• Entradas erradas: campos obrigatórios vazios, um nome com 5000 caracteres, um email sem @, uma quantidade negativa, uma data no passado.
• Atualizações e botões de voltar: recarregue a meio do checkout; carregue em voltar depois de enviar um formulário. Algo fica criado duas vezes?
• Dois separadores, dois utilizadores: inicie sessão com duas contas diferentes e tente abrir as páginas uma da outra alterando o ID no URL.
• Lento e pequeno: um ecrã do tamanho de um telemóvel e uma ligação limitada (as ferramentas de programador do navegador conseguem simular isto).
• Estados vazios: uma conta nova sem dados. Os protótipos costumam ser criados com dados de exemplo e parecem avariados sem eles.

Depois, torne a verificação repetível. No mínimo, mantenha uma lista escrita e execute-a antes de cada versão. Melhor ainda, peça à IA que escreva testes automáticos para os fluxos mais importantes:

Adiciona testes automáticos de ponta a ponta para estes fluxos: registo com email, criação de um projeto, convite de um segundo utilizador e conclusão do checkout no modo de teste da Stripe. Adiciona também testes que confirmem que um utilizador não consegue ver nem editar o projeto de outro alterando o URL.

Os testes que provam que um utilizador não consegue fazer algo são os que os protótipos mais costumam não ter.

Passo 3: Noções básicas de segurança que os protótipos ignoram

A maioria dos problemas de segurança em apps criadas com IA não são exóticos. São verificações em falta. Percorra esta lista e veja a lista de verificação de segurança para apps criadas com IA, mais completa:

• Autorização no servidor. Esconder um botão não é segurança. Cada pedido que lê ou altera dados tem de verificar, no servidor, que o utilizador com sessão iniciada tem permissão para isso. Se a sua app usa uma base de dados com regras por linha, confirme que estão ativas e testadas.
• Segredos fora do navegador. As chaves de API para pagamentos, email ou fornecedores de IA pertencem a variáveis de ambiente no servidor, nunca ao código do front-end. Se não tiver a certeza do que isto significa, leia o que são variáveis de ambiente e segredos.
• Validação no servidor. O navegador pode ser contornado, por isso repita no servidor qualquer verificação importante.
• Início de sessão feito corretamente. Use uma biblioteca ou serviço de autenticação bem testado, em vez de armazenamento de palavras-passe feito à mão. O nosso guia sobre como adicionar início de sessão à sua app cobre as opções.
• Limites de pedidos no início de sessão, registo, recuperação de palavra-passe e em tudo o que envie emails ou chame uma API paga.
• Erros amigáveis. Os utilizadores devem ver «algo correu mal»; os detalhes vão para os seus registos, não para o ecrã.
• Rode qualquer segredo que tenha sido divulgado. Se uma chave real foi alguma vez colada num chat, num commit ou numa captura de ecrã, substitua-a no fornecedor.

Um prompt que cobre muito terreno de uma só vez:

Revê esta app para segurança em produção. Verifica se cada rota da API confirma que o utilizador com sessão iniciada é dono do registo que lê ou altera, se nenhuma chave secreta é enviada para o navegador, se as entradas são validadas no servidor e se o início de sessão e a recuperação de palavra-passe têm limites de pedidos. Lista o que encontrares antes de alterar o que quer que seja.

Pedir primeiro uma lista permite-lhe ver os problemas e decidir a ordem, em vez de receber uma alteração gigante.

Passo 4: Saber quando algo falha — registos e monitorização

Na pré-visualização vê os erros à medida que acontecem. Em produção, precisa de que a app lhe avise. Três camadas, da mais barata à mais útil:

1. Registos do servidor. Garanta que os erros ficam registados com contexto suficiente para os reproduzir: que rota, que ID de utilizador (nunca a palavra-passe ou o cartão), que forma tinha a entrada. Peça à IA registos estruturados se a app apenas escreve na consola.
2. Rastreio de erros. Um serviço como o Sentry ou uma ferramenta semelhante capta exceções do front-end e do back-end, agrupa-as e envia-lhe emails. Para uma app pequena, os planos gratuitos destes serviços costumam chegar; verifique os limites atuais nos respetivos sites.
3. Verificações de disponibilidade. Um serviço externo que carrega a sua página inicial e uma rota de API importante a cada poucos minutos e lhe envia um alerta se falharem. Isto apanha os problemas que impedem a app de registar fosse o que fosse.

Adicione mais um hábito: após cada versão, abra a app em produção e execute a sua lista dos fluxos principais no URL real, e não apenas na pré-visualização.

Passo 5: Cópias de segurança e uma forma de voltar atrás

Há duas coisas diferentes a proteger, e são fáceis de confundir.

• Código. Mantenha o projeto em controlo de versões para que qualquer alteração possa ser desfeita. Muitos criadores com IA guardam pontos de restauro dos seus ficheiros; sincronizar com um repositório Git dá-lhe uma cópia fora do criador também.
• Dados. Reverter o código não reverte a base de dados. Uma migração má ou um botão de eliminar com erros pode destruir linhas que nenhum ponto de restauro do código recupera.

Para os dados, configure cópias de segurança regulares guardadas noutro local que não o alojamento da própria app — para uma base de dados Postgres, a abordagem comum é um pg_dump agendado para um armazenamento separado, e muitos fornecedores de bases de dados geridas oferecem cópias automáticas ou recuperação para um ponto no tempo. Depois, faça o passo que a maioria das pessoas ignora: restaure uma cópia de segurança para uma base de dados de teste e verifique que os dados lá estão.

Peça também à IA que torne as ações destrutivas mais seguras: um passo de confirmação para eliminações e «eliminação suave» (marcar linhas como eliminadas em vez de as remover) para tudo o que os utilizadores possam querer recuperar.

Passo 6: Desempenho que se mantém num telemóvel

Os protótipos parecem rápidos porque você é o único utilizador e o conjunto de dados é minúsculo. Antes do lançamento:

• Carregue dados de tamanho real. Peça à IA para inserir alguns milhares de linhas e veja que páginas abrandam. As listas costumam precisar de paginação e a base de dados costuma precisar de índices nas colunas que filtra e ordena.
• Reduza as imagens. Imagens sobredimensionadas são a razão mais comum para uma página carregar devagar. Peça imagens redimensionadas e comprimidas e carregamento preguiçoso abaixo da dobra.
• Meça. Execute o Lighthouse nas ferramentas de programador do Chrome, no URL real, em modo telemóvel. As Core Web Vitals do Google são um objetivo sensato: Largest Contentful Paint em até 2,5 segundos, Interaction to Next Paint de 200 ms ou menos, e Cumulative Layout Shift de 0,1 ou menos.
• Atenção aos atrasos de «despertar». Um alojamento que adormece quando está inativo poupa dinheiro, mas torna a primeira visita após um período sem uso mais lenta. Costuma ser uma troca aceitável para uma app nova; saiba que isso acontece.

A página de projetos está lenta com 5000 linhas. Adiciona paginação no servidor (25 por página), adiciona índices na base de dados para as colunas que filtramos e ordenamos, e mostra um estado de carregamento enquanto a página seguinte carrega.

Passo 7: Noções básicas de operação

Alguns pequenos detalhes separam uma app de passatempo de uma em que as pessoas confiam:

• Um domínio personalizado com HTTPS. Veja como ligar um domínio personalizado.
• Email transacional a partir de um domínio verificado para confirmações de registo e recuperação de palavras-passe — explicado em como enviar emails a partir da sua app.
• Política de privacidade e termos que descrevam o que recolhe de facto. Não copie declarações de conformidade que não conquistou.
• Um canal de apoio — mesmo que seja um endereço de email monitorizado.
• Chaves de teste e chaves reais separadas para pagamentos e email, e uma nota clara de qual ambiente usa qual.

Passo 8: Uma passagem limpa

Mais cedo ou mais tarde, outra pessoa vai trabalhar na app: um freelancer, um novo cofundador, ou você daqui a seis meses. Facilite isso:

• Um README que diga como a executar, que variáveis de ambiente precisa (apenas os nomes, nunca os valores) e como a publicar.
• A lista dos fluxos principais e os testes automáticos.
• Uma nota curta de arquitetura: front-end, back-end, base de dados, serviços de terceiros e onde está alojado cada um.
• Lista de acessos: quem tem acesso de administrador ao domínio, ao alojamento, à base de dados, às contas de pagamento e de email. Coloque estas contas sob um email profissional, e não pessoal.
• O código no Git, de preferência sincronizado com um repositório que lhe pertença. Se puder mudar de alojamento mais tarde, leia como exportar e alojar por conta própria uma app criada com IA.

A IA pode redigir grande parte disto por si:

Escreve um README para este projeto para um programador que nunca o viu: o que a app faz, a stack tecnológica, como a executar localmente, todas as variáveis de ambiente que lê (apenas nomes e finalidade), como o esquema da base de dados está organizado e como a publicar.

Lista de verificação de prontidão para produção

• Fluxos principais escritos e testados, incluindo «não consegue aceder aos dados de outra pessoa»
• Autorização e validação no servidor em cada rota de dados
• Nenhuma chave secreta no código do front-end; chaves divulgadas rodadas
• Limites de pedidos no acesso e em tudo o que custa dinheiro
• Rastreio de erros e alertas de disponibilidade a apontar para uma caixa de entrada que lê
• Cópias de segurança da base de dados fora do alojamento da app, com uma restauração de teste bem-sucedida
• Paginação e índices verificados com dados realistas
• Domínio personalizado, domínio de envio verificado, política de privacidade
• README e lista de acessos para quem vier a seguir

Fazer isto com a Mythex

Se criou o protótipo na Mythex, a maioria destes passos são prompts no mesmo projeto. Escreva /test e a Mythex percorre a pré-visualização em tempo real como um utilizador e comunica os fluxos que falham — veja Testes de app. As chaves vão para os segredos do projeto e não para o chat; cada turno bem-sucedido do agente guarda um ponto de restauro dos seus ficheiros para o qual pode voltar; e publicar dá-lhe um URL em produção, com alojamento e base de dados cobrados a partir do mesmo saldo de créditos (limites de alojamento explica como as apps e as bases de dados adormecem e acordam). Os pontos de restauro cobrem ficheiros, não linhas da base de dados, por isso planeie as cópias de segurança dos dados. No plano Pro pode ligar um domínio personalizado e exportar o código ou sincronizá-lo com o seu próprio repositório GitHub para uma passagem.

Perguntas