Glossário de Desenvolvimento AI-Native: Agentic Coding, Vibe Coding e mais 16 Termos Definidos

O vocabulário do desenvolvimento AI-native evolui mais depressa do que os dicionários. Novos termos — agentic coding, vibe coding, MCP, context engineering, subagents — surgem no X, chegam num CLI e são absorvidos pelo dia-a-dia das equipas, tudo num trimestre. Esta página é a referência canónica: cada termo recebe primeiro uma definição clara e citável, os factos de origem que a maioria dos glossários omite, e um mapeamento para onde a competência se situa no modelo de 7 níveis do AI-Native Developer — do L1 Chat-Assisted Developer ao L7 Universal AI Creator.

Cada entrada termina com a mesma pergunta honesta: em que nível é que isto te coloca? Quando acabares de ler, faz o quiz de 3 minutos e descobre.

Ir para um termo

Termo	Mapeia para	Termo	Mapeia para
AI-native developer	L1–L7	evals	L6
Agentic coding	L3	worktrees	L5+
Agentic engineering	L4–L5	Context engineering	L4–L6
Vibe coding	Fora da escala	Spec-driven development	L4–L6
Desenvolvimento assistido por IA	L1–L7	Autonomous coding agent	L3→L5
MCP	L5–L6	Prompt engineering	L1–L2
Agent orchestration	L5	Modelo de maturidade em IA	o modelo
Subagents	L5+	Model routing	L5–L6
Plan-before-code	L3–L4	Verification harness	L4–L5

---

AI-native developer

Um AI-native developer é um programador cujo fluxo de trabalho padrão é dirigir sistemas de IA para planear, escrever, testar e colocar código em produção, em vez de escrever a maioria das linhas à mão. Mede-se pela autonomia e pelos hábitos de verificação — não pelo número de ferramentas de IA instaladas.

Hoje, quase todos os programadores "usam IA." Isso não é o mesmo. Ser AI-native é uma postura, não um cinto de ferramentas: a IA é o teu principal mecanismo de produção, e o teu trabalho desloca-se para a direção, revisão e verificação. A questão divisória não é usas um assistente de IA? — é quanto delegas e como verificas o resultado?

É exatamente este traço que o modelo de 7 níveis do AI-Native Developer avalia, do L1 Chat-Assisted Developer (o "Artesão do Passado" que faz copy-paste de um chat) até ao L7 Universal AI Creator (uma pessoa a gerir um ciclo completo de produto com agentes). O nível onde ficas depende da autonomia e da verificação, não de vibes.

Em que nível é que isto te coloca? Faz o quiz →

Agentic coding

Agentic coding é uma abordagem de desenvolvimento em que agentes de IA autónomos planeiam, escrevem, executam, testam e modificam código em múltiplos passos com intervenção humana mínima, usando ferramentas — shell, edição de ficheiros, test runners — num ciclo de feedback até a tarefa estar concluída.

A palavra-chave é ciclo. O autocomplete de turno único entrega-te um snippet e para; um agente de agentic coding é dono de toda a tarefa. Lê o repositório, faz um plano, edita ficheiros, corre os testes, lê as falhas e tenta de novo — iterando ao longo de uma trajetória longa em vez de responder a um único prompt. A Google Cloud define-o como uma abordagem de desenvolvimento de software em que agentes de IA autónomos planeiam, escrevem, testam e modificam código com intervenção humana mínima; a IBM enquadra os coding agents subjacentes como sistemas de IA que combinam o raciocínio de LLMs com acesso a ferramentas de codificação para agir em múltiplos passos.

Na escala, agentic coding é a característica distintiva do L3, o Agentic Developer ("The Agentic Native") — onde o agente escreve a rotina, tu planeas antes de codificar, e não aceitas a resposta dele sem verificar. Aprofunda no pilar de agentic coding ou vê o nível em L3 →.

Em que nível é que isto te coloca? Faz o quiz →

Agentic engineering

Agentic engineering é a disciplina profissional de orquestrar agentes de IA como multiplicadores de força, mantendo o ser humano responsável pela arquitetura, qualidade e verificação. Os agentes fazem a maior parte da escrita; o engenheiro dirige, restringe e valida.

Se agentic coding é a técnica, agentic engineering é o rigor em torno dela. Segundo a MindStudio, é a prática de orquestrar agentes de IA para fazerem a maior parte da codificação, enquanto o ser humano mantém a responsabilidade sobre a arquitetura, a qualidade do código e o juízo de engenharia — apresentada como a sucessora disciplinada do vibe coding em 2026. A ênfase está em especificações, evals, revisão e reprodutibilidade, em vez de "aceitar e esperar."

Isto mapeia para a banda L4–L5 — o Director e o Orquestrador — onde deixas de escrever código de rotina e passas a construir o sistema que o produz. Vê como vibe coding e agentic engineering se distanciam em vibe coding vs agentic coding, ou navega pelos níveis completos.

Em que nível é que isto te coloca? Faz o quiz →

Vibe coding

Vibe coding é construir software fazendo prompt a uma IA e aceitando o seu output sem rever o código. Andrej Karpathy cunhou o termo a 2 de fevereiro de 2025, descrevendo o ato de ceder completamente às vibes e esquecer que o código existe — aceitar alterações de IA sem ler os diffs.

Simon Willison afiou-o numa definição utilizável: vibe coding é "construir software com um LLM sem rever o código que ele escreve." O corolário dele é a parte que os programadores seniores mais valorizam — se reveres, testas e consegues explicar o código, "é desenvolvimento de software", não vibe coding. Essa linha é tudo. Vibe coding é ótimo para protótipos descartáveis e experiências de fim de semana; torna-se um risco assim que a coisa tem de correr em produção sem supervisão.

Criticamente, vibe coding situa-se fora da escala de engenheiros L1–L7. Produz o arquétipo Vibe Builder: um criador de no-code/IA que coloca produtos reais em produção com ferramentas de app-builder de IA sem escrever código tradicional — AI-native desde o primeiro dia, mas uma espécie diferente do engenheiro a escalar a escala de maturidade. Não é uma despromoção; é um jogo diferente com o seu próprio superpoder (velocidade) e o seu próprio teto. Mais em vibe coding e no confronto direto vibe coding vs agentic coding.

Em que nível é que isto te coloca? Faz o quiz →

Desenvolvimento assistido por IA

Desenvolvimento assistido por IA é qualquer fluxo de trabalho em que ferramentas de IA — autocomplete, chat ou agentes — ajudam a escrever ou modificar código enquanto um ser humano permanece no ciclo a rever e a decidir. É o grande guarda-chuva que abrange tudo do L1 ao L7.

Pensa nisto como o superconjunto. Tanto vibe coding como agentic coding vivem dentro do desenvolvimento assistido por IA; o que os separa é quanta autonomia concedes e como verificas o output. Concedes pouco e revês tudo à mão, e és um delegador das primeiras posições da escala. Concedes muito mas tens um verification harness, e estás a fazer agentic engineering disciplinado. O próprio termo é deliberadamente amplo — razão pela qual um modelo com níveis é útil para te situares dentro dele.

O modelo de 7 níveis é o mapa que transforma este guarda-chuva num espectro onde te podes posicionar.

Em que nível é que isto te coloca? Faz o quiz →

MCP (Model Context Protocol)

MCP (Model Context Protocol) é uma norma aberta que permite aos modelos de IA conectarem-se a ferramentas externas e fontes de dados através de uma interface universal, em vez de integrações específicas por ferramenta. A Anthropic introduziu-o e publicou-o como open source a 25 de novembro de 2024 (versão da especificação 2024-11-05), com SDKs para Python e TypeScript.

O modelo mental mais usado é "USB-C para ferramentas de IA": um protocolo, e qualquer cliente compatível pode comunicar com qualquer servidor compatível — os teus docs, a tua base de dados, o teu issue tracker, o teu shell. Antes do MCP, cada integração era feita à medida; depois, o alcance do agente torna-se um ecossistema de plug-ins. A adoção expandiu-se amplamente pela indústria ao longo de 2025–2026, e podes ler a fonte primária no anúncio da Anthropic.

Ligar um servidor MCP pronto a usar é algo que a maioria dos programadores com assistência de IA consegue fazer cedo. Mas governar o MCP numa equipa — decidir o que os agentes podem alcançar e criar servidores reutilizáveis — é um sinal de L5–L6 Methodologist. Vê L6 → e a entrada relacionada sobre agent orchestration.

Em que nível é que isto te coloca? Faz o quiz →

Agent orchestration

Agent orchestration é coordenar múltiplos agentes de IA — atribuir tarefas, sequenciar passos, gerir estado partilhado e fundir resultados — para que uma equipa de agentes conclua trabalho que um único agente não consegue fazer de forma fiável sozinho.

A forma dominante é o padrão orquestrador-trabalhador (manager-worker): um agente planeia e delega enquanto agentes trabalhadores delimitados executam e reportam. Segundo a documentação do Claude Code, neste padrão o orquestrador é dono do plano e cada trabalhador trata de uma tarefa com âmbito definido — a estrutura que torna o trabalho multi-agente gerível em vez de caótico.

Esta é a característica definidora do L5, o AI Engineering Architect ("The Orchestrator") — o nível em que desenhas a pilha de agentes em vez de apenas conduzir um agente. Vê L5 →, e depois os blocos de construção: subagents e worktrees.

Em que nível é que isto te coloca? Faz o quiz →

Subagents

Subagents são agentes trabalhadores isolados para os quais um agente primário delega, cada um correndo com o seu próprio contexto, acesso a ferramentas e permissões, e devolvendo um único resumo — mantendo o contexto do agente principal limpo e o trabalho paralelizável.

Os subagents são a forma como a orquestração se mantém sensata. Em vez de uma janela de contexto inchada a fazer malabarismo com tudo, o agente primário cria trabalhadores com âmbito definido, cada um com uma folha em branco, e recebe de volta um resultado organizado. Segundo a documentação do Claude Code, cada subagent corre com o seu próprio contexto, ferramentas e permissões — e não pode criar novos subagents, pelo que o aninhamento tem um limite por design. Esse limite é uma funcionalidade: previne árvores de agentes fora de controlo.

O uso rotineiro de subagents é um sinal comportamental de L5+ — já passaste de conduzir um agente para gerir uma pequena equipa. Vê L5 → e o padrão mais amplo em agent orchestration.

Em que nível é que isto te coloca? Faz o quiz →

Plan-before-code

Plan-before-code é uma disciplina de agentic coding em que o agente (ou o ser humano) produz um plano explícito e aguarda aprovação antes de escrever qualquer código — para que a intenção seja verificada à partida e o passo de implementação permaneça delimitado e verificável.

É uma apólice de seguro barata. Alguns minutos a confirmar "aqui está o que estou prestes a fazer e porquê" previne o cenário de falha caro de um agente a editar vinte ficheiros confiante na direção errada. Também consome menos tokens e produz diffs sobre os quais consegues realmente raciocinar. Plan-before-code é o hábito de entrada que leva naturalmente ao spec-driven development.

Este é um hábito de maturidade L3–L4 — o momento em que deixas de deixar os agentes correr livremente e começas a filtrá-los com um plano aprovado.

Em que nível é que isto te coloca? Faz o quiz →

Verification harness

Um verification harness é o conjunto de verificações automatizadas — testes, linters, type-checks, scripts de build e execução — ligados de forma a que um agente de IA possa verificar o seu próprio trabalho num ciclo e autocorrigir-se, sem um ser humano a ler cada diff.

Esta é a coisa única que torna o agentic coding de alta autonomia ("YOLO") seguro em vez de imprudente. Um agente com um harness forte pode correr a alta velocidade — tentar uma alteração, correr as verificações, ler as falhas, corrigir, repetir — porque as verificações apanham os seus erros antes de tu o fazeres. Um agente sem harness é apenas risco não revisto a mover-se depressa. O harness é o que converte confiança num sistema em vez de numa esperança.

Construir harnesses reutilizáveis é a linha divisória L4–L5 — separa "revejo cada alteração" de "confio no ciclo e revejo o resultado." Vê os níveis →, e combina isto com evals.

Em que nível é que isto te coloca? Faz o quiz →

Evals

Evals são testes sistemáticos que medem se um modelo ou agente de IA produz outputs corretos e fiáveis. Para agentes de codificação, os evals verificam se o agente planeia, chama ferramentas e completa tarefas em múltiplos passos corretamente ao longo de toda uma trajetória — não apenas se a resposta final parece certa.

Existem duas formas principais, segundo a Confident AI: evals baseados em código (asserções automáticas, ao estilo de CI) e LLM-as-a-judge. Para trabalho de codificação, a trajetória importa porque uma execução abrange muitos passos — um agente pode produzir o ficheiro certo por razões erradas, ou tomar um caminho perigoso até um teste que passa. Os evals apanham isso. São a diferença entre "funcionou uma vez" e "funciona de forma fiável."

Escrever e manter evals é um sinal de L6 Methodologist — não estás apenas a usar agentes, estás a medir e a certificar o seu comportamento. Vê L6 → e o seu par, o verification harness.

Em que nível é que isto te coloca? Faz o quiz →

Worktrees

Os git worktrees são diretórios de trabalho separados que partilham o histórico de um único repositório, para que vários agentes de IA possam cada um trabalhar numa branch ou checkout isolado em paralelo — sem sobrescrever os ficheiros uns dos outros.

Este é o mecanismo padrão para correr múltiplas sessões do Claude Code num único codebase ao mesmo tempo. Segundo a documentação do Claude Code, um worktree é um diretório de trabalho separado com a sua própria branch que partilha o mesmo histórico do repositório, permitindo que múltiplos agentes trabalhem em paralelo em checkouts isolados. Na prática, combinas worktrees com isolamento de portas e bases de dados para que os agentes paralelos não colidam fora do sistema de ficheiros.

Fluxos de trabalho com agentes paralelos em worktrees são uma característica de L5+ — o Director no L4 já corre vários agentes desta forma, e o L5 Orchestrator sistematiza-o. Vê agent orchestration e L5 →.

Em que nível é que isto te coloca? Faz o quiz →

Context engineering

Context engineering é, na formulação de Andrej Karpathy em junho de 2025, "a arte e ciência delicada de preencher a janela de contexto com a informação certa para o próximo passo." É a disciplina de desenhar tudo o que um LLM vê: instruções, documentos recuperados, outputs de ferramentas, memória e estado.

Karpathy defendeu o termo em detrimento de "prompt engineering" em junho de 2025, e a Anthropic formalizou o conceito em setembro de 2025. O reencadramento importa: em sistemas de agentes em produção, a formulação de qualquer prompt individual é uma pequena fatia do que determina a qualidade do output. Como a Glean coloca, prompt engineering é um subconjunto do context engineering — o contexto completo inclui também o histórico da conversa, documentos recuperados, outputs de ferramentas e estado do agente. A diferença de qualidade entre utilizadores de IA hoje em dia é o contexto, não as palavras mágicas.

Context engineering deliberado é um sinal de L4–L6 — é o que as pessoas fazem quando curam ficheiros CLAUDE.md, desenham retrieval e orçamentam a janela de contexto com propósito. Contrasta com o seu subconjunto, prompt engineering, e vê os níveis →.

Em que nível é que isto te coloca? Faz o quiz →

Spec-driven development

Spec-driven development é uma metodologia que torna uma especificação escrita a fonte de verdade que os agentes de IA usam para gerar, testar e validar código. Escreves a spec primeiro, depois um plano, depois tarefas pequenas e testáveis, depois a implementação.

Segundo o GitHub, a especificação torna-se um contrato para o comportamento que o código deve ter — a fonte de verdade que ferramentas e agentes de IA usam para gerar, testar e validar código. O GitHub anunciou e publicou como open source o Spec Kit (licença MIT) a 2 de setembro de 2025, com o fluxo central Spec → Plan → Tasks → Implement, posicionado explicitamente como uma alternativa repetível e disciplinada ao vibe coding ad-hoc. É plan-before-code levado à sua conclusão lógica.

Os fluxos de trabalho spec-driven são um marcador de maturidade L4–L6. Baseiam-se em plan-before-code e estão no coração de como os Directors e Methodologists entregam trabalho. Vê os níveis →.

Em que nível é que isto te coloca? Faz o quiz →

Autonomous coding agent

Um autonomous coding agent é um sistema de IA que recebe um objetivo e, de forma independente, planeia, edita ficheiros, executa comandos e testes, e itera até concluir — operando ao longo de uma trajetória longa e multi-passo em vez de responder a um único prompt.

Os agentes CLI como o Claude Code são o exemplo canónico. O nuance importante é que a autonomia é um espectro, não um interruptor: até que ponto deixas um agente correr sem supervisão ("modo YOLO") é limitado por duas coisas — o teu verification harness e as permissões que lhe concedes. Harness forte mais permissões restritas equivale a autonomia segura. Harness fraco mais permissões amplas equivale a uma tarde má.

Aprender a confiar em agentes autónomos sem quebrar a produção é a progressão L3 → L5 em si: de "o agente escreve a rotina" a "o agente corre ciclos de múltiplos tickets do início ao fim." Vê os níveis →.

Em que nível é que isto te coloca? Faz o quiz →

Prompt engineering

Prompt engineering é a prática de criar as instruções textuais dadas a um LLM — formulação, exemplos, papel e formato do output — para o orientar para um resultado desejado num único turno.

Ainda importa; instruções claras continuam a superar as imprecisas. Mas o campo enquadrou-o como um componente de uma disciplina maior. Em sistemas de agentes em produção, o prompt é uma pequena fração do contexto total, que inclui também histórico, documentos recuperados, outputs de ferramentas e estado — razão pela qual o context engineering se tornou o enquadramento mais útil.

Prompt engineering é um elemento base de L1–L2 que amadurece para context engineering por volta do L4. É onde a maioria das pessoas começa; não é onde está o teto.

Em que nível é que isto te coloca? Faz o quiz →

Modelo de maturidade em codificação com IA

Um modelo de maturidade em codificação com IA é um enquadramento por níveis que avalia quão AI-native é um programador ou equipa — por comportamento de autonomia e verificação, não por contagem de ferramentas. O modelo de 7 níveis do AI-Native Developer da ProCoders (L1 Chat-Assisted → L7 Universal AI Creator) é um; os 8 estágios de fluxo de trabalho agentic de Steve Yegge é outro.

Os modelos de maturidade dão a um campo em rápida evolução um vocabulário partilhado para o gradiente de confiança — a rampa de "a IA autocompleta uma linha" a "construí o meu próprio orquestrador." Os 8 níveis de Yegge descrevem esse mesmo gradiente de perto-zero uso de IA até construir o teu próprio orquestrador, com a quebra crítica no estágio 5–6 onde um único agente síncrono dá lugar a múltiplos agentes paralelos (segundo o resumo da Augment Code). O enquadramento por níveis é o que permite às equipas falar em direção em vez de apenas ferramentas.

O exemplo canónico neste site é o modelo — o modelo de 7 níveis do AI-Native Developer com personas e sinais comportamentais concretos para cada degrau. A forma mais rápida de o usar é o quiz.

Em que nível é que isto te coloca? Faz o quiz →

Model routing

Model routing é escolher automaticamente qual modelo ou fornecedor de IA trata cada pedido com base em custo, latência, capacidade e disponibilidade — enviando tarefas fáceis para modelos baratos e as difíceis para modelos de fronteira, com fallbacks.

É uma alavanca de custo e fiabilidade, e a diferença é suficientemente grande para importar: segundo a OpenRouter, o custo por token entre modelos de fronteira e modelos mais baratos pode diferir cerca de 10x–50x, e plataformas como a OpenRouter expõem controlos de routing e limites de preço. Rotear uma frota de agentes de forma inteligente permite reservar os modelos de fronteira caros para o trabalho que genuinamente os precisa, enquanto modelos mais baratos absorvem o volume fácil.

Fazer routing de modelos numa frota de agentes — e definir a política para isso — é um sinal de arquiteto L5–L6; o L5 Orchestrator é dono da política de model routing para os agentes da equipa. Vê L5 →.

Em que nível é que isto te coloca? Faz o quiz →

---

Como estes termos se mapeiam para a escala

As definições são apenas metade da história. A razão pela qual este glossário liga cada termo a um nível é que a mesma palavra significa coisas diferentes a níveis de maturidade diferentes. "Usar MCP" é um sinal precoce; "governar MCP" é um sinal sénior. "Correr um agente" é L3; "orquestrar uma frota em worktrees" é L5. Aqui está o mapa comprimido:

Nível	Persona	Termos do glossário que o sinalizam
L1 Chat-Assisted	Artesão do Passado	prompt engineering
L2 AI-Assisted Junior	Delegador	prompt engineering, desenvolvimento assistido por IA
L3 Agentic Developer	Agentic Native	agentic coding, plan-before-code, autonomous coding agent
L4 System Builder	Director	verification harness, spec-driven development, context engineering
L5 Engineering Architect	Orquestrador	agent orchestration, subagents, worktrees, model routing
L6 Methodologist	Methodologist	evals, governação de MCP, métodos portáteis
L7 Universal AI Creator	Creator	ciclo completo a solo com tudo o acima
Fora da escala	Vibe Builder	vibe coding

Essa última linha é a distinção que os glossários genéricos ignoram. Vibe coding não é um degrau baixo — é uma escada completamente diferente. O Vibe Builder coloca produtos em produção sem código tradicional; o engenheiro L1–L7 sobe em direção a dirigir sistemas que o fazem. Ambos são legítimos; simplesmente não são o mesmo caminho.

Descobre o teu nível

Ler definições diz-te o que as palavras significam. O quiz diz-te onde tu estás no modelo de 7 níveis do AI-Native Developer — com base na tua autonomia real e nos teus hábitos de verificação, em cerca de três minutos.

Faz o quiz → /quiz