Vibe coding para monitorar memória ao rodar vários workers em paralelo sem travar

Quem decide quantos workers você consegue rodar em paralelo não é o provedor do modelo, é a memória da sua máquina, e ela está dividida com o navegador, o gravador de tela, o editor e tudo mais que ficou aberto desde cedo. Thiago abriu uma live do build em público da agência dele com o sistema recém-fechado, e já contou a causa:

"Estávamos trabalhando no plano e fechou o sistema por falta de memória, por conta que eu abri outras coisas aqui no meu computador."

Ele aponta as próprias aplicações abertas, não o agente. Horas depois, na mesma sessão, decidiu colocar mais workers para rodar ao mesmo tempo, já sabendo qual recurso ia apertar.

Quantos workers dá para abrir não tem número fixo

Quem procura essa resposta quer um número, e ele não existe. O teto muda conforme o que mais está aberto no seu computador naquele momento. A mesma máquina, no mesmo projeto, aguenta mais workers com o navegador leve e bem menos com o gravador de tela rodando e o editor cheio de coisa. Foi assim que o sistema dele fechou logo cedo, sem worker nenhum envolvido: as outras aplicações já tinham comido a memória.

Quem faz vibe coding com vários agentes ao mesmo tempo costuma procurar esse limite no plano que assinou. Ele está na barra de memória do próprio computador, compartilhada com tudo que você usa para trabalhar e para transmitir. O mesmo problema apareceu em vibe coding para organizar varios documentos de plano sem apagar historico.

No vibe coding, o recurso que acaba primeiro é local

Paralelismo é acelerador: tarefas que aconteceriam em fila passam a acontecer juntas. A conta fica torta porque a memória some sem avisar. Foi o que aconteceu com ele de manhã, com o sistema fechando no meio do trabalho em vez de reclamar antes.

O custo de cair no meio de uma rodada vai além de reabrir a máquina. Você perde o estado do que estava em andamento e fica sem saber em que ponto cada worker parou, quais mudanças chegaram ao código e quais evaporaram. Descobrir o que precisa ser refeito costuma custar mais que refazer.

A pergunta que ele fez antes de autorizar

O agente perguntou se podia usar mais workers para terminar mais rápido. Ele autorizou, mas antes verbalizou a dúvida certa:

"Será que não vai crashar minha memória de novo?"

Essa pergunta muda o tipo de autorização que ele deu. Em vez de "pode", virou "pode, e eu vou olhar". Escalar e escalar com acompanhamento parecem a mesma decisão no instante em que você aprova, e só se separam mais tarde, quando o consumo sobe e alguém está ou não está vendo.

Olhar o número enquanto os workers rodam

Com a rodada em andamento, ele foi narrando o consumo em voz alta:

"71% memória tá indo pro saco"

Em outro trecho da sessão, olhando o processador, o comentário foi "CPU tá com 40% de uso". Nenhum dos 2 números fez ele parar nada; serviram para saber quanta folga ainda tinha. Acompanhar o consumo durante a rodada é o que transforma a autorização em decisão reversível, porque dá tempo de fechar um worker antes do travamento. Sem esse número à vista, a primeira informação que chega é a máquina apagando.

Vale separar este caso de outro dia em que a memória dele estourou: lá o problema era não deixar o agente em loop de retry sem limite, repetição que ninguém percebeu a tempo; aqui não houve falha alguma, houve crescimento decidido por ele com o consumo sendo acompanhado.

O que fazer antes e durante uma rodada com vários workers

Antes de autorizar, feche o que não vai usar na próxima meia hora e deixe o monitor de memória visível em algum canto, não escondido atrás das janelas de trabalho. Anote mentalmente o número de partida, porque é ele que dá sentido ao número que você vai ver depois. Decida também o seu teto antes de precisar dele, um valor a partir do qual você fecha um worker em vez de torcer, e saiba o que você perde se a máquina cair agora: se a resposta for "não faço ideia", esse é o problema a resolver antes de aumentar o paralelismo.

Durante, olhe o consumo nas paradas que a rodada já te dá, cada aprovação de permissão, cada resposta que você lê. Se o número subiu e continua subindo, encerre um worker enquanto a decisão ainda é sua. Se estabilizou, siga e abra outro se quiser ir mais rápido. É esse hábito pequeno que faz o vibe coding aguentar uma sessão longa com várias coisas rodando ao mesmo tempo.

Dá para ver a rodada inteira, com os workers subindo e a memória junto, ao assistir à live.