O novo ciclo de desenvolvimento: do “vibe coding” à engenharia agêntica

Por décadas, programar foi sinônimo de escrever código: traduzir uma ideia, linha por linha, para uma linguagem que a máquina entende. Esse pressuposto está ruindo. Com agentes de IA capazes de gerar funções, módulos e sistemas inteiros a partir de uma descrição, a parte mais lenta do trabalho (a digitação) deixou de ser o gargalo. O que muda quando gerar código fica barato e abundante? Tudo o que vem antes e depois dele.

No whitepaper The New SDLC With Vibe Coding, o Google descreve essa virada como uma mudança “de escrever código para expressar intenção”. A geração, argumentam os autores, está essencialmente resolvida. O que sobra como ofício (e como diferencial competitivo) é outra coisa: verificar, julgar e direcionar. Este artigo é uma síntese desse mapa, generalizada para além do código: vale para quem constrói qualquer sistema agêntico, inclusive assistentes de IA em operação.

A geração está resolvida. Verificação, julgamento e direção são o novo ofício.Google · The New SDLC With Vibe Coding

Um espectro, não uma fronteira

É tentador opor “vibe coding” (improvisar com a IA, aceitando o que ela cospe) a “engenharia de verdade”. Mas o documento trata os dois como pontos de um mesmo espectro, com a codificação assistida estruturada no meio. O que muda ao longo desse eixo é quanta estrutura, verificação e julgamento humano cercam aquilo que a IA produz.

• Vibe coding: rápido e exploratório. Você descreve, a IA gera, você testa pela sensação. Ótimo para protótipos e descartáveis; arriscado para o que vai a produção.
• Codificação assistida estruturada: a IA gera, mas dentro de trilhos (arquivos de regras, padrões definidos, revisão deliberada de cada mudança).
• Engenharia agêntica: a IA opera dentro de um sistema de verificação, contexto e governança que você projetou; o resultado é confiável porque o entorno o torna confiável.

Nenhuma ponta é “certa” em absoluto. O improviso é legítimo para descobrir uma ideia; a engenharia é obrigatória para mantê-la viva. A maturidade está em saber em que ponto do espectro você precisa estar para cada tarefa, e subir o nível de rigor conforme o risco aumenta.

Verificação é o grande divisor

Se a geração ficou fácil, confiar nela é que é o problema. O Google aponta a verificação como o maior diferencial entre brincar com a IA e fazer engenharia com ela, e observa que parte do código tem comportamento determinístico, mas parte não. São dois regimes de verificação distintos:

• Testes verificam a parte determinística: dada a mesma entrada, a saída deve ser sempre a mesma. É o território clássico dos testes unitários e de integração.
• Avaliações (evals) verificam a parte não determinística: a trajetória que o agente percorreu, as ferramentas que escolheu, a qualidade do resultado. Quando não existe uma única resposta “certa”, você avalia em vez de assertar.

Essa distinção é o coração da engenharia agêntica. Um agente que faz a coisa certa pelo motivo errado (ou pelo caminho frágil) vai falhar quando o contexto mudar. Avaliar trajetória e escolha de ferramentas, não só o resultado final, é o que separa um sistema robusto de um truque de demonstração.

Engenharia de contexto: a habilidade que realmente importa

Se há uma competência que define o profissional desta era, o whitepaper é claro: é a engenharia de contexto. O modelo é capaz; o que decide a qualidade da saída é a informação certa, no formato certo, no momento certo. O Google organiza esse contexto em seis tipos:

• Instruções: o que o agente deve fazer e como se comportar.
• Conhecimento: os fatos e documentos de que ele precisa para fundamentar respostas.
• Memória: o que persiste entre interações e sessões.
• Exemplos: casos concretos que demonstram o resultado esperado.
• Ferramentas: as ações que ele pode executar no mundo.
• Guardrails: os limites que restringem o que ele pode e não pode fazer.

Parte desse contexto é estática (vale sempre) e parte é dinâmica (carregada conforme a tarefa). Daí a ideia de “Agent Skills”: pacotes portáteis de conhecimento procedural (como executar uma tarefa específica), carregados apenas quando são necessários. É a chamada divulgação progressiva (progressive disclosure): em vez de empilhar tudo no contexto, você entrega só o que a tarefa do momento exige, mantendo o agente focado e barato.

O ciclo se comprime de forma desigual

Um erro comum é imaginar que a IA acelera o desenvolvimento por igual. Não é o que acontece. O whitepaper mostra que ela comprime o ciclo de forma desigual: a implementação, que antes levava dias, colapsa para horas; mas requisitos, arquitetura e verificação seguem no ritmo humano, porque dependem de julgamento, contexto de negócio e responsabilidade. Quando a digitação some, o trabalho de pensar e validar não some junto; ao contrário, ganha proporção.

Daí o que o documento chama de “Modelo de Fábrica”: o resultado real do profissional deixa de ser o trabalho em si e passa a ser o sistema que produz o trabalho. Você não entrega mais apenas uma função: entrega os prompts, as regras, as suítes de avaliação e as skills que fazem o agente produzir aquela função de forma confiável, repetível e auditável. O artefato de valor migrou do output para a máquina que gera o output.

Dois papéis: maestro e orquestrador

Conduzir esse trabalho exige posturas diferentes conforme a escala. O Google descreve dois modos complementares:

• Maestro (Conductor): trabalho síncrono, dentro do editor, dirigindo um agente em tempo real, revisando, corrigindo e ajustando o rumo passo a passo.
• Orquestrador (Orchestrator): trabalho assíncrono, delegando a vários agentes em paralelo e avaliando o que voltou. Menos digitação, mais coordenação e julgamento.

A trajetória de carreira, nessa leitura, é a passagem de quem executa para quem dirige a execução. O valor não está em produzir mais linhas, e sim em desenhar e governar o sistema que as produz.

Os riscos: o “problema dos 80%” e a governança

Nada disso é mágica, e o whitepaper não vende ilusão. Ele nomeia o “problema dos 80%”: a IA chega rápido a uma versão quase pronta, mas os 20% finais (casos de borda, integração, robustez, segurança) continuam custando caro e exigindo gente. E vai além ao diagnosticar a origem das falhas: a maioria das falhas de agentes são falhas de configuração (contexto mal montado, instruções ambíguas, ferramentas erradas) e não limitações do modelo.

A consequência prática é direta: prompts, arquivos de regras, suítes de avaliação e bibliotecas de skills devem ser tratados como infraestrutura (versionada, revisada e com dono). Não são rascunhos descartáveis; são o tecido que torna o sistema confiável. Os números reforçam a cautela:

• No início de 2026, cerca de 85% dos desenvolvedores profissionais usam agentes de IA com regularidade, e aproximadamente 41% do novo código é gerado por IA.
• Um estudo da METR encontrou desenvolvedores experientes levando 19% mais tempo em certas tarefas, o custo da verificação, que cresce quando você precisa conferir o que a máquina produziu.
• A síntese do documento é desconfortável e honesta: a IA é um multiplicador de força; multiplica tanto as suas forças quanto as suas fraquezas.

O mesmo princípio, além do código: a Charla

Esse mapa não vale só para quem escreve software. Vale para quem constrói e opera assistentes de IA, e é exatamente onde a Charla se posiciona. A premissa é a mesma do novo SDLC: gerar é a parte fácil; o ofício é cercar a saída da IA de contexto, verificação e governança. A Charla permite montar e operar assistentes agênticos sem reconstruir o substrato a cada vez.

• Custom skills por assistente: capacidades empacotadas como instruções e recursos portáteis, carregados sob demanda, a mesma ideia de divulgação progressiva descrita pelo Google.
• Conexão via MCP: integração com sistemas externos por meio do MCP, um padrão aberto de interoperabilidade, em vez de integrações ad hoc presas a cada caso.
• Meta Charla: um template reutilizável já semeado, ponto de partida para novos assistentes em vez de começar do zero.
• Governança humana: postura de propor-e-aprovar e um log de auditoria append-only mantêm as pessoas no comando do que a IA produz.

É a leitura do whitepaper aplicada a operações, e não só a código: a IA gera; as pessoas dirigem, verificam e respondem pelo resultado. A Charla existe para tornar esse arranjo concreto: skills como infraestrutura versionável, integração por padrão aberto, aprovação humana antes do efeito e rastro auditável depois dele.

A conclusão do novo ciclo de desenvolvimento é, no fundo, libertadora. Se a geração está resolvida, o que resta é o que sempre foi mais difícil (e mais humano): saber o que construir, decidir se está certo e assumir a responsabilidade pelo resultado. Digitar deixou de ser o trabalho. Dirigir, verificar e julgar é que são. Esse é o novo ofício, em código e em operações.