💻 Para Técnicos — Vibe Coding Profissional e Agentic Engineering

Comparativo técnico entre os três principais ambientes de vibe coding profissional: Cursor (IDE baseado em VSCode com IA integrada), Windsurf (foco em agentic flows com Cascade), e Claude Code (terminal-first para automação e pipelines).

A escolha errada de IDE pode custar horas de produtividade. Cada ferramenta tem vantagens distintas para contextos específicos — usar Claude Code para refatoração de projetos grandes é muito mais eficiente do que usar Windsurf.

Cursor para projetos complexos com múltiplos arquivos; Windsurf para fluxos de criação rápida; Claude Code para automação em terminal, scripts e CI/CD. Combinação de ferramentas por tarefa.

Arquivos de configuração que definem regras persistentes de projeto lidas automaticamente pelo agente a cada sessão. O .cursorrules instrui o Cursor; o CLAUDE.md instrui o Claude Code. São a "memória de longo prazo" do agente sobre seu projeto.

Sem essas regras, cada sessão começa do zero — o agente não sabe qual framework usa, qual padrão de nomenclatura, quais arquivos não tocar. Com elas, a consistência do código gerado aumenta drasticamente.

Stack tecnológico, padrões de código, arquivos proibidos, comandos de teste, convenções de nomenclatura, segredos que nunca devem ser hardcodados. Manter o arquivo versionado no repositório.

Protocolo aberto criado pela Anthropic que permite conectar modelos de IA a fontes de dados externas: banco de dados, APIs, filesystem, ferramentas de observabilidade. É a ponte entre o agente e o ambiente real de produção.

MCP é o que transforma a IA de um assistente de texto em um agente que realmente opera no seu ambiente. Com MCP, o Claude Code pode fazer queries no Supabase, chamar sua API, verificar logs e muito mais.

Servidores MCP, ferramentas expostas, configuração no claude_desktop_config.json, MCP para Postgres, GitHub, filesystem e APIs customizadas. Segurança de acesso no MCP.

Estratégia de uso inteligente de diferentes modelos Claude (Opus, Sonnet, Haiku) baseada na complexidade e custo de cada tarefa. Não usar Opus para tarefas simples, nem Haiku para arquitetura crítica.

O custo de API pode inviabilizar o uso profissional se não houver estratégia. Times que usam Opus para tudo pagam 5-10x mais do que precisam. A roteagem inteligente de modelos é uma vantagem competitiva real.

Opus para decisões arquiteturais e análise complexa; Sonnet para implementação do dia a dia; Haiku para autocomplete e tasks repetitivas. Cálculo de custo por token em projetos reais.

Conjunto curado de extensões e integrações que maximizam a produtividade com IA: linters que o agente respeita, formatadores automáticos, controle de versão integrado e ferramentas de observabilidade.

O agente gera código de acordo com o ambiente configurado. Sem ESLint configurado, o código gerado ignora padrões. Com prettier integrado, o código já sai formatado sem intervenção manual.

ESLint + Prettier, GitLens, Error Lens, REST Client, extensões de segurança (Snyk), e configuração de hooks pre-commit que o agente respeita no fluxo de trabalho.

Técnica de fornecer contexto preciso ao agente usando referências explícitas a arquivos e pastas (@arquivo.ts, @src/components) em vez de descrições vagas. O agente lê o código real em vez de inferir o que existe.

Alucinações de código quase sempre acontecem quando o agente não tem acesso ao contexto real. Referenciar explicitamente os arquivos certos reduz erros e retrabalho em 60-70% em projetos complexos.

Sintaxe @file no Cursor, -f no Claude Code, contexto mínimo viável, quando incluir e quando excluir arquivos do contexto, evitar context overflow em projetos grandes.

Processo de medir objetivamente onde a IA aumenta e onde reduz produtividade em seu contexto específico. Inclui tracking de tempo, taxa de aceitação de sugestões e qualidade do código gerado vs. manual.

A IA não ajuda igualmente em todas as tarefas. Em código altamente otimizado para performance ou em sistemas de segurança críticos, a revisão manual adiciona overhead que pode superar o ganho. Dados orientam decisões melhores.

Métricas de aceitação de sugestões, tempo de ciclo antes/depois, taxa de bugs em código gerado vs. manual, ROI por tipo de tarefa e por desenvolvedor. Dashboard de produtividade com IA.

Técnica de prompting que instrui o modelo a raciocinar explicitamente antes de gerar código. Em vez de pedir diretamente a solução, você pede ao modelo para analisar o problema, identificar casos extremos e planejar a implementação antes de escrever qualquer linha.

Em problemas complexos, modelos que "pensam em voz alta" produzem código 40-60% mais correto na primeira tentativa. Chain-of-Thought é especialmente eficaz para algoritmos, lógica de negócio complexa e refatorações de grande escala.

Frases ativadoras ("Antes de implementar, analise..."), scratchpad explícito, decomposição de problemas em etapas rastreáveis, revisão do raciocínio antes da implementação.

Abordagem em dois estágios: primeiro pede ao modelo para descrever em pseudocódigo ou texto estruturado o que vai implementar, depois aprova o plano e solicita a implementação real. Separa planejamento de execução.

Corrigir a lógica em pseudocódigo leva 30 segundos; corrigir uma implementação errada pode levar horas. Para tarefas que envolvem múltiplos sistemas ou lógica de negócio crítica, esta técnica evita retrabalho custoso.

Checkpoint de aprovação antes da implementação, revisão de lógica em linguagem natural, identificação de casos extremos no estágio de planejamento, ajuste fino do plano antes do código.

Princípio de escrever prompts que descrevem o que o sistema deve fazer (comportamento observável) em vez de como implementar (método específico). "O usuário deve conseguir fazer X" em vez de "use o método Y da classe Z".

Especificar a implementação limita o agente a soluções subótimas e cria dívida técnica. Especificar o comportamento permite que o modelo escolha a implementação mais adequada ao contexto do projeto.

User stories como base de prompts, critérios de aceitação mensuráveis, comportamento em casos de erro, independência de implementação, alinhamento com testes de aceitação.

Prompts estruturados para agentes autônomos que incluem: objetivo claro, Definition of Done explícito, restrições e permissões, e checkpoint de validação. Diferente do prompting conversacional, o agente executa múltiplas etapas sem intervenção.

Agentes sem Definition of Done claro continuam trabalhando indefinidamente ou param antes do objetivo. Um DoD preciso define quando o agente deve parar e apresentar resultados para revisão humana.

Estrutura Objetivo + Contexto + Restrições + DoD, checkpoints de aprovação, rollback points, escopo de permissões (pode criar arquivos? pode fazer deploy?), confirmação antes de ações destrutivas.

Método sistemático de quebrar requisitos de sistemas complexos em subtarefas independentes e bem definidas que o agente pode executar com alta qualidade. Cada subtarefa tem contexto próprio e critério de conclusão claro.

Pedir ao agente para "construir um sistema de pagamentos completo" falha. Pedir para "implementar a validação de cartão de crédito com Luhn algorithm e testes unitários" tem 95% de chance de sucesso. Granularidade correta é tudo.

Work Breakdown Structure para agentes, dependências entre subtarefas, ordem de implementação (infraestrutura antes de features), integração incremental, evitar tasks com mais de 500 linhas de código esperado.

Técnica de solicitar refatoração de código existente especificando o objetivo de melhoria (legibilidade, performance, testabilidade) enquanto define explicitamente o que não deve mudar (interface pública, comportamento externo, compatibilidade).

Refactoring sem restrições claras frequentemente quebra funcionalidade. Definir invariantes (o que não pode mudar) e objetivos (o que deve melhorar) resulta em refatorações seguras e úteis.

Invariantes de comportamento, contratos de interface, métricas de melhoria (reduzir complexidade ciclomática, melhorar cobertura de testes), refactoring incremental vs. big-bang.

Estrutura de prompt para debugging que inclui: stack trace completo, código relevante, ambiente (versão, dependências), o que já foi tentado e o comportamento esperado vs. observado. Elimina o vai-e-volta de perguntas do agente.

Enviar apenas "meu código está quebrando" resulta em 5-10 trocas de mensagem antes de chegar na solução. Enviar o contexto correto na primeira mensagem resolve o problema em uma única resposta na maioria dos casos.

Template: Erro + Stack Trace + Código Relevante + Ambiente + O que tentou + Comportamento esperado. Reprodução mínima do problema, isolamento da causa raiz antes de enviar.

Efeito patchwork é quando cada sessão de vibe coding adiciona código que funciona isoladamente mas não se integra coerentemente. O resultado é um sistema que cresce mas fica progressivamente mais difícil de manter — com três padrões de erro diferentes, nomenclatura inconsistente e lógica de negócio duplicada.

Sem visão arquitetural persistente, todo projeto de vibe coding vira patchwork em semanas. Definir a arquitetura no .cursorrules ou CLAUDE.md garante que cada sessão respeite o padrão global, mesmo que o agente não veja o projeto inteiro.

Sinais de patchwork: padrões de erro inconsistentes, lógica duplicada, nomenclatura caótica (userId vs user_id vs userID), SQL raw misturado com ORM. Solução: visão arquitetural no .cursorrules/CLAUDE.md lida automaticamente em cada sessão.

Técnica de declarar explicitamente a arquitetura MVC (Model-View-Controller) e separação em camadas no arquivo de regras persistentes. Sem instrução explícita, a IA mistura camadas — lógica de negócio em controllers, queries diretas em services, validação espalhada por todo o código.

A IA tende a misturar camadas sem instrução explícita, resultando em código testável apenas com servidor rodando. Declarar Routes → Controllers → Services → Repositories no .cursorrules garante separação correta em cada sessão, sem precisar repetir a instrução.

Routes: apenas parsing + chamada de controller. Controllers: coordena serviços, monta response. Services: TODA lógica de negócio. Repositories: TODA interação com banco. Regra de dependência: Routes → Controllers → Services → Repositories. NUNCA pular camadas.

Uso de LLMs para modelagem de domínio: o modelo identifica entidades, agregados, value objects e bounded contexts a partir de descrições de regras de negócio. A IA é excelente nisso quando recebe o contexto de negócio correto — mas as decisões finais de bounded contexts e trade-offs permanecem com o engenheiro.

Modelagem de domínio é uma das tarefas mais demoradas em novos projetos. Com o prompt correto, a IA pode gerar um modelo inicial de entidades, relacionamentos e invariantes em minutos — acelerando discussões arquiteturais e reduzindo erros de modelagem precoce.

Entidades e atributos, agregados e raízes de agregado, value objects, bounded contexts. Onde a IA ajuda: identificar entidades óbvias, sugerir relacionamentos, gerar schemas. Onde você decide: bounded contexts, trade-offs de normalização, consistência eventual vs. imediata.

Processo de usar IA para gerar schemas de banco de dados completos e corretos desde o início — incluindo índices, soft delete, timestamps de auditoria e suporte a Row Level Security. O schema é a decisão mais difícil de reverter em qualquer projeto e nunca deve ser gerado sem revisão humana.

Um schema incorreto impacta performance, integridade de dados e segurança por toda a vida do projeto. Investir tempo na modelagem correta antes de qualquer linha de código de aplicação economiza semanas de refatoração futura.

Schema Prisma multi-tenant, soft delete em todas as tabelas principais, timestamps de auditoria (created_at, updated_at), suporte a RLS para Supabase, índices para queries comuns. Schema Review obrigatório antes de aplicar em produção.

Princípio e prática de implementar autenticação antes de qualquer feature de produto. Autenticação é infraestrutura, não feature — adicioná-la depois exige refatorar cada rota, endpoint e potencialmente o schema inteiro. A ordem correta: schema com user_id → autenticação → middleware → features.

O erro arquitetural mais comum em vibe coding: construir features sem auth e tentar adicionar depois. O custo de refatoração cresce exponencialmente com o tamanho do projeto. Implementar auth primeiro custa horas; refatorar depois custa dias ou semanas.

MVP simples: Supabase Auth (magic link/OAuth). API própria: JWT stateless com refresh tokens. Enterprise/Compliance: OAuth 2.0 + PKCE. Multi-tenant: RLS no banco + contexto de tenant no token. Middleware de auth protege todas as rotas antes de qualquer feature.

Processo de tomar decisões de escalabilidade explicitamente antes de iniciar a implementação — banco SQL vs. NoSQL, monolito vs. microserviços, estratégia de cache. A IA gera soluções que funcionam para o caso atual sem considerar crescimento, a menos que você forneça esse contexto explicitamente.

Decisões de escalabilidade incorretas são as mais caras de reverter. A IA escolherá SQL e monolito por padrão — o que é correto em 80% dos casos. Mas sem instrução explícita, também não adiciona cache, não considera sharding e não pensa em separação de serviços para escala.

SQL (Postgres) por padrão — correto em 80% dos casos. Monolito bem estruturado antes de microserviços. Redis para sessões e cache de alta frequência. CDN para assets estáticos. Instrua a IA no CLAUDE.md sobre a estratégia de cache do projeto.

Architecture Decision Records (ADRs) são documentos curtos que registram decisões arquiteturais importantes, o contexto que as motivou e as alternativas consideradas. A IA é excelente em gerar ADRs quando você fornece o contexto da decisão — e ADRs são essenciais para manutenção de longo prazo.

Sem ADRs, decisões arquiteturais importantes se perdem com o tempo. Ninguém sabe por que foi escolhido o Supabase em vez de uma API própria, ou por que o projeto usa monolito em vez de microserviços. ADRs gerados pela IA enquanto as decisões são tomadas eliminam esse problema com custo mínimo.

Formato ADR: Status, Contexto, Decisão, Consequências, Alternativas. Salvar em docs/decisions/ no repositório. Gerar ADR com prompt fornecendo: decisão tomada, contexto do projeto, alternativas consideradas. ADRs versionados explicam "por que" para futuras manutenções.

Análise dos dados de pesquisa que quantificam o risco de segurança em código gerado por IA: 45% do código contém pelo menos uma falha (Veracode 2025), 2,74x mais vulnerabilidades vs. código humano (CodeRabbit 2025), 40% dos devs não revisam o código antes de commitar (Stack Overflow 2025).

Entender a escala do problema com dados concretos muda a postura de revisão. A IA não tem intenção maliciosa — ela reproduz padrões de código inseguro dos dados de treinamento (tutoriais online frequentemente não validam input). O modelo otimiza para "funcionar", não para "funcionar com segurança".

Pesquisa Veracode 2025, CodeRabbit 2025, Stack Overflow Survey 2025. 78% das vulnerabilidades em código de IA são OWASP Top 10. 16/18 CTOs reportaram problemas sérios com vibe coding não supervisionado. Revisão de código de IA não é opcional.

As vulnerabilidades mais críticas geradas por IA são categorizadas no OWASP Top 10. As mais frequentes: SQL Injection (IA gera queries concatenadas sem instrução), XSS (innerHTML com dados de usuário), e BOLA/Broken Object Level Authorization (endpoint sem verificação de ownership).

A IA cria todas as vulnerabilidades OWASP, mas as mais frequentes têm padrões identificáveis que você pode prevenir com instruções específicas no CLAUDE.md. Uma linha de instrução pode prevenir toda uma categoria de vulnerabilidade em todas as sessões futuras.

SQL Injection: usar ORM parametrizado (Prisma) — nunca SQL raw com input do usuário. XSS: textContent em vez de innerHTML. BOLA: sempre verificar req.user.id ao acessar dados. Instrução no CLAUDE.md: "SEMPRE verificar ownership, NUNCA confiar em parâmetros de URL sem validação".

Row Level Security (RLS) é uma funcionalidade do PostgreSQL/Supabase que garante que usuários só acessam seus próprios dados no nível do banco de dados, independente do que a aplicação faça. É a última linha de defesa e a mais frequentemente esquecida em vibe coding — um app Lovable expôs 18.000 usuários por falta de RLS.

Mesmo que a aplicação tenha bugs de autorização, RLS garante que o banco não retorne dados de outros usuários. O incidente dos 18K usuários no Lovable (2025) foi causado exatamente por ausência de RLS — prevenível com 3 linhas de SQL e uma instrução no CLAUDE.md.

ALTER TABLE ... ENABLE ROW LEVEL SECURITY. CREATE POLICY "users_own_data" USING (auth.uid() = user_id). Política para admins separada. Instrução no CLAUDE.md: "SEMPRE criar políticas RLS ao criar novas tabelas no Supabase. Nunca criar tabela sem RLS habilitado."

Prática de nunca hardcodar credenciais, API keys ou senhas no código — sempre usando variáveis de ambiente. A IA aprende de exemplos online onde credenciais frequentemente aparecem hardcodadas para simplificação educacional. Sem instrução explícita, o agente reproduz esse padrão inseguro.

Secrets hardcodados commitados no repositório são um dos erros mais comuns e devastadores. GitHub Secret Scanning detecta e alerta, mas a rotação do secret é imediata e obrigatória. Uma instrução no CLAUDE.md previne esse erro em 100% das sessões futuras.

.env no .gitignore (sempre, sem exceção). .env.example com chaves vazias no repositório. process.env.STRIPE_SECRET_KEY em vez de string hardcodada. git-secrets ou trufflehog para scan automático. GitHub Secret Scanning habilitado. Rotacionar imediatamente se secret foi commitado.

SAST (Static Application Security Testing) analisa o código sem executá-lo, detectando vulnerabilidades antes do deploy. Em vibe coding, SAST deve rodar automaticamente em cada commit ou PR — não manualmente depois. Ferramentas: CodeQL (GitHub nativo, gratuito), Semgrep (regras customizáveis), Snyk (dependências).

Segurança manual pós-deploy é cara e inconsistente. SAST automático no CI/CD transforma segurança de uma revisão pontual para um processo contínuo — cada linha de código gerado por IA passa por análise de segurança antes de entrar no repositório.

CodeQL: GitHub Actions nativo, detecta vulnerabilidades complexas de múltiplos arquivos. Semgrep: regras customizáveis p/security-audit p/secrets p/owasp-top-ten. Bandit: Python. ESLint Security Plugin: JavaScript/TypeScript. Snyk: dependências com CVEs conhecidas. Rodar em cada PR, não apenas no main.

Checklist estruturado para revisão humana de código de IA focado em segurança: autenticação e autorização, validação de input/output, gestão de secrets e dependências. SAST detecta padrões conhecidos, mas o humano detecta falhas de lógica de autorização que tecnicamente compilam mas semanticamente estão erradas.

SAST não detecta: verificação de ownership incorreta (acessa dados de outro usuário mas o código é sintaticamente correto), RLS ausente, regras de negócio de segurança implícitas, erros de lógica de autorização por papel. Code review humano é a segunda linha de defesa insubstituível.

Checklist: todas as rotas privadas têm middleware de auth? Verificação de ownership em todos os recursos? Todo input validado com schema (Zod)? Queries usam ORM ou parâmetros? Nenhum secret hardcodado? RLS configurado? Dependências auditadas com npm audit?

Análise detalhada de incidentes reais documentados em plataformas de vibe coding: Lovable (18.000 usuários expostos por falta de RLS), CurXecute CVE-2025-54135 (prompt injection executava código no sistema do dev), Replit (banco de produção deletado por instrução ambígua), Base44 (qualquer usuário exportava dados de qualquer empresa).

Estudar casos reais é a forma mais eficaz de internalizar a importância de segurança. Todos esses incidentes eram preveníveis com as técnicas do módulo — RLS obrigatório, verificação de ownership, ambientes separados, confirmação antes de operações destrutivas.

Lovable: RLS não configurado por padrão → dados de 18K usuários expostos. CurXecute: plugin de IDE com prompt injection → execução de código arbitrário. Replit: "limpe dados de teste" → DELETE sem WHERE em produção. Base44: BOLA em exportação de relatórios → qualquer empresa acessível. Todos preveníveis.

A relação direta entre cobertura de testes e capacidade de usar IA com segurança: quanto mais testes, mais seguramente o agente opera autonomamente. Com suite robusta, o agente pode refatorar, otimizar e adicionar features com confiança — qualquer regressão é detectada imediatamente. Dados: 67% redução em regressões, 4x aprovação de PRs mais rápida.

Sem testes, cada mudança do agente é um salto no escuro. Com testes, cada mudança tem feedback objetivo imediato. Testes bem escritos também são especificação — descrevem exatamente o comportamento esperado, o que permite ao agente implementar corretamente e verificar sua própria implementação.

67% redução em regressões com suite robusta (Devin 2025). 4x mais rápido para aprovar PRs com >80% cobertura. 90% dos bugs introduzidos por IA detectados por testes antes do deploy. Testes como especificação: descrevem comportamento esperado antes da implementação.

A IA é excepcionalmente boa em gerar testes unitários — especialmente para identificar e cobrir edge cases que humanos frequentemente esquecem. Com o prompt correto, você obtém uma suite completa incluindo casos extremos em minutos: desconto 0%, desconto >100%, preço negativo, tipos incorretos.

Sem instrução explícita, a IA gera apenas testes para o "happy path". Pedir explicitamente edge cases — inputs inválidos, zeros, negativos, máximos possíveis — resulta em cobertura que normalmente leva horas para escrever manualmente, gerada em segundos.

Prompt: referenciar @arquivo a testar, listar casos felizes e edge cases explicitamente, especificar framework (Vitest vs Jest), pedir describe blocks por categoria. Sempre incluir: inputs inválidos (null, undefined, string em vez de number), valores extremos (0, negativo, máximo), tipos incorretos.

Testes que verificam que componentes funcionam corretamente quando conectados. Em APIs REST, significa testar endpoints reais com banco de dados real (ou banco de testes). A IA gera testes de integração de forma eficaz quando você fornece o contrato esperado da API — status codes, estrutura do response, efeitos colaterais no banco.

Testes unitários verificam funções isoladas; testes de integração verificam que o sistema como um todo funciona. Um sistema pode ter 100% de cobertura unitária e ainda falhar em integração por problemas de configuração, autenticação ou interação com banco.

Setup/teardown com banco de teste limpo. Testar: 201 com payload válido + verificação no banco, 401 sem autenticação, 422 com payload inválido. Verificar efeitos colaterais: a entidade foi criada no banco com o userId correto? Supertest para Node.js, banco de teste separado do desenvolvimento.

Testes End-to-End verificam fluxos completos do ponto de vista do usuário — clicando em botões, preenchendo formulários, navegando entre páginas. A IA pode gerar testes Playwright ou Cypress a partir de descrições de comportamento em linguagem natural, usando seletores data-testid para estabilidade.

Testes E2E são os mais caros de escrever manualmente e os mais valiosos — verificam o que o usuário realmente experimenta. A IA pode gerar suites completas de Playwright/Cypress a partir de descrições de fluxo em minutos, economizando horas de trabalho manual.

Seletores data-testid: estáveis, não dependem de CSS ou texto que muda. Instrução no CLAUDE.md: "Todo componente de UI deve ter data-testid". Setup: criar usuário de teste e fazer login. Teardown: limpar dados criados. Timeout para operações de rede. Playwright tem suporte nativo a componentes React/Vue/Svelte.

Técnica de pedir à IA para escrever os testes que definem o comportamento esperado antes da implementação, depois pedir para implementar o código que faz os testes passarem. Passo 1: "escreva os testes para validatePassword — NÃO implemente a função". Passo 2: "implemente para que os testes em @arquivo.test.ts passem".

Testes como especificação eliminam ambiguidades antes da implementação. O agente sabe exatamente quando terminou (testes passando). Ambiguidades são descobertas na fase de testes, não de implementação — quando corrigir custa 30 segundos em vez de horas de refatoração.

Separação de fases: testes primeiro (sem implementação), implementação depois (referenciando o arquivo de testes). Vantagens: especificação precisa antes do código, verificação automática de conclusão, 100% de cobertura dos comportamentos documentados, menos retrabalho por ambiguidades descobertas tarde.

Métricas de cobertura de código (linhas, branches, funções) e como atingi-las com IA. 80% é o threshold mínimo profissional — abaixo disso, o agente opera em território desconhecido onde pode introduzir regressões sem detecção. Configuração de thresholds no CI para falhar automaticamente se a cobertura cair.

Cobertura baixa significa que o agente pode fazer mudanças em código não coberto sem qualquer sinal de falha. Com thresholds configurados no CI, cobertura insuficiente bloqueia o merge — forçando a geração de testes antes de qualquer código novo entrar no repositório.

Vitest config: thresholds lines/functions/statements: 80, branches: 70. Prompt para aumentar cobertura: "execute npm run test:coverage, identifique branches não cobertos em @arquivo.ts, gere testes para atingir 85%+". Cobertura de qualidade vs. quantidade: asserções explícitas > execução sem erro.

Técnica de isolar o problema antes de enviar para o agente: contexto mínimo viável para debugging. Em vez de enviar o sistema completo com "algo está errado no checkout", enviar um teste que falha + código mínimo que reproduz o problema. Quanto menor e mais preciso o problema isolado, maior a probabilidade de resolução na primeira tentativa.

Debugging ineficaz: enviar sistema completo com descrição vaga → 5-10 trocas de mensagem, sugestões genéricas, alta chance de solução incorreta. Debugging eficaz: teste que falha + código mínimo → resolução em 1-2 mensagens com solução específica e teste confirmando a correção.

Técnica de regressão como ponto de partida: escrever um teste que falha reproduzindo o bug, enviar o teste + @arquivo para o agente. Template de bug report: Erro + Stack Trace + Código Relevante + Ambiente + O que tentou + Comportamento esperado. Reprodução mínima: isolar a menor quantidade de código que reproduz o bug.

CI/CD captura em desenvolvimento tradicional bugs que humanos introduzem por descuido. Em vibe coding, captura bugs que agentes introduzem por falta de contexto ou instrução ambígua. O pipeline é a verificação objetiva que o agente não pode fazer por si mesmo. Pipeline mínimo profissional: Lint → Testes → SAST → Build → Deploy.

Sem CI/CD, código de agente vai diretamente para produção sem nenhuma verificação objetiva. Com CI/CD, cada push passa por lint, testes, análise de segurança e build antes de qualquer deploy. É a diferença entre vibe coding profissional e vibe coding que resulta em incidentes.

Pipeline obrigatório: 1-Lint (ESLint, TypeScript strict), 2-Testes unitários (cobertura mínima 80%), 3-SAST (Semgrep/CodeQL para vulnerabilidades), 4-Build (compilação sem erros), 5-Deploy automático (apenas se todos anteriores passaram). Deploy nunca ocorre diretamente sem pipeline.

GitHub Actions é a ferramenta padrão de CI/CD para projetos de vibe coding por integrar nativamente com o repositório, ser gratuito para projetos privados (2.000 min/mês) e ser facilmente gerado por IA. O agente pode criar o workflow completo para Node.js/TypeScript com lint, testes, cobertura e deploy em uma única sessão.

Configurar CI/CD manualmente leva horas para quem não tem experiência. Pedir ao agente para criar o workflow completo com as especificações do projeto leva minutos. GitHub Actions integrado com Vercel/Railway transforma push em main em deploy automático seguro.

Workflow YAML: on push/PR, jobs quality (lint, type check, testes com cobertura), security (Semgrep SAST), deploy (needs: [quality, security], if: main branch). Cache npm para velocidade. Secrets no GitHub Actions para DATABASE_URL e tokens de deploy. Upload de cobertura para Codecov.

Integração de SAST (Static Application Security Testing) diretamente no pipeline de CI/CD, transformando segurança de uma fase final para um processo contínuo. CodeQL (GitHub nativo, detecta vulnerabilidades complexas de múltiplos arquivos) e Semgrep (regras customizáveis por projeto) são as ferramentas padrão.

SAST no pipeline encontra vulnerabilidades antes de qualquer código chegar à produção. Em vez de encontrar problemas de segurança em auditoria trimestral, você os encontra em segundos após cada commit. SAST não substitui code review humano, mas é a primeira linha de defesa automática.

CodeQL via github/codeql-action: languages: javascript-typescript, queries: security-extended. Semgrep via semgrep/semgrep-action: config p/security-audit p/secrets p/owasp-top-ten. SAST detecta padrões conhecidos; não detecta falhas de lógica de autorização — code review humano ainda necessário.

Vercel e Railway são plataformas de deploy padrão para vibe coding por sua integração nativa com GitHub, zero configuração de infraestrutura e deploy automático a cada push. Vercel para frontend/Next.js/serverless; Railway para APIs, workers e banco de dados nativos. O Vercel cria preview deploys automáticos para cada PR — revisores podem testar em ambiente real antes de aprovar o merge.

Preview deploys são a killer feature para vibe coding em times: cada PR tem um ambiente real onde o código de IA pode ser testado sem necessidade de rodar localmente. Isso acelera code review e aumenta a confiança antes do merge em main.

Vercel: frontend, Next.js, serverless, gratuito até 100GB/mês, preview deploys automáticos por PR. Railway: APIs, PostgreSQL e Redis nativos, $5/mês (Hobby). Estratégia: Vercel para frontend + Railway para backend + Supabase/Neon para banco é o stack padrão de vibe coding profissional.

Feature flags permitem deploar código de IA em produção mas ativá-lo apenas para subconjuntos controlados de usuários. Se algo der errado, você desliga o flag sem rollback de código — alterando apenas uma variável de ambiente. É a estratégia de release mais segura para código gerado por agentes.

Código de IA pode ter bugs sutis que só aparecem com tráfego real de produção. Feature flags permitem release gradual: 1% interno → 5% beta → 25% → 100%. Se o bug aparecer em 1%, você desliga antes de impactar todos os usuários — sem rollback de código, sem novo deploy.

Implementação simples: process.env.FF_NEW_FEATURE === 'true'. Rollback: alterar variável de ambiente, sem novo deploy. Ferramentas: variáveis de ambiente (simples e grátis), PostHog (gratuito, flags + analytics), LaunchDarkly (enterprise, regras por usuário). Release gradual: 1% → 5% → 25% → 100% com monitoramento.

Capacidade de reverter um deploy automaticamente quando métricas de saúde do sistema degradam além de um threshold configurado. Em projetos de vibe coding, bugs sutis que passam por todos os checks só aparecem com tráfego real — rollback automático é a última linha de defesa antes que usuários sejam amplamente impactados.

Monitorar manualmente pós-deploy é lento e dependente de alguém estar acordado. Rollback automático por métricas detecta e reverte em minutos — antes que o time perceba o problema. Para vibe coding com agentes que fazem múltiplos deploys por dia, rollback automático é segurança crítica.

Métricas para acionar rollback: taxa de erro HTTP 5xx acima de 2%, latência P95 acima de 2s, taxa de conversão caiu 20%+, erros de JavaScript no browser acima de 5%. Vercel CLI: vercel rollback [deployment-url]. GitHub Actions: verificação de error rate via Sentry API, rollback automático se acima do threshold.

Stack de observabilidade pós-deploy para detectar bugs de código de IA que passam por todos os checks mas só aparecem com tráfego real. Três camadas: Sentry para error tracking em tempo real, logs estruturados em JSON para debugging, e métricas de negócio (PostHog) para impacto em conversão e comportamento de usuário.

Código de IA pode ter bugs que passam por lint, testes unitários, integração e SAST — mas falham com dados específicos de produção. Monitoramento pós-deploy é o último guardrail do processo. Sentry configurado corretamente alerta no primeiro erro, antes que o problema se espalhe.

Sentry: captura exceções em tempo real, stack traces com contexto de usuário, alertas no primeiro erro, gratuito até 5K erros/mês. Logs estruturados: Pino.js para Node.js, JSON estruturado, LogTail/Datadog. Métricas de negócio: PostHog para funnels de conversão e feature flag analytics. BeforeSend: remover dados sensíveis (passwords, creditCard) antes de enviar ao Sentry.

O desenvolvimento com IA evoluiu em quatro níveis: Autocomplete (GitHub Copilot, sugestão de linha, latência <100ms), Editor Agêntico (Cursor Composer/Windsurf, edita múltiplos arquivos por objetivo), Agente Autônomo (Devin/Claude Code, planeja e implementa sem intervenção, sessões de horas), Multi-Agent (orquestra de especialistas, tarefas de dias).

Escolher o nível certo de automação para cada tarefa é tão importante quanto dominar a ferramenta. Usar agente autônomo para autocomplete é desperdício; usar autocomplete para implementar uma feature complexa é frustrante. Cada nível tem seu contexto ótimo de uso.

Autocomplete: sugestão de linha/bloco, humano ainda escreve. Editor agêntico: multi-arquivo por objetivo, humano aprova cada step. Agente autônomo: objetivo de alto nível + Definition of Done, humano revisa resultado. Multi-agent: diretor humano orquestra especialistas (Planejamento-Opus, Implementação-Sonnet, Testes-Haiku, Revisão-Opus).

Devin (Cognition AI) é o agente de software autônomo mais avançado disponível comercialmente. Em 2026, passou de experimento a ferramenta de produção usada por empresas Fortune 500: Goldman Sachs (automação de análise de código legado), Nubank (microsserviços internos), Stripe (SDKs para 14 linguagens) e Accenture (50.000 devs em migração de sistemas legados).

Os dados do Devin em produção definem o estado da arte: 67% de PRs mergeados sem modificação humana, 4x mais rápido que desenvolvimento humano médio, $500/mês vs. $8K de dev junior. Entender o que é possível hoje define o que você deve preparar como engenheiro para os próximos anos.

Métricas Devin 2026: 67% PRs mergeados sem modificação, 4x mais rápido, 24/7 disponibilidade, $500/mês. Casos de uso enterprise: código legado, migração de sistemas, geração de SDKs, automação de conformidade regulatória. Não substitui engenheiros sênior — o 33% de PRs que precisam modificação requer expertise humana.

Claude Code é o agente mais acessível para desenvolvedores individuais e times pequenos: sessões longas, CLAUDE.md como memória persistente de projeto, capacidade de executar comandos, criar arquivos e fazer commits. Com --dangerously-skip-permissions, opera autonomamente por horas executando tarefas complexas.

Claude Code transforma o terminal em um agente de desenvolvimento completo — sem IDE, sem interface gráfica. Para automação de CI/CD, scripts de migração e tarefas em lote, é a ferramenta mais poderosa disponível. O CLAUDE.md garante que o agente mantenha contexto de projeto entre sessões.

Sessão autônoma: objetivo de alto nível + referências a specs (@docs/spec.md) + instruções de commit incremental. O agente: lê CLAUDE.md, apresenta plano para aprovação, implementa módulo por módulo, executa testes após cada módulo, faz commits incrementais, para quando finaliza. CLAUDE.md = memória persistente entre sessões.

Em vez de um agente tentando fazer tudo, a arquitetura multi-agent distribui responsabilidades entre agentes especializados em paralelo: Agente de Planejamento (Opus) decompõe e distribui, Agentes de Implementação (Sonnet) executam backend e frontend em paralelo, Agente de Testes (Haiku) valida outputs, Agente de Revisão (Opus) revisa segurança e qualidade.

Multi-agent tem maior qualidade, maior velocidade e menor custo que um agente único tentando fazer tudo — porque cada agente usa o modelo mais adequado para sua tarefa. Haiku para testes é 10x mais barato que Opus. Backend e frontend em paralelo reduz tempo total pela metade.

Estrutura: Planejamento (Opus) → Implementação Backend + Frontend em paralelo (Sonnet) → Testes (Haiku) → Revisão (Opus) → Aprovação humana. Cada agente tem escopo definido. Roteamento de modelos por complexidade: Opus para arquitetura/revisão, Sonnet para implementação, Haiku para tasks repetitivas.

MCP (Model Context Protocol) é o que dá aos agentes acesso ao ambiente real de produção. Sem MCP, o agente trabalha com código em texto. Com MCP, pode interagir com banco de dados, APIs, infraestrutura e ferramentas externas como um desenvolvedor humano: queries Supabase, PRs no GitHub, logs do Sentry, leitura/escrita de arquivos.

MCP transforma o agente de "assistente de texto" para "operador do ambiente". Com servidores MCP configurados, o agente pode "verificar os top 3 erros do Sentry das últimas 24h e corrija", "crie PR no GitHub com as mudanças e solicite review", "query o banco de produção para entender o schema atual".

Servidores MCP essenciais: @supabase/mcp-server-supabase, @modelcontextprotocol/server-github, @modelcontextprotocol/server-filesystem, @modelcontextprotocol/server-postgres, mcp-server-sentry. Princípio de menor privilégio: agente de desenvolvimento sem escrita em produção. Ambientes separados: staging para dev, produção apenas read-only para diagnóstico.

OpenHands (anteriormente OpenDevin) é o projeto open-source mais avançado de agente de software autônomo. Permite rodar localmente ou em infraestrutura própria — sem enviar código para serviços externos. Suporta qualquer modelo via API. Ideal para experimentação, pesquisa e compliance que não permite código em nuvem.

Para organizações com requisitos de compliance que impedem envio de código para serviços externos, OpenHands é a única opção viável de agente autônomo. Para experimentação, é uma forma de aprender arquitetura de agentes sem custo de plataforma comercial.

MIT License, 100% open-source. Instalação via Docker com runtime sandbox. Acesso ao filesystem e execução de comandos. Vantagens: código nunca sai da infraestrutura, suporta qualquer modelo API. Limitações vs. Devin/Claude Code: requer infraestrutura própria, menos otimizado para projetos grandes, suporte community (não enterprise).

Karpathy declarou em fevereiro de 2026 que o próximo passo após vibe coding é "Agentic Engineering". O papel do engenheiro sênior está evoluindo de implementador para arquiteto de sistemas de agentes — define arquitetura que agentes respeitam, revisa PRs de agentes por segurança e lógica, toma decisões que definem o que agentes podem fazer.

Os engenheiros que mais se beneficiam de agentes são os mais experientes — porque sabem exatamente o que pedir, como validar o resultado e quando não confiar. A IA amplifica expertise, não a substitui. Expertise técnica sólida se torna mais crítica, não menos, em um mundo com agentes autônomos.

Habilidades que permanecem valiosas: arquitetura de sistemas (agentes seguem a arquitetura que você define), segurança (agentes reproduzem vulnerabilidades sem instrução), julgamento técnico (distinguir código correto de código plausível mas errado), decomposição de problemas (transformar sistemas complexos em subtarefas executáveis por agentes).

O modelo que funciona em times: agentes implementam, sêniors revisam. Não porque a IA não seja capaz — mas porque o humano traz julgamento sobre contexto de negócio, arquitetura de longo prazo e implicações de segurança que o agente não pode inferir. O fluxo: implementação → CI automático → revisão sênior → aprovação → deploy automático.

Revisores que não entendem o código são uma vulnerabilidade de governança. "Aprova tudo que o CI passou" não é revisão. Sêniors precisam identificar problemas de lógica de autorização, falhas de segurança sutis e violações de padrões arquiteturais que o CI não captura.

Fluxo: dev/agente implementa → CI/CD automático (lint, testes, SAST) → dev sênior revisa (arquitetura, segurança, lógica de negócio) → aprovação humana explícita → merge → deploy automático → monitoramento pós-deploy. PR só avança se CI passa. Merge só ocorre com aprovação de sênior.

Times de vibe coding profissional não usam uma ferramenta para tudo. Padronização por papel e tipo de tarefa: Cursor para desenvolvimento diário (contexto de projeto, multi-arquivo), Claude Code para automação e CI/CD (terminal-first), Windsurf/Lovable para protótipos rápidos, GitHub Copilot Enterprise para compliance, Claude.ai para análise arquitetural profunda.

Padronizar a ferramenta por tipo de trabalho — não por preferência individual — reduz surface de ataque, facilita onboarding e garante consistência de processo. Um dev usando uma ferramenta não auditada pode enviar código proprietário para servidores externos sem que o time saiba.

Documentar no handbook de engenharia: ferramentas aprovadas por tipo de tarefa e ferramentas proibidas (enviam código para servidores não auditados). Desenvolvimento diário: Cursor. Automação/pipelines: Claude Code. Protótipos: Windsurf ou Lovable. Enterprise/SOC 2: GitHub Copilot Enterprise. Análise arquitetural: Claude.ai (Opus).

A política de governança mais importante para vibe coding em times: nenhum código — gerado por IA ou por humano — vai para a branch principal sem passar por review e CI/CD. Sem exceções. Nem para "hotfixes urgentes". Branch Protection no GitHub: require PR reviews, require status checks, include administrators.

A política sem exceções existe exatamente para momentos de pressão. Um CTO que faz push direto em main para resolver "urgente" com código de IA e sem review é o mesmo padrão que destruiu bancos de dados de produção em casos documentados. A regra protege mais quando é mais difícil de seguir.

Branch Protection Settings: Require pull request (min 1 aprovação), Require status checks (CI/quality + CI/security), Require branches up to date, Include administrators (sem exceções), Allow force pushes: NUNCA. Configurar em Settings → Branches → Branch rules, branch pattern: main.

Em um time, cada desenvolvedor com seus próprios prompts e regras resulta em codebase inconsistente — o patchwork em escala de time. Regras (CLAUDE.md, .cursorrules) e templates de prompt devem ser assets de equipe, versionados no repositório: docs/prompts/feature.md, bugfix.md, refactor.md, security-review.md.

Consistência de input gera consistência de output do agente. Quando todos os devs do time usam o mesmo CLAUDE.md e os mesmos templates de prompt, o código gerado tem o mesmo padrão de arquitetura, nomenclatura e tratamento de erro — independente de quem abriu a sessão de IA.

Estrutura no repositório: CLAUDE.md (raiz), .cursorrules (raiz), docs/prompts/feature.md (template para novas features), docs/prompts/bugfix.md (template para correções), docs/prompts/security-review.md (checklist), docs/decisions/ (ADRs), docs/ai-guidelines.md (política de uso de IA no time). Todos versionados e revisados como código.

Segurança como processo contínuo, não como fase final. SAST (análise estática, antes do deploy): CodeQL em cada PR, Semgrep com regras customizadas, npm audit para dependências, truffleHog para secrets. DAST (teste dinâmico, em staging): OWASP ZAP para scan automático, Burp Suite Community para análise manual, Nuclei para vulnerabilidades conhecidas.

SAST antes do deploy detecta padrões conhecidos de vulnerabilidade automaticamente. DAST em staging detecta vulnerabilidades que só aparecem com a aplicação rodando — como problemas de configuração de CORS, headers de segurança ausentes ou endpoints expostos inadvertidamente pelo agente.

Política Security Gate: SAST de alta severidade bloqueia merge, média gera alertas, baixa registrada para revisão futura. SAST gratuito: CodeQL, Semgrep, npm audit, truffleHog. DAST gratuito: OWASP ZAP (automático), Burp Suite Community (manual), Nuclei (templates de CVEs). Penetration testing anual para sistemas críticos.

Framework DORA adaptado para vibe coding: Deployment Frequency (múltiplos/dia como target elite), Lead Time for Changes (<1 hora ticket→deploy), Change Failure Rate (<5% deploys causam incidente), Time to Restore (<1 hora para restaurar serviço), Test Coverage (>80%). Métricas de resultado, não de atividade.

Métricas incorretas criam incentivos perversos. "Linhas de código por dia" foi inútil antes da IA — com IA é ainda mais inútil (o agente infla artificialmente). "Velocidade de sprint" incentiva code dumping. As métricas que importam medem resultado de negócio e qualidade de software, não velocidade de geração de código.

Métricas úteis com IA: lead time para features, taxa de bugs por feature em produção, cobertura de testes e tendência, taxa de aceitação de código de IA em review, custo de API por feature entregue. Métricas inúteis/prejudiciais: linhas de código/dia, número de commits, velocidade de sprint sem considerar bugs introduzidos.

Em pesquisa com 18 CTOs que adotaram vibe coding sem estrutura de governança, 16 reportaram problemas sérios. Três padrões de falha: Velocidade sem processo (8/16) — codebase inutilizável em 3 meses sem PRs; Júniores sem supervisão (5/16) — dívida técnica e vulnerabilidades massivas; Sem contexto de arquitetura (3/16) — 4 padrões de auth diferentes, refactoring mais caro que reconstrução.

Estudar casos reais de falha é a forma mais eficaz de evitar cometê-los. Os 2 CTOs sem desastres fizeram coisas específicas diferentes: processo antes de velocidade, arquitetura documentada antes de dar IA para o time, sêniors revisando sempre, gradualidade na adoção, treinamento real.

O que os 2 CTOs sem desastres fizeram: implementaram PRs e CI/CD antes de usar IA extensivamente, CLAUDE.md com regras claras antes de dar IA para o time, sênior como reviewer obrigatório, piloto com 1 time antes de expandir, treinamento real em prompting e revisão de código de IA — não assumiram que "é intuitivo".