Pular para o conteudo
AI Coding Flow
Voltar aos artigos
nextjscloudflarevercelviteia-codingvinext

Cloudflare Recriou o Next.js em Uma Semana com IA — O Que Realmente Aconteceu

O vinext da Cloudflare reimplementa 94% da API do Next.js usando Vite, criado por um engenheiro com Claude AI por US$ 1.100. A Vercel respondeu com 7 vulnerabilidades. Aqui está a história completa.

9 min de leitura

Cloudflare Recriou o Next.js em Uma Semana com IA — O Que Realmente Aconteceu

Um engenheiro, 800 sessões de IA, US$ 1.100 em tokens da API do Claude, e uma guerra de frameworks que está mudando como pensamos sobre vantagens competitivas em open source.

A versão curta

Em fevereiro de 2026, a Cloudflare lançou o vinext — um plugin Vite que reimplementa a API pública do Next.js. Roteamento, renderização no servidor, React Server Components, server actions, cache, middleware. Tudo rodando no Vite em vez do compilador do Next.js.

Steve Faulkner, Diretor de Engenharia na Cloudflare, construiu em uma semana usando Claude AI. O custo: aproximadamente US$ 1.100 em tokens de API.

Dois dias depois, o CEO da Vercel, Guillermo Rauch, divulgou sete vulnerabilidades de segurança no vinext — duas críticas, duas altas, duas médias, uma baixa. A internet teve opiniões.

Essa é a história completa.

O que o vinext realmente é

O vinext não é um fork do Next.js. Ele não copia o código-fonte do Next.js. Em vez disso, reimplementa a mesma superfície de API como um plugin Vite.

Na prática: você pega um projeto Next.js existente, troca next por vinext nos scripts, e seu app roda no toolchain do Vite. Mesmo diretório app/, mesmo diretório pages/, mesmo next.config.js. A API que o desenvolvedor usa é a mesma — o motor por baixo é diferente.

O que ele cobre:

  • App Router: layouts aninhados, loading states, error boundaries, rotas paralelas, rotas interceptadas
  • Pages Router: getStaticProps, getServerSideProps, getStaticPaths, _app, _document
  • React Server Components via @vitejs/plugin-rsc
  • Server Actions, middleware, cache
  • ~94% da superfície da API do Next.js 16

E é rápido. Em um app de teste com 33 rotas, builds de produção terminaram em 1,67 segundo usando o bundler Rolldown do Vite 8 versus 7,38 segundos do Next.js 16 com Turbopack — 4,4x mais rápido. Os bundles do cliente encolheram de 168,9 KB para 72,9 KB (gzip), redução de 57%.

A própria Cloudflare avisa que esses números são "direcionais, não definitivos" — baseados em um único teste, não em apps de produção reais. Justo.

Como um engenheiro construiu um framework em uma semana

Essa é a parte que chamou a atenção de todo mundo.

Steve Faulkner passou algumas horas definindo a arquitetura com o Claude — o que construir, em que ordem, quais abstrações usar. A partir daí, o fluxo foi metódico: definir uma tarefa, deixar a IA escrever a implementação e os testes.

Mais de 800 sessões de IA produziram a maior parte do código. Mas o detalhe importante: cada linha passa pelas mesmas verificações de qualidade que você esperaria de código escrito por humanos. O projeto tem:

  • 1.700+ testes unitários com Vitest
  • 380 testes E2E com Playwright (portados da própria suíte de testes do Next.js)
  • Type checking completo via tsgo
  • Linting via oxlint

Faulkner foi claro sobre o elemento humano: "Tive que corrigir o rumo regularmente." Decisões de arquitetura, priorização, saber quando a IA estava indo para um beco sem saída — tudo isso foi julgamento humano.

Essa é uma distinção relevante. Não foi "vibe coding" no sentido descuidado. Foi um engenheiro experiente direcionando IA com intenção e validando o resultado por meio de testes rigorosos.

Por que a Cloudflare fez isso

A resposta começa com uma palavra: portabilidade.

O Next.js é o framework React mais popular. Mas tem se tornado cada vez mais otimizado para a infraestrutura da própria Vercel. Funcionalidades como ISR, middleware, otimização de imagens e cache funcionam melhor — e às vezes só — na Vercel.

A Cloudflare já havia investido no OpenNext, um adaptador que transforma o output de build do Next.js para rodar em outras plataformas. O pacote @opennextjs/cloudflare permite fazer deploy de apps Next.js no Cloudflare Workers. Funciona. Mas está sempre correndo atrás dos releases da Vercel.

O vinext toma uma abordagem diferente: em vez de adaptar o output do Next.js, reimplementa a API do zero. Se sua vantagem competitiva depende de complexidade de implementação e sua suíte de testes é pública, você publicou o blueprint da sua própria substituição.

A Cloudflare também introduziu um recurso experimental chamado Traffic-aware Pre-Rendering (TPR): usa analytics de zona da Cloudflare no momento do deploy para pré-renderizar páginas baseado em padrões de tráfego recentes. Páginas fora desse conjunto caem para SSR sob demanda com cache ISR. Isso só é possível porque o vinext controla todo o pipeline de build.

A resposta da Vercel

Dois dias após o anúncio, o CEO da Vercel, Guillermo Rauch, postou no X:

"Identificamos, divulgamos de forma responsável e confirmamos 2 vulnerabilidades críticas, 2 altas, 2 médias e 1 baixa no framework vibe-coded da Cloudflare, Vinext. Acreditamos que a segurança da internet é a prioridade mais alta, especialmente na era da IA."

As vulnerabilidades incluíam Server-Side Request Forgery (SSRF), fluxos de autenticação quebrados, headers de segurança ausentes e parsing incorreto de caminhos.

A Vercel submeteu as descobertas pelo programa de bug bounty da Cloudflare e ofereceu doar as recompensas para pesquisa em IA e cibersegurança.

O timing e o enquadramento foram... estratégicos. Junto com a divulgação de segurança, a Vercel publicou um guia "Migre da Cloudflare para a Vercel". Transformar uma divulgação de segurança em oportunidade de aquisição de clientes é uma jogada ousada.

Para dar contexto: o pesquisador de segurança Sam Curry notou que havia reportado uma vulnerabilidade de parsing de caminhos no próprio Next.js dois anos antes — e a Vercel reportou exatamente a mesma classe de vulnerabilidade no vinext. Como Curry colocou, uma "coincidência engraçada."

Descobertas independentes de segurança

A Vercel não foi a única olhando. Pesquisadores independentes da Hacktron AI rodaram sua própria auditoria e encontraram 45 vulnerabilidades, 24 das quais foram validadas manualmente. As descobertas críticas incluíam:

  • Poluição de estado entre requisições: o vinext usou AsyncLocalStorage.enterWith() para passar dados de requisição entre os sandboxes RSC e SSR. Mais simples que a alternativa, e todos os testes passaram. Mas os testes só enviam uma requisição por vez. Em produção com tráfego concorrente, a requisição de um usuário poderia ler o token de autenticação de outro.
  • Chaves de cache inseguras: o fetch patcheado do vinext usa URL, método HTTP e corpo da requisição como chave de cache. O que falta? Headers da requisição. Isso significa que requisições autenticadas e não autenticadas poderiam compartilhar respostas em cache.

Esses não são problemas triviais. São o tipo de bug que surge de código gerado por IA que passa em testes unitários mas não foi revisado por um humano que entende padrões de concorrência em produção.

O que isso significa para desenvolvedores

Se você usa Next.js na Vercel

Nada muda para você agora. A Vercel continua sendo a plataforma mais otimizada para Next.js, e é improvável que isso mude em breve.

Se você faz deploy de Next.js em outro lugar

Agora você tem opções:

  • OpenNext (@opennextjs/cloudflare): a abordagem madura e testada em produção. Transforma o output de build do Next.js para Cloudflare Workers. Suporta Next.js 14 e 15. É o que a maioria dos times deveria usar hoje.
  • vinext: experimental, builds mais rápidos, visão mais ampla. Mas não está pronto para produção na maioria dos casos. Fique de olho.

Se você está pensando em escolhas de framework

Esse episódio revela algo importante: vantagens competitivas construídas sobre complexidade de implementação estão erodindo. Quando um engenheiro consegue reimplementar 94% da API de um framework em uma semana usando IA, o valor se desloca de "código que funciona" para "código que foi battle-tested, protegido e mantido ao longo de anos."

Escrever é barato. Confiança é cara.

Se você se interessa por desenvolvimento assistido por IA

O vinext é um dos case studies mais interessantes de engenharia assistida por IA até o momento. Não porque o código é perfeito — claramente não é — mas porque demonstra o que é possível quando um engenheiro experiente usa IA como multiplicador de força com testes rigorosos.

O custo de US$ 1.100 para atingir 94% de cobertura da API é o número que vai tirar o sono dos mantenedores de frameworks.

O contexto maior

Isso não é realmente sobre vinext vs Next.js. É sobre duas mudanças acontecendo simultaneamente:

  1. Portabilidade de plataforma está virando campo de batalha. Desenvolvedores estão rejeitando vendor lock-in. OpenNext, vinext e projetos similares são o resultado.

  2. IA está comprimindo o tempo de reimplementação. O que antes levava meses com um time agora leva uma semana com um engenheiro. Isso muda a economia das vantagens competitivas em software.

Cloudflare e Vercel vão continuar competindo. O vinext vai ficar mais seguro. O Next.js vai melhorar sua história de self-hosting. Desenvolvedores se beneficiam de tudo isso.

A guerra dos frameworks de 2026 está apenas começando.

Referências