Como separar ambiente de cliente e projeto pessoal no vibe coding

O projeto que alguém está pagando roda na ferramenta mais estável que você tem. A que ainda está sendo construída fica para os seus projetos, onde um bug do próprio ambiente custa uma tarde sua e nada além disso.

Guilherme Saraiva contou essa divisão ao vivo, quando o papo do chat chegou em por onde cada um roda o assistente de código no dia a dia. Ele trabalha dentro da IDE e mantém 2 ambientes, separados pelo dono do projeto: cliente em um, projeto paralelo no outro. O motivo dele:

às vezes rola uns bugzin, algumas coisas e eu não quero que dê bug no projeto do cliente

O critério da separação é o risco de quem paga

A ferramenta que ele deixa para os projetos pessoais está sendo construída agora, e isso a torna instável, que é coisa diferente de ser ruim. Software em obra quebra em lugar que já funcionava, e às vezes o erro que aparece na sua frente é dele.

Enquanto o projeto é seu, isso é aceitável. Você perde a tarde, reporta o bug e espera o conserto. Num projeto pago o mesmo evento muda de natureza, porque quem carrega o atraso passa a ser o cliente, e do lado de lá não dá para distinguir um bug do ambiente de um erro seu. Ele contratou uma entrega, e o que chegaria até ele seria o atraso.

Guilherme resolve isso no ponto em que a decisão sai barata, que é a hora de abrir o projeto. Para o trabalho de cliente ele fica com o que já rodou bastante:

Então eu uso que já tá bem estruturado

Alguém vai pagar o preço de usar ferramenta nova

Adotar cedo tem retorno real. Você aprende a ferramenta antes de ela virar padrão, e o seu report chega enquanto ainda dá tempo de mudar o produto. O preço é o bug que ninguém tinha visto antes, e Guilherme continua pagando esse preço dentro dos projetos dele, longe da entrega paga.

Vale para muito além de assistente de código. Framework em versão zero e biblioteca adotada na semana do lançamento entram na mesma conta: você quer as duas por perto, e não quer nenhuma delas na primeira entrega de um contrato.

Manter 2 ambientes custa pouco quando o vibe coding é a sua carteira inteira

Logo depois de dizer que cuida de tudo pelo ambiente estável, ele estimou o tamanho da carteira, e a estimativa explica por que a separação sai barata para ele:

Eu tenho vários vários projetos que eu deve ter uns 12, uns 13, sei lá

Ele não sabe o total exato e não precisa saber. Quem carrega uma carteira desse tamanho já divide o trabalho de algum jeito, porque não cabe tudo aberto ao mesmo tempo. O ambiente vira mais um eixo dessa divisão que já existe, escolhido uma vez, no dia em que o projeto nasce, e não a cada sessão.

A separação por ferramenta também aguenta mais do que uma regra de disciplina. "No cliente eu tomo mais cuidado" depende de você lembrar da regra justo no dia corrido, com o cliente cobrando. Abrir o projeto do cliente num ambiente onde o beta nem está instalado não depende de memória nenhuma, porque a escolha foi feita antes, quando você estava calmo. O mesmo problema apareceu em onboarding de cliente. Isso aparece também em vibe coding para testar em ambiente local antes do servidor do cliente. Vale ver como isso terminou em ambiente de homologacao. Foi o mesmo caminho de ambiente de producao. Foi o mesmo caminho de mvp projeto. O mesmo problema apareceu em como nao desistir de um projeto com vibe coding.

O custo que sobra é conhecer 2 ambientes de verdade, com os atalhos e a configuração de cada um duplicados. É o que você paga para poder usar o beta todo dia.

Como montar essa separação no seu vibe coding

Liste seus projetos abertos e marque quais têm alguém pagando do outro lado. Essa coluna define o ambiente estável.

Depois olhe o que você instalou nos últimos meses e ainda está em beta ou em construção. Cada uma dessas ferramentas sai da coluna paga hoje e passa a viver nos seus projetos pessoais, onde um erro do próprio ambiente atrasa só você.

Por último, e é isso que faz a regra durar: toda ferramenta nova entra pela coluna pessoal. Ela só atravessa para o lado do cliente depois de algumas semanas em que nada te surpreendeu. A via de volta vale igual, e é a parte que quase ninguém escreve: no dia em que a ferramenta estável começar a te surpreender, ela desce para a coluna pessoal e o trabalho pago muda de casa.

As leis do movimento cobram esse tipo de conversa de quem constrói na frente dos outros, dizendo em público qual ferramenta ainda não entra no trabalho pago e por quê. Decidir isso antes de o problema existir é o que mantém o vibe coding longe de virar teste de novidade em cima da entrega alheia. Dá para assistir à live e ouvir ele emendar a divisão dos ambientes com a lista de projetos que carrega.