Quando a pessoa que criou um app com vibe coding deixa a empresa, o que se perde não é só o acesso: é o contexto de por que o app existe, o que ele faz e do que ele depende. Em apps tradicionais, esse contexto vive em código revisado, tickets e documentação. Em apps vibe coded criados por áreas de negócio, ele muitas vezes vive só na cabeça de quem conversou com a IA. Este guia trata de continuidade de apps vibe coded: como medir o risco, o que montar antes do desligamento, como fazer a transferência e o que fazer com os apps que já ficaram órfãos.
O problema: um app, uma pessoa, nenhuma cópia do conhecimento
Na engenharia de software, o risco chama-se bus factor: o número mínimo de integrantes de uma equipe cuja saída repentina paralisaria o projeto. A Wikipedia registra que um bus factor igual a um é um ponto único de falha, e lista três mitigadores clássicos: simplificar o sistema, documentar processos e manter a documentação atualizada, e promover treinamento cruzado.
O vibe coding leva muitos apps a nascer com bus factor igual a um, por três razões:
- Quem criou raramente é desenvolvedor. A ideia é justamente permitir que áreas de negócio criem. Mas, como escreveu Tom Barnett, do escritório Jackson Lewis, na Fast Company Brasil (01/05/2026), diferentemente do código tradicional, pode não haver ninguém na equipe que compreenda plenamente como o software foi construído.
- A "documentação" é uma conversa. O raciocínio do app está no histórico de prompts e nas decisões tomadas ao longo de iterações, não em um README.
- O app cresce sem anúncio. Um painel pessoal vira ferramenta da equipe sem que ninguém reclassifique, como detalhado em governança de portfólio de vibe coding.
A DIO descreve o cenário como um tipo de shadow IT alimentado por IA: dashboards, automações e scripts internos criados sem documentação, versionamento ou validação institucional. Quando o criador sai, o app que era "só uma ferramenta" passa a ser uma dependência operacional sem dono.
O que exatamente se perde quando o criador sai
Antes de resolver, vale listar o que está em jogo. Em um app vibe coded típico, o conhecimento que só o criador tem se divide em seis camadas:
| Camada | Pergunta que ninguém mais sabe responder | Consequência se ficar sem resposta |
|---|---|---|
| Intenção | Para que o app foi feito e para quem? | Ninguém sabe se ainda é necessário |
| Acesso | Quem é o dono da conta onde ele roda? | App preso a uma conta pessoal, que é desativada no desligamento |
| Segredos | Quais chaves de API e senhas ele usa, e quem as emitiu? | Chaves órfãs, sem rotação; integração quebra sem aviso |
| Dados | De onde vêm e para onde vão os dados? | Risco de LGPD e de decisão com dado errado |
| Dependências | O que quebra se o app parar, e o que quebra o app? | Falha em cadeia numa planilha, CRM ou rotina que depende dele |
| Manutenção | Como se corrige um bug ou se muda uma regra? | Cada ajuste vira tentativa e erro, o que alimenta a dívida técnica |
Repare que quatro das seis camadas (acesso, segredos, dados e dependências) são também questões de segurança. Um app abandonado com credenciais ativas e dados pessoais é a mesma superfície de risco descrita em apps vibe coded expostos.
O kit de transferência: o que deve existir antes do desligamento
A melhor continuidade é a que já está pronta quando a saída acontece. Para todo app vibe coded usado por mais de uma pessoa, o kit de transferência tem sete itens:
- Ficha de uma página: finalidade, usuários, frequência de uso, nível de criticidade e o dado que o app toca.
- Dono e substituto nomeados, com o substituto tendo acesso de fato (não apenas "sabe que existe").
- Código em repositório versionado da empresa, e não só dentro da ferramenta. Isso permite histórico, revisão e recuperação.
- Lista de segredos e integrações: o que cada chave faz, quem a emitiu e como rotacioná-la.
- Mapa de dependências: o que alimenta o app e o que consome a saída dele.
- Roteiro de operação: como rodar, como publicar, como reverter, como saber que quebrou.
- Registro de decisões: as regras de negócio embutidas no app (por que este filtro, por que esta exceção), porque são o que o código sozinho não explica.
Um atalho útil: peça ao próprio agente de IA para gerar o rascunho do README, do mapa de dependências e do roteiro de operação a partir do código, e peça ao criador para revisar e corrigir o resultado. A IA descreve o que o código faz; só a pessoa sabe se é o que ele deveria fazer. A revisão por quem entende de código segue as práticas de code review de código gerado por IA, e os testes mínimos que dão segurança a quem herda o app estão em testes e QA de apps vibe coded.
Transferindo a propriedade: o exemplo do Replit
A transferência do conhecimento só funciona se a propriedade do app também mudar de mãos. Em plataformas como o Replit, um app criado em um workspace pessoal pertence à conta de quem o criou. Segundo a documentação do Replit, a transferência de um app do workspace pessoal para o workspace de uma equipe (Team) é imediata, irreversível e mantém as configurações de deploy e as URLs. Para transferir, a pessoa precisa ser membro da equipe de destino; para muitos apps, a documentação aponta para comandos de CLI. Há ainda a possibilidade de membros de uma organização transferirem apps para outros membros.
Dois cuidados práticos:
- Faça a transferência antes do último dia. Depois do desligamento, a conta pessoal pode ser desativada e o app fica inacessível. Como a ação é irreversível, confirme o destino correto antes de executá-la.
- Combine com o controle de identidade. No Replit Enterprise, o provisionamento automático via SCIM revoga o acesso de quem sai da empresa, como explicado em Replit Enterprise: governança nativa para vibe coding. Isso protege contra acesso indevido, mas também significa que o app precisa ter sido movido antes da revogação. A divisão entre o que a plataforma cobre e o que é da empresa está em responsabilidade compartilhada no Replit.
Checklist de desligamento para criadores de apps
Inclua este bloco no processo de desligamento de RH e TI, para qualquer colaborador que consta como dono no portfólio de apps:
Quando o aviso de saída chega
- Consultar o portfólio e listar todos os apps cujo dono é a pessoa.
- Para cada um, classificar: continua, será reescrito ou será desativado.
Nas duas semanas seguintes
- Nomear o novo dono e transferir a propriedade do app para a conta da equipe ou da empresa.
- Mover o código para o repositório corporativo.
- Rotacionar as chaves e senhas que o criador conhecia, e registrar as novas.
- Gravar uma sessão curta (15 a 20 minutos) em que o criador explica o app, e anexar à ficha.
No último dia
- Confirmar que o novo dono consegue rodar, publicar e reverter o app sozinho.
- Revogar o acesso do criador e conferir se nada deixou de funcionar.
Trinta dias depois
- Verificar se o app continua em uso, se há erros recorrentes e se o novo dono consegue fazer uma alteração simples.
Apps que já ficaram órfãos: como fazer a triagem
Se o criador já saiu, o trabalho é de arqueologia. Uma triagem em quatro passos evita decisões no escuro:
- Descobrir. Usar os registros de acesso, os logs da plataforma e uma pesquisa interna para identificar apps sem dono ativo. A busca por apps não registrados é abordada em governança de portfólio de vibe coding.
- Medir o uso. O app ainda é acessado? Por quantas pessoas e com que frequência? Um app sem uso há meses é candidato a desativação.
- Classificar o risco. O app toca dado pessoal, dado financeiro ou integração com sistema oficial? Se sim, ele sobe de prioridade e exige revisão de segurança antes de qualquer outra coisa, conforme o checklist de segurança do vibe coding.
- Decidir: manter (com novo dono e ficha), reescrever (se a lógica é valiosa mas o código é opaco) ou aposentar (com retenção do registro e eliminação de dados conforme a LGPD).
Reescrever costuma ser mais barato do que parece quando o app é pequeno e a lógica é clara: a especificação do que o app deve fazer pode ser reaproveitada em um novo ciclo de vibe coding, agora com dono, repositório e revisão desde o início.
Quem é responsável: o papel de TI, de RH e da área
A continuidade falha quando é "responsabilidade de todo mundo". Uma divisão que funciona:
- A área dona do app mantém a ficha, nomeia o substituto e participa da gravação de transferência.
- TI garante repositório, contas corporativas, rotação de segredos e a revisão técnica dos apps críticos, no papel descrito em o novo papel de TI no vibe coding.
- RH inclui a consulta ao portfólio de apps no fluxo de desligamento e de mudança de área.
- Segurança define o critério que separa app que pode ficar com a área de app que precisa de revisão formal.
O mesmo vale para áreas que mais criam ferramentas próprias, como as de operações, em que um app de um único criador vira rapidamente um ponto único de falha.
Como a Jetpacks apoia a continuidade
A Jetpacks é parceira oficial da Replit no Brasil e conduz as imersões e os workshops oficiais da Replit para destravar o vibe coding, com governança, dentro de grandes empresas. No método Flight Plan, o diagnóstico (Launchpad) mapeia o que já existe, a capacitação (Booster) ensina as áreas a entregar o kit de transferência junto com o app, e o acompanhamento (Mission Control) mede o que está em uso. O panorama completo de como estruturar o vibe coding na empresa está em vibe coding nas empresas, e o contexto da parceria em Jetpacks, parceira oficial da Replit no Brasil.
FAQ
O que acontece com um app vibe coded quando o criador sai da empresa?
Depende de onde o app está. Se vive em uma conta pessoal, pode ficar inacessível quando a conta é desativada. Se vive em uma conta corporativa, continua rodando, mas sem ninguém que entenda a lógica, as chaves e as dependências. Por isso a transferência de propriedade e de conhecimento deve ocorrer antes da saída.
O que é bus factor e por que importa no vibe coding?
É o número mínimo de pessoas cuja saída paralisaria um projeto. Um bus factor igual a um é um ponto único de falha. No vibe coding, muitos apps nascem com bus factor um, porque o criador é a única pessoa que sabe como e por que o app foi construído.
Como transferir um app do Replit para outra pessoa ou equipe?
Segundo a documentação do Replit, é possível mover um app do workspace pessoal para o de uma equipe, desde que o dono seja membro dessa equipe. A transferência é imediata e irreversível, e preserva as configurações de deploy e as URLs. Confirme o destino antes de executar.
Que documentação mínima todo app vibe coded deve ter?
Uma ficha de uma página (finalidade, usuários, dados e criticidade), lista de segredos e integrações, mapa de dependências, roteiro de operação e registro das regras de negócio embutidas. O código deve estar em repositório versionado da empresa.
A IA pode documentar o app por mim?
Pode gerar um bom primeiro rascunho do README e do mapa de dependências a partir do código. Mas ela descreve o que o código faz, não o que ele deveria fazer. Quem criou o app precisa revisar e corrigir o rascunho antes de sair.
Vale a pena reescrever um app órfão ou é melhor mantê-lo?
Se o app é pequeno e a lógica é clara, reescrever com dono, repositório e revisão costuma compensar. Se é crítico e funciona, mantenha com novo dono, ficha e revisão de segurança. Se ninguém usa, aposente com eliminação de dados conforme a LGPD.
Quem deve ser o dono de um app vibe coded?
A área de negócio que usa o resultado, com um substituto nomeado. TI cuida da infraestrutura, do repositório e da revisão técnica, mas não deve ser dona de todos os apps de todas as áreas.
Conclusão: continuidade se planeja antes da saída
Apps vibe coded democratizam a criação, e é isso que os torna valiosos. O mesmo fator cria o risco: ferramentas importantes que dependem de uma única pessoa. A resposta não é frear a criação, e sim exigir um kit mínimo de transferência, incluir o portfólio de apps no processo de desligamento e fazer a triagem dos apps que já ficaram órfãos.
Para descobrir quantos apps da sua empresa hoje têm bus factor um e quais precisam de ação primeiro, comece pelo diagnóstico gratuito da Jetpacks.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.