O que quebra quando o vibe coding chega num repositório compartilhado

Tudo sobre vibe coding muda quando o repositório tem outras pessoas dentro. Não porque o código fique pior, mas porque o jeito como ele falha deixa de ser visível.

Na sua própria máquina, um erro aparece como algo que não funciona. Num repositório compartilhado, a falha característica é código que funciona, se lê como razoável, passa na revisão e mesmo assim está errado — porque quebrou uma regra que nunca foi escrita em nenhum lugar que o modelo pudesse ler.

O formato disso

Pede-se a um agente que adicione um campo a um formulário. Ele adiciona, com competência. Ele também adiciona uma migração de banco de dados, porque é isso que adicionar um campo geralmente exige.

A migração está boa. O problema é que este time aplica migrações à mão, numa ordem específica, depois de uma revisão da pessoa que é owner do schema — uma convenção que existe por causa de um incidente de dezoito meses atrás, é conhecida por quatro pessoas, e não está escrita em lugar nenhum.

Nada naquele diff parece errado. Essa é a falha. Não é código ruim; é código localmente razoável e globalmente errado, e a distância entre essas duas coisas é exatamente a distância entre o que está no repositório e o que está na cabeça de alguém.

Por que a revisão não pega isso?

A revisão lê o diff e pergunta se ele é bom. Essa classe de problema é invisível para essa pergunta, porque o diff é bom. O defeito mora na relação entre a mudança e um pedaço de contexto que não está na tela.

Quem revisa só pega se por acaso carregar a convenção e por acaso lembrar dela enquanto lê. Isso funciona, às vezes, quando quem revisa é uma das quatro pessoas. Para de funcionar no momento em que o volume sobe — e o volume subir é o ponto inteiro de usar agentes.

Então o conselho de sempre, revise código gerado por IA com mais cuidado, está meio certo e não escala. Revisão cuidadosa linha por linha de tudo remove o motivo de gerar em primeiro lugar.

Qual é a falha que custa mais?

Dois agentes, ao mesmo tempo, no mesmo repositório.

Cada um está correto isoladamente. Cada um passa nos próprios testes. Um refatora um helper de que o outro depende; ou os dois tocam a mesma configuração de direções opostas; ou um move um arquivo em que o outro está escrevendo. Nada dá erro. Os dois branches estão verdes.

A perda aparece dias depois como uma mudança que foi feita e depois não estava mais lá, e ninguém consegue dizer quando ela parou de existir. É cara justamente porque não existe um momento de falha para apontar — você está reconstruindo um negativo a partir do histórico do git.

Isso não é hipotético e não é raro. É a consequência comum de rodar mais de um agente num repositório, o que hoje é uma terça-feira normal.

Como sei que isso já está acontecendo?

Não chega como um incidente, e essa é a dificuldade. Chega como um conjunto de fatos pequenos que cada um tem uma explicação individual plausível:

• Trabalho que foi feito e depois não estava lá. Alguém lembra de ter escrito. O git diz que existiu. Ninguém consegue nomear o commit que removeu.
• O mesmo bug corrigido duas vezes, com três semanas de diferença, por duas pessoas que cada uma achou que era a primeira.
• Uma convenção reexplicada em três sessões separadas, porque cada sessão começou sem memória da anterior e ninguém escreveu no meio.
• Um pull request que toca arquivos que ninguém esperava, onde os arquivos a mais são todos individualmente defensáveis.
• “Quem mudou isso?” respondido por uma mensagem de commit que diz refactor e um autor que não estava lendo com atenção.

Qualquer uma dessas sozinha é uma semana ruim comum. Todas juntas são a falha, e o motivo de ela ficar sem nome por tanto tempo é que não existe erro para procurar. Você está procurando a ausência de uma coisa, e ausências não acionam ninguém.

E se as outras pessoas forem os meus próprios agentes?

A inversão que pega mais gente de surpresa: você não precisa de um time para ter um problema de repositório compartilhado. Dois terminais bastam.

Um repositório não sabe que duas sessões pertencem ao mesmo humano. Toda propriedade que torna isso difícil num time está presente quando você está sozinho — escritas concorrentes nos mesmos arquivos, nenhuma memória compartilhada entre as sessões, convenções que existem só na sua cabeça — e uma propriedade é estritamente pior. Num time, o trabalho do segundo agente é pelo menos lido por uma pessoa diferente. Quando os dois são seus, você aprova os dois, rápido, na mesma tarde, e não existe um segundo leitor em lugar nenhum do circuito.

É por isso que “sou desenvolvedor solo, isso não se aplica a mim” normalmente já está errado no momento em que alguém diz. O limiar não é o número de pessoas. É o número de coisas escrevendo no repositório ao mesmo tempo.

AGENTS.md e CLAUDE.md resolvem isso?

A resposta padrão é um CLAUDE.md ou um AGENTS.md com as suas convenções dentro. Escreva um. Ajuda de verdade, e é a coisa mais barata desta lista.

Ele também apodrece, pela mesma razão que toda documentação apodrece: é uma foto do que alguém lembrava no dia em que escreveu, e nada força a revisitá-lo quando a coisa que ele descreve muda. Seis meses depois é uma mistura de verdadeiro, vencido e aspiracional, e um agente lendo não consegue dizer qual linha é qual. Uma pessoa recém-contratada também não.

Um arquivo de contexto é necessário e não é suficiente, e o vão entre essas duas coisas é onde está o trabalho interessante.

O que ajuda de verdade?

Nomeie os paths onde errar sai caro. Não tudo — a maior parte de um repositório é genuinamente segura para mudar, e tratar tudo como perigoso significa que nada é. Uma lista curta dos paths que doeriam vale mais do que uma exaustiva, porque uma lista curta é lida.

Dê a cada um deles um owner. Não por burocracia: para que “isso deveria mudar?” tenha a quem perguntar. Uma regra sem owner é uma regra contornada no primeiro inconveniente, por humanos tanto quanto por agentes.

Defina o escopo do trabalho antes de ele começar, não depois. O que isso deve fazer, o que não pode tocar, quais áreas toca. Escrito antes de o código existir, isso é uma especificação. Escrito depois, é uma desculpa.

Torne possível ver o que uma peça de trabalho de fato tocou, contra o que ela disse que tocaria. Essa diferença é onde estão as surpresas, e é uma pergunta que o git consegue responder se alguém fizer.

Nada disso precisa de um produto. Precisa que a lista exista em algum lugar que tanto as pessoas quanto os agentes consigam ler.

O que eu posso fazer na segunda-feira, sem comprar nada?

Em ordem, porque fazer as duas primeiras é a maior parte do valor:

1. Escreva os cinco paths onde errar sai caro. Cinco, não cinquenta — o ponto é que a lista seja lida. Migrações, auth, o código de pagamentos, a configuração compartilhada, os que forem os seus.
2. Coloque um nome ao lado de cada um. Para que “isso deveria mudar?” tenha para onde ir. Não precisa ser um owner formal; precisa ser uma pessoa.
3. Comece toda peça de trabalho dizendo o que ela não pode tocar. Uma linha, antes de o código existir. Essa é a frase de maior rendimento do desenvolvimento agêntico e não custa nada.
4. Uma vez por semana, olhe o que de fato mudou contra o que você achava que estava sendo trabalhado. Não uma revisão do código: uma comparação de duas listas. O vão é onde as surpresas moram, e uma vez por semana basta para pegá-las enquanto ainda estão baratas.

Nada disso é um produto e nada disso precisa de permissão. Se acabar importando para você, a próxima pergunta é o que impõe isso quando todo mundo está ocupado — que é onde o resto disso fica interessante.

Onde o CommitCycle entra

Essa lista é a coisa sobre a qual a gente constrói. As zones são os paths que doeriam, cada uma com um owner e um risk level. Uma task declara o que toca antes de começar, e mover um muro exige uma aprovação com um motivo. Cada agente ganha um grant preso a uma task e a um branch que expira sozinho, então duas sessões em worktrees próprios não conseguem se autorizar mutuamente em silêncio — dividindo um mesmo diretório elas ainda conseguem, e é por isso que o worktree é a instrução, não uma preferência. Cada task fecha com um registro do que declarou contra o que tocou.

Onde isso de fato está, em bom português: o enforcement se instala hoje como plugin do Claude Code; o pacote commitcycle no npm coloca cycle no seu PATH e não carrega hook, então ele te dá o processo sem o muro. O board hospedado é só por convite enquanto isso é pequeno. O modelo de zones é agnóstico de agente, mas o ponto de enforcement precisa de um pequeno adaptador por harness, e hoje exatamente um é publicado.

E o limite honesto que vale repetir: negar uma chamada de ferramenta em voo não é o que torna isso diferente. Vários fornecedores entregam isso e o Claude Code inclui de graça. A parte que é nossa é o grant preso a uma única task, atribuído a um owner, e que expira sozinho — e o registro depois que diz o que realmente aconteceu.

Se você é uma pessoa só num protótipo, nada disso é problema seu ainda, e o post dos primeiros passos é o mais útil — ou o do setup, se o protótipo começou a parecer que vai sobreviver ao mês.