O Glossário do DEV Fullstack 2026 com Vibecoding

Andrej Karpathy cunhou o termo vibe coding em fevereiro de 2025 num tuíte que parecia provocação e virou agenda. A ideia: deixar o modelo escrever o código e o humano dirigir o resultado por intenção, conversa e revisão. Em 2026, esse modo de trabalho deixou de ser curiosidade e virou padrão em times sérios da Vercel, Anthropic, OpenAI, Supabase e nas frentes de produto da Brasil GEO.

Karpathy não inventou a prática; ele nomeou um movimento que já estava em curso desde o lançamento do Cursor em 2023, do GitHub Copilot em 2021 e do Codex original em 2021. O batismo importa porque, quando uma prática ganha nome, ela ganha contorno. A partir do nome, time pode discutir, recrutador pode procurar, escola pode ensinar. Nomear é o primeiro ato de engenharia coletiva.

A confusão começa quando alguém interpreta vibe coding como ausência de engenharia. É o oposto. O modelo zera o custo marginal de digitar uma linha, mas não zera o custo de decidir qual linha existir, em qual repositório, sob qual contrato e com qual reversibilidade. O gargalo desloca-se da produção textual para a curadoria estrutural.

Pense no equivalente histórico. Quando o Excel chegou na década de 1980, contadores não pararam de existir; eles passaram a fazer mais análise por hora e menos cálculo por hora. Quando o Photoshop chegou nos anos 1990, designers não pararam de existir; eles passaram a fazer mais composição por dia e menos manipulação manual. O padrão se repete: a ferramenta nova zera o custo da etapa repetitiva e empurra o profissional para a etapa de julgamento.

Resumo numa equação que vai aparecer várias vezes neste curso: P(T) = f(clareza, contexto, raciocínio). A probabilidade de o modelo entregar a tarefa T cresce com a clareza do pedido, com o contexto carregado na janela e com o raciocínio explícito (chain-of-thought, planos, listas de verificação). Quem domina essa função produz dez vezes; quem ignora, debuga vinte vezes.

A clareza vem da especificação: o que entra, o que sai, qual o critério de sucesso. O contexto vem do material colado na janela: arquivos relevantes, exemplos, restrições, padrões do time. O raciocínio vem do modo como o modelo é instruído a pensar: passo a passo, com plano antes da execução, com auto-crítica antes da entrega. Os três fatores são multiplicativos; quando um deles vai a zero, o produto inteiro vai a zero.

Antes de falar de Git, de testes ou de deploy, precisamos compartilhar o vocabulário. Vinte termos compõem o chão de fábrica do DEV em 2026. Sem eles, qualquer conversa com o modelo, com o tech lead ou com o cliente vira ruído. O resto do curso assume que estes termos são reflexo.

Carregar esses vinte termos como vocabulário ativo muda como o DEV pensa. Antes de pedir ao modelo para gerar código, é preciso decidir: vai para qual repo, qual stack, qual ambiente, com qual variável, com qual segredo. Essas decisões antecedem qualquer linha gerada e definem se o output vai funcionar ou se vai virar lixo.

O caso prático mais frequente em times brasileiros: o DEV abre o Cursor ou o Claude Code, descreve a tarefa em uma frase, recebe trezentas linhas de código e cola direto no editor. Funciona em localhost, mas quebra em produção porque o modelo assumiu uma variável de ambiente que não existe, uma versão de Postgres diferente da real ou uma stack que o time deixou de usar há dois anos. Cada falha desse tipo se rastreia até uma das vinte palavras acima.

A separação entre dev environment e production é o erro mais caro que iniciantes cometem. Em desenvolvimento, é tentador conectar diretamente ao banco de produção para testar, popular dados ou debugar. Cada vez que isso acontece, o DEV está dirigindo um carro de Fórmula 1 com cinto de ferro de passar roupa. A regra é simples: produção é leitura para humanos e escrita só para o pipeline automatizado de deploy. Tudo o mais é ensaio, e ensaio acontece em outro palco.

Outro nó comum: o DEV trata environment variables como detalhe de configuração e segredos como detalhe de variável. Não é. Variável de ambiente é contrato; cada nome carrega expectativa de tipo, de presença e de origem. Segredo é variável de ambiente com responsabilidade adicional: nunca aparece em commit, nunca em log, nunca em chat. A Cloudflare oferece secrets via wrangler secret put; a Vercel via dashboard; a Supabase via Vault. Confundir os três cofres é como guardar a chave do cofre dentro do cofre.

Sobre arquitetura, há uma confusão recorrente entre escolha de stack e desenho de sistema. Stack é o quê: Next.js, Postgres, Cloudflare Workers. Arquitetura é o como: quem chama quem, com qual contrato, sob qual restrição de latência, com qual estratégia de cache. Dois produtos com a mesma stack podem ter arquiteturas radicalmente diferentes, e dois produtos com stacks distintas podem implementar a mesma arquitetura. Confundir os planos leva o DEV a achar que escolher o framework certo resolve o desenho; não resolve.

Sobre system design em entrevistas técnicas, o filtro implícito mudou de 2020 para 2026. Antes, o entrevistador queria ver se o candidato sabia desenhar consenso entre nós, replicação síncrona e particionamento de Cassandra. Agora, o entrevistador quer ver se o candidato sabe articular trade-offs sob restrição econômica concreta: quanto custa esse Postgres versus esse DynamoDB no volume Z, com que latência média, com que SLA. A engenharia ficou financeira, e o DEV que ignora FinOps perde competitividade.

Há uma competência que rende mais a um executivo do que qualquer conhecimento técnico deste glossário: distinguir a qualidade da evidência por trás de um número. Três níveis costumam aparecer no mesmo slide, com o mesmo corpo de letra, como se valessem igual. O primeiro é telemetria ou experimento controlado, com base grande e método publicado: o GitClear analisou 623 milhões de mudanças de código, o METR rodou um ensaio randomizado com desenvolvedores experientes, o programa DORA em parceria com a Faros.ai coletou dados de 22 mil desenvolvedores.

O segundo nível é a declaração de fornecedor sobre o próprio produto. Sundar Pichai afirmou em 24/04/2026 que 75 por cento do código novo do Google é gerado por IA, sem divulgar metodologia. A Anthropic reportou mais de 80 por cento do código mergeado em 2026 e publicou, no mesmo material, a ressalva de que o multiplicador de oito vezes quase certamente superestima o ganho real. Essa ressalva carrega mais informação do que o número, e é justamente ela que evapora quando o dado atravessa uma apresentação.

O terceiro nível é o número que circula sem fonte primária localizável, e ele domina boa parte do material executivo sobre o tema. A pergunta que separa os três cabe em uma linha e serve para qualquer reunião: quem mediu, com que amostra, e o que essa pessoa vende. Os três níveis têm uso; tratá-los como equivalentes é o que produz decisão cara.

O caso METR mostra por que a distinção importa. Em ensaio randomizado publicado em 10/07/2025, desenvolvedores experientes trabalhando com IA em repositórios que eles próprios mantinham ficaram 19 por cento mais lentos, enquanto estimavam de 20 a 24 por cento de aceleração. O erro de 39 pontos entre desempenho percebido e desempenho medido diz respeito a viés de autoavaliação antes de dizer qualquer coisa sobre a ferramenta. Na atualização de 24/02/2026, os intervalos de confiança passaram a cruzar zero e os próprios autores publicaram a inconclusividade do resultado junto com o viés de seleção da amostra. A lição para quem decide é procedimental: exija baseline medido antes de aprovar orçamento, porque quem aprova investimento pela percepção do time compra aqueles 39 pontos de erro junto.

MVP virou palavra-coringa que perdeu rigor. O sentido original de Eric Ries: a menor coisa que se pode colocar diante de usuários reais para aprender se a hipótese central do produto é verdadeira. Não é versão pobre de um produto rico; é versão focada de um aprendizado. O MVP do landing-page-geo da Brasil GEO em outubro de 2025 era uma única página estática com formulário de contato; o aprendizado era se executivos B2B convertem por aquele tipo de copy. Aprendido isso, o produto cresceu.

Sobre system design, há um equívoco recorrente em entrevistas e em posts de LinkedIn: confundir desenho com diagrama. Desenho de sistema é a sequência de decisões e trade-offs que justificam por que o sistema é assim e não de outro jeito; o diagrama é o subproduto visual dessa conversa. Um candidato sênior não memoriza arquiteturas; ele articula trade-offs. Quando perguntado por que escolheu Postgres em vez de DynamoDB, ele responde com latência, custo, consistência e equipe, não com modinha.

Stack e tech stack carregam função sociológica além da técnica. Quando uma startup brasileira anuncia que usa Next.js, Vercel, Supabase e Tailwind, ela está sinalizando para recrutadores e investidores que opera na fronteira atual; quando uma corporação anuncia que usa Java, Spring, Oracle e Jenkins, sinaliza estabilidade e maturidade. Nenhuma das duas escolhas é melhor em abstrato; cada uma é mensagem para um público. O DEV maduro lê esse subtexto antes de aceitar uma vaga.

Sobre staging, vale uma anedota recorrente em times brasileiros. O ambiente de staging foi criado para imitar produção, mas com o tempo divergiu: dados defasados, dependências em versão antiga, configuração que ninguém atualizou. Quando isso acontece, staging vira teatro caro: passa em todos os testes, mas não preserva o sinal de que produção vai funcionar. A regra prática para evitar a deriva: pipeline automatizado de seed em staging, executado pelo menos uma vez por semana, copiando esquema e dados anonimizados de produção. Sem isso, staging vira museu.

Sobre dev environment, em 2026 a escolha mais saudável para times distribuídos é o Devcontainer ou o GitHub Codespaces. A vantagem é que cada DEV ganha um ambiente idêntico ao do colega, configurado por um arquivo versionado no repositório. Adeus à frase clássica do suporte de TI: na minha máquina funciona. O custo são alguns dólares por mês por DEV; o ganho é eliminar a categoria inteira de bugs causados por divergência de ambiente local.

Sobre prototype versus MVP, há uma diferença que o mercado mistura mas que importa. Prototype é instrumento de exploração: testa uma ideia visual, técnica ou de UX, vive horas ou dias e vai para o lixo. MVP é instrumento de aprendizado de produto: testa uma hipótese de mercado com usuários reais, vive semanas ou meses e evolui. Mandar um prototype para usuários reais sem virar MVP é entregar peça inacabada; manter um MVP em modo de prototype é prolongar exploração depois que ela já cumpriu o papel.

Para fechar este módulo, registre a tese central que os quatro blocos seguintes vão desdobrar. Vibe coding não substitui engenharia; eleva o nível de abstração em que a engenharia acontece. O DEV de 2026 escreve menos código por dia do que escrevia em 2020, mas toma mais decisões de arquitetura, de revisão e de qualidade. A pessoa que sai deste glossário com vocabulário sólido nos cinco blocos consegue conversar com qualquer time de engenharia sério no Brasil ou no exterior, da Brasil GEO à OpenAI.

A última observação deste módulo é prática. Se você terminou a leitura e não consegue, agora, definir os vinte termos sem consultar o texto, releia. O glossário é a fundação do resto; cada módulo seguinte assume que essas vinte palavras são reflexo. O DEV que avança para Git, qualidade, deploy e observabilidade sem dominar o vocabulário básico vai gastar o dobro de tempo em cada conceito novo, porque vai precisar reaprender o chão a cada andar. Vinte palavras. Vinte minutos para fixar. O retorno em produtividade nas próximas semanas paga mil vezes esse investimento.