Vibe coding: utilizações e limites

Dê às pessoas espaço para construir

O CTO de uma empresa pode ajudar mais pessoas a transformar os seus conhecimentos em ideias de software. Convide pessoas das áreas financeira, de operações, vendas e engenharia. Dê-lhes tempo, dados sintéticos, APIs de sandbox e apoio.

Deixe as pessoas explorar ideias com diferentes ferramentas, dentro de regras claras para a instalação, as contas e os dados permitidos. Um construtor no browser, um assistente de programação ou um agente local pode ajudar a testar uma ideia. Escolher a ferramenta não autoriza o envio de informação da empresa nem a ligação a um sistema real.

Divulgue um procedimento simples para apresentar um protótipo útil à equipa de engenharia ou de plataforma. O autor contribui com o problema, um exemplo do processo de trabalho e o valor observado. Não tem de se tornar a equipa de segurança e operações do serviço.

Identifique o que precisa de aprender

O vibe coding começa habitualmente com uma descrição do software pretendido. Aceita-se o código gerado e usa-se o resultado visível para orientar a alteração seguinte. O termo tem vários significados. Neste guia, quem orienta o trabalho não compreende necessariamente cada decisão de implementação.

Este método pode ajudar a aprender. Uma interface simples pode revelar que um processo de aprovação tem demasiados passos. Um script temporário pode ajudar a avaliar um formato de ficheiro. Um protótipo oferece uma proposta concreta para discussão. Pode guardar esse conhecimento mesmo que descarte o código.

Comece por definir uma pergunta com uma resposta observável. Por exemplo: «O responsável de uma equipa consegue compreender este processo de aprovação?» A pergunta tem um âmbito claro. Pedir um sistema de despesas envolve também proteção de dados, controlo de acesso, operação e responsabilidade pelo serviço.

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

Considere um exemplo fictício. Numa terça-feira, um colega da área financeira usa o Lovable para criar um painel com transações bancárias inventadas. O painel agrupa despesas e mostra faturas por pagar. A equipa pode agora discutir um processo de trabalho útil.

Alguém sugere ligar a conta bancária da empresa. Isso altera as consequências, mesmo que a aplicação continue a ter o rótulo de «protótipo».

Consoante a API, o acesso de leitura pode revelar saldos, histórico de transações, nomes de clientes ou referências de pagamento. Se a ligação também permitir pagamentos, os erros podem movimentar dinheiro real. Confirme o âmbito efetivo das permissões: uma ligação ao banco nem sempre inclui acesso a pagamentos.

A demonstração não prova que cada utilizador só vê as contas a que está autorizado a aceder. Ocultar um botão não impõe uma permissão. A OWASP explica como a falta de verificações de contas ou registos pode expor os dados de outro utilizador.

Nas APIs de pagamento, idempotência significa que repetir um pedido não repete o efeito pretendido. A Stripe documenta uma implementação. Verifique o comportamento, os limites e as regras de repetição do fornecedor em causa. Um rollback da aplicação não reverte um pagamento já processado pelo banco.

Este exemplo não demonstra um defeito do Lovable. As orientações de segurança do próprio Lovable exigem segredos protegidos, verificações no servidor, políticas de dados testadas e revisão contínua. Aplique o mesmo padrão de prova a qualquer construtor, agente ou aplicação escrita manualmente.

Verifique o acesso antes de ligar sistemas reais

Continue a testar o processo com dados sintéticos e contas de sandbox. Antes de conceder acesso real, peça aos responsáveis pelo serviço, pela segurança e pela plataforma que verifiquem a aplicação e o ambiente onde funciona.

Use o processo de ligação aprovado pelo banco ou pelo fornecedor. Conceda apenas o acesso às contas e as permissões necessários. Guarde as credenciais privadas num armazenamento de segredos aprovado, fora dos prompts e do código do browser. Quando forem necessários pagamentos, defina as aprovações e os limites. Verifique como revogar o acesso, investigar falhas e responder a atividade suspeita.

Estas decisões têm de preceder a entrada de informação confidencial ou credenciais reais no sistema. Esperar pelo lançamento formal em produção pode ser demasiado tarde. Continue com limites dos dados e infraestrutura empresarial.

Defina responsabilidades antes de alargar a utilização

Uma experiência com dados inventados pode ter uma duração curta e poucos utilizadores. Quando outras pessoas dependem da aplicação, defina as responsabilidades pela sua utilização.

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

Nem todos os scripts precisam de uma plataforma empresarial. Um formatador pessoal sem dados sensíveis exige menos controlos do que uma aplicação de aprovação de pagamentos. Avalie as consequências de um erro. Verifique se consegue detetá-lo e reverter os seus efeitos.

Antes de alargar o protótipo, separe o que aprendeu sobre o problema das provas relativas à implementação. Pode manter a interface e substituir o código interno. Pode restringir a utilização prevista. Também pode conservar o protótipo como uma experiência temporária.

Prepare a gestão de vulnerabilidades após a demonstração

Uma demonstração bem-sucedida pode esconder uma falha grave de manutenção. Pode surgir um novo aviso de vulnerabilidade numa dependência sem qualquer alteração ao seu código. Uma análise feita no lançamento descreve apenas esse momento.

Se a aplicação continuar a ser usada, alguém tem de continuar a encontrar, avaliar e corrigir vulnerabilidades. A correção tem de chegar à produção e ser verificada. Um scanner sem este processo de resposta deixa a exposição por resolver.

Verifique o que a ferramenta e a configuração realmente oferecem. Mais adiante, a lição sobre gestão contínua de vulnerabilidades explica o processo completo, incluindo falhas de análise e versões instaladas.

Facilite a revisão da alteração seguinte

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

O NIST Secure Software Development Framework descreve práticas mais amplas de desenvolvimento seguro. Use-o como referência para avaliar os controlos em falta. Não precisa de memorizar o framework. Precisa de identificar as provas em falta antes de o software afetar outras pessoas.