Cloudflare Reconstruiu o Next.js Com IA em 7 Dias
Um engenheiro. Uma semana. Mil dólares.
Foi isso que custou para a Cloudflare reconstruir o Next.js do zero.
Não corrigir. Não encapsular. Não fazer engenharia reversa da saída de build como todo mundo vinha tentando. Uma reimplementação completa da superfície de API do Next.js — Vite no lugar de Webpack, Cloudflare Workers no lugar de Node.js, e um modelo de deploy que roda no edge por design, não como um improviso.
O resultado se chama V-Next. E quando li o anúncio pela primeira vez, minha reação inicial foi uma mistura de "isso é impressionante" e "espera, isso é estável o suficiente para considerar?" Essas duas sensações coexistiram por cerca de um dia, até eu começar a investigar os detalhes técnicos e os dados de produção.
O que mudou minha perspectiva: o valor de $1.000 não é a parte interessante. O custo é apenas a manchete que chama atenção. O que realmente vale a pena examinar é a metodologia — como um loop de feedback assistido por IA, ancorado na própria suíte de testes open-source do Next.js, transformou o que deveria ter sido um projeto de vários meses para uma equipe em sete dias de trabalho de um único engenheiro. Essa metodologia é mais significativa que o framework em si, porque descreve algo sobre como software complexo será construído daqui para frente.
Há também uma decisão técnica enterrada no V-Next que a maioria das análises ignora — aquela que explica por que a redução do tamanho do bundle é de 57% e não de 15%. Vou chegar lá, mas primeiro você precisa entender por que a Cloudflare estava motivada a fazer isso, porque a história por trás faz as escolhas de arquitetura fazerem sentido.
O Problema de Lock-In da Vercel Sobre o Qual Ninguém Fala com Honestidade
Next.js é um software genuinamente excelente. A Vercel construiu algo que resolveu problemas reais — renderização amigável para SEO, geração estática, renderização server-side, ISR, server actions — e embalou tudo numa experiência de deploy que fazia tudo parecer fácil. O framework e a plataforma cresceram juntos, e essa co-evolução é parte do que tornou o Next.js dominante.
Também é exatamente o que criou a tensão.
A Vercel roda em Node.js completo. Isso dá acesso à superfície completa da API do Node.js — módulos nativos, sistema de arquivos, crypto, streams, tudo. As funcionalidades do Next.js evoluíram assumindo que essa compatibilidade completa estava disponível. Algumas dessas funcionalidades — particularmente as configurações mais avançadas de ISR e padrões de server actions — funcionam na Vercel e se tornam dores de cabeça de manutenção em todo o resto.
Cloudflare Workers é um runtime diferente. Não é Node.js. É um ambiente de execução personalizado baseado em V8 com um subconjunto de APIs web padrão e uma camada limitada de compatibilidade com Node.js. O tradeoff é significativo: Workers roda no edge, em data centers em mais de 300 cidades, com tempos de cold start medidos em milissegundos ao invés de segundos. O perfil de performance é genuinamente diferente. Mas essa performance vem de um runtime restrito, e o Next.js nunca foi projetado com essa restrição em mente.
A tentativa da comunidade de preencher essa lacuna se chamou OpenNext — um projeto open-source que tentou fazer o Next.js funcionar no Cloudflare Workers adaptando a saída de build. O problema era arquitetural. O OpenNext precisava fazer engenharia reversa do que o processo de build do Next.js produzia e então transformar isso para funcionar num runtime diferente. Toda vez que a Vercel atualizava os internos do Next.js (o que acontece constantemente), algo no OpenNext quebrava. Os mantenedores estavam sempre correndo atrás do framework ao invés de construir.
A Cloudflare assistiu a esse ciclo tempo suficiente, avaliou o esforço necessário para manter o OpenNext, e tomou uma decisão diferente: parar de adaptar a saída do Next.js e reconstruir aquilo que a produz.
Isso é o V-Next. Uma implementação limpa da superfície de API do Next.js — o mesmo diretório app/, as mesmas convenções de roteamento, os mesmos padrões de componentes que os desenvolvedores já conhecem — mas escrito do zero tendo como alvo o Cloudflare Workers.
Como a IA Construiu um Framework em Sete Dias
A metodologia é a parte dessa história que continua puxando minha atenção.
A suíte de testes do Next.js é pública. É abrangente — cobrindo comportamento de roteamento, modos de renderização, padrões de data fetching, error boundaries, e algumas centenas de outros casos que definem exatamente como o comportamento correto do Next.js deve ser. É o tipo de cobertura de testes que você gostaria para um framework do qual milhões de aplicações dependem.
O engenheiro da Cloudflare usou esses testes como a especificação. Não a documentação. Não o código-fonte do Next.js. Os testes — porque testes definem comportamento de forma inequívoca de um jeito que documentação em prosa nunca consegue completamente.
O processo rodou como um loop de feedback: a IA gera código, os testes rodam, as falhas são alimentadas de volta para a IA, a IA revisa, os testes rodam de novo. Repetir. A suíte de testes open-source forneceu a verdade fundamental em direção à qual a geração da IA precisava convergir. Sem essa âncora, código gerado por IA se desviaria — produzindo algo que parecia comportamento do Next.js mas divergia em casos extremos de formas que só aparecem em produção.
O papel do engenheiro humano foi supervisão e correção de curso. Quando a IA interpretou mal um requisito, quando dois testes puxavam em direções incompatíveis, quando uma solução gerada tecnicamente passava nos testes mas implementava algo semanticamente errado — esses eram os momentos que exigiam julgamento humano. Não a maioria do trabalho. Mas os 10% críticos que determinavam se o resultado era realmente correto.
O valor de custo — $1.000 — reflete gasto com computação de IA. Uma semana de execuções intensivas de agentes, iterações de testes e ciclos de revisão. Esse número só vai diminuir conforme os modelos ficam mais eficientes.
O que essa abordagem requer é uma suíte de testes abrangente que realmente especifique o comportamento que você está tentando replicar. A maioria dos projetos não tem isso. O Next.js tem porque é um projeto open-source maduro, intensamente mantido, com milhares de contribuidores que se preocupam com a correção comportamental. A metodologia que funcionou aqui funciona precisamente porque a especificação já estava codificada em testes. Essa é uma restrição real, e vale a pena reconhecê-la.
O que acho mais interessante sobre a metodologia é onde o engenheiro humano investiu seu tempo. Não escrevendo código de implementação — a IA cuidou disso. Não rodando testes — CI cuida disso. O trabalho humano foi em grande parte semântico: avaliar se uma solução gerada que passava nos testes estava realmente implementando a coisa certa. Testes verificam comportamento dentro de entradas definidas. Eles não verificam que você escolheu a arquitetura certa para as próximas três versões do framework.
Essa distinção importa. Existe uma classe de decisão — "o estado de roteamento deveria viver em memória ou ser reconstruído a partir da URL em cada requisição?" — onde testes não te dão uma resposta clara, mas as consequências arquiteturais se acumulam ao longo do tempo. Essas são as decisões onde expertise humana é inegociável. A IA consegue gerar ambas as abordagens. É preciso alguém que tenha mantido aplicações Next.js em produção para saber qual delas causa problemas seis meses depois.
A implicação para equipes pensando em aplicar essa metodologia aos seus próprios projetos: vocês precisam de uma suíte de testes densa e um especialista no domínio que consiga auditar o resultado. A IA comprime o tempo de implementação. Ela não elimina a necessidade de julgamento de engenharia. Essas duas coisas são diferentes, e confundi-las é como você acaba com uma codebase que passa todos os seus testes e ainda tem problemas arquiteturais fundamentais.
A Decisão Técnica Que Explica a Redução de 57% no Bundle
Aqui está o que a maioria da cobertura sobre V-Next passa batido.
Trocar Webpack por Vite não é apenas uma substituição de ferramenta de build. As duas ferramentas têm filosofias fundamentalmente diferentes sobre empacotamento.
Webpack foi projetado numa era de HTTP/1 onde empacotar tudo em menos arquivos maiores era a decisão certa — menos round trips significavam melhor performance. Vite foi projetado depois que ES modules se tornaram universais, o que mudou completamente a matemática da otimização. Vite usa ES modules nativos em desenvolvimento e Rollup por baixo dos panos para builds de produção. Ambos são orientados a produzir uma saída menor e mais direcionada que o Webpack.
Além disso, Cloudflare Workers roda no edge — o que significa que a latência geográfica já é resolvida pela arquitetura do runtime. Você não está competindo contra round trips de 200ms para um servidor distante. A localização no edge cuida disso. O que você está otimizando muda de "menos requisições HTTP" para "menor payload total." A filosofia de saída do Vite se alinha melhor com essa restrição.
A redução de 57% no tamanho do bundle não é mágica. É o efeito composto de uma ferramenta de build que produz uma saída mais enxuta combinada com um alvo de deploy que não precisa das otimizações da era Webpack que adicionavam peso aos bundles.
Tempos de build 4x mais rápidos seguem raciocínio similar. A experiência de desenvolvimento do Vite sempre foi mais rápida que a do Webpack — hot module replacement quase instantâneo, cold starts mais rápidos, processamento paralelo que a arquitetura de plugins do Webpack dificultava. Essa vantagem de velocidade se traduz também para builds de produção.
O Que V-Next Faz Com ISR
ISR é uma das funcionalidades mais poderosas do Next.js e também a mais difícil de portar para um runtime diferente. A implementação original de ISR no Next.js usa o sistema de arquivos — ele escreve as páginas regeneradas no disco do servidor, as serve, e revalida em segundo plano.
Cloudflare Workers não tem sistema de arquivos. Ele tem Cloudflare KV — um armazenamento de chave-valor distribuído globalmente com velocidades de leitura no nível do edge.
A implementação de ISR do V-Next usa KV como camada de armazenamento. As páginas são escritas em stores KV, servidas de lá, e revalidadas no intervalo configurado. O comportamento do ponto de vista do desenvolvedor é o mesmo. A implementação por baixo é adaptada às restrições de runtime do Workers.
Isso na verdade é uma boa combinação. Leituras de KV no edge são rápidas. A natureza globalmente distribuída do KV significa que páginas com ISR ficam disponíveis perto dos usuários em todas as mais de 300 localizações de data centers da Cloudflare sem configuração adicional. Na Vercel, ISR requer um comportamento específico de cache no edge que você configura por rota. No V-Next com Cloudflare, a distribuição é uma propriedade da própria camada de armazenamento.
O Que V-Next Significa Se Você Está Construindo Algo Hoje
Antes de começar a migrar qualquer coisa: V-Next é experimental. A Cloudflare tem sido clara sobre isso, e é o enquadramento correto. Várias aplicações reais estão rodando em produção — incluindo CIO.gov, o que é um endosso significativo — mas os casos extremos são reais.
Eis o que ainda não funciona completamente:
Analytics de Open Graph no edge runtime não portam de forma limpa. Se você depende disso para previews de compartilhamento social em configurações específicas, teste antes de se comprometer.
Bindings de blobs em KV e bindings de Postgres têm limitações. V-Next usa as primitivas de armazenamento da Cloudflare, e padrões complexos de integração com banco de dados que funcionam num ambiente Node.js esbarram nas restrições do runtime do Workers. Prisma com conexões diretas ao Postgres, por exemplo, requer Hyperdrive (o serviço de proxy de banco de dados da Cloudflare) para funcionar corretamente.
Turbopack não está integrado. Se você adotou Turbopack para velocidade no desenvolvimento local, no V-Next você está usando Vite — que é rápido, mas é uma ferramenta diferente e algumas configurações específicas do Turbopack não vão se transferir.
O scaffolding do Create Next App não tem um equivalente no V-Next ainda. Você vai configurar projetos manualmente ou adaptar configurações existentes.
Algumas APIs específicas da Vercel das quais o Next.js depende silenciosamente não existem no V-Next. Se você está usando @vercel/og, @vercel/analytics, ou pacotes similares fornecidos pela Vercel que se integram com os internos do Next.js, esses precisam de alternativas.
Projetos onde V-Next faz sentido agora:
Se você está começando um projeto novo e planeja fazer deploy no Cloudflare Workers de qualquer forma, V-Next merece consideração séria. Você obtém a superfície de API do Next.js que já conhece, builds mais rápidos, bundles menores, e não herda as restrições do Webpack.
Se você está na Vercel e custos são um ponto de pressão, vale fazer benchmarks. O modelo de preços da Cloudflare (bandwidth é mais barato, computação no edge é mais barata para certos padrões de uso) pode tornar a economia significativamente diferente em escala.
Se você roda um site de conteúdo de alto tráfego com uso intensivo de ISR, a abordagem com KV tem vantagens reais para performance de leitura global.
Projetos para esperar por enquanto:
Aplicações Next.js complexas que usam muitas funcionalidades específicas da Vercel ou dependem de padrões avançados da API do Node.js vão bater em paredes de compatibilidade. A superfície de migração é grande demais para software experimental.
Aplicações com requisitos rigorosos de estabilidade. Sistemas críticos de produção não pertencem a frameworks experimentais a menos que você tenha capacidade de engenharia séria para lidar com o inesperado.
As Partes Disso Que Deveriam Te Incomodar
Reação honesta: V-Next me impressionou. A abordagem técnica é sólida, os números de performance são reais, e a metodologia de desenvolvimento assistido por IA representa algo genuinamente novo sobre como frameworks podem ser construídos.
E: não tenho certeza de que a Cloudflare é a heroína dessa história.
A Vercel construiu o Next.js. Publicaram como open-source, mantiveram, financiaram seu desenvolvimento por anos. A Cloudflare usou essa superfície open-source — especificamente a suíte de testes que a equipe da Vercel gastou um esforço enorme para construir — para criar um produto concorrente. Isso é legalmente correto. É o que o open-source permite. Mas vale a pena nomear o que é: a Cloudflare se beneficiou diretamente do investimento da Vercel para competir com a plataforma da Vercel.
O problema do lock-in de fornecedor também não desaparece. Ele se muda. V-Next é projetado para Cloudflare Workers. ISR roda no Cloudflare KV. Assets são servidos pelo Cloudflare R2. Se você adota V-Next, não está preso à Vercel — está preso à Cloudflare. A dependência apenas mudou de mãos.
Minha opinião impopular: essa pode ser a troca certa para muitas equipes. A Cloudflare é dona de sua infraestrutura de ponta a ponta — data centers, computação, bandwidth, armazenamento. Essa integração vertical é uma vantagem real para previsibilidade de preços e otimização de performance. A Vercel está construindo em cima da AWS, o que adiciona uma camada à estrutura de custos. Mas desenvolvedores devem entrar com os olhos abertos sobre o que "escapar do lock-in" realmente significa aqui.
Há também um panorama estratégico mais amplo que vale manter em mente. A Cloudflare adquiriu o Astro — outro framework frontend popular — antes nessa linha do tempo. V-Next faz parte de um padrão: a Cloudflare não está mais apenas vendendo infraestrutura. Estão construindo uma plataforma de desenvolvimento full-stack opinada que compete com a Vercel em múltiplos frameworks simultaneamente. O estado final em direção ao qual estão trabalhando é um onde todo o ecossistema de deploy frontend — framework, ferramentas de build, CDN, armazenamento, computação — vive dentro da superfície de produto da Cloudflare.
Isso não é inerentemente ruim para desenvolvedores. A competição entre Vercel e Cloudflare pela experiência do desenvolvedor vai empurrar ambas as plataformas a melhorar. Mas vale reconhecer a estrutura de incentivos por trás do V-Next. Isso é uma jogada de aquisição de clientes, não uma contribuição filantrópica ao ecossistema de frameworks. A Cloudflare quer o tráfego, a retenção e a computação faturável que vem com rodar suas aplicações de produção. V-Next é o meio técnico para esse fim comercial.
Entender isso não torna o V-Next pior. Apenas clarifica a lente através da qual a Cloudflare vai tomar decisões sobre seu desenvolvimento futuro. Funcionalidades que te mantêm na infraestrutura da Cloudflare serão priorizadas. Funcionalidades de portabilidade que facilitem sair não serão.
A história do desenvolvimento assistido por IA também precisa de enquadramento cuidadoso. Um engenheiro + IA + uma semana é notável. Também é um engenheiro que entendia Next.js profundamente, entendia Cloudflare Workers profundamente, e conseguia avaliar a saída gerada por IA com precisão. A IA comprimiu o cronograma de implementação. A expertise humana determinou se a saída comprimida estava correta. Ambas as partes dessa equação importam.
O Que os Números Realmente Mostram
Deixe-me ser concreto sobre o que está comprovado e o que ainda está sendo estabelecido.
Tempos de build 4x mais rápidos: medidos contra projetos reais, não aplicações de brinquedo. Se seu pipeline de CI está gastando 8-12 minutos em builds do Next.js, você está olhando para builds de menos de 3 minutos com V-Next. Isso se acumula numa equipe — menos trocas de contexto esperando builds, feedback de CI mais rápido, mais iterações por dia.
Bundles 57% menores: isso é significativo para o Time to Interactive, especialmente em dispositivos móveis. Uma redução de 57% no tamanho do bundle se traduz diretamente em carregamentos de página mais rápidos em conexões limitadas. Para sites de conteúdo, isso afeta tanto a experiência do usuário quanto as pontuações de Core Web Vitals.
CIO.gov rodando V-Next em produção: um site do governo dos EUA com tráfego real e requisitos reais de compliance rodando software experimental é um sinal significativo. Equipes de TI do governo não correm riscos levianamente. O fato de terem migrado é um dado.
O que ainda não está estabelecido: estabilidade de longo prazo sob padrões complexos de carga, a superfície completa de compatibilidade ao longo da real diversidade de uso do Next.js em codebases de produção, e a trajetória de manutenção uma vez que V-Next alcance as versões atuais do Next.js.
Monitore estas métricas se estiver pilotando V-Next: tempo de build (os logs de CI te dão isso imediatamente), tamanho do bundle (os relatórios de saída de build da Cloudflare reportam isso), e Time to Interactive (Lighthouse ou WebPageTest contra produção). Esses três números te dizem se as vantagens teóricas estão aparecendo na sua aplicação específica.
Uma nota prática: configure primeiro um deploy paralelo. Rode V-Next em paralelo com seu deploy existente na Vercel em rotas não críticas antes de fazer a migração completa. Isso te dá benchmarks com tráfego real sem risco em produção. As lacunas de compatibilidade que importam para o seu projeto específico vão aparecer rapidamente sob condições reais — muito mais confiavelmente do que qualquer teste interno pode revelar. Duas semanas de tráfego paralelo nos seus padrões reais de usuários valem mais do que qualquer comparação de benchmarks do projeto de outra pessoa.
A Parte Que Vale a Pena Refletir
Um engenheiro e um modelo de IA reconstruíram um framework frontend importante em sete dias, e a saída roda em produção em sites reais incluindo um domínio governamental.
Isso não é um benchmark. É uma prova de conceito de como software complexo pode ser construído.
A suíte de testes do Next.js atuou como a especificação. A IA atuou como o motor de implementação. A expertise humana atuou como o portão de qualidade. Essa divisão de trabalho vai aparecer em mais projetos de software nos próximos 18 meses — não apenas reconstruções de frameworks, mas migrações complexas, ports de bibliotecas, e reimplementações de API onde o comportamento correto já está definido mas o trabalho de implementação é proibitivo.
A pergunta interessante não é se a Cloudflare consegue terminar o V-Next. Eles têm a capacidade de engenharia e o motivo de infraestrutura. A pergunta interessante é o que será reconstruído em seguida, por quem, e o que isso faz com a suposição de que software complexo requer equipes de pessoas ao longo de longos períodos.
Se um framework pode ser reconstruído em uma semana, o que mais pode?
Essa é a pergunta que V-Next está realmente fazendo. A resposta vai remodelar como pensamos sobre o custo e o ritmo de trabalho de engenharia ambicioso — e como alguém que constrói profissionalmente com agentes de IA, essa pergunta é significativamente mais empolgante para mim do que qualquer número de benchmark.
🤝 Vamos Trabalhar Juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura de tecnologia? Adoraria ajudar.
- 🔗 Fiverr (desenvolvimento e integrações sob medida): fiverr.com/s/EgxYmWD
- 🌐 Portfólio: mejba.me
- 🏢 Ramlit Limited (soluções empresariais): ramlit.com
- 🎨 ColorPark (design e branding): colorpark.io
- 🛡 xCyberSecurity (serviços de segurança): xcybersecurity.io
