Vibe Coding em Escala: Riscos, Dívida, Complexidade e Excesso de Confiança

O que “Vibe Coding” Significa Quando Você Escala

“Vibe coding” é programação orientada pela intuição e pela velocidade: você segue o momentum, toma decisões rápidas e continua entregando sem parar para formalizar cada requisito, caso de borda ou escolha de design. Muitas vezes se baseia em experiência pessoal, padrões copiados, testes leves e um otimismo do tipo “a gente arruma depois”.

Esse método pode ser extremamente útil quando você está explorando ideias, validando um protótipo ou tentando encontrar product–market fit. A diferença é que, nesse contexto, o código é tratado como meio para aprender rápido — não como um contrato de longo prazo.

Por que muda quando a equipe e a base de código crescem

Em pequena escala, a mesma pessoa (ou um time minúsculo) mantém a maior parte do contexto na cabeça. Quando algo quebra, geralmente é óbvio onde olhar. Ao escalar, o contexto se distribui: novos desenvolvedores entram, sistemas se multiplicam e as “regras não escritas” do código deixam de ser conhecimento compartilhado.

Então o vibe coding deixa de ser apenas um estilo pessoal e vira um comportamento organizacional. O custo de decisões não documentadas aumenta, gambiarras rápidas viram dependências e atalhos são copiados porque parecem funcionar.

Os três riscos aos quais voltaremos repetidamente

À medida que a base de código cresce, três modos de falha aparecem repetidamente:

• Dívida técnica que se acumula silenciosamente: pequenos hacks solidificam numa estrutura permanente.
• Complexidade oculta e dependências-surpresa: mudanças numa área quebram outra de maneiras que ninguém previu.
• Excesso de confiança como hábito de time: entregar rápido passa a ser prova de que o sistema está saudável.

Isso não é contra velocidade. O objetivo é manter os benefícios do momentum enquanto se adicionam guarda‑corpos para que o produto possa escalar sem transformar cada release numa aposta.

Por que parece rápido (e por que isso pode enganar)

Vibe coding parece rápido porque otimiza para fluxo: você toma decisões rapidamente, corta cerimônias e segue a intuição em vez de checklists. Isso cria momentum real — especialmente quando você começa do zero e cada commit muda visivelmente o produto.

As vitórias de curto prazo são reais

Quando o objetivo é aprender, não acertar de primeira, vibe coding pode ser uma superpotência. Você entrega protótipos crús, explora ideias e mantém criatividade alta. Times frequentemente conseguem:

• Protótipos rápidos que validam (ou rejeitam) uma ideia barato
• Feedback rápido de usuários porque há algo para testar
• Uma sensação de progresso que mantém todo mundo engajado

Essa velocidade é valiosa quando a incerteza é alta e o custo de estar errado precisa ser baixo.

Sucesso inicial pode esconder bases fracas

A parte enganosa é que software em estágio inicial é tolerante. Com uma base pequena, um único desenvolvedor e pouco tráfego, muitos problemas simplesmente não aparecem. Testes ausentes ainda não fazem diferença. Nomes ambíguos ficam “na sua cabeça”. Uma configuração por atalho funciona porque nada depende dela.

Mas essas fundações estão sendo lançadas enquanto você corre. Mais tarde, quando você adiciona features, incorpora novos colegas ou integra serviços de terceiros, os mesmos atalhos viram atrito — e a abordagem “rápida” começa a gerar resultados mais lentos.

A armadilha do “funcionou uma vez”

Um padrão comum é: algo funciona uma vez, então a equipe assume que continuará funcionando. É assim que consertos pontuais viram padrões copiados e soluções engenhosas tornam‑se “a nossa maneira”. A velocidade vira hábito, e o hábito vira cultura.

Onde é realmente útil

Vibe coding brilha em spikes, protótipos e experimentos de vida curta — situações onde aprender importa mais que manutenibilidade. O erro é deixar um experimento se tornar produto sem uma transição deliberada para práticas de engenharia que suportem escala.

Risco #1: Dívida técnica que se acumula silenciosamente

Dívida técnica é o custo do “a gente arruma depois” que você assume quando escolhe o caminho mais rápido em vez do mais claro e seguro. No vibe coding, isso frequentemente se parece com entregar uma feature com testes mínimos, nomes confusos ou um patch rápido que serve para a demo atual, mas não foi pensado para as próximas três requisições.

Como a dívida aparece no código real

Alguns exemplos concretos:

• Atalhos na lógica: duplicar a mesma validação em três lugares em vez de centralizá‑la
• Falta de testes: ausência de checagens automatizadas para casos de borda, tratamento de erros ou permissões
• Código obscuro: variáveis “mágicas”, nomes de função vagos e comentários como “TODO: limpar” que nunca são resolvidos
• Regras hard-coded: thresholds de preço, feature flags ou regras regionais embutidas diretamente no código
• Modelos de dados bagunçados: campos adicionados ad hoc (“temp2”, “status_v3”), enums inconsistentes ou significados misturados numa mesma coluna

Por que atalhos pequenos se multiplicam

Um atalho pode ser ok para uma pessoa trabalhando num arquivo. Em escala, ele se espalha: equipes copiam padrões que parecem funcionar, serviços integram‑se com suposições não documentadas e o mesmo “conserto rápido” é reimplementado de maneiras ligeiramente diferentes. O resultado não é uma falha grande — são milhares de pequenas incongruências.

A curva de custo: fica caro rápido

A dívida muda a forma do trabalho. Mudanças simples começam a levar mais tempo porque engenheiros precisam desembaraçar efeitos colaterais, adicionar testes depois do fato e reaprender decisões não documentadas. Bugs ficam mais frequentes e mais difíceis de reproduzir. Onboarding desacelera porque novos colegas não conseguem distinguir o que é intencional do que é acidental.

A dívida fica invisível — até não ficar

Dívida técnica frequentemente mora em sistemas “funcionando”. Ela aparece quando você tenta uma grande mudança: redesign, requisito de conformidade, melhora de performance ou nova integração. É aí que os atalhos silenciosos exigem pagamento, geralmente com juros.

Risco #2: Complexidade oculta e dependências-surpresa

Vibe coding tende a otimizar por “funciona na minha máquina”. Em pequena escala, muitas vezes dá para relevar isso. Em escala, a complexidade se esconde nos espaços entre módulos: integrações, casos de borda e o caminho real que os dados percorrem no sistema.

Onde a complexidade realmente vive

A maioria das surpresas não vem da função que você mudou — vem do que essa função toca.

Integrações adicionam regras invisíveis: peculiaridades de API, retries, limites de taxa, falhas parciais e respostas “bem sucedidas” que ainda significam “algo deu errado”. Casos de borda se acumulam nos dados de produção: campos ausentes, formatos inesperados, eventos fora de ordem ou registros antigos criados antes de uma validação existir.

Fluxos de dados são o multiplicador máximo de complexidade. Uma pequena mudança em como você grava um campo pode quebrar um job a jusante, um dashboard de analytics ou uma exportação de billing que assumia o significado antigo.

Dependências desconhecidas (o que ninguém lembra)

Acoplamentos ocultos aparecem como:

• Módulos que compartilham uma tabela do banco (ou só uma coluna) sem contrato claro
• Configs compartilhadas e feature flags reaproveitadas para comportamentos não relacionados
• Bibliotecas “utilitárias” que viram um saco de gatos usado por toda parte

Quando essas dependências não são explícitas, você não consegue raciocinar sobre impacto — só descobrir depois.

A lacuna de produção (o que parece fazer vs. o que faz)

Uma mudança pode parecer correta em um teste local, mas se comportar diferente sob concorrência real, retries, caching ou dados multi‑tenant.

Ferramentas assistidas por IA também podem agravar isso: abstrações geradas que escondem efeitos colaterais, padrões inconsistentes que complicam edições futuras, ou estilos de tratamento de erro ligeiramente diferentes que criam modos estranhos de falha.

Uma história simples

Um desenvolvedor “só” renomeia um valor de status para ficar mais claro. A UI ainda funciona. Mas um consumidor de webhook filtra pelo status antigo, uma sincronização noturna pula registros e relatórios financeiros deixam de contabilizar receita por um dia. Nada “travou” — apenas fez a coisa errada, silenciosamente, em todo lugar.

Risco #3: Excesso de confiança vira hábito de time

Excesso de confiança no vibe coding não é só “estar confiante”. É confiar na intuição mais que em evidências enquanto os riscos aumentam — enviar porque parece certo, não porque foi verificado.\

Vitórias iniciais tornam isso tentador. Um protótipo rápido funciona, clientes reagem, métricas sobem e o time aprende uma lição perigosa: revisões, testes e design são “opcionais”. Quando você anda rápido, qualquer coisa que te atrase começa a parecer burocracia — mesmo quando é o único freio que previne um incêndio futuro.

Como vitórias iniciais viram falta de disciplina

Vibe coding frequentemente começa com momentum real: menos reuniões, menos docs, commits mais rápidos. O problema é o hábito que isso forma:

• Pull requests viram carimbos (“parece bom, envia”)\n- Testes são adiados (“a gente adiciona cobertura depois”)\n- Decisões arquiteturais acontecem na cabeça de alguém, não em contexto compartilhado

Isso é administrável com uma pessoa e um código pequeno. Quebra quando várias pessoas precisam mudar os mesmos sistemas com segurança.

“Hero coding” não escala

Excesso de confiança gera padrões de herói: alguém entregando grandes mudanças à noite, resgatando releases e se tornando o responsável não oficial por tudo. Parece produtivo — até essa pessoa tirar férias, sair da empresa ou simplesmente se queimar.

Risco de decisão: cronogramas ficam otimistas, migrações são ignoradas

Com a confiança, estimativas encurtam e riscos são desconsiderados. Migrações, refactors e mudanças de dados são tratados como reescritas simples em vez de projetos coordenados. É aí que times se comprometem com datas assumindo que tudo correrá bem.

Como se espalha culturalmente

Se velocidade é mais recompensada que aprendizado, o time copia o comportamento. As pessoas param de pedir evidências, deixam de compartilhar incertezas e deixam de levantar preocupações. Um processo saudável de engenharia não é se mover devagar — é criar provas antes que a produção faça isso por você.

Deriva de qualidade e confiabilidade conforme a base cresce

Vibe coding pode parecer movimento constante — até a base de código atingir um tamanho em que pequenas mudanças reverberam por lugares surpreendentes. Aí a qualidade não falha de uma vez. Ela deriva. A confiabilidade vira “quase ok”, depois “ocasionalmente estranha”, depois “temos medo de deployar às sextas”.

Modos de falha típicos que você começa a ver

Com a superfície maior, as falhas mais comuns não são dramáticas — são barulhentas:

• Regressões: uma correção numa área quebra outra de forma silenciosa.
• Comportamento instável: mesma ação ora funciona, ora não (tempo, caching, condições de corrida ou suposições de dados inconsistentes).
• UX inconsistente: telas semelhantes se comportam diferente porque padrões não foram padronizados (validações, estados de erro, spinners de carregamento, estados vazios).

Por que teste manual para por aí

Testes manuais escalam mal com frequência de releases. Quando você entrega mais, cada release tem menos tempo para checagem cuidadosa, e o “testa tudo rápido” vira amostragem. Isso cria pontos cegos, especialmente em casos de borda e interações entre features. Com o tempo, equipes passam a depender de relatos de usuários como mecanismo de detecção — caro, lento e prejudicial à confiança.

Sinais de degradação da qualidade (e como aparece)

A deriva de qualidade é mensurável mesmo que pareça subjetiva:

• Backlog de bugs cresce mais rápido do que reduz
• Incidentes repetidos com causas raízes semelhantes
• Cultura de hotfix: deploys de emergência frequentes após releases
• Mais volume de suporte para “antes funcionava”

O que “pronto” deveria significar em escala

Em escala, “pronto” não pode ser “funciona na minha máquina”. Uma definição razoável inclui:

• Testes automatizados para caminhos críticos (e correções incluem testes de regressão)
• Documentação básica para comportamentos e decisões não óbvias
• Ganchos de monitoramento: logs/métricas em ações chave e pontos de falha

Velocidade sem qualidade vira velocidade mais lenta depois — porque cada mudança nova custa mais para verificar, mais para debugar e mais para explicar.

Riscos de segurança, privacidade e conformidade

Velocidade é um recurso — até pular passos “entediosos” que previnem vazamentos. Vibe coding frequentemente otimiza progresso visível (telas novas, endpoints, integrações rápidas), o que pode ignorar modelagem de ameaças, revisão básica de segurança e perguntas simples como: o que pode dar errado se essa entrada for maliciosa ou se uma conta for comprometida?

Falhas comuns que aparecem depois

Alguns padrões reaparecem quando times se movem rápido sem guardrails:

• Segredos no código: chaves de API, senhas do banco e tokens cometidos no repo, colados em tickets ou embutidos no frontend.
• Validação de entrada ausente: endpoints aceitando IDs não checados, uploads de arquivo ou JSON livre que vira vetor de injeção ou exposição de dados.
• Permissões inseguras: serviços com papéis amplos na nuvem, contas admin compartilhadas ou acessos “temporários” que se tornam permanentes.

Essas falhas podem ficar quietas até a base crescer e ninguém lembrar por que um atalho existe.

Privacidade e conformidade: risco cresce com dados de usuário

Ao armazenar dados de usuário — emails, metadados de pagamento, localização, dados de saúde ou analytics comportamentais — você é responsável por como é coletado, armazenado e compartilhado. Iteração rápida pode levar a:

• Coletar mais dados do que precisa (difícil de justificar e proteger)
• Políticas de retenção pouco claras (“a gente limpa depois”)
• Exposição acidental via logs, exports ou dashboards internos mal escopados

Se você está sujeito a GDPR/CCPA, SOC 2, HIPAA ou requisitos de indústria, “a gente não percebeu” não é defesa.

Risco da cadeia de suprimentos ao adicionar dependências rápido

Adicionar bibliotecas rapidamente — especialmente auth, crypto, analytics ou ferramentas de build — pode trazer vulnerabilidades, telemetria indesejada ou licenças incompatíveis. Sem revisão, uma dependência pode ampliar sua superfície de ataque dramaticamente.

Defaults seguros que mantêm o momentum

Use automação e gatekeeps leves em vez de contar com memória:

• Scans automáticos: varredura de segredos, vulnerabilidades de dependências e SAST no CI
• Privilégio mínimo por padrão para papéis na nuvem, contas de serviço e dados de produção
• Gate de revisão para áreas sensíveis (auth, pagamentos, PII, permissões, criptografia) com um checklist curto e revisores obrigatórios

Feito direito, esses guardrails preservam velocidade enquanto previnem dívida de segurança irreversível.

Operações: quando produção vira o cheque de realidade

Vibe coding muitas vezes “funciona” no ambiente onde foi criado: laptop do dev com credenciais em cache, dados seed e runtime permissivo. Produção tira essas almofadas. “Funciona na minha máquina” fica caro quando cada descompasso vira deploys falhos, outages parciais ou bugs visíveis a clientes que não se reproduzem fácil.

A camada que falta: observabilidade

Quando a velocidade é priorizada sobre estrutura, times frequentemente pulam o encanamento que explica o que o sistema está fazendo.

Logs pobres significam que você não responde “o que aconteceu?” após uma falha.

Sem métricas você não vê performance degradando gradualmente até cruzar um limite.

Sem traces você não sabe onde o tempo é gasto entre serviços, filas ou APIs de terceiros.

Relatórios de erro fracos fazem exceções acumularem no escuro, transformando incidentes reais em suposições.

Dívida operacional aparece como entrega frágil

Dívida operacional é o gap entre “a app roda” e “a app pode ser operada com segurança”. Geralmente aparece como deploys frágeis, correções específicas de ambiente, passos de rollback obscuros e ações manuais escondidas (“rode esse script após deploy”, “reinicie esse worker se travar”). Runbooks não existem ou estão desatualizados e são propriedade de “quem mexeu por último”.

Sintomas que você sente primeiro

Sinais comuns de que produção virou gargalo:

• Resposta a incidentes demora porque ninguém vê a causa raiz
• Propriedade não está clara: alertas disparam, mas nenhum time se sente responsável
• Alertas são ruidosos ou sem sentido, então as pessoas passam a ignorá‑los
• Deploys dependem de conhecimento tribal e regras tipo “não mexa às sextas”

Hábitos pequenos que evitam o caos

Comece cedo com rotinas operacionais leves: um runbook de uma página por serviço, alguns dashboards ligados ao impacto do usuário, reporting automático de erros e postmortems curtos que gerem uma ou duas correções concretas. Isso não é “processo extra” — é como manter velocidade sem transformar produção em QA gratuito.

Quebra de time e processo em escala

Vibe coding pode parecer colaborativo no começo porque todo mundo está “só entregando”. Mas conforme o time cresce, a base de código vira a interface compartilhada entre pessoas — e inconsistência vira atrito.

Drift de estilo desacelera a colaboração

Quando cada feature segue um padrão diferente (estrutura de pastas, nomes, tratamento de erros, gerenciamento de estado, chamadas de API), engenheiros gastam mais tempo traduzindo do que construindo. Reviews viram debates de gosto em vez de correção, e pequenas mudanças demoram mais porque ninguém tem certeza de qual padrão é “o certo” naquela área.

O resultado não é só entrega mais lenta — é qualidade desigual. Algumas partes são bem testadas e legíveis, outras são frágeis. Times começam a encaminhar trabalho para “quem conhece aquela parte”, criando gargalos.

Onboarding vira adivinhação

Novos engenheiros precisam de previsibilidade: onde fica a lógica de negócio, como os dados fluem, como adicionar um endpoint novo, onde colocar validação, quais testes escrever. Num código vibe, essas respostas variam por feature.

Isso aumenta custo de onboarding de duas formas:

• Novos hires precisam de mais tempo de suporte dos senior engineers
• Eles fazem mudanças “razoáveis” no lugar errado, criando regressões ou lógica duplicada

Custos de coordenação aparecem como duplicações e conflitos

Conforme mais pessoas trabalham em paralelo, suposições inconsistentes geram retrabalho:

• Dois engenheiros constroem utilitários similares porque não acham o existente
• Features conflitam porque um módulo depende silenciosamente de efeitos colaterais de outro
• Conflitos de merge aumentam porque arquivos compartilhados viram depósito

Eventualmente, o time desacelera não porque programar é difícil, mas porque coordenar é difícil.

Dívida de decisão substitui arquitetura

Quando você pula escolhas explícitas — limites, propriedade, contratos de API, “esta é a forma que fazemos X” — você acumula dívida de decisão. Cada mudança futura reabre perguntas antigas. Sem seções claras, ninguém se sente seguro para refatorar e tudo vira interconectado.

Ferramentas simples de alinhamento que mantêm a velocidade

Você não precisa de burocracia pesada. Alguns “primitivos de alinhamento” leves ajudam muito:

• Convenções: nomes, estrutura de pastas, tratamento de erros, logging
• Templates compartilhados: scaffolds de serviço/módulo, setup de testes, checklists de PR
• Golden paths: uma abordagem recomendada para trabalho comum (ex.: adicionar rota API, criar job em background, introduzir nova página UI)

Essas ferramentas reduzem overhead de coordenação e tornam a base mais previsível — assim o time continua rápido sem tropeçar um no outro.

Sinais de alerta: métricas e cheiros a observar

Vibe coding pode parecer ok — até o dia em que não é. O truque é capturar a mudança de “bagunça temporária que vamos limpar” para “dívida sistêmica que continua se espalhando”. Observe números e comportamento do time.

Indicadores mensuráveis (os números não mentem)

Algumas métricas mudam primeiro:

• Tempo de ciclo aumenta: mudanças pequenas demoram mais semana a semana, mesmo com escopo similar
• Taxa de defeitos sobe: mais bugs por release, mais issues reportadas por clientes ou mais hotfixes
• Rollbacks aumentam: releases são revertidos com mais frequência ou deploys são pausados por “dar uma sensação de risco”
• Frequência/gravidade de incidentes cresce: mais pages, mais tempo para restaurar serviço, incidentes repetidos

Cheiros qualitativos (o que as pessoas começam a dizer)

Freqüentemente sinais anteriores aos dashboards:

• “Não toque naquele arquivo — quebra tudo.”
• “Só a Ana entende essa parte.”
• Features são entregues e reescritas semanas depois porque a versão anterior é difícil de estender.
• PRs viram enormes porque times evitam integrar com frequência.

Bagunça temporária vs dívida sistêmica

Bagunça temporária é intencional e com prazo (ex.: experimento rápido com ticket de limpeza e dono). Dívida sistêmica é comportamento padrão: atalhos sem plano, espalhados por módulos, que tornam mudanças futuras mais lentas.

Maneiras leves de auditar a realidade

• Crie um simples mapa de dependências (mesmo um diagrama) para identificar acoplamentos surpresa
• Acompanhe tendência de cobertura de testes ao longo do tempo (direção importa mais que número)
• Rode revisões rápidas de incidentes para identificar causas repetidas, não só consertos pontuais

Torne o risco visível

Use um “registro de dívida” e cheques mensais de saúde técnica: uma lista curta das maiores dívidas, impacto, dono e data alvo. Visibilidade transforma preocupação vaga em trabalho gerenciável.

Guardrails práticos que mantêm velocidade sem caos

Código rápido pode continuar rápido se você definir o que “velocidade segura” significa. O objetivo não é frear as pessoas — é fazer do caminho rápido o caminho previsível.

Defina um fluxo de trabalho “velocidade segura”

Mantenha mudanças pequenas e com dono. Prefira PRs que façam uma coisa, tenham um revisor claro e possam ser revertidos facilmente.

Uma regra simples: se uma mudança não cabe numa explicação de poucas frases, provavelmente precisa ser dividida.

Coloque portões leves antes dos merges

Guardrails funcionam melhor quando são automáticos e consistentes:

• Normas de code review: exigir pelo menos um revisor além do autor e tornar “o que pode quebrar?” uma pergunta padrão
• Gates de CI: builds passam, testes rodam e falhas bloqueiam merges
• Linting/formatação: aplicar estilo com ferramentas para evitar debates humanos sobre tabs vs spaces
• Política de dependências: documentar como novas libs são aprovadas, como versões são atualizadas e quem é dono de dependências críticas

Camadas de testes (em termos simples)

Pense em camadas para não tentar testar tudo da mesma forma:

• Testes unitários: checam pequenas partes da lógica rapidamente
• Testes de integração: garantem que componentes funcionam juntos (DB, filas, serviços externos)
• Testes end-to-end: simulam caminho real do usuário; mantenha poucos e de alto valor
• Testes de contrato: validam o “aperto de mão” entre serviços ou consumidores de API para que mudanças não surpreendam outros

Documentação que escala

Escreva menos, mas escreva o essencial:

• ADRs (Architecture Decision Records): notas curtas sobre o que foi decidido e por quê
• Mini notas de design: uma página antes de trabalho grande para alinhar escopo e riscos
• Runbooks: passo a passo para problemas comuns de produção e procedimentos de deploy/rollback

Onde ferramentas de IA ajudam (e onde não ajudam)

Use assistentes de IA para rascunhos: primeira versão de código, scaffolding de testes, sugestões de refactor e esboços de documentação. Mas mantenha responsabilidade humana: revisores respondem pelo merge, time decide dependências e ninguém deve aceitar código gerado que não consiga explicar.

Uma forma prática de manter “velocidade de protótipo” reduzindo risco operacional é padronizar a transição de protótipos gerados por chat para sistemas mantidos. Por exemplo, se você usa uma plataforma de vibe-coding como Koder.ai para gerar apps web (React), backends (Go + PostgreSQL) ou mobile (Flutter) a partir de um chat, trate a saída como qualquer artefato de engenharia: exporte o código-fonte, coloque nos gates normais do CI e exija testes + revisão antes de uso amplo. Funcionalidades como snapshots/rollback e modo de planejamento ajudam a mover rápido mantendo alterações auditáveis e reversíveis.

Quando vibe coding é aceitável (e quando não é)

Vibe coding pode ser escolha inteligente quando você quer aprender rápido, validar uma ideia ou desbloquear um time. Vira má aposta quando a velocidade substitui clareza e o código é tratado como “bom o suficiente” para uso de longo prazo.

Critérios de decisão (cheque rápido)

Use vibe coding quando a maioria disso for verdade:

• Nível de risco: baixo (um erro é incômodo, não catastrófico)
• Impacto no usuário: raio de ação limitado (pequena coorte, usuários internos ou feature‑flagged)
• Sensibilidade dos dados: sem dados regulados ou altamente sensíveis
• Horizonte de tempo: dá para substituir em breve ou você planejou explicitamente tempo para endurecer

Evite quando tocar pagamentos, auth, permissões, workflows centrais ou algo que você teria vergonha de explicar numa revisão de incidente.

Pense em “zonas”

• Zona de experimento: protótipos, scripts descartáveis, demos. Vibe coding cabe bem.
• Zona de sistemas core: caminhos de receita, dados de clientes, libs compartilhadas. Vibe coding só para spikes — depois refatore.
• Zona regulada: saúde, finanças, produtos com muita privacidade/auditoria. Não use vibe coding em produção.

Playbook simples: rápido primeiro, depois endureça

1. Prototipe rápido atrás de um flag ou em sandbox.
2. Nomeie como protótipo (label no ticket, README, data de expiração).
3. Endureça antes de adoção ampla: adicione testes, simplifique dependências, documente comportamento e faça revisão.
4. Gradue ou delete: ou torna‑se manutenível — ou remove.

Checklist que você pode usar já na próxima semana

• Existe um dono claro e uma data de expiração para esse código?
• Está por trás de um feature flag ou tem escopo seguro?
• Há testes básicos no caminho crítico?
• Dependências são mínimas e intencionais?
• Trata erros e casos de borda de forma previsível?

Escolha um guardrail para implementar primeiro: “Nenhum protótipo alcança 20% dos usuários sem testes + revisão.” Alinhe isso com o time e você mantém velocidade sem herdar o caos.