Todo projeto front-end com Vitest chega nessa pergunta em algum momento: environment: 'jsdom' ou environment: 'happy-dom'?

A resposta que circula por aí é "happy-dom é 2 a 4 vezes mais rápido". Fui atrás de onde vem esse número e, na maioria dos artigos, ele não tem código, não tem metodologia e não tem versão. Então resolvi medir.

Montei uma suíte com 240 testes de componentes React, rodei nos dois ambientes, em configurações diferentes do Vitest, várias vezes. Também testei 20 APIs e comportamentos do navegador nos dois pra ver o que cada um realmente implementa. O resultado tem uma surpresa: a configuração do Vitest pesa mais que a escolha da biblioteca.

No post sobre prompt, context e harness engineering eu separei as três camadas e falei do harness do ponto de vista de quem constrói um agente: idempotência, circuit breaker, gate de aprovação, audit trail.

Só que a maioria de nós não está construindo agente. Está usando um: Claude Code, OpenCode, Cursor, Codex. E aí surge a pergunta óbvia: se o harness da ferramenta já vem pronto, o que sobra pra mim?

Sobra muito. E é justamente a parte que mais muda o resultado no dia a dia.

Se você usa agente de código com frequência, provavelmente já viveu essa cena: três terminais abertos, um Claude Code implementando uma feature, um Codex revisando outra branch, um OpenCode investigando um bug. Você vai tomar um café. Quando volta, dois estão parados esperando você aprovar alguma coisa há 15 minutos, e um terminou faz tempo sem você perceber.

Ou pior: você fecha o terminal sem querer, a conexão SSH cai, e a sessão inteira vai junto.

O Herdr resolve exatamente isso. Ele se descreve como "onde seus agentes de código moram": um runtime de terminal que mantém os agentes rodando em segundo plano, mostra o estado de cada um e expõe uma API pra que scripts (e outros agentes) controlem tudo.

Todo dev JavaScript tem uma história com Date. O relatório que mostrava o dia anterior. O vencimento que pulou de 31 de janeiro pra 3 de março. A data de nascimento que mudou de dia quando o usuário estava em outro fuso. O moment de 300KB instalado só pra somar um mês.

O Date foi criado em 1995, em poucos dias, copiado do java.util.Date. O próprio Java depreciou boa parte dela pouco tempo depois. O JavaScript ficou com ela por 30 anos.

Isso acabou. Em março de 2026 o Temporal chegou ao Stage 4 no TC39 e virou parte do ECMAScript 2026. Já roda sem flag no Chrome, no Edge, no Firefox e no Node 26.

Esse artigo é sobre o que de fato melhorou. Com exemplo real, rodando, lado a lado com o new Date().

Se você acompanha o ecossistema React de perto, provavelmente tropeçou nesse anúncio essa semana. Dominic Gannaway lançou o Octane, descrito como "o modelo de programação do React, compilado". É o sucessor declarado do Inferno, framework que o próprio Gannaway criou lá em 2016 com o mesmo pitch de performance. Um gênio indomável.

Vale parar pra entender duas coisas. Primeiro, o que ele faz tecnicamente. Segundo, e mais importante pra quem decide stack, o que a chegada dele diz sobre pra onde o React está indo.

Vamos para a maior de todas novidades da última semana!

Você já ficou meia hora refinando um prompt, tentando deixar as instruções mais claras, mais detalhadas, com exemplos, com restrições — e o agente continuou errando da mesma forma?

Já passou por isso: o modelo alucina mesmo com o prompt perfeito. Ou pior: o agente age no mundo, faz uma coisa que não deveria, e você vai descobrir isso em produção. Não no chat de testes, não no sandbox. Em produção, com dado real.

Isso não é problema de prompt. E polir o texto do sistema prompt não vai resolver.

Esse artigo é sobre entender onde o problema de fato está — e por que confundir as três camadas de engenharia de IA custa tempo, dinheiro e, às vezes, incidentes.