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.

DEV -- abreviação de developer, profissional que projeta, escreve e mantém software. Em 2026, o DEV não é mais quem digita mais rápido; é quem decide melhor o que merece existir.

Full Stack -- profissional que opera nas duas pontas da pilha (front e back) e na cola entre elas (banco, infraestrutura, API). O modelo amplia o alcance de um full stack porque preenche as lacunas de profundidade onde antes era preciso outro especialista.

Vibe Coding -- modo de trabalho em que o humano descreve intenção em linguagem natural e o modelo gera código, que o humano revisa, refatora e integra. Karpathy, fevereiro de 2025. Não significa programar sem ler o código; significa programar lendo mais código do que escrevendo.

Codebase -- o conjunto vivo de arquivos-fonte de um produto. A codebase de alexandrecaramaschi.com cabe num único repositório Next.js; a da Stripe vive distribuída em dezenas. Tamanho não é virtude; coerência é.

Repo (Repository) -- a unidade física onde a codebase é versionada (em geral, no GitHub, GitLab ou Bitbucket). Um repo carrega histórico, permissões, automações e o contrato social do time.

Monorepo -- estratégia de manter vários projetos relacionados num único repositório (Vercel, Google, Meta usam). Vantagem: refatoração atômica entre projetos. Custo: ferramentas de build mais sofisticadas (Turborepo, Nx, Bazel).

Polyrepo -- estratégia oposta: cada projeto vive no seu próprio repositório. Vantagem: autonomia de times. Custo: sincronização e versionamento entre repos vira problema permanente.

Stack -- a combinação concreta de tecnologias usada num produto. Dizer que a stack do landing-page-geo é Next.js 16 + Cloudflare Workers + Vercel diz mais do que mil slides de arquitetura.

Tech Stack -- sinônimo de stack, com ênfase no inventário (linguagem, framework, banco, hospedagem, CDN, observabilidade). Recrutadores adoram listar; engenheiros adoram justificar.

Architecture -- o desenho de alto nível das partes do sistema e dos contratos entre elas. Arquitetura responde a três perguntas: o que existe, como conversa e o que pode falhar sem derrubar o resto.

System Design -- a disciplina de propor uma arquitetura sob restrições de escala, custo, latência e equipe. É o que separa o sênior do pleno em qualquer entrevista séria de OpenAI, Anthropic ou Vercel.

MVP (Minimum Viable Product) -- a menor versão do produto capaz de gerar aprendizado real com usuários reais. Eric Ries popularizou o termo; o erro mais comum é confundir MVP com versão feia, em vez de versão focada.

Prototype -- versão exploratória, descartável, criada para testar uma hipótese visual ou técnica. Protótipo não vai para produção; quem manda protótipo para produção quebra produção.

Production / Prod -- o ambiente onde usuários reais executam o software e onde dinheiro real circula. Em 2026, derrubar produção custa reputação, contrato e, em alguns mercados, multa.

Staging -- ambiente espelho de produção, com dados parecidos e infraestrutura equivalente, usado como último teste antes do deploy. Staging que não parece com prod é teatro.

Dev Environment -- ambiente local ou em nuvem onde o DEV escreve, executa e testa a codebase enquanto programa. Pode ser a máquina física, um container Docker, um Codespace do GitHub ou um Devcontainer da Microsoft.

Localhost -- o próprio computador como servidor, em geral atendendo na porta 3000 (Next.js) ou 5173 (Vite). Acessível por http://localhost:3000.

Environment -- termo genérico para qualquer ambiente de execução: dev, staging, prod, preview. Cada ambiente carrega suas próprias configurações, segredos e dados.

Environment Variables -- variáveis injetadas no processo no momento da execução, para que código não carregue valores específicos de ambiente (URL do banco, chave de API, feature flag). Ler `process.env.DATABASE_URL` é o jeito padrão em Node.js e em Next.js.

Secret -- variável de ambiente que carrega valor sigiloso (token, senha, chave privada). Secret nunca deve aparecer em commit, em log ou em mensagem de chat. A Vercel, a Cloudflare e a Supabase oferecem cofres próprios para guardar secrets fora do código.

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.

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 o curso vai desdobrar nas próximas trinta semanas. 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 desse curso com vocabulário sólido nesses três 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.

Tabela comparativa: o velho regime e o novo regime do trabalho DEV.

Tabela: ambientes e seus contratos.