Vibe coding: usos e limites

Dê às pessoas espaço para criar

Um CTO pode ajudar mais pessoas da organização a transformar seu conhecimento em ideias de software. Convide pessoas das áreas financeira, de operações, vendas e engenharia. Ofereça tempo, dados sintéticos, APIs de sandbox e apoio.

Permita o uso de ferramentas diferentes para explorar ideias, com limites claros para instalações, contas e dados de entrada permitidos. Um construtor no navegador, um assistente de programação ou um agente local pode ajudar a testar uma ideia. A escolha da ferramenta não autoriza o envio de informações da empresa nem a conexão com um sistema real.

Divulgue um caminho simples para levar um protótipo útil à equipe de engenharia ou de plataforma. Quem criou o protótipo contribui com o problema, um exemplo do fluxo de trabalho e o valor observado. Essa pessoa não precisa assumir a segurança e a operação do serviço.

Identifique o que precisa aprender

Vibe coding costuma começar com uma descrição do software desejado. Você aceita o código gerado e usa o resultado visível para orientar a próxima alteração. O termo tem significados diferentes. Neste guia, quem orienta o trabalho não necessariamente entende cada decisão de implementação.

Esse método pode ajudar no aprendizado. Uma interface simples pode mostrar que um processo de aprovação tem etapas demais. Um script temporário pode ajudar a avaliar um formato de arquivo. Um protótipo dá às pessoas uma proposta concreta para discutir. Você pode preservar esse conhecimento mesmo ao descartar o código.

Primeiro, defina uma pergunta cuja resposta possa ser observada. Por exemplo: “Um gerente de equipe consegue entender este processo de aprovação?” Essa pergunta tem um escopo claro. Já um pedido para criar um sistema de despesas também envolve proteção de dados, controle de acesso, operação e definição de responsáveis.

O protótipo bancário de terça-feira

Considere um exemplo fictício. Na terça-feira, uma pessoa da área financeira usa o Lovable para criar um dashboard com transações bancárias inventadas. Ele agrupa despesas e mostra faturas não pagas. A equipe agora pode discutir um fluxo de trabalho útil.

Alguém sugere conectar a conta bancária da empresa. Isso muda as consequências, mesmo que a aplicação continue com o rótulo de “protótipo”.

O acesso de leitura pode revelar saldos, histórico de transações, nomes de clientes ou referências de pagamento, dependendo da API. Se a conexão também permitir pagamentos, erros podem movimentar dinheiro real. Confirme o escopo efetivo das permissões; uma conexão bancária nem sempre inclui acesso para pagamentos.

A demonstração não comprova que um usuário só consegue ver as contas que está autorizado a acessar. Ocultar um botão não faz cumprir uma permissão. A OWASP descreve como a ausência de verificações de contas ou registros pode expor os dados de outro usuário.

Em APIs de pagamento, idempotência significa que repetir uma requisição não repete o efeito pretendido. A Stripe documenta uma implementação. Verifique o comportamento, os limites e as regras de novas tentativas do provedor utilizado. Um rollback da aplicação não desfaz um pagamento já processado pelo banco.

Este exemplo não é evidência de uma falha do Lovable. As próprias orientações de segurança do Lovable exigem proteção de segredos, verificações no servidor, políticas de dados testadas e revisão contínua. Aplique o mesmo padrão de evidência a qualquer construtor, agente ou aplicação escrita manualmente.

Verifique o acesso antes de conectar sistemas reais

Continue testando o fluxo de trabalho com dados sintéticos e contas de sandbox. Antes do acesso a sistemas reais, peça aos responsáveis pelo serviço, pela segurança e pela plataforma que verifiquem a aplicação e seu ambiente de operação.

Use o fluxo de conexão aprovado pelo banco ou provedor. Conceda acesso apenas às contas e permissões necessárias. Mantenha credenciais privadas em um repositório de segredos aprovado, fora de prompts e do código do navegador. Defina aprovações e limites de pagamento quando pagamentos forem necessários. Verifique como revogar o acesso, investigar falhas e responder a atividades suspeitas.

Essas decisões devem ocorrer antes de informações confidenciais ou credenciais de sistemas reais entrarem no sistema. Esperar pelo release formal em produção pode ser tarde demais. Continue com limites de dados e infraestrutura corporativa.

Defina responsabilidades antes de ampliar o uso

Um experimento com dados inventados pode ter vida curta e poucos usuários. Quando outras pessoas passam a depender da aplicação, defina as responsabilidades pelo seu uso.

1. Defina o responsável.
2. Identifique os usuários e dados permitidos.
3. Defina a resposta a uma falha.
4. Mantenha o código-fonte e a configuração em um repositório.
5. Verifique se outra pessoa consegue inspecionar e reproduzir o sistema.

Nem todo script precisa de uma plataforma corporativa. Um formatador pessoal sem dados sensíveis precisa de menos controles que uma aplicação de aprovação de pagamentos. Avalie as consequências de um erro. Verifique se é possível detectá-lo e reverter seus efeitos.

Antes de ampliar o protótipo, separe o que aprendeu sobre o problema das evidências sobre a implementação. Você pode manter a interface e substituir o código interno. Pode restringir o uso pretendido. Também pode manter o protótipo como um experimento temporário.

Planeje o tratamento de vulnerabilidades após a demonstração

Uma demonstração bem-sucedida pode ocultar uma lacuna grave de manutenção. Uma dependência pode receber um novo alerta de vulnerabilidade sem nenhuma alteração no seu código. Um escaneamento feito no release descreve apenas aquele momento.

Se a aplicação continuar em uso, alguém deve continuar identificando, avaliando e corrigindo vulnerabilidades. A correção precisa chegar à produção e passar por verificação. Um scanner sem esse processo de resposta deixa a exposição sem solução.

Verifique o que a ferramenta e a configuração efetivamente oferecem. Mais adiante, a lição sobre gestão contínua de vulnerabilidades explica o processo completo, incluindo falhas de escaneamento e versões implantadas.

Facilite a revisão da próxima alteração

Dê ao agente uma alteração pequena com critérios de aceitação explícitos. Informe quais ações ele pode executar. Inspecione o diff resultante. Faça verificações capazes de rejeitar uma implementação incorreta. Mantenha o deployment como uma decisão separada até que as responsabilidades pelo release estejam claras.

O NIST Secure Software Development Framework descreve práticas mais amplas de desenvolvimento seguro. Use-o como referência ao avaliar os controles que faltam. Não é necessário memorizar o framework. É necessário identificar as evidências que faltam antes que o software afete outras pessoas.