Há uma mudança a acontecer nas equipas digitais que parece anedota até deixar de ser: em 2026, em mais do que uma empresa, o “campeão de commits” já não é o engenheiro mais antigo. É um designer. Ou um gestor de produto. Ou alguém de operações que, até há pouco tempo, pedia “uma featurezinha” por Slack e aguardava duas semanas. Agora abre o Cursor, fala com um modelo, e acorda com um front-end montado, validações a funcionar e uma demo pronta para o daily.
Chamam-lhe vibe coding porque o processo é meio musical, meio improviso: descreve-se a intenção, o agente escreve, ajusta-se por sensação, empurra-se para staging. O resultado pode ser brilhante. Também pode ser uma fábrica de dívida técnica com cheiro a verniz fresco.
O conflito é claro: democratização vs. controlo. E vai dar debate, porque mexe no orgulho profissional e no bolso das empresas.
A noite em que o “não técnico” passou à frente
Numa tarde de inverno, ao lado de um cowork em Marvila, um designer mostrou-me o que tinha “shipado” durante a noite: uma página de checkout com copy melhor, componentes alinhados com o design system e um fluxo de erro que, pela primeira vez, falava como gente. O truque? Não escreveu quase nada à mão. Orquestrou: descreveu, testou, pediu refatoração, voltou a testar.
Daquela cena, fica um detalhe que vale por tese: a codificação mecânica já não é o gargalo. O gargalo passou a ser a definição do que se quer e a garantia de que não se parte o que existe.
Velocidade vs. qualidade: “rubbish at scale” com boa tipografia
Vibe coding funciona melhor onde o erro custa pouco e onde a interface manda: landing pages, dashboards, protótipos, microferramentas internas. É aí que o “não técnico” pode acelerar a empresa sem passar por camadas de priorização que, muitas vezes, só travam.
O risco aparece quando se atravessa a fronteira invisível entre “mexer no UI” e “mexer na lógica de negócio”. Um agente escreve rápido, mas nem sempre entende invariantes, políticas de segurança, permissões, idempotência, concorrência. A superfície fica bonita. Por baixo, o sistema pode ficar mais frágil.
Uma frase curta para não haver ilusões: o vibe coding não falha devagar — falha de uma vez.
Micro-história: um botão que custou uma tarde inteira
Num escritório perto do Saldanha, alguém “só” quis melhorar um botão: o texto era confuso, a taxa de conversão estava baixa. O designer gerou uma alteração com IA, lançou-a em staging, correu bem. Em produção, aquele botão passou a disparar duas chamadas em paralelo a um serviço interno — e, durante algumas horas, o sistema de reservas duplicou pedidos em casos raros. Não houve catástrofe pública. Houve o tipo de caos silencioso que as equipas odeiam: logs, correções apressadas, reuniões de “como é que isto passou?”.
Não foi incompetência. Foi falta de guardrails.
O que muda na equipa: menos “escrever”, mais “definir e garantir”
A discussão mais difícil não é técnica. É de identidade. O engenheiro clássico foi treinado para escrever e controlar. De repente, há gente a “produzir” código sem falar a linguagem — e a empresa adora porque vê velocidade.
O novo papel do engenheiro tende a deslocar-se: Definir limites (o que qualquer pessoa pode mudar e o que exige revisão especializada). Criar trilhos seguros: templates, componentes, scaffolding, ambientes de teste fáceis. Rever por risco, não por ego. Ensinar: literacia mínima de engenharia para quem “shipa” via agentes.
Como aproveitar o vibe coding sem transformar a empresa num laboratório instável
Zonas verdes e zonas vermelhas: Zonas verdes: UI, conteúdo, pequenos fluxos internos. Zonas vermelhas: pagamentos, permissões, dados sensíveis, integrações críticas. Guardrails no processo, não no fim: testes automáticos obrigatórios, linting, CI que bloqueia, revisão mínima por alguém que conhece o sistema. Métricas que não premiem barulho: não medir “commits”; medir incidentes, regressões, tempo de recuperação.
Frase final, sem dramatismo gratuito: o vibe coding é uma alavanca — e toda a alavanca precisa de um ponto de apoio.