Diretrizes de Desenvolvimento com AI
1. Quem Pode Usar Vibecoding

1. Quem Pode Usar Vibecoding

Vibecoding não é para todos. O uso de ferramentas de IA para desenvolvimento de software requer maturidade técnica, conhecimento de segurança da informação e compreensão das responsabilidades legais envolvidas. Este capítulo estabelece os critérios de elegibilidade e os níveis de permissão para uso de vibecoding.

1.1. Pré-requisitos Técnicos

1.1.1. Conhecimento Mínimo Obrigatório

Para estar apto a utilizar ferramentas de vibecoding, o desenvolvedor deve possuir:

Segurança da Informação:

  • Compreensão dos riscos de exposição de dados
  • Conhecimento básico de vulnerabilidades comuns (OWASP Top 10)
  • Capacidade de identificar dados sensíveis em código
  • Noções de criptografia e proteção de credenciais

LGPD e Privacidade:

  • Conhecimento dos conceitos de dados pessoais e dados pessoais sensíveis (LGPD Art. 5)
  • Compreensão das bases legais para processamento de dados
  • Noções de anonimização e pseudonimização
  • Conhecimento das penalidades por violações

Desenvolvimento de Software:

  • Capacidade de revisar código criticamente
  • Compreensão de padrões de projeto e arquitetura
  • Experiência com testes automatizados
  • Familiaridade com ferramentas de análise estática (linters, SAST)

Code Review:

  • Habilidade de identificar code smells
  • Capacidade de detectar vulnerabilidades de segurança
  • Experiência em revisão de pull requests
  • Conhecimento de boas práticas de codificação

1.1.2. Certificações Recomendadas

Desejáveis:

  • Certificações de segurança (OWASP, CEH, Security+, etc.)
  • Treinamento em Secure Coding
  • Certificações específicas de tecnologia (AWS Certified, etc.)
  • Conhecimento de LGPD (leitura das diretrizes)

1.2. Requisitos por Nível de Desenvolvedor

1.2.1. Desenvolvedores Júnior

Status: ⚠️ USO ALTAMENTE RESTRITO

Permissões:

  • ✅ Uso PERMITIDO APENAS em:
    • Projetos de treinamento e sandbox
    • Ambientes de desenvolvimento local (sem dados reais)
    • Código não integrado ao repositório principal
    • Exercícios e estudos pessoais
    • Tudo além de landing-pages estaticas

Restrições:

  • ❌ PROIBIDO em:
    • Qualquer código que vá para produção
    • Projetos com dados reais (mesmo em dev/staging)
    • Sistemas críticos de qualquer natureza
    • Código que será integrado sem supervisão

Requisitos Especiais:

  • Supervisão obrigatória de desenvolvedor Pleno ou Sênior
  • Todo código gerado deve ser revisado presencialmente
  • Não pode aprovar pull requests com código AI
  • Período probatório de 6 meses após habilitação

Justificativa:

Desenvolvedores júnior ainda estão desenvolvendo senso crítico para:

  • Identificar vulnerabilidades de segurança
  • Compreender trade-offs arquiteturais
  • Detectar dados sensíveis em contextos não-óbvios
  • Avaliar qualidade e manutenibilidade de código

A ignorância das regras NÃO é desculpa para violações.

1.2.2. Desenvolvedores Pleno

Status: ✓ USO PERMITIDO COM RESTRIÇÕES

Permissões:

  • ✅ Uso permitido para:
    • Funcionalidades não-críticas em projetos aprovados
    • Refatoração de código não-sensível
    • Implementação de testes automatizados
    • Documentação e comentários de código
    • Scripts de automação internos

Restrições:

  • ❌ PROIBIDO em:
    • Módulos de autenticação/autorização
    • Processamento de dados sensíveis (LGPD)
    • Sistemas financeiros ou de pagamento
    • Integrações críticas de negócio
    • Lógica de negócio proprietária complexa

Requisitos Especiais:

  • Code review obrigatório por desenvolvedor Sênior
  • Aprovação prévia do Tech Lead para features com autenticação
  • Não pode revisar código AI de outros desenvolvedores Pleno (apenas Júnior)
  • Reconfirmação anual obrigatória

Diretrizes:

  • Divida tarefas complexas em partes menores revisáveis
  • Documente decisões de design ao usar IA
  • Quando em dúvida, peça revisão de sênior ANTES de commitar
  • Marque todo código AI-generated em comentários

1.2.3. Desenvolvedores Sênior

Status: ✓ USO PERMITIDO COM RESPONSABILIDADE PLENA

Permissões:

  • ✅ Uso permitido para:
    • Todos os projetos (exceto casos absolutamente proibidos)
    • Funcionalidades críticas (com code review)
    • Refatorações arquiteturais
    • Implementações de segurança (com validação extra)
    • Revisão de código AI de outros desenvolvedores

Restrições:

  • ❌ PROIBIDO em:
    • Sistemas que processam dados de saúde (sem aprovação DPO)
    • Core banking systems (sem aprovação CTO)
    • Criptografia de dados em repouso (usar bibliotecas auditadas)

Responsabilidades:

  • Validar rigorosamente a segurança de todo código AI
  • Revisar código AI de desenvolvedores Júnior e Pleno
  • Tomar decisões arquiteturais considerando limitações de IA
  • Reportar imediatamente qualquer incidente ou violação
  • Mentorear desenvolvedores menos experientes no uso de IA
  • Contribuir para melhoria contínua destas diretrizes

Autoridade:

  • Pode aprovar exceções pontuais para desenvolvedores Pleno (documentadas)
  • Pode escalar uso de IA em projetos críticos para aprovação
  • Pode suspender temporariamente acesso de desenvolvedor Júnior se identificar uso inadequado

1.3. Perfis de Risco Permitidos

1.3.1. Projetos de Baixo Risco (PERMITIDO)

Características:

  • Aplicações internas sem dados pessoais
  • Ferramentas de desenvolvimento e automação
  • Protótipos e POCs (Proof of Concept) descartáveis
  • Scripts de análise de dados públicos ou anonimizados
  • Documentação e wikis internos
  • Landing Pages e Marketing sem funcionalidades/backend

Exemplos:

// ✅ PERMITIDO: Script de automação interno
// Gerado com Claude Code - Revisado por: Murilo Bones (20/01/2026)
function generateProjectScaffold(projectName: string): void {
    const folders = ['src', 'tests', 'docs'];
    folders.forEach(folder => {
        fs.mkdirSync(`${projectName}/${folder}`, { recursive: true });
    });
    console.log(`Projeto ${projectName} criado com sucesso!`);
}

Nível de review: Code review padrão por pares

1.3.2. Projetos de Médio Risco (PERMITIDO COM RESTRIÇÕES)

Características:

  • Sistemas internos com dados não-sensíveis
  • APIs internas sem dados pessoais
  • Dashboards administrativos (dados agregados)
  • Features isoladas em sistemas existentes
  • Integrações com serviços de terceiros (dados públicos)

Exemplos:

// ✅ PERMITIDO (com restrições): Dashboard de métricas de sistema
// Gerado com Codex - Revisado por: Felipe Poatan (20/01/2026)
class SystemMetricsController extends Controller
{
    public function index()
    {
        // Apenas métricas agregadas, sem dados pessoais
        $metrics = [
            'total_requests' => Cache::get('metrics:requests:total'),
            'avg_response_time' => Cache::get('metrics:response:avg'),
            'error_rate' => Cache::get('metrics:errors:rate'),
        ];
        
        return view('admin.metrics', compact('metrics'));
    }
}

Requisitos adicionais:

  • Aprovação do Tech Lead documentada
  • Code review por desenvolvedor Sênior
  • Testes de segurança automatizados (SAST)
  • Validação de que não processa dados pessoais

1.3.3. Projetos de Alto Risco (PROIBIDO)

Características:

  • Sistemas financeiros ou de pagamento
  • Plataformas com dados de saúde (HIPAA/LGPD)
  • Módulos de autenticação/autorização
  • Processamento de dados pessoais sensíveis
  • Sistemas críticos de negócio (revenue-generating)
  • Integrações com dados sensíveis conforme LGPD

Exemplos de código PROIBIDO:

// ❌ PROIBIDO: Módulo de autenticação
// NUNCA use IA para gerar sistemas de autenticação completos
class AuthenticationService {
    async login(email: string, password: string) {
        // Lógica crítica de segurança - NÃO usar IA
    }
}
// ❌ PROIBIDO: Processamento de pagamento
// Sistema financeiro crítico - NÃO usar IA
class PaymentProcessor {
    public function processPayment($amount, $cardData) {
        // Lógica financeira crítica - desenvolver manualmente
    }
}

Exceções:

Podem ser solicitadas através do processo formal de aprovação (ver capítulo 8) com:

  • Justificativa técnica detalhada
  • Análise de risco completa
  • Aprovação de múltiplos níveis (Tech Lead, Security Analyst, DPO, CTO)
  • Code review 100% manual linha por linha
  • Testes de segurança extensivos (SAST + DAST + pen testing)

1.4. Processo de Habilitação

Passo 1: Autoavaliação

Antes de solicitar habilitação, responda:

  • Tenho conhecimento sólido de segurança da informação?
  • Compreendo os riscos de exposição de dados?
  • Sei identificar dados pessoais e sensíveis conforme LGPD?
  • Tenho experiência em code review?
  • Compreendo as consequências legais de violações?

Se respondeu "não" a qualquer pergunta, busque conhecimento adicional e releia as diretrizes antes de prosseguir.

Passo 2: Confirmação de Leitura e Termo

Após ler todas as 9 seções destas diretrizes:

  • Enviar confirmação para ti@toolzz.me
  • Assinar termo de responsabilidade
  • Aguardar validação do gestor

Passo 3: Termo de Responsabilidade

Assine digitalmente o Termo de Responsabilidade declarando que:

  • Leu e compreendeu todas as diretrizes
  • Compromete-se a seguir todas as restrições
  • Assume responsabilidade integral pelo código produzido
  • Compreende as consequências de violações

Passo 4: Aprovação do Gestor

Seu gestor direto revisará e aprovará (ou rejeitará) com base em:

  • Nível de experiência
  • Histórico de qualidade de código
  • Conhecimento demonstrado em segurança
  • Necessidade da função

Passo 5: Registro e Credencial

Após aprovação:

  • Registro no sistema de compliance
  • Emissão de credencial digital (válida por 1 ano)
  • Liberação de acesso a ferramentas aprovadas
  • Inclusão em lista de desenvolvedores habilitados

1.5. Suspensão e Revogação de Acesso

Causas de Suspensão

Suspensão Temporária (30 dias):

  • Uso de ferramenta não aprovada (sem vazamento de dados)
  • Code review inadequado (primeira ocorrência)
  • Não reconfirmação no prazo
  • Violação leve de procedimento

Durante a suspensão:

  • Acesso a todas as ferramentas de IA bloqueado
  • Obrigatoriedade de reler diretrizes
  • Código manual passa por revisão adicional

Suspensão Estendida (90 dias):

  • Reincidência de violações leves
  • Uso de IA em projeto não aprovado
  • Compartilhamento de código sem validação de dados sensíveis
  • Múltiplas falhas em code review

Causas de Revogação Permanente

  • Exposição de dados sensíveis a ferramentas de IA
  • Violação grave de LGPD (mesmo sem dolo)
  • "Fucking code" em sistema crítico resultando em incidente
  • Reincidência após múltiplas suspensões
  • Má-fé ou negligência grave

Revogação permanente implica:

  • Impossibilidade de reabilitação
  • Registro permanente em arquivo funcional
  • Possível rescisão de contrato
  • Responsabilização legal conforme o caso

Processo de Reinserção Pós-Suspensão

Para retornar após suspensão:

  1. Cumprir período integral de suspensão
  2. Releitura completa das diretrizes
  3. Entrevista com Tech Lead
  4. Período probatório de 3 meses com:
    • Code review 100% de todo código (AI ou manual)
    • Supervisão próxima
    • Relatórios quinzenais de atividades
  5. Avaliação final para retorno à normalidade

Lembre-se: Vibecoding é um privilégio, não um direito. Use com responsabilidade.

0. Introdução ao Vibecoding Seguro2. Restrições e Proibições