Executando verificação de segurança...
4

O que a Reescrita do Next.js nos faz pensar? O que achou disso?

É rapeize, recentemente aconteceu um marco técnico que deveria acender um alerta vermelho em qualquer um de nós: a reconstrução funcional de um framework complexo (Next.js) em apenas uma semana, utilizando agentes de IA e um único engenheiro de direção. Esse é o Vinext. Custou 1100 dólares, e o resultado: compilação 4,4x mais rápida, bundle 57% menor.

O que vimos com o Vinect não é apenas "mais uma ferramenta", mas a prova de que a complexidade que vendemos como "essencial" pode ser na verdade um vício arquitetural. Eu pessoalmente sempre defendi esse ponto, de que abstração demais, principalmente no frontend era uma merda. Essa ideia de Clean Arch no front e outras coisas, geravam complexidade desnecessária. O Mano Deyvin lançou um vídeo comentando sobre isso e levantou uns temas:

  1. A Política do "Sabor Open Source"

Vivemos uma era que usam o Open Source como estratégia de captura de mercado. O Next.js consolidou-se como um padrão, mas ao atrelar funcionalidades críticas ao Turbo Pack (que é proprietário né papai) e otimizar o framework especificamente para a infraestrutura da Vercel, criaram na prática um isolamento técnico. Por isso é só saBOR open-source.

Em negócios, isso é brilhante: você controla o framework que dita as regras do mercado e, "coincidentemente", a melhor forma de rodar ele é na sua própria nuvem. Isso gera um efeito de manada onde a comunidade passa a defender abstrações que, na prática, servem para sustentar um modelo de negócio de hospedagem, não necessariamente para resolver o problema do cliente final. Vocês já ouviram o papo de que o MC Dondals não lucra vendendo hamburguér e sim possuindo propriedades e ganhando com aluguel delas? Fizeram isso no software e ninguém discutiu muito sobre né... A Cloudflare foi lá e deu um tiro na principal fonte de receita da Vercel, porque simplesmente atrapalhava o negócio deles.

  1. O Triunfo da Especificação sobre a Intuição

O que permitiu que uma IA reescrevesse um framework em sete dias? Rigor Metodológico.

O sucesso desse experimento aconteceu por conta de três pilares que muitas vezes negligenciamos em nossos "projetos de mundo real":

Contrato de API Imutável: A especificação era clara. Quando o input e o output são determinísticos, a implementação torna-se um problema de busca, não de criatividade.

Suíte de Testes como Sistema Imune: Com mais de 1.700 testes unitários e centenas de E2E, a IA não precisava "acertar"; ela precisava "não falhar". O erro era o feedback imediato para a autocorreção.

Arquitetura Pragmática: Ao trocar o Turbo Pack pelo Vite e focar em Edge Workers, eliminou-se o "bloatware" arquitetural. O resultado? Uma compilação 4.4x mais rápida.

Isso nos remete à famosa Navalha de Occam: a solução mais simples tende a ser a correta. Se uma IA, guiada por especificações claras e uma suíte de testes rigorosa (mais de 1.700 testes), consegue entregar o mesmo valor sem o "peso morto" arquitetural acumulado em anos, precisamos questionar: estamos construindo soluções ou apenas empilhando camadas para satisfazer o ego técnico e criar palestras legais em enventos Tech?

Mas a maior discussão que eu queria levantar aqui é: E agora? kkk
Mudanças que impactam as áreas sempre aconteceram, mas a diferença agora é a velocidade. Um engenheiro SOZINHO da Cloudflare usou IA para reimplementar partes do Next.js em UMA FUCKING SEMANA. O que isso significa para um time de 5 pessoas que mantinha uma base de código parecida? Não necessariamente que elas serão demitidas amanhã, mas pode ter certeza que os CEOs e CFOs vão começar a pensar no "Quando" e não no "Como". Por enquanto é uma redistribuição, e, historicamente, redistribuições tecnológicas tendem a concentrar ganhos em cima e distribuir custos embaixo.

O Vinext provou que a barreira de código é muito mais baixa do que imaginávamos. O diferencial até agora é a profundidade do fundamento técnico. Mas até quando? Quantas pessoas com essa profundidade precisam pra sustentar o Software Global?

Carregando publicação patrocinada...
2

A primeira coisa a se levar em consideração é que por ser um framework já com um bom tempo (é de 2016), ele tem um monte de débito técnico (coisa que a IA já não teve). É claro que eles poderiam ter sido mais abertos com a comunidade para melhorar todas essas coisas, mas se a vercel não tivesse sido como ela foi, não teríamos chegado no ponto em que estamos (não é nem defesa da empresa, é só um fato mesmo). Já era hora de alguém reinventar, eu tentei usar o tanstack, mas não me pareceu tão intuitivo e tão tranquilo quando o Next.js. Querendo ou não, eles se tornaram referência, agora ou eles encolhem o projeto, otimizam tudo ou vai passar a hora deles (se o vinext realmente conseguir resolver todos os problemas que o next já resolve). Outro ponto a ser discutido é que a vercel não chegaria onde chegou com um projeto open-source sem grana no bolso (coisa que é causa de morte de muitos projetos open-source), inclusive de patrocínio mesmo, não só de um modelo de negócio "predatório" (não sei se é o termo correto)

1

Eu só consigo pensar numa coisa: Tem espaço pra todo mundo se tornar trabalhador meramente arquitetural? Acho que o maior problema é a velocidade das mudanças sem o tempo de absorção dos profissionais por outras áreas. Enquanto a demanda está diminuindo na nossa área, ela não está aumentando em outras. A economia vai colapsar se 50% dos trabalhadores de TI e outras áreas tiverem sem emprego em 2027,2028. Não dá nem tempo de trocar de profissão.

Isso impacta o ramo de Aluguel, Varejo, e etc. Se todo o dinheiro ficar concentrado em poucas pessoas de alto poder nas empresas, o que acontece?

Pra mim, inventando número só pra servir de exemplo: Se você automatiza o trabalho de 30% da força de trabalho e não redistribui a renda gerada por essa automação, você destrói o consumo que sustenta a própria economia que a automação deveria estar servindo. Uma maluquice do caralho, que já aconteceu na história.

Sem sacanagem, quem é que vai comprar o produto que a IA ajudou a produzir mais barato, se quem comprava esse produto não tem mais salário?

Igual eu falei, já aconteceu coisas similares antes, mas as ações eram diferentes. Em 1914 Ford dobrou o salário dos operários justamente porque percebeu que não adianta o trabalhador fazer mais e não ter condições de comprar o carro que ele mesmo fazia. Num era bondade, era lógica econômica. Aí a lógica atual é o inverso disso: corta headcount, concentra margem, distribui para acionistas. Tá funcionando enquanto ainda tem consumidores com renda. Mas é óbvio que vai parar de funcionar quando a automação corroer essa base.

Só consigo ver dois caminhos:

Um é redistribuição forçada, que é a famosa renda básica ou uma taxação de automação e, algo defendido em alguns países, a redução de jornada. Só que esse caminho exige vontade política que hoje não existe em nenhum lugar, e se eu puder opinar, não resolve o problema. Se alguém recebia 15K de salário por mês e passa a receber 3K de renda básica universal e não consegue se realocar em pouco tempo, a economia sofre um impacto. Taxar a automação creio que dificilmente seria aprovada em qualquer lugar, já que a automação é incentivada pelos Governos. Reduzir a jornada, só funcionaria se os CEOs e Acionistas pensassem como Ford, mas não é o que vem mostrando os acontecimentos.

O outro caminho é o que geralmente acontece quando a redistribuição não vem: contração econômica severa, instabilidade social, e eventualmente algum tipo de ruptura política, que pode ser progressista ou reacionária, a história não tem preferência, mas se eu pudesse apostar seria reacionária.

O problema real não é tecnológico. É de distribuição de poder sobre quem captura o ganho da automação. E esse é um problema político, que a gente só pode assistir e discutir um pouco. Quem tem reservas financeiras, que tente lucrar com isso enquanto dá.