Vibe Coding Agent
Security & Evaluation

Software engineering está passando pela sua transformação mais significativa desde a introdução das linguagens de alto nível. A mudança mais profunda é a transição de escrever código para expressar intenção — confiando em sistemas inteligentes para traduzir essa intenção em software funcional. Esse novo paradigma abrange um espectro: do "vibe coding" casual, onde o desenvolvedor descreve o que quer em linguagem natural e aceita o que a IA gera, até a "agentic engineering" disciplinada, onde a IA atua como motor de implementação dentro de constraints cuidadosamente desenhados.

Para operacionalizar vibe coding na enterprise, precisamos redefinir confiança em dois eixos distintos:

Este whitepaper fornece o framework definitivo de 2026 para ambos: estabelecer o "safety harness" estrito necessário para proteger agentes não-determinísticos, e abrir o "glass box" para medir rigorosamente a qualidade, eficiência e alinhamento do raciocínio interno.

Desenvolvimento orientado por intenção acelera drasticamente a inovação, mas introduz vulnerabilidades de segurança sem precedentes. Não estamos mais simplesmente protegendo aplicações web contra exploits tradicionais — estamos encarregados de proteger um workforce não-humano que possui a agência ambiente para executar código gerado, acessar APIs internas sensíveis e modificar dinamicamente ambientes de produção.

Modelos tradicionais de teste e segurança de software dependem de lógica determinística, onde um conjunto fixo de inputs produz um output previsível. Porém, num sistema agêntico, um agente pode possuir um token de acesso válido mas operar autonomamente com intenção desalinhada. Uma realização crítica: um modelo de IA bruto NÃO é um agente. Ele só se torna um quando envolvido num "harness" — o scaffolding que lhe dá estado, execução de ferramentas, loops de feedback e constraints aplicáveis. Proteger esse novo paradigma exige mudar o foco de proteger sintaxe de código para proteger o harness.

Para alcançar essa Effective Trust contínua e proteger a realidade caótica do vibe coding, desenvolvemos uma arquitetura defence-in-depth em camadas: um baseline estrito de 7 pilares, estendido por controles de execução de alta velocidade, e coroado por mecanismos de defesa agêntica ativa.

Em ambientes enterprise tradicionais, segurança é determinística. Aplicações dependem de sintaxe de código previsível, e acesso é governado por modelos estáticos de Identity-as-a-Perimeter, como RBAC. Se um usuário ou service account tem o token de autorização correto, o sistema implicitamente confia no caminho de execução.

O ambiente agêntico fundamentalmente rompe esse modelo. Como falhas do dia a dia de agentes frequentemente remontam a uma ferramenta ausente, uma regra vaga ou um guardrail inexistente, organizações devem migrar para um modelo "Context-as-a-Perimeter". Como devemos assumir que o modelo subjacente pode falhar ou ser comprometido, segurança não pode residir somente na IA — precisamos aplicar um "safety envelope" externo e estrito abrangendo múltiplas disciplinas.

Pilar 1 — Infrastructure & Networking

Cloud Infrastructure Engineers devem proteger o ambiente fundacional contra upstream poisoning e container escapes. Como o harness deve ditar onde o código do agente realmente roda e o que ele não pode alcançar, isolamos a execução de runtime dentro de sandboxes efêmeros kernel-level (como gVisor). Além disso, governança de egresso de rede estrita garante que dados gerados pelo agente viajem apenas por caches offline autorizados ou proxies internos explícitos, prevenindo exfiltração pública inadvertida.

Pilar 2 — Data

Data Architects enfrentam a ameaça de agentes vazarem informações sensíveis de suas janelas de contexto ou ingerirem dados RAG envenenados. A prática de "context engineering" fornece aos agentes informação rica e estruturada sobre codebases e intenção. Para proteger esse contexto sensível: dados em repouso são protegidos com Customer-Managed Encryption Keys (CMEK), dados em trânsito via mutual TLS (mTLS). Acesso a dados deve ser estritamente escopado para aplicar o princípio de least privilege. Crucialmente, stores de memória de longo prazo — particularmente Vector Databases — devem aplicar tenant partitioning estrito para prevenir Cross-Tenant Vector Poisoning: um payload malicioso ingerido por um tenant não pode ser recuperado durante a similarity search de outro tenant.

Pilar 3 — Model

AI Engineers devem defender a lógica central da aplicação contra ataques semânticos que subvertem as instruções do modelo. Em workflows agênticos, o prompt e os "Instructions and Rule Files" que definem o que o agente é proibido de fazer servem como o novo source code. Proteger este pilar exige tratar as system instructions e prompt templates do modelo como artefatos altamente sensíveis e criptograficamente atestados.

Pilar 4 — Application & Runtime

Agentes operam interativamente — firewalls rules-based tradicionais são insuficientes. Deployamos LLM firewalls para filtragem dinâmica de prompt e resposta, junto com "hooks" determinísticos que rodam em pontos específicos do lifecycle (antes de uma tool call, depois de uma file edit). Centralised Agent Gateways atuam como os "bouncers do ecossistema", governando orquestração Agent-to-Agent (A2A) para prevenir movimento lateral não autorizado.

Pilar 5 — Identity & Access Management

O risco principal é o "Confused Deputy": um agente com privilégios excessivos é enganado para executar comandos não autorizados. Resolvemos atribuindo identidades criptográficas únicas (SPIFFE IDs) a cada agente. Acesso depende de Attribute-Based Access Control (ABAC) e Just-In-Time (JIT) token downscoping, aplicando uma matriz de permissões estrita de Intent × User × Time — agentes recebem credenciais fresh e hiper-restritas que expiram imediatamente após a conclusão da tarefa.

Pilar 6 — Observability & Security Ops

SecOps deve combater "invisible failures" onde um agente cascateia silenciosamente em loop infinito de raciocínio. Sem observabilidade — logs, traces e metering — não há como saber se um agente está indo bem ou derivando silenciosamente. Resolvemos deployando uma tríade SecOps autônoma: o Blue Team utiliza OpenTelemetry e Agent Behavioural Analytics (ABA), o Red Team simula proativamente ataques multi-hop, e o Green Team executa "Stateful Quarantines" se uma anomalia é detectada.

Pilar 7 — Governance

Governance Officers devem garantir que decisões autônomas atendam padrões regulatórios rigorosos. Além de frameworks tradicionais de dados, governança deve agora aderir estritamente ao EU AI Act, mandando Algorithmic Impact Assessments para agentes autônomos de alto risco. Organizações devem criar um audit trail imutável que atribui estritamente cada ação do mundo real a um agente específico e ao humano que o deployou ou aprovou. Substituímos botões simples de aprovação por "Logic Reviews" obrigatórios (traduzindo sintaxe complexa para linguagem simples) e utilizamos Risk-Stratified Attestation para vincular assinaturas digitais aos outputs do agente.

O mecanismo central do vibe coding depende de traduzir dinamicamente intenção humana em lógica executável on the fly. Porém, agentes vibe-coded raramente escrevem código perfeito na primeira tentativa. A realidade do desenvolvimento orientado por intenção é um ciclo iterativo de alta velocidade: o agente escreve um script, executa, lê os error logs resultantes e reescreve autonomamente a lógica até alinhar com o "vibe" do usuário. Como esse processo generativo introduz alta variabilidade, o código resultante não pode ser implicitamente confiado. Rodar esses scripts gerados dinamicamente diretamente junto com o agente raiz ou na infraestrutura host padrão introduz um nível inaceitável de risco.

Geração de código agêntica introduz uma vulnerabilidade de supply chain altamente específica e perigosa: LLMs frequentemente alucinam pacotes de software que não existem. Atores maliciosos monitoram ativamente fóruns de desenvolvedores e outputs de IA para essas alucinações, publicando proativamente malware sob esses nomes exatos e falsos. Como agentes autônomos podem alterar dependency graphs sem confirmação humana, uma única alucinação pode puxar malware diretamente para o ambiente de build.

Enquanto isolamento kernel-level protege a infraestrutura host, organizações também devem proteger o limite de rede. Em software tradicional, tráfego de saída é altamente previsível. Em sistemas vibe-coded, egresso é não-determinístico porque é dirigido pelo uso dinâmico de ferramentas recém-geradas. Um failure mode comum: o agente tenta inadvertidamente pushar código não verificado para ambientes live ou exfiltrar dados sensíveis. Porém, confiar numa simples allowlist de domínios aprovados é insuficiente — uma allowlist não pode proteger um agente contra prompt injections indiretos escondidos em páginas web de terceiros.

Para mitigar esse risco, agentes devem ser restritos a acesso à internet não-interativo. Administradores devem forçar o agente a buscar informação externa exclusivamente por caches offline ou serviços de web-crawling dedicados e pré-sanitizados. Forçando todos os dados a viajar estritamente por caminhos governados, organizações previnem o agente de interagir diretamente com payloads maliciosos ou baixar inadvertidamente pacotes typosquatted.

Um sandbox perfeito não previne um agente de escrever código fundamentalmente falho ou conectar a uma ferramenta interna maliciosa. Vibe coding inerentemente prioriza funcionalidade imediata sobre design seguro — as aplicações geradas frequentemente contêm falhas estruturais severas. Usuários frequentemente confiam implicitamente no código gerado simplesmente porque compila e roda sem erros, cegos para o fato de que a aplicação pode ter completamente bypassado controles de segurança padrão do backend.

Para capturar essas falhas estruturais, precisamos balancear velocidade do desenvolvedor com enforcement estrito de segurança. Tentar bloquear agressivamente prompts inseguros diretamente na IDE é facilmente bypassado e causa fricção excessiva. Em vez disso: "shift left" via Developer Advisory Linters na IDE (orientação em tempo real), enquanto o enforcement inegociável é empurrado para checks determinísticos no CI/CD pipeline. Integrar SAST (Static Application Security Testing) e SCA (Software Composition Analysis) no pipeline garante que toda lógica de aplicação gerada é deterministicamente escaneada para dependências vulneráveis e falhas estruturais antes de alcançar produção.

Uma vez que a lógica da aplicação vibe-coded é deployada, controles de segurança devem governar como o agente interage com sistemas externos. Agentes dependem cada vez mais de frameworks de coordenação de ferramentas, como o Model Context Protocol (MCP), que permitem descobrir e conectar a servidores externos ou internos enterprise em runtime.

Para proteger orquestração Agent-to-Tool e Agent-to-Agent (A2A), organizações devem deployar um LLM firewall de runtime na frente do agente ativo para interceptar dinamicamente prompt injections oportunistas. Além disso, um Centralised Agent Gateway deve avaliar Autorização Contextual — atuando como enforcer do fator de trust "Association", verificando dinamicamente se o pedido do agente de chamar uma ferramenta se alinha perfeitamente com a intenção original do desenvolvedor.

Ao rotear todas as invocações de ferramentas por um Centralised Agent Gateway, limitamos com sucesso a capacidade do agente de executar ações não autorizadas no pilar de runtime. Porém, a integridade dessas decisões depende em última instância de como verificamos o ator por trás do agente, gerenciamos credenciais sob pressão e estabelecemos controle humano sobre ações de alto risco. Isso desloca o limite de segurança da orquestração de aplicação para a verificação criptográfica de identidade e a mecânica de autorização humana.

Como desenvolvedores frequentemente usam linguagem natural vaga ou altamente abstraída para gerar código (por exemplo, "fix the backend routing"), os workflows agênticos resultantes são inerentemente amplos. Conceder a esses agentes autônomos identidades de serviço compartilhadas e de longa vida cria um vetor de ameaça interna incontrolável. Para proteger este pilar, organizações devem atribuir identidades criptográficas únicas (como SPIFFE IDs) a cada agente individual.

O Confused Deputy e Identidade Delegada vs. Agêntica

Mesmo com identidade única, um agente vibe-coded permanece altamente suscetível ao problema do Confused Deputy. Isso ocorre quando um prompt injection — como uma instrução maliciosa escondida dentro de um repositório open-source que um desenvolvedor colou sem saber na janela de contexto da IDE — engana um agente com privilégios excessivos para executar um comando não autorizado em nome do atacante.

Para resolver isso, um agente nunca deve ser o árbitro final de acesso. Uma identidade agêntica distinta e observável garante que suas permissões permaneçam estritamente vinculadas e sujeitas a audit logs granulares.

Zero Ambient Authority e JIT Downscoping

Construindo sobre isso, a arquitetura deve aplicar Zero Ambient Authority. Um agente executando um "vibe" nunca deve herdar os privilégios administrativos completos e ambientes do desenvolvedor. Em vez disso, o sistema depende de Just-In-Time (JIT) token downscoping.

Enquanto constraints automatizados de identidade lidam com a maioria das tarefas de rotina, ações de alto risco — como modificar databases de produção, executar transferências financeiras ou alterar configurações de IAM — requerem verificação explícita e não podem depender de simples botões "approve/deny". Como vibe coders frequentemente dependem da IA para escrever sintaxe complexa que podem não entender completamente (a falácia "It Works, Ship It"), portões de aprovação simples rapidamente causam confirmation fatigue, levando desenvolvedores a autorizar cegamente código que não compreendem.

Para combater isso, o sistema deve implementar elicitação estruturada e context-aware. O agente é forçado a solicitar ativamente confirmação baseada no contexto específico de uma ação de alto risco, que deve ser acompanhada por duas fronteiras de segurança distintas:

Mesmo com verificação de identidade perfeita e autorização humana granular, instruções maliciosas ainda podem passar pelas defesas iniciais. Quando desenvolvedores confiam cegamente em repositórios open-source ou puxam blocos massivos de contexto não estruturado, convidam ataques semânticos sofisticados que bypassam controles IAM padrão. Para detectar e neutralizar proativamente essas ameaças ocultas à medida que o código é gerado, as operações de segurança devem evoluir para corresponder à velocidade exata do workflow agêntico.

Num ambiente vibe-coded, lógica de aplicação é gerada, executada e descartada a uma velocidade sem precedentes. Como a superfície de ataque é não-determinística e dirigida por linguagem natural, operações de segurança manuais tradicionais simplesmente não escalam. Para proteger sistemas autônomos, as próprias operações de segurança devem se tornar agênticas, exigindo o deploy de uma tríade contínua de Red, Blue e Green teaming rodando em paralelo com o workflow do desenvolvedor.

Invisible Payloads e Repository Poisoning

Antes de deployar operações defensivas, precisamos entender a natureza furtiva das ameaças agênticas. Repositórios atuam como um vetor de ataque altamente eficaz. Atores de ameaça podem comprometer repositórios inserindo caracteres Unicode zero-width ou homóglifos diretamente no codebase. A Knostic alerta que esses "invisible payloads hide in plain sight and bypass human review". Como agentes manipulam e replicam código muito mais rápido que um desenvolvedor humano, um único payload oculto pode "spread across hundreds of files in minutes" antes que alguém perceba.

Para prevenir agentes de gerar modificações massivas e não revisáveis de código durante este processo, desenvolvedores devem restringir o output do agente a small batch sizes. Isso é idealmente alcançado usando um loop test-driven onde o sistema bloqueia o agente de modificar testes e código de implementação simultaneamente, garantindo que o teste permaneça como baseline objetivo.

Com esses constraints em vigor, a tríade Red, Blue e Green adapta dinamicamente o comportamento do agente primário em runtime em três fases distintas:

Para garantir que esses mecanismos de defesa automatizados possam intervir com sucesso, a tríade de segurança requer uma visão granular e sem impedimentos no raciocínio interno do agente. Uma operação de segurança agêntica é inteiramente cega se olha apenas para o output final de código. Precisamos deslocar o foco de observar a infraestrutura host para observar a "mente" do agente, criando um audit trail imutável que mapeia exatamente como uma intenção difusa se traduz em uma ação no mundo real.

Para proteger e avaliar efetivamente um agente vibe-coded, precisamos reconhecer uma regra fundamental: you cannot secure what you cannot see. Em microservices tradicionais, um status HTTP 200 OK indica operação bem-sucedida. Porém, num sistema agêntico, um status "success" pode meramente mascarar um cenário onde a lógica interna do agente cascateou silenciosamente em um loop de alucinação. Isso introduz o risco crítico de ataques de Denial of Wallet (DoW), onde adversários disparam intencionalmente loops de API infinitos e computacionalmente caros para falir deliberadamente as contas de billing de cloud e LLM da organização.

Observabilidade não é mais meramente uma preocupação operacional de uptime e latência; é um requisito estrito de segurança para iluminar o "glass box" da lógica não-determinística.

Tracing the "Vibe Trajectory" e Content Scanning

Para responder à pergunta crítica "Why did an agent do that?", times de segurança devem construir uma lente cronológica unificada para ver os passos cognitivos do agente. Utilizando frameworks de telemetria padrão como OpenTelemetry, enterprises podem agregar sinais diversos — API calls, tool inputs/outputs, RAG retrievals e token latency — numa Vibe Trajectory completa.

Rastrear essa trajetória requer logar o salto cognitivo massivo do prompt inicial do usuário até a Abstract Syntax Tree (AST) compilada. Para fortificar esse trace, organizações devem parear logging tradicional com Centralised Content Scanning, explicitamente desenhado para inspecionar todos os snippets de código dinâmicos ou scripts recuperados pelo agente em runtime. Esse trace vincula com segurança o loop de raciocínio interno do agente às suas ações físicas, suportando auditorias de segurança rigorosas de terceiros.

Measuring Intent Drift e Trust Decay

À medida que um agente vibe-coded gera dinamicamente lógica e puxa novas ferramentas, seu perímetro de segurança flutua constantemente, tornando inventários estáticos de ativos (SBOMs) instantaneamente obsoletos. Em vez disso, plataformas de observabilidade devem monitorar um Runtime Agent Bill of Materials (AgBOM) — um documento vivo que mapeia o blast radius ativo do agente a cada milissegundo.

Como trust num sistema autônomo é um ativo degradável, a arquitetura monitora continuamente por Intent Drift. O princípio de Trust Decay dita que confiança se perde quando a cadeia de pensamento interna do agente persegue sub-objetivos que divergem do "vibe" humano original. Por exemplo, um prompt simples para "optimize the database query" pode derivar maliciosamente para o agente tentar baixar uma nova biblioteca de indexação não autorizada.

Checkpoints e Stateful Circuit Breakers

Para prevenir ações destrutivas quando esse drift ocorre, o pilar de observabilidade deve gerenciar proativamente o estado. Antes de um agente executar qualquer modificação de codebase, o sistema deve gerar um version control checkpoint.

Para desenvolvedores operacionalizando esses conceitos, proteger uma arquitetura vibe-coded depende de abandonar confiança implícita e implementar o seguinte baseline prático:

Implementar esses controles de segurança ajuda nossos agentes vibe-coded a operar com segurança dentro de um perímetro seguro e bem governado. Porém, um agente seguro não é inerentemente um agente eficaz. Segurança garante que o agente não fez nada malicioso ou não autorizado — mas como provamos definitivamente que ele realmente alcançou a intenção nuançada do usuário?

Para verdadeiramente operacionalizar esses agentes, precisamos ir além de proteger o perímetro e abrir o "glass box" para medir a qualidade, eficiência e alinhamento do raciocínio interno. Isso nos traz à próxima fase crucial do pipeline: Agent Evaluation.

As seções anteriores cobriram os controles de segurança que restringem o que um agente vibe-coded pode fazer. Esses controles não respondem à pergunta que o desenvolvedor realmente tem: o agente construiu o que eu pedi, e é bom? Um agente vibe-coded pode passar em todos os checks de segurança e ainda assim ler mal a intenção do desenvolvedor, ignorar as convenções do projeto ou quebrar uma feature não relacionada.

As seções seguintes são estruturadas em torno de três perguntas: por que a avaliação de vibe coding é diferente de avaliar outro software, o que avaliar e como avaliar. Duas áreas ficam deliberadamente fora do escopo deste framework, ambas merecendo tratamento dedicado: avaliação subjetiva de outputs não-verificáveis, onde qualidade é definida por preferências do usuário ou da empresa em vez de ground truth; e o feedback loop de correções do usuário de volta para o modelo, o harness ou o eval suite para impulsionar melhoria.

Figura 2 · O framework de avaliação de agentes de vibe coding

Avaliar agentes vibe coding não é o mesmo problema que avaliar software determinístico, e também não é o mesmo problema que avaliar um agente de customer-service ou um agente de pesquisa. Três coisas o tornam único:

Esses três constraints moldam cada dimensão, método e dica que segue.

A avaliação de agentes vibe coding se divide em sete dimensões, em dois grupos. Dimensões user-facing são o que o desenvolvedor experimenta diretamente. Dimensões internal descrevem o que o agente faz invisivelmente ao usuário. Além disso, Safety e Responsible AI é transversal — intersecta múltiplas dimensões (vulnerabilidades de código, comportamento de recusa, segurança de conteúdo, exposição de IP) e deve ser avaliada junto com cada uma delas.

👤 Dimensões User-Facing

🧠 Dimensões Internal

Figura 3 · Dimensões de avaliação para agentes de vibe coding

As sete dimensões não são todas mensuráveis da mesma forma. Nenhum método único cobre tudo, então pipelines de produção combinam vários. A matriz abaixo resume os métodos de avaliação e as dimensões recomendadas para cada um; o restante da seção descreve cada um em detalhe.

Figura 4 · Métodos de avaliação e dimensões recomendadas

Enquanto frameworks de avaliação customizados lidam com a natureza aberta do vibe coding, testes padronizados isolam capacidades cognitivas específicas do ruído de ambientes enterprise customizados. Eles fornecem o baseline empírico necessário para confiar num sistema não-determinístico.

Kaggle Agent Exams (SAE) e Avaliação Zero-Setup

Endereçando o fardo historicamente pesado de infraestrutura necessário para rodar esses benchmarks, os Kaggle Standardised Agent Exams (SAE) representam uma mudança massiva em direção à avaliação autônoma "zero-setup". Deployado como uma integração de API leve via um arquivo SKILL.md, o SAE permite que um agente se registre autonomamente no Kaggle, busque questões de prova, execute a lógica multi-step dentro do seu próprio ambiente sandboxado e publique instantaneamente sua pontuação num leaderboard público ao vivo. Atua como um teste rigoroso e sem fricção do raciocínio multi-hop do agente e da segurança adversarial sob pressão.

Para avaliar o raciocínio interno de um agente, desenvolvedores precisam possuir a capacidade de vê-lo. Observabilidade é o pré-requisito absoluto para avaliação Glass Box; sem ela, falhas do agente aparecem como eventos monolíticos inexplicáveis.

Vibe coding não tem spec para testar — a intenção do usuário é não declarada e evolui entre turnos. O mais próximo de uma spec são as primeiras uma ou duas mensagens do usuário. Trate-as como rubric: derive critérios de avaliação automaticamente do session prefix, depois pontue cada turno subsequente contra eles. Esta é a única forma prática de avaliar a dimensão 1 (intent satisfaction) em escala.

from google import genai

client = genai.Client(vertexai=True, project="...", location="us-central1")

# Derive criteria from the user's opening turns
opening = " ".join(session.user_messages[:2])
criteria = client.models.generate_content(
    model="gemini-3-pro",
    contents=f"Produce 3-5 acceptance criteria for: {opening}. Return JSON.",
).parsed["criteria"]

# Score every agent turn against the derived criteria
score = client.models.generate_content(
    model="gemini-3-pro",
    contents=f"Does this output satisfy {criteria}? Score 1-5 with rationale."
             f"Output: {agent_response}",
).parsed

Em vibe coding o usuário julga o output, não o diff. Um modelo multimodal olhando a página renderizada captura problemas que avaliação de nível de código perde completamente: layout quebrado no mobile, contraste muito baixo para acessibilidade, estados de botão errados. Combine isso com asserções Playwright — o judge captura problemas visuais e de design, as asserções capturam interatividade quebrada.

from google import genai
from google.genai import types

client = genai.Client(vertexai=True, project="...", location="...")

result = client.models.generate_content(
    model="gemini-3-pro",
    contents=[
        "Score this rendered web app against the spec on layout_match, styling, "
        "and interactive_correctness (1-5 each). Return JSON.",
        user_spec,
        types.Part.from_bytes(data=screenshot_bytes, mime_type="image/png"),
    ],
)

Uma sessão de vibe coding é multi-turno por construção. A pergunta relevante não é "o turno 4 estava correto?" mas "o usuário convergiu para algo que queria?" Sessões que convergem em poucos turnos são os casos de sucesso. Sessões abandonadas no meio do fluxo são as falhas mais informativas — muito mais do que erros por turno. Cloud Trace expõe uma sessão de vibe coding, instrumentada via ADK e Agent Engine, como uma única árvore de trace.

from google.cloud import trace_v2

trace = trace_v2.TraceServiceClient().get_trace(
    name=f"projects/{project}/traces/{session_id}"
)

def session_outcome(trace):
    return {
        "converged":         trace.last_turn.user_signal == "satisfied",
        "turns_to_converge": trace.user_correction_count,
        "abandoned":         trace.last_user_action == "close",
        "cost_to_converge":  trace.total_token_cost_usd,
    }

Cada "não, não assim" do usuário é um exemplo de falha rotulado, e vibe coding produz isso em volume. Clusterize-os e as lacunas sistemáticas do agente se tornam visíveis — muito mais rápido do que construir um benchmark sintético de falhas.

from google import genai
from sklearn.cluster import KMeans

client = genai.Client(vertexai=True, project="...", location="...")

corrections = [t.user_message for trace in traces
               for t in trace.turns if t.is_correction]

emb = client.models.embed_content(
    model="text-embedding-005",
    contents=corrections,
)
vectors = [e.values for e in emb.embeddings]
clusters = KMeans(n_clusters=8).fit(vectors)
# Clusters.labels_ is the prioritized list of failure modes for the next iteration

A transição de sintaxe para intenção não é uma previsão futura; é a realidade imediata do desenvolvimento de software. Em 2026, os gargalos na criação de software mudaram fundamentalmente. Não estamos mais esperando mãos humanas digitarem boilerplate; estamos esperando mentes humanas definirem os limites, avaliarem os outputs e protegerem o ambiente de execução.

Migrar de vibe coding casual para agentic engineering disciplinado requer abandonar confiança implícita. Um modelo de IA bruto é meramente um motor; só se torna um agente enterprise-ready quando envolvido num harness robusto. Implementando a 7-Pillar Security Architecture — aplicando sandboxing estrito, ABAC contextual e teaming agêntico Red/Blue/Green — organizações podem conter com segurança o blast radius de ações autônomas.

Porém, segurança sozinha só prova que o agente não causou dano. Pareando esses controles de segurança com um Evaluation Framework rigoroso — medindo tudo de intent satisfaction e trajectory quality até visual correctness — líderes de engenharia podem provar com confiança que o agente realmente entregou valor.

Os times que prosperarão nesta nova era serão aqueles que abraçam a IA como um motor de implementação de alta velocidade, mantendo ao mesmo tempo a disciplina rigorosa necessária para produzir software com o qual o mundo pode realmente contar.

🎯 Teste seu entendimento

✅ Checklists de implementação

📋 Cheat sheets

# SECURE VIBE CODING — 5 COMMANDMENTS
1. SANDBOX THE VIBE LOOP
   → kernel-level, network-isolated sandboxes
   → SCA scan for hallucinated/vulnerable deps
2. SHIFT THE PERIMETER LEFT
   → trusted sources + verified internal registries
   → deterministic checks at multiple CI/CD points
3. ENFORCE ZERO AMBIENT AUTHORITY
   → delegated user identities + JIT hyper-restricted tokens
   → mandatory "Vibe Diff" for high-stakes actions
4. DEPLOY AGENTIC SECOPS
   → Virtual Red-Teaming Agents inject "Adversarial Vibes"
   → ABA monitors Runtime AgBOM + Green auto-refactors
5. TRACE THE EXECUTION TRAJECTORY
   → log API calls, tool inputs, reasoning steps
   → version-control checkpoints to revert on drift

# EVALUATION — 7 DIMENSIONS × 8 METHODS
DIMENSIONS  1 Intent satisfaction  2 Functional correctness
            3 Visual & behavioural  4 Cost & efficiency
            5 Code quality          6 Trajectory quality
            7 Self-repair           RAI Safety (transversal)
METHODS     benchmarks → 2,4    functional testing → 2,5
            security eval → RAI  LLM/Agent-judge → 1,5,6
            browser-based → 3    trajectory inspect → 6,7
            human review → 1,5,RAI  online eval → all

# DAY 4 — KEY TERMS
Effective Trust      continuous metric: supply chain + identity
                     + runtime behaviour + contextual associations
slopsquatting        malware published under hallucinated pkg names
Confused Deputy      over-privileged agent tricked by prompt injection
Zero Ambient Auth    agent never inherits dev's full privileges
Vibe Diff            plain-English translation before critical tool runs
AgBOM                Runtime Agent Bill of Materials (live blast radius)
Intent Drift         chain-of-thought diverges from original vibe
Trust Decay          trust is a degradable asset
DoW                  Denial of Wallet — bankrupt via infinite API loops
circuit breaker      auto rollback when Trust Score drops below threshold
underspecification   the prompt is not a spec — gap must be reconstructed
SAE                  Kaggle Standardised Agent Exams (zero-setup eval)

📚 Endnotes