Como operar de forma AI-native na prática

Da teoria pra prática

As sessões anteriores explicaram o que é IA, como modelos funcionam, quais ferramentas existem e quais são os níveis de maturidade. Tudo isso é útil pra entender. Mas entender e operar são coisas diferentes.

Não tem uma receita universal. O que funciona pra um dev sênior em um projeto grande é diferente do que funciona pra um PM validando uma ideia. Mas tem princípios que se aplicam a todo mundo.

Por que isso importa

A maioria das frustrações com IA vem de dois lugares:

1. Input ruim: você pediu de forma vaga e recebeu resultado genérico. Não é culpa do modelo. É culpa da especificação.
2. Validação ausente: você aceitou o resultado sem verificar e descobriu o problema em produção. Não é culpa da ferramenta. É culpa do processo.

Essa sessão ataca os dois: o que fazer antes de pedir e o que fazer antes de aceitar.

Antes de pedir: o checklist de contexto

Antes de mandar qualquer coisa pra IA, responda 4 perguntas:

1. Qual é o objetivo?

Não o que você quer que a IA faça. O que você quer como resultado final.

“Gera um componente de modal” não é objetivo. “Preciso de um modal de confirmação que aparece quando o usuário tenta deletar uma conta, com botões de cancelar e confirmar, que bloqueia o scroll do fundo” é um objetivo.

2. Qual é o contexto?

O que o modelo precisa saber além do pedido?

• Quais arquivos são relevantes? (tipos, componentes existentes, padrões)
• Qual framework ou biblioteca estamos usando?
• Quais convenções o time segue? (nomes de variáveis, estrutura de pastas, patterns)
• Existe algo parecido no projeto que pode servir de referência?

3. Quais são as restrições?

O que o modelo não deve fazer?

• “Não use biblioteca externa”
• “Mantenha compatibilidade com a versão atual da API”
• “Não mude a interface pública do módulo”
• “Use CSS Modules, não Tailwind”

Restrições evitam que o modelo tome decisões que você vai ter que reverter. É mais rápido dizer “não faça X” do que desfazer X depois.

4. Qual é o formato esperado?

Como você quer receber o resultado?

• Um arquivo completo ou um diff?
• Com testes ou sem testes?
• Com explicação do raciocínio ou só o código?
• Estrutura de pastas ou tudo no mesmo arquivo?

Antes de aceitar: o checklist de validação

O modelo gerou algo. Antes de aceitar, passe por essas verificações:

Testes passam?

Se o projeto tem testes, rode. Se o modelo gerou testes novos, leia antes de rodar. Teste que passa mas não testa nada dá falsa confiança.

Tipos batem?

Rode o typecheck. O modelo pode gerar código que parece correto mas tem tipos incompatíveis que só aparecem na compilação.

Lint passa?

Lint pega o que o modelo ignora: nomes de variáveis errados, imports fora de ordem, padrões não seguidos.

Você leu o código?

Não skimmou. Leu. Cada linha não lida pode ter um bug, vulnerabilidade, ou decisão de design que não faz sentido no seu contexto. Pra um componente de 50 linhas, 2 minutos bastam.

Faz o que foi pedido?

Compare o resultado com o objetivo original. O modelo pode gerar algo tecnicamente correto que não resolve o problema.

Exemplo aplicado

PM: usando IA pra refinar specs

Situação: Beatriz é PM e precisa escrever a spec de uma feature de notificações push.

Como ela opera:

1. Escreve um rascunho da spec com os requisitos que conhece
2. Manda pro modelo: “Revisa essa spec e aponta lacunas. Quais cenários de borda eu não cobri?”
3. O modelo aponta gaps: notificações desabilitadas no OS, retry em falha, prioridade
4. Complementa a spec e manda pro time

O que ela não faz: pedir pro modelo escrever a spec do zero. O domínio é dela; o modelo ajuda a encontrar buracos.

Dev júnior: aprender e implementar

Situação: Lucas é dev júnior e precisa implementar paginação numa API que ele nunca mexeu.

Como ele opera:

1. Lê o código existente da API pra entender a estrutura
2. Pede pro modelo explicar cursor pagination versus offset/limit
3. Decide usar cursor-based e pede a implementação passando o handler + tipos do projeto
4. Revisa o código, roda os testes, ajusta o que não bate com as convenções do time

O que ele não faz: pedir “faz paginação” sem entender o conceito primeiro.

Dev sênior: acelerar e revisar

Situação: Carlos é dev sênior e precisa migrar 15 controllers de Express pra Fastify.

Como ele opera:

1. Migra o primeiro controller manualmente pra definir o padrão
2. Escreve um rules file com as convenções da migração
3. Usa um agente de código pra migrar os 14 restantes, validando testes a cada migração
4. Revisa os diffs: o agente seguiu o padrão? Os testes passam?

O que ele não faz: mandar “migra tudo” sem definir o padrão primeiro.

Construindo artefatos repetíveis

O que separa “usar IA às vezes” de “operar AI-native” é ter artefatos que tornam o processo repetível.

Rules files

Arquivos que definem como o agente deve operar no seu projeto (AGENTS.md, CLAUDE.md no Claude Code, .cursor/rules/). Um bom rules file é específico e curto: “TypeScript strict. CSS Modules. Testes com Vitest. Componentes em PascalCase.”

Templates de prompt

Prompts reutilizáveis pra situações comuns: gerar testes a partir de specs, revisar PRs com foco em segurança e performance, explicar módulos pra quem é novo no projeto. São pontos de partida, não scripts rígidos.

Checklists de validação

O checklist de “antes de aceitar” pode ser um arquivo no repo, um comentário no PR template, ou um passo no CI. O ponto é que exista e seja seguido.

Scripts de validação

Comandos que automatizam verificação: npm run typecheck && npm run lint && npm run test. Pre-commit hooks e CI que bloqueiam merge tornam o processo menos dependente de disciplina.

Onde isso quebra

• Checklists como burocracia. Se o checklist vira um ritual que você preenche sem pensar, perdeu o propósito. O valor é verificar de verdade.

• Pular validação quando tá com pressa. “Eu sei que tá certo, não preciso rodar os testes.” Essa frase é responsável por mais bugs em produção do que qualquer modelo de IA.

• Automatizar cedo demais. Se você não sabe qual é o processo certo, automatizar é congelar o processo errado. Primeiro faça manualmente, depois identifique padrões, depois automatize.

Bloco interativo

O que levar daqui

• Antes de pedir: defina objetivo, contexto, restrições e formato
• Antes de aceitar: rode testes, typecheck e lint. Não aceite no automático
• Comece com um rules file pro seu projeto. É o artefato com maior retorno por esforço
• Primeiro manual, depois padrão, depois automação. Nessa ordem