Vibe coding para reiniciar o Next.js quando o RSS chega a 3 GB

Se o Next.js de desenvolvimento está com 3 GB de RSS e o request foi de 400 ms para 1.1 s, reinicie o processo antes de caçar bug no app. O fix da tela que você acabou de aplicar não acelera o processo inchado.

Thiago ouviu o agente no meio da sessão. RSS é a memória residente do processo. O servidor de desenvolvimento estava degradado: 3 GB de RSS e 1.1 s por request, contra 400 ms de antes. O pedido dele foi o restart no computador, com o terminal aberto como administrador.

3 GB de RSS e o request que foi de 400 ms para 1.1 s

O agente mediu o servidor de desenvolvimento depois de um fix na tela: 3 GB de RSS e 1.1 s por request. O tempo por request, antes, era 400 ms. O processo do Next.js de desenvolvimento tinha inchado, e um restart resolveria.

Thiago ouviu o diagnóstico e pediu a ação, com 2 caminhos: o agente faz o restart, ou ensina o passo a passo ali, porque o terminal já estava aberto como administrador.

Beleza? Então, eh, o que você pode fazer agora é fazer esse restart next devidor ou me dizer como eu faço aqui no meu computador, já que o terminal tá aberto aqui como administrador.

Next devidor no áudio é o Next.js de desenvolvimento. O terminal como administrador era o caminho para ele mesmo rodar o restart, se o agente passasse o comando.

O task kill não colou e ele fechou o processo

O primeiro caminho era o agente fazer o restart. O segundo era Thiago rodar o comando no terminal que já estava aberto como administrador. O task kill era esse segundo caminho: ele tentou colar o que o agente tinha passado e não funcionou. Fechou o processo na mão e pediu ao agente para subir o servidor de desenvolvimento de novo.

Olha, tentei colar esse task kill, não funcionou, então eu simplesmente fechei. É, você pode estar subindo aí para mim o servidor.

O processo com 3 GB de RSS acabou quando ele fechou. Faltava o dev server voltar a subir. A live já tem o recorte de query params; aqui o assunto é o processo do Next.js.

O vibe coding reinicia o Next.js antes de caçar bug no app

No vibe coding com agente, a tela lenta vira hipótese de código. Você manda investigar, o agente mexe no app, e o request continua em 1.1 s porque o processo do Next.js já estava com 3 GB de RSS.

A ordem que Thiago executou coloca o restart na frente dessa investigação. Se, com o processo novo, o request ainda estiver em 1.1 s e o RSS não estiver em 3 GB, o bug está no app.

Quem constrói com agente no Next.js de desenvolvimento precisa de RSS e tempo por request à vista. 3 GB e 1.1 s, contra 400 ms de antes, já justificam o restart. Sem esses 2 números, o vibe coding gasta o agente no app enquanto o servidor de desenvolvimento segue degradado.

O fix da tela não devolve o request para 400 ms

Eles tinham acabado de aplicar um conserto na tela. O agente avisou na sequência: aquele conserto não devolve o request para 400 ms. Só impede o travamento. Tratar o patch como se ele tivesse restaurado os 400 ms deixa o RSS em 3 GB: a tela deixa de travar, o request segue em 1.1 s, e a próxima mensagem para o agente é outro bug no app.

A live não mostra o request voltando para 400 ms depois da subida. O recorte termina no pedido para o agente subir o servidor.

Amanhã, se o Next.js de desenvolvimento estiver lento depois de um patch, meça RSS e o tempo por request. Se estiver em 3 GB e o request tiver ido de 400 ms para 1.1 s, reinicie o processo. Só então volte a caçar bug no app.

Dá para assistir à live e ouvir o pedido de restart no computador, com o terminal como administrador, e o "tentei colar esse task kill, não funcionou".