Vibe coding em 2026: como construir software enorme com IA (do seu primeiro app à escala do Google)

Dois anos atrás, “só descreva o que você quer e deixe a IA escrever o código” soava como piada. Em 2026 é assim que uma fatia enorme e ainda crescente do software do mundo realmente é construída. O GitHub relata que cerca de 46% de todo o código novo agora é gerado por IA. O Google afirmou que cerca de um quarto do seu próprio código é assistido por IA. A Gartner espera que 60% de todo o código novo de software seja escrito por máquina até o fim deste ano. O vibe coding não só sobreviveu ao ciclo de hype — ele silenciosamente engoliu a indústria.

Eu construo software de produção quase inteiramente dirigindo agentes de IA em linguagem simples. Sem sintaxe digitada à mão, sem diploma de ciência da computação — só instruções precisas, revisão dura e um método que impede a coisa toda de desabar sob o próprio peso. Este é o guia que eu gostaria que alguém tivesse me entregado no primeiro dia: o que o vibe coding realmente é em 2026, como começar do zero, as ferramentas e modelos exatos que valem seu tempo agora, e — a parte que todo mundo secretamente quer saber — se você pode mesmo usar isso para construir algo do tamanho do Google ou do Facebook.

Resumo: você pode ir surpreendentemente longe com vibe coding, mais longe do que quase todo mundo esperava. Mas as pessoas que entregam software sério e de grande escala com IA não são as que jogam prompts em um chatbot e rezam. Elas seguem um processo disciplinado. Até o fim deste artigo você vai saber exatamente como é esse processo, e vai ter uma stack que pode começar a usar hoje.

O que é vibe coding, de verdade? (A definição de 2026)

O termo foi cunhado por Andrej Karpathy em fevereiro de 2025 e se popularizou tanto que o Dicionário Collins o elegeu Palavra do Ano de 2025. A formulação original dele era deliberadamente solta: você se entrega às vibes, descreve o que quer e aceita o que o modelo devolver sem se preocupar com os detalhes.

Essa versão descontraída está morta e, sinceramente, ainda bem. Em 2026, vibe coding significa algo mais maduro: você escreve especificações precisas em linguagem natural, um agente de IA as implementa, e você permanece no circuito como arquiteto, revisor e autoridade final. Você não está digitando o código. Está dirigindo o sistema que digita o código — e é responsável pelo que vai ao ar.

O próprio Karpathy mudou as regras no início de 2026, aposentando o “vibe coding” como algo ultrapassado e propondo “engenharia agêntica” em vez disso: agêntica porque você orquestra agentes em vez de escrever código 99% do tempo, engenharia porque fazer isso bem é um ofício de verdade, com experiência real por trás. O nome não pegou totalmente — a maioria das pessoas ainda diz “vibe coding” — mas a mudança que ele descreve está exatamente certa. O centro de gravidade saiu de digitar a dirigir.

Aqui estão os dados que importam. Cerca de 92% dos desenvolvedores nos EUA usam ferramentas de codificação com IA diariamente, e 82% dos desenvolvedores no mundo usam essas ferramentas pelo menos semanalmente. Entre as turmas recentes da Y Combinator, uma fatia impressionante de startups tem bases de código mais de 90% geradas por IA. Isso não é mais uma técnica de nicho. É o padrão, e ou você é fluente nisso ou é lento.

A verdade honesta sobre “fazer vibe coding de um Google ou Facebook”

Vamos encarar o sonho de frente, porque é a pergunta que mais recebo.

Você consegue sentar neste fim de semana e tirar de primeira um clone funcional do google.com ou do facebook.com? Não. Quem disser o contrário está vendendo curso. O Google é milhares de engenheiros, infraestrutura em escala planetária, uma década de sistemas acumulados e tecnologia de busca e ranqueamento que é genuinamente difícil. Um print de um “clone do Facebook feito em um prompt” é um mockup de interface sem backend real, sem autenticação em escala, sem modelo de dados que sobreviva ao contato com usuários e sem segurança que mereça o nome.

Mas aqui está a parte que é é verdade, e é a verdade mais interessante: software grande, de nível de produção, está absolutamente sendo construído assim agora — inclusive dentro das empresas que você está tentando imitar. A estatística do próprio Google sobre um quarto de todo o código entrega o jogo. A diferença entre uma demo descartável e algo real não está nos prompts. Está no método.

Uma demo é fácil. Software que é seguro, escalável e fácil de manter é difícil — e essa lacuna é a tensão que define o vibe coding em 2026. As equipes que a atravessam tratam os agentes de IA como engenheiros júnior rápidos, incansáveis e às vezes confiantes demais, e os envolvem na mesma disciplina que uma boa organização de engenharia aplica a humanos: arquitetura clara, trabalho decomposto, contexto de projeto persistente, testes automatizados e revisão de segurança em que cada linha gerada pela IA é tratada como não confiável até prova em contrário.

Então reformule o objetivo. Você não vai fazer um Google surgir do nada um Google. Você pode fazer vibe coding de um produto real, ambicioso e cheio de recursos — uma rede social, um marketplace, uma plataforma SaaS — até qualidade de produção de verdade, sozinho ou com uma equipe minúscula, em uma fração do tempo que costumava levar. Isso não é uma versão diluída do sonho. Para um fundador solo, beira a mágica. O resto deste guia é como você faz isso de verdade.

Como começar no vibe coding (o básico absoluto)

Se você nunca fez isso, aqui está todo o modelo mental em uma frase: você é o arquiteto e o diretor; a IA é a construtora. Internalize isso e todo o resto vem junto.

Veja como chegar ao seu primeiro resultado real, passo a passo.

1. Escolha um agente e um projeto. Não passe uma semana pesquisando ferramentas. Pegue um único agente de codificação com IA (recomendações abaixo) e escolha um projeto pequeno, mas real — um site pessoal, um rastreador de hábitos, uma ferramentinha que você realmente quer. O real vence o tutorial.
2. Descreva o resultado, não a implementação. Diga ao agente o que você quer e por que, em linguagem simples. “Faça um site pessoal limpo, com uma home, um blog com páginas individuais de post, modo escuro e um formulário de contato que me mande e-mail.” Você ainda não precisa saber o que são React ou PostgreSQL. Você precisa saber o que quer.
3. Leia o que ele faz — não apenas aceite. Este é o único hábito que separa quem entrega de quem pega uma “ressaca de vibe”. Quando o agente explicar o plano, leia. Quando ele escrever código, peça para explicar qualquer coisa que você não acompanhar. Você não está decorando sintaxe; está construindo julgamento sobre se o trabalho faz sentido.
4. Itere em passos pequenos e específicos. “Agora adicione um botão de modo escuro.” “O formulário de contato deve validar o e-mail antes de enviar.” Uma mudança por vez. Passos pequenos mantêm o agente preciso e mantêm você capaz de perceber quando algo quebrou.
5. Teste a coisa o tempo todo. Clique em todos os botões. Tente quebrar seus próprios formulários. Peça ao agente para escrever testes. Quanto mais rápido você pega um problema, mais barato é corrigir.
6. Trate a IA como par, não como oráculo. Questione. Discorde. Pergunte “existe um jeito mais simples?” A regra de ouro do vibe coding em 2026 é direta: nunca entregue código que você não entende, pelo menos em alto nível. Você não precisa ler cada linha. Precisa saber para que serve cada parte.

É isso. Esse é o ciclo. Todo o resto deste artigo é sobre fazer esse ciclo melhor, em escala maior, com as ferramentas certas.

As ferramentas: o que realmente usar em 2026

O agente é com quem você conversa. Ele lê sua base de código, planeja uma mudança, edita vários arquivos, roda comandos e testes, e itera com o mínimo de acompanhamento. O campo se dividiu em três grupos claros, e a maioria dos usuários pesados que conheço usa dois ou três e direciona o trabalho por tipo de tarefa.

Agentes com terminal em primeiro lugar (onde o trabalho sério acontece)

Esses rodam no seu terminal, editam arquivos direto na sua máquina em um ciclo de feedback apertado, e costumam ser os mais capazes para engenharia de verdade.

• Claude Code — Meu uso diário e líder em capacidade bruta. Movido pelo Claude Opus 4.8, lidera o ranking do SWE-bench Verified com 88.6%. É profundamente programável (hooks, “Rotinas” agendadas e tudo o mais) e lê um CLAUDE.md no seu repositório para carregar o contexto do projeto automaticamente em cada sessão. Os níveis pagos começam em cerca de US$ 20/mês.
• OpenAI Codex — Com o GPT-5.5 por trás, lidera o ranking do Terminal-Bench e abrange CLI, nuvem, web e celular em uma única conta, com preço de entrada a partir de cerca de US$ 8/mês. Ótimo se você vive no ecossistema ChatGPT.
• OpenCode — O destaque de código aberto (mais de 172 mil estrelas no GitHub, licença MIT). É um agente de terminal de verdade, não um wrapper, e é agnóstico de modelo: traga a chave de API de qualquer modelo — Claude, GPT, Gemini, Kimi, GLM, DeepSeek, Qwen — e rode. A velocidade de novos recursos é alta porque a comunidade entrega rápido. Essa é a jogada se você quer liberdade de qualquer fornecedor único.
• Aider, Cline, Hermes Agent, Goose, Kilo Code — Uma camada saudável de código aberto. Todos gratuitos para rodar; você paga apenas pelos tokens do modelo que rotear por eles.

Ambientes de trabalho nativos de IDE e visuais (onde a edição encontra a direção)

• Cursor — A experiência de editor mais limpa e completa. Seu modelo Composer é barato por saída, e o Cursor 2.0 roda até oito agentes em paralelo. Se você quer ver seu código enquanto dirige, comece por aqui.
• Google Antigravity — o ambiente de trabalho do Google que coloca agentes em primeiro lugar, gratuito para pessoas físicas em prévia pública, com Gemini 3.5 Flash como padrão e gestão visual de agentes em paralelo. O curinga interessante. (Nota: o antigo nível gratuito do Gemini CLI, de 1.000 requisições/dia, termina June 18, 2026 quando o Google o incorporar ao Antigravity CLI — então, se você dependia disso, hoje é o dia de trocar.)
• GitHub Copilot — A opção nativa do GitHub, mais forte se o seu código já está lá e você quer automação de issue para PR. O Pro custa US$ 10/mês.
• Windsurf / Devin Desktop — O Windsurf virou Devin Desktop, apostando em agentes de nuvem autônomos e paralelos que abrem pull requests enquanto você faz outra coisa.

Uma nota técnica que vale saber: quase todo agente sério agora suporta o Model Context Protocol (MCP), um padrão aberto que permite plugar as mesmas ferramentas externas (busca na web, bancos de dados, seu gerenciamento de projetos etc.) em qualquer agente com a mesma configuração. Aprenda MCP uma vez, use em todo lugar.

Os modelos: o lineup de 2026 (e quando usar cada um)

Seu agente é o cockpit; o modelo é o motor. E meados de 2026 foi um período absolutamente alucinante de lançamentos de modelos — três dos mais importantes abaixo chegaram nas últimas semanas antes de eu escrever isto.

Os modelos fechados de fronteira (capacidade máxima, preço premium)

• Claude Opus 4.8 (Anthropic) — Lançado em 28 de maio de 2026. O líder de qualidade para engenharia complexa, com vários arquivos e contexto longo: 88.6% no SWE-bench Verified. Custa US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de saída. É o que eu uso quando um erro sairia caro — arquitetura, grandes refatorações, qualquer coisa estrutural.
• GPT-5.5 (OpenAI) — Lado a lado com o Opus, e líder do Terminal-Bench. Excelente em produzir saída utilizável mesmo quando seu prompt deixa de fora os casos extremos, o que o torna ótimo para prototipagem rápida.
• Gemini 3.1 Pro / 3.5 Flash (Google) — Forte, profundamente integrado ao ecossistema do Google e ao Antigravity, com o Flash otimizado para velocidade.

A onda dos pesos abertos (a verdadeira história de 2026)

É aqui que fica divertido, e onde mora a economia. Uma onda de modelos de pesos abertos — muitos de laboratórios chineses — ficou genuinamente competitiva com a fronteira, e eles são baratos ou gratuitos para auto-hospedar. A geopolítica é parte do combustível aqui: restrições recentes dos EUA à exportação dos melhores modelos americanos para o exterior tornaram os modelos abertos com licenças permissivas muito mais atraentes estrategicamente no mundo todo.

• Kimi K2.7-Code (Moonshot AI) — Lançado em June 12, 2026. Um monstro de pesos abertos com foco em código: um modelo Mixture-of-Experts de 1 trilhão de parâmetros (32B ativos por token), uma janela de contexto de 256K tokens, entrada multimodal e uma licença MIT modificada que permite uso comercial. A Moonshot afirma cerca de 30% menos uso de tokens de raciocínio que o antecessor, além de ganhos de dois dígitos em benchmarks, o que importa porque tokens são dinheiro. Ele funciona com o Kimi Code CLI, focado em terminal (planos a partir de US$ 19/mês), e custa cerca de US$ 0,95 por milhão de tokens de entrada via API. Feito especificamente para ciclos de agente de longo prazo: planejar, executar e depurar. Uma escolha forte para execuções muito longas sem supervisão.
• GLM 5.2 (Z.ai, antiga Zhipu AI) — Lançado em June 13, 2026, um dia depois do Kimi. Um MoE de 744B parâmetros (≈40B ativos) com uma janela de contexto utilizável de 1 milhão de tokens — grande o suficiente para alimentá-lo com um repositório inteiro — e pesos abertos com licença MIT no Hugging Face. A Z.ai afirma que ele supera o GPT-5.5 em alguns benchmarks de código de horizonte longo por cerca de um sexto do custo, embora esses benchmarks tenham sido divulgados pelo fornecedor e ainda não verificados de forma independente no lançamento. O recurso matador para quem faz vibe coding: ele é servido por um endpoint compatível com a Anthropic e o O GLM Coding Plan começa em cerca de US$ 10/mês, então ele entra direto no Claude Code, OpenCode, Cline, Roo Code, Goose e companhia. Brilhante para front-end e trabalho pesado de interface, e um valor absurdo para a maior parte da sua codificação agêntica.
• DeepSeek V4 (e o V4-Flash mais barato) — A escolha padrão para trabalho em alto volume e sensível a custo, quando você quer qualidade decente a preços baixíssimos.
• Qwen 3.5 — Excelente desempenho por parâmetro, especialmente nas variantes menores, que rodam rápido em hardware de consumidor.

Rodando modelos você mesmo: Ollama e Ollama Cloud

Se privacidade, controle de custos ou simplesmente não depender da API de ninguém te atrai, Ollama é o “momento Docker dos LLMs locais”: um comando para baixar e rodar modelos abertos (Llama, Qwen, Mistral, DeepSeek, Gemma e outros) localmente, com uma API compatível com a OpenAI em localhost:11434 que qualquer agente pode apontar.

O problema do local sempre foi o hardware — modelos abertos de nível de fronteira exigem VRAM de verdade. É exatamente isso que o Ollama Cloud Ollama Cloud resolve, e agora está disponível em geral. É inferência gerenciada: você roda esses mesmos modelos abertos grandes nas GPUs de data center da Ollama, com sem precisar de GPU local, e — esta é a parte esperta — ele expõe a idêntica API HTTP da sua configuração local. Sem reescrever código, sem SDK novo. Você só aponta para um modelo na nuvem e vai. Os preços são acessíveis: um plano gratuito, um Nível Pro em torno de US$ 20/mês, e um nível Max mais alto em torno de US$ 100/mês, cobrado por tempo de GPU em vez de tokens. A Ollama também se compromete a não registrar logs, não treinar com seus dados e não retê-los com seus parceiros de hospedagem — o que importa se você trabalha com algo sensível ou sob o GDPR.

A estratégia de roteamento entre vários modelos

Este é o padrão que os melhores profissionais realmente usam, e é a maior alavanca de custo do vibe coding: não rode tudo no modelo mais caro. Roteie por tarefa.

• Use um modelo de fronteira (Opus 4.8, GPT-5.5) para a pequena fatia de trabalho em que um erro custa caro de verdade: arquitetura, design de schema, lógica sensível à segurança, grandes refatorações.
• Use um modelo aberto bom e barato (GLM 5.2, Kimi K2.7, DeepSeek V4) para a maior parte da labuta: implementação de recursos, boilerplate, interface, testes.
• Uso modelos abertos locais ou do Ollama Cloud para inferência em alto volume e de baixo risco: classificação, resumo, edições simples.

Equipes que roteiam assim costumam cortar suas contas de inferência em 60–80% sem perda significativa de qualidade. Com um agente agnóstico de modelo como o OpenCode, trocar é tão fácil quanto mudar uma chave de API.

O sistema de arquivos que torna possíveis grandes projetos de vibe coding (AGENTS.md, CLAUDE.md & cia.)

Esta é a seção mais importante do artigo e — aviso — a parte para a qual o resto deste guia existe. É onde quase todo mundo se queima, incluindo eu, e muito, quando comecei. Então vamos com calma e concretude, porque é a diferença entre um projeto que cresce por meses e um que desaba silenciosamente na segunda semana.

Aqui está a realidade brutal: Agentes de IA não têm memória entre sessões. Feche o terminal e tudo o que o agente “sabia” sobre seu projeto evapora. Abra uma nova sessão amanhã e ele é um estranho total de novo — não lembra sua stack, suas convenções, as decisões que você tomou semana passada nem o que estava no meio de construir. Troque do Claude Code para o Cursor, ou um modelo por outro, e você começa do zero uma segunda vez. Em um projeto pequeno, você reexplica tudo em um parágrafo. Em um grande, esse único fato é o que te mata: você passa mais tempo reorientando o agente do que construindo, ele contradiz escolhas que você já fez, e a base de código vira um espaguete.

A solução é o jogo inteiro, então vou dizer sem rodeios: a memória do seu projeto precisa viver em arquivos no repositório, não no chat. O chat é descartável. Os arquivos são permanentes. A cada sessão, o agente reconstrói seu entendimento lendo esses arquivos primeiro — e, como são Markdown simples no seu repositório, qualquer agente, qualquer modelo, qualquer ferramenta pode lê-los. Você para de reexplicar seu projeto para sempre e o documenta uma vez, direito. É isso que permite a um projeto sobreviver a resets de contexto, trocas de modelo e mudanças de ferramenta. É também, não por coincidência, o que permite a uma pessoa carregar uma ambição do tamanho do Google: você não a carrega na cabeça. Carrega no disco.

Esta é a camada de documentação que coloco na raiz de todo projeto sério:

project-root/
├── README.md          # Porta de entrada: o que é, por que existe, como rodar
├── AGENTS.md          # Instruções de operação para agentes de IA de várias ferramentas (o padrão)
├── CLAUDE.md          # Orientações específicas do Claude Code (enxuto; importa o AGENTS.md)
├── GEMINI.md          # Orientações específicas do Gemini CLI (enxuto; importa o AGENTS.md)
├── CONVENTIONS.md     # Convenções de código (também carregadas automaticamente pelo aider)
├── CONTEXT.md         # Contexto longo do projeto para humanos + LLMs
├── llms.txt           # Mapa legível por máquina do repositório/docs para agentes
├── VISION.md          # O "porquê" e a estrela-guia de longo prazo
├── ROADMAP.md         # Para onde o projeto vai: fases e marcos
├── TASKS.md           # Lista de tarefas ativas / backlog de trabalho (o "cursor")
├── TODO.md            # Captura rápida e solta do que ainda não foi planejado
├── DECISIONS.md       # Índice de decisões arquiteturais (nunca reabertas)
└── CHANGELOG.md       # Histórico versionado e legível por humanos do que foi entregue

Pode parecer muita coisa. Não é — depois que você vê que esses arquivos fazem três trabalhos diferentes. Pense neles em três camadas, da mais permanente à mais descartável.

Camada 1 — As regras (duráveis, raramente mudam)

Elas definem como um agente deve se comportar no seu repositório. Você as escreve cedo e as edita de vez em quando.

• AGENTS.md é o coração do sistema e o arquivo que resolve seu problema de portabilidade. É o padrão aberto e independente de ferramenta para dizer a qualquer agente de codificação com IA como seu projeto funciona: a stack, como instalar e rodar, como rodar testes e lint, as convenções a seguir e as coisas que nunca fazer. Surgiu em 2025 de uma colaboração entre Sourcegraph, OpenAI, Google, Cursor e Factory, e hoje é mantido sob a Linux Foundation, adotado por mais de 30 ferramentas e presente em mais de 60.000 repositórios. A ideia toda é portabilidade: escreva uma vez e Codex, Cursor, Windsurf, Cline, Copilot, Gemini CLI e outros leem nativamente. Tudo o que é compartilhado mora aqui.
• CLAUDE.md é o arquivo de instruções nativo do próprio Claude Code — e aqui está a pegadinha que morde todo mundo, que pode ser exatamente a que te queimou: a partir de meados de 2026, o Claude Code não lê automaticamente o AGENTS.md. Ele lê CLAUDE.md. Se seu repositório tem apenas um AGENTS.md, o Claude Code carrega zero instruções de projeto, e não vai avisar. Você só recebe resultados piores e se pergunta por quê. A correção é muito simples e oficialmente documentada: crie CLAUDE.md um arquivo fino que puxa o compartilhado com uma única linha — @AGENTS.md — assim o Claude lê suas instruções universais mais quaisquer extras exclusivos do Claude. (A outra abordagem comum é um link simbólico: ln -s AGENTS.md CLAUDE.md, o que faz dos dois literalmente o mesmo arquivo.) Uma única fonte de verdade, sem duplicação, sem divergência.
• GEMINI.md é a mesma ideia para o Gemini CLI do Google — seu arquivo de instruções específico da ferramenta. Mantenha-o fino e faça com que ele aponte de volta para AGENTS.md também. O padrão nunca muda: um arquivo compartilhado para o mundo, um arquivo fino por ferramenta.
• CONVENTIONS.md guarda suas convenções de codificação — nomenclatura, formatação, padrões, as regras arquiteturais do caminho. É útil por si só e é o arquivo que o agente aider carrega no contexto por convenção. Faça referência a ele em AGENTS.md para que toda ferramenta herde os mesmos padrões.

O retorno dessa camada é exatamente o que você queria: independência real de ferramentas. Como as regras compartilhadas ficam em AGENTS.md e cada ferramenta apenas aponta para ele, você pode entregar o mesmo projeto ao Claude Code hoje, ao Cursor amanhã e ao OpenCode na próxima semana — e todos trabalham a partir de instruções idênticas. Sem reexplicar, sem aprisionamento. É isso que portabilidade significa na prática.

Camada 2 — O conhecimento e o estado vivo (esta é a memória de verdade)

Esta camada é o que o que o projeto é e onde ele está agora. Os arquivos do “agora” mudam a cada sessão — são a cura real para a amnésia.

• README.md — a porta de entrada, escrita primeiro para humanos: o que o projeto é, por que existe, como executá-lo. Todo novato (e todo agente) começa aqui.
• CONTEXT.md — contexto detalhado para humanos e LLMs: o domínio, o problema que você está resolvendo, conceitos e terminologia-chave, as restrições. É o contexto profundo que não cabe em um arquivo de instruções conciso, mas que um agente precisa para tomar boas decisões.
• VISION.md — a estrela-guia: por que este projeto existe e para onde ele vai no longo prazo. Mantém você e o agente apontados para o mesmo objetivo quando você está enterrado em uma única funcionalidade.
• llms.txt — um pequeno mapa em Markdown legível por máquina que aponta aos agentes (e às ferramentas que buscam documentação) seus arquivos mais importantes com descrições de uma linha, para que encontrem o contexto certo rápido e gastem menos tokens. Ressalva honesta: como uma tática para site público de SEO, llms.txt ainda não está comprovada — as grandes empresas de IA não se comprometeram a lê-lo e estudos não mostram nenhum benefício mensurável de ranking até agora. Mas como um repo/docs índice para agentes de codificação, ele se justifica.
• ROADMAP.md — para onde o projeto vai, dividido em fases (veja a próxima seção) e marcos. Seu mapa da jornada inteira.
• TASKS.md — o arquivo mais importante para a continuidade do dia a dia. Este é o cursor: o que está feito, o que está em andamento agora, o que vem a seguir e quaisquer bloqueios. Quando uma sessão nova lê isto, ela sabe exatamente de onde continuar. Mantenha-o conciso e atual — é para reorientação rápida, não para prosa.
• TODO.md — captura solta de ideias e coisas pequenas ainda não agendadas. Mantém TASKS.md o foco no trabalho ativo sem que nada passe despercebido.
• DECISIONS.md — um registro somente de acréscimos das escolhas arquiteturais que você fez e por que. “Escolhemos Postgres em vez de SQLite porque precisamos de gravações concorrentes.” É isso que impede um agente de reabrir silenciosamente questões já resolvidas ou de contradizer uma escolha três sessões depois. O mais novo no topo; nunca editado, apenas acrescentado.
• CHANGELOG.md — um registro versionado e legível por humanos do que realmente foi entregue, em ordem. É ao mesmo tempo o histórico do seu projeto e a forma mais rápida de uma sessão que retorna ver o que mudou recentemente.

Camada 3 — A sessão (efêmera, vive só no chat)

Esta é a conversa que você está tendo agora. É a única camada que não persiste — e isso está bem, porque tudo o que importa nela é gravado de volta na Camada 2 antes de você fechar. Qualquer coisa que viva só aqui está, por definição, prestes a ser esquecida.

Como uma sessão realmente flui

Juntando tudo, o ritmo diário é quase entediante — e é essa a questão. Uma sessão normal é assim:

1. Abra a sessão. A primeira coisa que o agente faz é ler as regras e o estado: AGENTS.md (via CLAUDE.md/GEMINI.md), depois ROADMAP.md, TASKS.md, e DECISIONS.md.
2. Reoriente. Ele responde: “Estamos na Fase 2, a última tarefa foi o fluxo de login, a próxima é o middleware de autenticação, sem bloqueios.” Você confirma ou redireciona. Trinta segundos, zero esforço, sem reexplicar.
3. Faça uma tarefa. Ele trabalha um único item de TASKS.md, seguindo as convenções e respeitando as decisões travadas.
4. Grave a memória de volta. Antes de fechar, o agente atualiza TASKS.md (move o cursor), adiciona uma linha a CHANGELOG.md (o que foi entregue) e registra qualquer nova escolha em DECISIONS.md.
5. Feche. A janela de contexto se esvazia — e não importa, porque nada de valor estava nela. Está tudo no disco.

Amanhã você abre uma sessão nova, ou muda para uma ferramenta totalmente diferente, e o passo 1 reconstrói todo o contexto em segundos. Isso o problema da amnésia morre, e é a razão inteira pela qual um construtor solo consegue manter um projeto grande de vários meses coerente.

Isto é a “engenharia agêntica” concretizada. A era do mega-prompt único acabou; a era da decomposição estratégica chegou. Você não está apenas conversando com uma IA — está construindo e operando um sistema operacional para seus agentes, com esses documentos como a única fonte de verdade. Configure uma vez, e o trabalho diário volta a parecer sem esforço enquanto o projeto escala silenciosamente além de tudo o que uma única conversa poderia conter.

Um roteiro realista: vibe coding de um app grande, fase por fase

Então como você aponta tudo isso para algo ambicioso — digamos, uma rede social ou um marketplace de verdade? Você não constrói tudo de uma vez. Você avança por fases e só deixa o agente trabalhar um pequeno passo de cada vez dentro de cada uma.

• Fase 0 — Fundação. Configure o repositório, o sistema de documentação acima, e escolha sua stack. Faça um “hello world” rodar localmente. Trave suas grandes decisões arquiteturais antes de qualquer funcionalidade.
• Fase 1 — Arquitetura & dados. Defina a forma do sistema: o modelo de dados, os componentes principais, como eles conversam. Isso é trabalho de modelo de fronteira — acerte aqui e tudo o que vem depois fica mais fácil.
• Fase 2 — Funcionalidades centrais. Construa o coração do produto de ponta a ponta até a jornada principal do usuário funcionar. (Para uma rede social: contas, perfis, postagem, um feed.)
• Fase 3 — Integrações & autenticação. Autenticação de verdade, serviços externos, persistência, o tecido conectivo.
• Fase 4 — Interface & acabamento. O front end, design responsivo, internacionalização se você precisar. Trabalho ótimo para um modelo forte em UI como o GLM 5.2.
• Fase 5 — Robustez e segurança. Testes, desempenho, tratamento de erros e segurança — a parte que as demos sempre pulam e os produtos reais nunca podem.
• Fase 6 — Implantação & operações. Coloque no ar. Configure implantação, monitoramento, backups e os runbooks para quando as coisas quebrarem.
• Fase 7 — Lançamento & conformidade. Páginas legais, documentação pública e (se você opera em algum lugar como a UE) os requisitos de privacidade e divulgação que são inegociáveis para um site comercial.
• Fase 8 — Itere. Agora você é um produto real. Corrija, melhore e cresça, para sempre.

Repare no que isso faz: transforma uma montanha que parece impossível (“construir uma rede social”) em uma longa sequência de sessões únicas e termináveis. É esse o truque inteiro. Projetos gigantescos não são construídos com prompts gigantescos. São construídos com mil pequenos passos bem direcionados e bem documentados.

As armadilhas (ou: não pegue uma “ressaca de vibe”)

2025 ganhou um apelido: o ano da ressaca do vibe coding. Muitas equipes correram para substituir engenharia cuidadosa por prompts e bateram de frente com a realidade. Aprenda com isso.

• Segurança é o ponto principal. Uma empresa de segurança construiu recentemente 15 aplicativos idênticos em cinco ferramentas populares de vibe coding e encontrou 69 vulnerabilidades, seis delas críticas. Código gerado por IA é desproporcionalmente propenso a falhas de segurança. Trate cada linha de saída da IA como não confiável até que tenha sido revisada e escaneada. Nunca deixe um agente inventar sua própria autenticação ou lidar com segredos sem seus olhos em cima.
• A podridão do código é real. Estudos têm registrado aumento da rotatividade de código e multiplicação de código duplicado à medida que o volume de IA cresce. A disciplina de refatoração importa mais, não menos. Faça o agente limpar a própria bagunça.
• A lacuna de confiança é saudável. A favorabilidade dos desenvolvedores em relação às ferramentas de IA na verdade caiu from 77% in 2023 to about 60% in 2026, even as usage kept climbing. That’s not pessimism — it’s maturity. The industry learned to use the tools without blindly trusting them. You should too.
• Depurar pode consumir suas economias. Uma parcela significativa dos desenvolvedores relata gastar mais tempo corrigindo código de IA do que levaria para escrevê-lo eles mesmos — quase sempre porque aceitaram uma saída que não entendiam e pularam os testes. A correção é a mesma de sempre: passos pequenos, testes constantes, revisão de verdade.

Nada disso é motivo para evitar o vibe coding. É motivo para fazê-lo como um profissional.

Uma stack inteligente de vibe coding em 2026 (minha recomendação)

Se você quer pular a paralisia por análise, aqui está uma configuração concreta que eu entregaria de bom grado a um iniciante ou para rodar em um projeto sério.

A stack inicial enxuta e quase gratuita

• Agente: OpenCode (gratuito, de código aberto, agnóstico de modelo) ou Google Antigravity (gratuito em prévia).
• Modelos: GLM 5.2 pelo Coding Plan de ~US$ 10/mês para a maior parte do trabalho, mais o nível gratuito do Ollama Cloud para tarefas avulsas de grande volume.
• Método: o sistema com documentação em primeiro lugar descrito acima. Inegociável.
• Custo: cerca do preço de dois cafés por mês.

A stack de construtor sério (o que eu realmente uso)

• Agente principal: Claude Code, pela capacidade bruta e pelo quanto é programável.
• Modelo de arquitetura: Claude Opus 4.8 para as decisões estruturais.
• Modelos de trabalho: GLM 5.2 e Kimi K2.7-Code para o trabalho pesado do dia a dia, roteados por uma configuração agnóstica de modelo. Kimi especialmente para execuções autônomas muito longas e sem supervisão, graças à sua eficiência de tokens e contexto de 256K.
• Camada barata/local: Ollama Cloud (Pro) para inferência de alto volume e baixo risco.
• Cola: MCP para ferramentas, e uma estrutura de projeto rigorosa com documentação em primeiro lugar amarrando tudo.

Seja o que for que você escolher, lembre-se da meta-lição: a ferramenta que você escolhe importa menos do que o fluxo de trabalho que você constrói em torno dela. Um construtor disciplinado com ferramentas gratuitas entrega mais do que um desleixado com a stack mais cara que o dinheiro pode comprar.

Perguntas frequentes

Um não programador completo consegue realmente fazer vibe coding de algo real em 2026? Sim — é exatamente esse o ponto de onde as ferramentas chegaram. Não engenheiros estão entregando software funcional especificando intenção e avaliando resultados. Você ainda precisa de julgamento, paciência e disposição para aprender o que a IA está fazendo em alto nível, mas não precisa escrever código à mão.

O vibe coding ainda é relevante, ou a “engenharia agêntica” está tomando seu lugar? A mesma coisa, com um nome melhor. “Engenharia agêntica” é apenas vibe coding feito com disciplina — orquestrar agentes, definir portões de qualidade e manter supervisão humana nos pontos críticos. A maioria das pessoas ainda diz “vibe coding” na conversa; a prática por baixo simplesmente amadureceu.

Qual é o melhor modelo de IA para codificação agora? Para máxima qualidade, Claude Opus 4.8 (88,6% no SWE-bench Verified) e GPT-5.5 são os líderes de fronteira. Para o melhor custo-benefício, modelos de pesos abertos como GLM 5.2 e Kimi K2.7-Code ficam surpreendentemente perto por uma fração do custo. A resposta inteligente é usar os dois — fronteira para os 10% difíceis, barato e forte para os outros 90%.

Como posso fazer vibe coding de graça (ou quase)? Use um agente gratuito e de código aberto como o OpenCode, combine com o nível gratuito do Ollama Cloud ou com um plano abaixo de US$ 15 como o Coding Plan do GLM ou o Kimi Code, e rode modelos de pesos abertos. O Google Antigravity também é gratuito para pessoas físicas em prévia. Dá para construir muita coisa séria pelo preço de um sanduíche por mês.

Posso realmente construir uma startup ou um aplicativo grande assim? Um produto real, com várias funcionalidades e qualidade de produção — sim, e pessoas fazem isso sozinhas o tempo todo. Um clone literal do Google ou do Facebook em escala total — não, isso são milhares de engenheiros e infraestrutura em escala planetária. O alvo realista e genuinamente empolgante é um produto ambicioso construído com qualidade de produção por uma pessoa ou uma equipe minúscula, o que antes era impossível.

Código gerado por IA é seguro o suficiente para colocar no ar? Não por padrão. Código de IA é desproporcionalmente propenso a vulnerabilidades, então você precisa revisar e escanear, nunca deixar agentes lidar com autenticação ou segredos sem supervisão, e tratar toda saída como não confiável até ser verificada. Feito com essa disciplina, é perfeitamente entregável. Feito às cegas, é uma invasão esperando para acontecer.

Claude Code vs Cursor — qual um iniciante deve escolher? Se você quer o agente mais capaz e se sente confortável no terminal, Claude Code. Se quer ver seu código em um editor polido enquanto direciona a IA, Cursor. Muitas pessoas usam os dois. Qualquer um dos dois é um bom lugar para começar; não sofra com isso.

O que é o Ollama Cloud e por que eu usaria? O Ollama Cloud roda grandes modelos de código aberto em GPUs gerenciadas de data center para que você não precise de hardware caro, expondo exatamente a mesma API de rodar o Ollama localmente — então é plug-and-play. Use para inferência amigável à privacidade e com custo controlado, especialmente trabalho de alto volume, com um nível gratuito para começar.

Qual é a diferença entre AGENTS.md e CLAUDE.md — e o Claude Code lê o AGENTS.md? AGENTS.md é o padrão aberto e entre ferramentas (administrado sob a Linux Foundation e lido por Codex, Cursor, Windsurf, Cline, Gemini CLI e mais de 30 outros); CLAUDE.md é o arquivo de instruções nativo do próprio Claude Code. O detalhe: a partir de meados de 2026, o Claude Code não lê automaticamente AGENTS.md — se um repositório tem apenas esse arquivo, o Claude Code não carrega nenhuma instrução de projeto e não avisa. A correção é manter AGENTS.md como sua fonte compartilhada de verdade e fazer do CLAUDE.md um arquivo fino que o importa com uma única @AGENTS.md linha (ou criar um link simbólico entre os dois com ln -s AGENTS.md CLAUDE.md). Um arquivo para o mundo, um arquivo fino por ferramenta.

Como impedir que um agente de IA esqueça meu projeto entre sessões? Coloque a memória do projeto em arquivos no repositório, não no chat. Mantenha um AGENTS.md para as regras, um ROADMAP.md para o plano, um TASKS.md para o cursor atual (feito / em andamento / próximo), e um DECISIONS.md para as escolhas travadas. Faça o agente ler esses arquivos no início de cada sessão e gravar as atualizações no final. Como é tudo Markdown puro no disco, o contexto sobrevive a redefinições de contexto, trocas de modelo e mudanças completas de ferramenta.

Para onde ir a partir daqui

O vibe coding em 2026 não é um truque e não é um atalho para preguiçosos. É uma forma real, poderosa e cada vez mais padrão de construir software — uma que dá alavancagem enorme a qualquer pessoa disposta a aprender a direcioná-la bem. A barreira para criar software desabou. A nova barreira é gosto, julgamento e disciplina.

Então comece pequeno hoje. Escolha um agente, aponte-o para um projeto real e execute o ciclo: descreva, revise, itere, teste. Depois, quando estiver pronto para ir maior, configure o sistema com documentação em primeiro lugar para que seu projeto tenha memória e seus agentes possam escalar com você. A distância entre “tenho uma ideia” e “está no ar na internet” nunca foi tão pequena. A única pergunta que resta é o que você vai construir.

---

Está construindo algo ambicioso e quer exatamente o sistema de documentação e prompts que faz o vibe coding em larga escala realmente funcionar? Isso é um guia inteiro à parte — e uma ótima próxima leitura neste site.