Developer Portal - Labzz LLC

4. Boas Práticas de Vibecoding

Este capítulo apresenta as melhores práticas para uso seguro e eficiente de ferramentas de vibecoding, equilibrando produtividade e segurança.

4.0. Treinamento Obrigatório

⚠️ OBRIGATÓRIO: Antes de iniciar o uso de vibecoding, você DEVE assistir ao vídeo de treinamento oficial abaixo. Este vídeo é parte integrante do processo de habilitação e sua visualização é obrigatória para todos os desenvolvedores.

Vídeo: Diretrizes de Vibecoding Seguro

Requisitos:

Assistir ao vídeo completo (não pular partes)
Compreender todos os conceitos apresentados
Confirmar visualização no email de confirmação de leitura para ti@toolzz.me

O que o vídeo cobre:

Fundamentos de vibecoding seguro
Exemplos práticos de uso correto e incorreto
Demonstrações de violações comuns e como evitá-las
Casos reais de incidentes e suas consequências

Consequências:

Uso de vibecoding sem assistir ao vídeo = Violação das diretrizes
Pode resultar em suspensão imediata

4.1. Prompt Engineering Seguro

4.1.1. Template de Prompt Ideal

Estrutura recomendada:

Contexto: [Descrição genérica da funcionalidade - SEM dados reais]
Objetivo: [O que precisa ser implementado especificamente]
Requisitos:
- [Requisito 1]
- [Requisito 2]
- [Requisito 3]

Restrições:
- [Limitação técnica 1]
- [Limitação técnica 2]

Stack: [Tecnologias - ex: Node.js 20, TypeScript 5, PostgreSQL 15]
Padrões: [Arquitetura - ex: Clean Architecture, Repository Pattern]

IMPORTANTE: Não incluir dados reais, credenciais ou informações sensíveis.

Exemplo de prompt BOM:

Contexto: API REST para gerenciamento de produtos
Objetivo: Criar repository class para entidade Product usando TypeORM
Requisitos:
- Métodos CRUD completos (create, findAll, findById, update, delete)
- Suporte a paginação (limit/offset)
- Filtro por categoria
- Usar prepared statements para segurança

Restrições:
- PostgreSQL como database
- Deve seguir padrão Repository do projeto

Stack: Node.js 20, TypeScript 5, TypeORM 0.3, PostgreSQL 15

Incluir:
- Type safety completo
- Tratamento de erros
- Testes unitários com Jest

4.1.2. Exemplos de Prompts Seguros vs Inseguros

❌ INSEGURO:

"Conserte este código que está dando erro ao conectar no banco:
const db = await connect('postgresql://admin:S3nh@Pr0d@prod-db.empresa.com:5432/production')"

Problema: Expôs credenciais reais de produção

✅ SEGURO:

"Como configurar conexão PostgreSQL usando variáveis de ambiente em Node.js?
Preciso carregar host, user, password e database de process.env de forma segura."

❌ INSEGURO:

"Debug este erro: User 'joao.silva@cliente.com' não consegue fazer login, senha dele é XYZ123"

Problema: Expôs email real de cliente e senha

✅ SEGURO:

"Implementar tratamento de erro de autenticação em Express que:
- Retorna status 401 se credenciais inválidas
- Loga tentativa (sem expor senha)
- Rate limit após 5 tentativas"

4.2. Checklist de Code Review para Código AI

Checklist OBRIGATÓRIO - Marcar TODOS os itens:

Segurança (Critical):

Qualidade de Código:

Testes:

Testes unitários criados
Cobertura maior que 80% para código crítico
Testes passando 100%
Edge cases cobertos
Testes de integração (se aplicável)
Testes de segurança

Conformidade:

Código AI marcado em comentários
Nenhum dado sensível usado no prompt
Documentação adequada (JSDoc/PHPDoc)
Sem violações LGPD
Compliance com diretrizes vibecoding

4.3. Uso Iterativo e Incremental

Princípio: Divida em pequenas tarefas revisáveis

Exemplo - Feature "Sistema de Notificações":

❌ ERRADO (Fucking Code):

Prompt: "Crie um sistema completo de notificações com email, SMS, push,
templates, fila, retry logic, analytics e dashboard"

Resultado: 2000+ linhas de código não-revisável

✅ CORRETO (Iterativo):

Iteração 1: Interface e tipos (20 linhas)

interface Notification {
    id: string;
    userId: string;
    type: 'email' | 'sms' | 'push';
    template: string;
    data: Record<string, any>;
    status: 'pending' | 'sent' | 'failed';
}

✅ Revisado e aprovado

Iteração 2: Service base (50 linhas)

class NotificationService {
    async send(notification: Notification): Promise<void> {
        // Implementação básica
    }
}

✅ Revisado e aprovado

Iteração 3: Provider de email (60 linhas) - Com testes
✅ Revisado e aprovado

Iteração 4: Queue implementation (70 linhas) - Com testes
✅ Revisado e aprovado

Resultado: Sistema completo, 100% revisado, testado e compreendido

4.4. Ferramentas Complementares

4.4.1. Análise Estática (Obrigatória)

PHP/Laravel:

# PHPStan - Level 8 (máximo)
./vendor/bin/phpstan analyse --level=8
 
# PHP CS Fixer
./vendor/bin/php-cs-fixer fix

Node.js/TypeScript:

# ESLint + TypeScript
npx eslint . --ext .ts,.tsx
 
# TypeScript strict mode
tsc --noEmit --strict

SonarQube (Todos os projetos):

sonar-scanner
# Quality Gate deve ser PASSED

4.5. Quando NÃO Usar IA

Cenários inadequados para vibecoding:

Decisões Arquiteturais Críticas
- Escolha de padrão arquitetural
- Design de schema de banco para sistema crítico
- Definição de boundaries de microserviços
Lógica de Negócio Proprietária Complexa
- Algoritmos de precificação
- Cálculos financeiros críticos
- Regras de negócio únicas da empresa
Debugging de Produção com Dados Reais
- NUNCA compartilhe logs de produção
- Reproduza problema em ambiente local com dados fake
Otimizações de Performance Críticas
- Profiling e análise humana necessária
- IA pode sugerir, mas validação profunda obrigatória
Código que Você Não Compreende
- Se não entende, NÃO use
- Busque mentoria humana

💡 Regra de Ouro: Se você não consegue explicar o código gerado para um desenvolvedor júnior, você não deveria estar usando esse código.

3. Proteção de Dados Sensíveis 5. Code Review Obrigatório