Da codificação do vibe à implantação do vibe: fechando a lacuna entre o protótipo e a produção

Em fevereiro de 2025, Andrej Karpathy cunhou o termo “codificação de vibração” com um twittar que ressoou instantaneamente na comunidade de desenvolvedores. A ideia period simples, mas poderosa: em vez de escrever código linha por linha, você descreve o que deseja em linguagem pure e um modelo de IA sustenta toda a solução. Sem especificações formais, sem rotina, apenas vibrações.

A codificação Vibe rapidamente ganhou força porque eliminou o atrito de iniciar um projeto. Em minutos, os desenvolvedores poderiam passar de uma ideia vaga de produto a um protótipo funcional. Não se tratava apenas de velocidade, tratava-se de criatividade fluida. As equipes poderiam explorar ideias sem comprometer semanas de engenharia. A demonstração viral, como o um que Satya Nadella fez e vários experimentos reforçaram a sensação de que o desenvolvimento assistido por IA não period apenas uma curiosidade; foi um vislumbre do futuro da criação de software program.

Mas mesmo naqueles primeiros dias, havia uma realidade tácita: embora a IA pudesse “vibrar” um MVP, o salto do protótipo para a produção permanecia uma lacuna formidável. Essa lacuna tornar-se-ia em breve o desafio central para a próxima evolução desta tendência.

A parte difícil: por que os protótipos raramente sobrevivem ao contato com o produto

A codificação Vibe é excelente na idealização velocidade mas luta com o rigor da implantação. O caminho para a produção não é uma linha reta; é um labirinto de escolhas, restrições e governança.

Uma implantação típica de produção força as equipes a tomar dezenas de decisões:

• Versões de idioma e tempo de execução – nem todos são igualmente suportados ou aprovados em seu ambiente. Por exemplo, sua organização pode certificar apenas Java 21 e Node.js 18 para produção, mas o agente escolhe Python 3.12 com uma nova biblioteca assíncrona que as operações ainda não suportam.
• Opções de infraestrutura – Kubernetes? Sem servidor? Baseado em VM? Cada um tem seu próprio modelo de escalonamento, rede e segurança. Um protótipo pode assumir o AWS Lambda, mas seu provedor de nuvem preferido é diferente. A escolha da infraestrutura também mudará a arquitetura.
• Integrações de terceiros – A maioria das soluções precisará ser integrada a sistemas de terceiros por meio de APIs e webhooks. Haverá vários sistemas de terceiros para realizar uma tarefa e esse único sistema selecionado também terá várias versões de API, que diferirão significativamente em funcionalidade, fluxos de autenticação e preços.
• Uso do modelo de IA – nem todos os modelos são aprovados e as regras de custo ou de privacidade podem limitar as escolhas. Um desenvolvedor pode criar protótipos com GPT-4o por meio de uma API pública, mas a organização só permite um modelo hospedado internamente por motivos de conformidade e privacidade.

Esta explosão combinatória sobrecarrega tanto os desenvolvedores humanos quanto os agentes de IA. Sem restrições, o agente pode produzir uma arquitetura que seja elegante em teoria, mas incompatível com o seu ambiente de produção. Sem proteções, isso pode introduzir lacunas de segurança, riscos de desempenho ou violações de conformidade que só surgem após a implantação.

Realidades operacionais, SLAs de tempo de atividade, orçamentos de custos, verificações de conformidade e gerenciamento de mudanças exigem disciplina de engenharia deliberada. Estas não são coisas que a IA pode adivinhar; eles precisam ser codificados no sistema em que funcionam.

O resultado? Muitos protótipos codificados por vibração param antes da implantação ou exigem uma reescrita completa para atender aos padrões de produção. A energia criativa que tornou o protótipo emocionante fica atolada na lenta rotina da engenharia de última milha.

Tese: Restringir para capacitar – Dê ao agente um contexto limitado

O instinto comum ao trabalhar com grandes modelos de linguagem (LLMs) é dar-lhes o máximo de liberdade, mais opções, mais ferramentas. Mas na entrega de software program, é exatamente isso que faz com que eles falhem.

Quando um agente precisa escolher entre todas as linguagens, tempos de execução, bibliotecas, padrões de implantação e configurações de infraestrutura possíveis, é como pedir a um chef para preparar uma refeição em um supermercado do tamanho de uma cidade: muitas possibilidades, sem restrições e sem garantia de que os ingredientes funcionarão juntos.

O verdadeiro desbloqueio para a implantação do vibe é a restrição. Não limites arbitrários, mas padrões opinativos incorporados em uma Plataforma de Desenvolvedor Interna (IDP):

• Um menu selecionado de linguagens de programação e versões de tempo de execução que a organização oferece suporte e mantém.
• Uma lista abençoada de serviços e APIs de terceiros com versões aprovadas e análises de segurança.
• Courses de infraestrutura predefinidas (bancos de dados, filas, armazenamento) que se alinham com SLAs organizacionais e modelos de custos.
• Um conjunto finito de modelos de IA e APIs aprovados com diretrizes de uso claras.

Este “contexto limitado” transforma o trabalho do agente. Em vez de inventar uma solução arbitrária, ela monta um sistema a partir de blocos de construção conhecidos e prontos para produção. Isso significa que todos os artefatos gerados, desde o código do aplicativo até os manifestos do Kubernetes, podem ser implantados no primeiro dia. É como fornecer a um chef uma bancada bem projetada com utensílios e ingredientes selecionados.

Em outras palavras: liberdade no nível criativo, disciplina no nível operacional.

A Interface: Expondo a Plataforma through MCP

Uma plataforma opinativa só é útil se o agente puder compreendê-la e operar dentro dela. É aí que entra o Mannequin Context Protocol (MCP).

O MCP é como a interface do menu entre sua plataforma interna de desenvolvedor e o agente de IA. Em vez de o agente adivinhar: “Quais mecanismos de banco de dados são permitidos aqui? Qual versão da API do Salesforce é aprovada?” ele pode perguntar à plataforma diretamente through MCP, e a plataforma responde com uma resposta oficial.

O Servidor MCP será executado junto com o seu IDP, expondo um conjunto de capacidades estruturadas (ferramentas, metadados).

1. Catálogo de Capacidades – lista as opções aprovadas para linguagens, bibliotecas, recursos de infra-estrutura, padrões de implantação e APIs de terceiros por meio de descrições de ferramentas
2. Modelos de Caminho Dourado – acessível por meio de descrições de ferramentas para que o agente possa estruturar novos projetos com estrutura, configuração e postura de segurança corretas.
3. APIs de provisionamento e governança – acessível por meio de ferramentas MCP, permitindo que o agente solicite infra ou execute verificações de política sem sair do contexto limitado.

Para o LLM, o MCP não é apenas um endpoint de API; é a realidade operacional da sua plataforma tornada legível e operável por máquina. Isso faz a diferença entre “o agente pode gerar algo implementável” e “o agente sempre gera algo implementável”.

Na nossa analogia com o chef, o MCP é como o gerente de cozinha que entrega o mapa da despensa e os cardápios ao chef, por meio dos quais o chef aprende os ingredientes e utensílios de que dispõe para não tentar fazer pizza no forno a lenha com forno a gás.

Arquitetura de referência: fluxo “Immediate-to-Prod”

Com base na combinação acima da tese acima e das seções de interface, podemos chegar a uma arquitetura de referência para implantação de vibe. A arquitetura de referência para implantação do vibe é uma estrutura de cinco etapas que combina a opinião da plataforma com a orientação do agente:

1. Inventário e Opinião

• Escolha linguagens abençoadas, versões, dependências de terceiros, lessons de infraestrutura (bancos de dados, filas, armazenamento) e arquiteturas de implantação (VM, Kubernetes).
• Defina projetos, modelos e caminhos dourados que reúnam o inventário selecionado acima e ofereçam experiências opinativas. Serão abstrações que sua plataforma de negócios usará, como componentes de back-end, aplicativos da net e tarefas. Golden path será uma definição que diz para serviços de backend usar Go versão 10 com banco de dados MySQL.
• Documente claramente o que está no escopo e fora do menu para que humanos e agentes operem dentro dos mesmos limites.

2. Construir/Modificar a Plataforma

• Adapte sua plataforma interna de desenvolvedor para refletir essas decisões opinativas. Isto incluirá a adição de novas infra-estruturas e serviços para disponibilizar os recursos opinativos. Se você decidir pela versão 10 do lang, isso significa ter imagens de base adequadas nos registros de contêiner. Se você decidir por uma dependência específica de terceiros, isso significa ter uma assinatura e manter essas informações de assinatura em seus armazenamentos de configuração ou cofres de chaves.
• Put together modelos de caminho dourado, definições de infraestrutura pré-configuradas e verificações de governança integradas. Implemente os projetos definidos e os caminhos dourados usando os recursos de plataforma recém-adicionados. Isso incluiria a integração de infraestrutura e serviços adicionados anteriormente por meio de manifestos do Kubernetes e gráficos de leme, de forma a fornecer uma experiência selecionada

3. Expor through servidor MCP

• Assim que a plataforma estiver disponível, trata-se de implementar a interface. Esta interface deve ser autodescritível e legível por máquina. Características que claramente se adequam ao MCP.
• Exponha recursos que destacam limites opinativos — desde versões de API até limites de infraestrutura — para que o agente tenha um contexto limitado para operar. Os recursos também devem ser autodescritíveis e fáceis de usar. Isso incluirá descrições de ferramentas bem elaboradas que os agentes podem usar para tomar melhores decisões.

4. Refinar e Iterar

• Teste o fluxo prompt-to-prod com equipes de desenvolvimento reais. A iteração é o que faz tudo isso funcionar. Dada a diferença na composição da plataforma, não existe uma regra de ouro. Trata-se de testar e melhorar as descrições das ferramentas.
• Ajuste as ferramentas MCP com base no suggestions. Com base no suggestions recebido nos testes, proceed alterando as descrições das ferramentas e, às vezes, também exigirá alterações na API. Isto pode até exigir uma mudança de opiniões demasiado rígidas.

5. Implantação do Vibe já!

• Com a base definida, as equipes podem passar facilmente da codificação de vibração à implantação de produção com um único immediate.
• Monitore os resultados para garantir que os ganhos de velocidade não prejudiquem a confiabilidade ou a capacidade de manutenção.

O que medir: provando que é mais do que uma demonstração

O perigo das tendências impulsionadas pelo hype é que elas funcionam perfeitamente em demonstrações, mas desmoronam sob o peso das restrições do mundo actual. A implantação do Vibe evita isso — mas apenas se você medir as coisas certas.

O “porquê” aqui é simples: se não monitorarmos os resultados, os aplicativos codificados por vibração poderão silenciosamente introduzir dores de cabeça de manutenção e prolongar os prazos de entrega, como qualquer projeto apressado. Os guarda-corpos só são úteis se soubermos que estão aguentando.

Então, o que medimos?

• Prazo para mudanças — Estamos realmente entregando mais rápido após o primeiro lançamento, e não apenas para a v1?
• Alterar taxa de falha — Estamos mantendo a estabilidade da produção mesmo enquanto aceleramos?
• MTTR (tempo médio para recuperação) — Quando algo quebra, nos recuperamos rapidamente?
• Custo de infra-estrutura por serviço — Estamos mantendo as implantações econômicas e previsíveis?

Essas métricas informam se a implantação do vibe está agregando valor sustentado ou apenas antecipando o ciclo de desenvolvimento com uma velocidade que você pagará mais tarde com dívida técnica.

Para os líderes de plataforma, este é um apelo à ação:

• Pare de pensar na opinião como uma limitação; comece a tratá-lo como um facilitador da entrega alimentada por IA.
• Codifique suas práticas recomendadas, regras de conformidade e padrões de arquitetura na própria plataforma.
• Meça incansavelmente para garantir que a velocidade não prejudique a estabilidade.

O futuro da entrega de software program não é “rápido para prototipar”. A produção é imediata, sem ignorar a disciplina de engenharia que mantém os sistemas saudáveis. As ferramentas existem. Os padrões estão aqui. A única questão é se você dará o salto.