Imagine que você consegue criar um aplicativo inteiro apenas conversando com uma IA, sem escrever uma única linha de código manualmente. Isso é o que chamamos de Vibe Coding is uma abordagem de desenvolvimento impulsionada por IA onde a criação de software acontece através de diálogos contextuais, permitindo que a ideia se transforme em código quase instantaneamente. Parece o paraíso da produtividade, certo? Mas para quem cuida da governança e segurança, isso acende um alerta vermelho. Se a IA escreve o código e o desenvolvedor apenas "sente a vibe" e aprova, onde fica o controle? Como evitar que um único usuário tenha o poder de criar, testar e implantar algo potencialmente perigoso em produção?
O risco do "Superusuário AI"
No modelo tradicional de desenvolvimento, temos barreiras claras. O programador escreve, o revisor analisa e o engenheiro de DevOps implanta. Quando entramos no mundo do vibe coding, especialmente com ferramentas como o Build Agent da ServiceNow, a linha entre essas funções começa a sumir. O risco real aqui é a criação do "Superusuário AI": alguém que, munido de agentes inteligentes, consegue pular todas as etapas de verificação.
Se não houver uma estrutura de Segregação de Funções (ou SoD, do inglês Separation of Duties), você abre as portas para erros catastróficos ou até sabotagens internas. Afinal, a SoD serve justamente para garantir que nenhuma pessoa sozinha tenha controle total sobre um processo crítico. Em um pipeline de vibe coding, onde a velocidade é absurda, a tentação de ignorar essas travas é enorme.
Implementando SoD em pipelines modernos
Para não matar a agilidade do vibe coding, mas manter a empresa segura, precisamos de travas automatizadas. Não dá para voltar ao modelo de formulários em PDF para aprovação. A solução está em integrar a governança diretamente no fluxo de CI/CD.
Plataformas como o GitLab permitem criar políticas de execução de pipeline. No contexto de vibe coding, isso significa que, mesmo que a IA gere o código e o desenvolvedor o aceite, o sistema impede que esse mesmo desenvolvedor aprove o merge request para a branch de produção. Você precisa de um "segundo par de olhos", mesmo que esse par seja de outro humano ou de uma IA de auditoria independente.
| Etapa | Dev Tradicional | Vibe Coding (Sem SoD) | Vibe Coding (Com SoD) |
|---|---|---|---|
| Criação | Manual (Cód.) | Conversacional (IA) | Conversacional (IA) |
| Revisão | Peer Review | Apenas "Vibe" do autor | Revisor Independente/Políticas |
| Implantação | DevOps/SRE | Automação Total | Trigger Token / Governança |
| Risco | Lento / Erros Humanos | Altíssimo / Shadow IT | Equilibrado / Auditável |
O papel do Platform Engineering na era dos agentes
Aqui entra a figura do Platform Engineering. Em vez de serem os "porteiros" que travam tudo, esses profissionais agora atuam como designers de guardrails. Eles não revisam cada linha de código gerada pela IA, mas definem os portões de qualidade (quality gates) que o código deve atravessar.
Por exemplo, podem configurar que qualquer código gerado via vibe coding obrigatoriamente passe por um scan de vulnerabilidades (SAST) e que o resultado seja validado por um engenheiro de segurança antes de seguir. O desenvolvedor continua na "vibe" de criar, mas a infraestrutura garante que a segurança não seja opcional. O segredo é usar mecanismos de tokens de trigger: o desenvolvedor dispara a requisição, mas a implantação real só acontece após a validação de tokens emitidos por quem detém a função de compliance.
Auditando a conversa: a nova trilha de evidências
Uma das maiores dores de cabeça para auditores será: "quem escreveu isso?". Se o código foi gerado por uma IA após um prompt mal escrito, a responsabilidade recai sobre quem? A segregação de funções agora deve incluir a auditoria dos logs de conversa.
Não basta olhar o commit final. É preciso rastrear a intenção. Ferramentas de audit events, como as do GitLab, que registram mudanças de permissões e variáveis de CI/CD, devem ser expandidas para registrar qual agente de IA foi usado e quem validou a saída. Isso transforma a "vibe" em algo tangível e auditável, evitando que mudanças críticas sejam feitas "no escuro".
Dicas práticas para não travar a produtividade
- Automatize a confiança: Use testes automatizados rigorosos como primeira camada de SoD. Se o código da IA não passar nos testes unitários, ele nem chega ao revisor humano.
- Siga a regra dos dois: Nunca permita que a mesma pessoa que deu o prompt para a IA seja a pessoa que aperta o botão de deploy em produção.
- Crie papéis específicos: Defina quem é o "Curador de Vibe" (quem refina a ideia) e quem é o "Guardião do Pipeline" (quem garante a conformidade).
- Monitore desvios: Fique atento a alterações manuais em pipelines que deveriam ser governadas por políticas de compliance.
O que acontece se a IA fizer a revisão do código que ela mesma gerou?
Isso quebra completamente o princípio da Segregação de Funções. Se a mesma entidade (ou modelo de IA) cria e aprova, você tem um ponto único de falha. A revisão deve ser feita por um humano ou por uma IA de auditoria configurada com parâmetros de segurança diferentes e independentes do modelo de criação.
Vibe Coding é compatível com normas de conformidade como SOC2 ou ISO 27001?
Sim, desde que a governança não esteja na escrita do código, mas no processo de aprovação e implantação. O auditor não se importa se o código foi escrito por um humano ou por uma IA, mas sim se houve revisão independente e se há evidências de que as permissões de acesso foram respeitadas.
Como evitar que o desenvolvedor altere o pipeline para pular a SoD?
Utilize políticas de execução de pipeline (Pipeline Execution Policies). Configure o sistema para que apenas administradores de compliance possam editar o arquivo de configuração do pipeline (ex: .gitlab-ci.yml). Assim, o desenvolvedor consegue alterar o código da aplicação, mas não consegue alterar as regras de segurança que o código deve seguir.
Qual a diferença entre AI-assisted dev e Vibe Coding na governança?
No AI-assisted, o humano ainda escreve e revisa cada linha (Copilot). No Vibe Coding, o humano fornece a visão e a IA entrega o componente pronto. A governança no Vibe Coding precisa ser muito mais rigorosa nos portões de saída, pois o humano perde a visibilidade do detalhe técnico durante a criação.
O uso de agentes de IA substitui a necessidade de um time de DevOps?
Não. Pelo contrário, ele muda o papel do DevOps para Platform Engineering. Em vez de configurar servidores manualmente, eles agora configuram as regras de governança, os limites de segurança e a infraestrutura onde a IA opera, garantindo que a autonomia do desenvolvedor não vire anarquia.
Próximos passos para sua operação
Se você está começando a implementar vibe coding na sua empresa, não comece pelas ferramentas, comece pelas permissões. Revise quem tem acesso de escrita em seus repositórios de produção e implemente a exigência de ao menos um aprovador diferente do autor para qualquer merge request.
Para cenários mais complexos, considere a implementação de trigger tokens. Isso garante que a infraestrutura de deploy seja isolada do ambiente de desenvolvimento, forçando a passagem por um processo de validação externa. Lembre-se: a agilidade da IA é maravilhosa para criar, mas a segurança da governança é o que mantém a empresa viva.
13 Comentários
Sinceramente, chamar isso de "Vibe Coding" é a coisa mais cafona que já vi na tecnologia. Estamos trocando a engenharia real por um "sentir a vibe"? Patético. O texto tenta passar a ideia de que a governança resolve, mas a verdade é que estamos delegando a inteligência para máquinas e aceitando que o programador vire um mero operador de prompt. Isso não é evolução, é involução cognitiva travestida de produtividade. Onde está o rigor técnico? Onde está a análise de complexidade ciclomática? Sumiram porque agora a vibe é que manda. É um desastre anunciado e quem acha que SoD vai salvar esse caos está apenas fingindo que trabalha.
É inadmissível que sequer se discuta a possibilidade de pular etapas de verificação em prol de uma tal de agilidade. A ética profissional exige que o código seja auditável e compreendido por quem o implementa. Se você não sabe o que a IA escreveu, você não é um desenvolvedor, é um impostor. A segregação de funções não é apenas uma norma de compliance, é o que separa empresas sérias de amadores que brincam de montar Lego com o dinheiro dos investidores. A responsabilidade moral sobre o software deve ser humana, ponto final.
muito texto pra falar que nao pode deixar o stagiario de prompt subir codigo direto em prod lol
SÓ O BRASILEIRO MESMO PRA QUERER ATALHO EM TUDO! 🇧🇷 Se a gente não tiver rigor, vamos virar escravos de ferramenta gringa que nem sabemos como funciona! 😡 Esse negócio de vibe coding é papo de quem não quer ralar no código. Quero ver se essa IA aguenta a pressão de um sistema legado brasileiro sem travar tudo! Kkkkkkkk
Fico pensando na natureza da autoria nesse novo paradigma. Se a IA gera a estrutura e o humano apenas valida a "vibe", a essência da criação mudou de técnica para curadoria. Mas será que a curadoria é suficiente para garantir a estabilidade de sistemas críticos? Parece que estamos trocando a profundidade do conhecimento pela superfície da intenção. É quase poético, mas ao mesmo tempo aterrorizante pensar no apagão de conhecimento técnico que isso pode gerar nas próximas gerações de devs.
Achei a abordagem bem interessante! É ótimo ver que existem formas de manter a segurança sem matar a criatividade do time. Vamos pra cima que a automação veio pra somar!
Nossa, que fofinho achar que um "segundo par de olhos" resolve tudo 🙄. Como se as pessoas realmente revisassem o código e não apenas dessem o merge sem ler nada. Boa sorte com a ISO 27001 enquanto o time ignora os avisos do SAST 💅
A redação do texto é aceitável, mas a premissa é quase beira o ridículo. "Curador de Vibe"? Por favor, que nomenclatura deplorável! Estamos reduzindo a ciência da computação a um exercício de estética. Além disso, a ideia de que a governança reside apenas no processo de aprovação é own a definição de negligência técnica. Se o código é gerado por um modelo estocástico, a probabilidade de bugs sutis que passam por testes unitários é altíssima. É preciso mais do que tokens de trigger para evitar que um sistema colapse por causa de uma alucinação da IA.
Tudo isso é apenas a manifestação da nossa pressa contemporânea. Queremos o resultado sem o processo. A segregação de funções é a tentativa burocrática de simular a prudência que o desenvolvedor moderno já não possui.
Achei super útil! 😍 Imagina a paz de criar as coisas rápido e ter alguém (ou algo) cuidando da parte chata da segurança ☁️✨
GENTE, EU NÃO ACREDITO QUE ESTAMOS FALANDO DISSO! Imagina o caos se alguém subir um prompt errado e deletar o banco de dados da empresa inteira? Eu teria um ataque cardíaco na hora! Alguém me tira daqui!
Interessante. Gostaria de saber mais sobre como esses tokens de trigger funcionam na prática.
O Platform Engineering é a única saída viável. Sem guardrails rígidos, o desenvolvimento vira anarquia. O resto é conversa.