Claude Code e Jev no mesmo projeto: quem escreve nos arquivos e como evitar conflito?

Fala aí, beleza? Começa por aqui: o Jev não escreve uma palavra 😛

Então, se tu tá com medo de o Claude Code e o Jev brigarem pelo mesmo arquivo, se liga: essa briga não acontece do jeito que parece

O conflito de verdade é o Claude Code contra o que roda em volta dele: o script que chama o Jev, outra sessão aberta no mesmo projeto, aquela edição manual que você fez no editor e esqueceu…

Rapidinho pra situar: o Jev é um modelo ‘System One’ da TypeSafe AI

Ele não gera texto, ele devolve decisões tipadas com probabilidade, que o seu código usa direto

Ele saiu primeiro com lista de espera e depois abriu o acesso pra todo mundo

Neste post a ideia é deixar claro quem escreve, quem só lê e como usar o Git como árbitro, beleza? 🙂

O que você precisa antes de colocar os dois no mesmo projeto?

Antes de ligar qualquer integração, confere se tu tem isso aqui:

• Projeto sob Git: ele vai ser o seu árbitro, então sem ele nem começa
• Claude Code instalado e funcionando no projeto
• Acesso à API do Jev com chave própria: o Jev é uma API hospedada separada, não vem embutido no Claude Code
• Um caminho do agente até o Jev: o Claude Code não chama o Jev sozinho

E que caminho é esse?

Pode ser um script que o agente roda, a skill de agente da TypeSafe ou um servidor MCP da comunidade

Existe, por exemplo, o projeto jev-code, que coloca o Jev como ferramenta dentro do Claude Code, Codex, Pi e OpenCode

Tome cuidado: ele é da comunidade, não é oficial

Como dividir a escrita entre Claude Code e Jev sem conflito?

A lógica é simples: uma ferramenta escreve, a outra decide

É como ter um dev que mexe no código e um consultor que só responde ‘sim’, ‘não’ ou ‘opção B’… o consultor nunca encosta no teclado

1. Defina os papéis por escrito

O Claude Code escreve e revisa o código

O Jev responde perguntas tipadas estreitas e ajuda a filtrar ou rotear trabalho

Testes e revisão humana verificam os resultados importantes

Deixa isso anotado no projeto e não crie nenhuma etapa que grave arquivo ‘em nome do Jev’

No fundo a pergunta é a mesma de entender a relação entre duas ferramentas de IA: qual o papel de cada uma?

Erro comum deste passo: tratar o Jev como se ele pudesse ser o modelo por trás do agente

Não pode! Um agente de código precisa de um modelo que escreva texto, chame ferramentas e edite arquivos, e o Jev devolve respostas tipadas e nunca escreve uma palavra

2. Reserve caminhos fixos pro script e bloqueie o Claude Code neles

Se o seu script de integração precisar gravar alguma coisa (o resultado da decisão, por exemplo), separa uma pasta só pra isso

Aí tu bloqueia o Claude Code nesse caminho com permissions.deny no settings.json, usando regras Edit(...)

As regras de deny do tipo Edit bloqueiam as ferramentas Edit e Write nos caminhos que casam com o padrão

Se liga no exemplo (o caminho é só ilustrativo, ajusta pro teu projeto):

{
  "permissions": {
    "deny": [
      "Edit(./resultados-jev/**)"
    ]
  }
}

E o deny vale pra quê exatamente?

Pras ferramentas de arquivo nativas do Claude Code, pros comandos de arquivo reconhecidos no Bash (cat, head, tail, sed, tee) e pros redirecionamentos do Bash (> file)

Ou seja, o agente não consegue ‘dar a volta’ gravando por redirecionamento, muito massa né? 😀

Erro comum deste passo: achar que o deny protege o arquivo contra o próprio script externo

Ele só restringe o Claude Code, o script continua livre pra gravar onde quiser

3. Confira as regras com /permissions

Roda /permissions dentro do Claude Code

Ele lista e edita as regras de permissão (allow, ask, deny) e mostra de qual settings.json cada uma vem

Erro comum deste passo: colocar a regra num arquivo de settings diferente do que você imagina e achar que está protegido

Se a coisa começar a se comportar estranho mesmo com tudo configurado, vale o mesmo raciocínio de quando tu investiga conflito entre mods no Claude Code: descobrir quem está atuando onde

4. Use o Git como árbitro

Faz um commit antes de cada rodada do agente e deixa a automação com o Jev numa branch separada

git add -A
git commit -m "antes da rodada do agente"
git switch -c automacao-jev

Depois da rodada, revisa o diff antes de aceitar qualquer coisa

git diff

Erro comum deste passo: confiar no checkpoint do Claude Code como histórico

A própria documentação diz que checkpoint é pra recuperação rápida na sessão, e que pra histórico permanente e colaboração tu continua usando Git

5. Use a confiança do Jev como trava

Na API do Jev, quem chama envia um estado (texto ou dados estruturados) e um conjunto de perguntas tipadas

O Jev responde com uma distribuição de probabilidade e um valor de confiança

Aí o seu código age acima de um limiar que você define e escala pra um humano abaixo dele

Isso evita que uma decisão ‘meio assim’ dispare uma edição automática no projeto

Erro comum deste passo: ignorar a confiança e usar só a resposta

A resposta sozinha parece sempre certeira, a confiança é que te conta quando desconfiar…

Como perceber que uma mudança foi sobrescrita (e desfazer)?

Já me ferrei com isso: tu volta no arquivo e a alteração simplesmente sumiu xD

Sintoma:

Código que você ou o agente alterou voltou ao estado anterior, ou mudou sem explicação nenhuma

Causa provável:

Alguma coisa fora do Claude Code mexeu no arquivo: o script da integração, outra sessão concorrente, uma edição manual ou um comando bash como rm, mv ou cp

E por que o checkpoint não pegou?

Porque o checkpointing do Claude Code só rastreia as edições feitas pelo próprio Claude, criando um checkpoint a cada prompt seu

Mudanças externas, edições de outras sessões concorrentes e arquivos alterados por esses comandos bash normalmente ficam de fora

Solução:

Primeiro descobre o que mudou e quem mudou:

git status
git diff

Se a mudança perdida foi uma edição do Claude na sessão atual, aperta Esc duas vezes ou roda /rewind

Aí tu escolhe restaurar só a conversa, só o código ou os dois

Se foi algo externo, o caminho de volta é o Git, por isso o commit antes de cada rodada faz tanta diferença

Como prevenir:

• Commits frequentes, principalmente antes de rodar o agente
• Uma única sessão do agente por área do código
• Caminhos reservados pro script protegidos por deny
• Nada que grave arquivo fora do Claude Code sem passar pelo Git

Onde o Jev entra no fluxo sem tocar em arquivo?

Agentes como Claude Code, Codex e OpenCode podem chamar o Jev pra classificar, pontuar ou checar coisas sem gastar uma chamada de raciocínio completa

Alguns use cases que encaixam bem:

• Classificar uma tarefa antes de o agente agir: é bug, refactor ou feature nova?
• Pontuar um resultado: o quanto essa mudança atende o pedido?
• Checar um critério: isso passa ou não passa na regra do time?
• Rotear trabalho: qual fluxo ou pessoa deve cuidar disso?

Pra escolha entre opções, as perguntas do tipo Choice pegam um item de uma lista explícita de até 255 opções

E repara no padrão: em todos esses casos o Jev só devolve a decisão

Quem escreve o código é sempre o Claude Code 🙂

Resumo: uma ferramenta escreve, a outra decide, o Git registra

A regra prática fica assim:

• O Claude Code escreve o código, e o script da integração, se precisar gravar algo, fica só na pasta reservada pra ele
• O Jev só responde perguntas tipadas, com probabilidade e confiança
• O checkpoint serve pra recuperação rápida dentro da sessão
• O Git é o histórico permanente e o árbitro quando algo some

Seguindo isso, o ‘conflito entre Claude Code e Jev’ vira o que ele realmente é: controle de quem mais mexe no projeto

Próximo passo: abre o /permissions no seu projeto e confere quais caminhos o agente pode editar antes de ligar a integração com o Jev

Faça o teste e me conta como ficou o seu fluxo!

Até o próximo post! 😀