Vibe coding: quando criar deixa de ser privilégio do time técnico 

Eu sei que o tempo tem passado rápido. Quando tudo muda muito em pouco tempo, a memória fica meio turva, como se seis meses tivessem passado em seis dias. Mesmo assim, vale puxar um fio recente, porque ele ajuda a explicar com bastante clareza o que está acontecendo agora. 

Lembra do começo das discussões sobre IA nas empresas? Sim, parece que foi “lá atrás”, mas foi ontem. As perguntas eram sempre as mesmas: funciona bem ou não funciona? Alucina ou não alucina? É segura ou não é? Meus dados estão treinando ou não estão? Posso usar? Devo proibir? Quem vai ser responsável? 

E, no fim, depois de tanta mesa redonda, tanta opinião e tantos “depende”, a realidade fez o que ela sempre faz. Ela chegou. Chegou para as pessoas. Chegou para as empresas. Chegou para o dia a dia. 

É por isso que esse filme me veio à cabeça agora. Estou vendo a mesma história começar de novo, só que com outra personagem principal: o vibe coding. 

Na minha visão, vibe coding é algo bastante objetivo. É a democratização da capacidade de criar produtos. 

Quem trabalha com tecnologia sabe que a esteira de construção de produto é longa. Começa na ideação, passa por discussão de mercado, protótipo, análise e definição de arquitetura, escrita de histórias, definição de roadmap. Só então chega ao time de desenvolvimento para, de fato, começar a trabalhar. Depois volta para validação, homologação e teste. Não por acaso, o ágil é tão adotado. Mudanças entram no caminho. E só quando a coisa começa a tomar forma é que fica claro como ela realmente vai funcionar. 

Vale olhar esse fluxo com calma. A quantidade de pessoas envolvidas. O custo. Não apenas o de execução, mas o de coordenação. O de alinhamento. O custo do “deixa eu te mostrar isso aqui rapidinho” que vira uma reunião de uma hora. 

Com vibe coding, uma parte relevante desse caminho encurta. A construção começa mais cedo, com menos intermediários. A solução passa a nascer de forma mais direta. Quem tem a dor e a intenção já consegue materializar uma primeira versão. 

Quando falo em democratização, não me refiro apenas a PMs ou a times de produto criando software. Estou falando de mais pessoas dentro da empresa. 

O mercado já vinha nessa direção, buscando automação, velocidade, fluxo e menos fricção no dia a dia. Mas agora a mudança é de outra ordem. Não se trata apenas de otimizar o que já existe. Trata-se de quem, de fato, consegue construir. 

Quando essa conversa começa, as perguntas aparecem, agora com novas camadas. 

“E a segurança?” 

“E a governança?” 

“E a escalabilidade?” 

“E a arquitetura?” 

“E a qualidade?” 

Essas preocupações são legítimas. Fazem parte de qualquer discussão séria sobre tecnologia que pretende escalar e sustentar valor no tempo. 

O ponto central, no entanto, é outro. Segurança, governança e escalabilidade não são impeditivos da mudança. São elementos de projeto. E, quando tratados desde a base, deixam de ser risco para se tornarem vantagem competitiva. 

Por isso, a questão não é “adotar ou não adotar”. Nem “liberar ou proibir”, como se fosse uma escolha filosófica. A questão é sair de uma posição negacionista. Não dá para negar o que já está acontecendo. 

O debate maduro é outro. Como fazer isso do melhor jeito possível? 

E, honestamente, esse talvez seja um dos maiores espaços de negócio e inovação que se abriu nos últimos anos. A governança de um mundo em que cada vez mais pessoas terão capacidade de gerar soluções dentro das empresas. 

Para sair da abstração, vale ir para o concreto. 

Um Sistema Criado em um Dia

No fim do ano, com um pouco mais de tempo. Férias, mas não exatamente. Eu já vinha usando essas ferramentas, estudando bastante, testando, entendendo limites e possibilidades. Conversando com outras empresas e pegando referências de quem já usa com mais maturidade, senti segurança para fazer algo e publicar internamente. 

Eu fiz um sistema.

Um portal de RH conectado a um portal de finanças. 

E quando digo “fiz”, é literal. Tela, fluxo, lógica, organização, estrutura. Isso gerou um ganho enorme de eficiência para análises, pesquisas, apresentações, gestão de metas, fechamento automático de folha, contratos, ausências, aprovações. 

O mais curioso, ou mais absurdo, dependendo do ponto de vista, é que isso foi feito em um dia. 

Depois de pronto, aconteceu exatamente o que um bom produto provoca. Surgiram discussões, ajustes, novas sugestões das pessoas que começaram a usar. O produto passou a existir e, com ele, veio o refinamento. 

Naturalmente, vieram também os questionamentos técnicos do meu time, como sempre acontece quando algo começa a ganhar escala. 

“Que arquitetura você usou?” 

“Qual linguagem?” 

“Isso está aderente à nossa arquitetura?” 

“Quais integrações você fez?” 

“Onde isso roda?” 

“Como você publicou?” 

“Como fica segurança e acesso?” 

Para contextualizar, desenhei até o logo e a linguagem visual, como ponto de partida. E, sim, não usei exatamente a arquitetura que costumamos adotar. 

A beleza disso é que não virou “joga fora”. Virou “agora desenvolvemos em cima do que já existe”. 

Passei para o time e, juntos, usamos nossa plataforma de orquestração e automação para colocar tudo dentro do padrão, publicar na nuvem, adaptar e ajustar o que precisava ser ajustado. 

Ou seja, não houve substituição do time técnico. Houve aceleração do nascimento. 

O caminho entre intenção e primeira versão funcional ficou mais curto. 

A partir daí, o time fez o que faz de melhor. Garantir robustez, segurança, escala e governança. 

Essa é, para mim, uma virada de chave que o mercado começa a assimilar. 

O Futuro do Vibe Coding

Vibe coding não é sobre “todo mundo virar programador”. 

É sobre permitir que mais pessoas consigam tirar boas ideias do papel. Prototipar, testar, aprender rápido. Enquanto o time técnico se concentra onde é insubstituível. Arquitetura, segurança, padrões e qualidade. 

Uma empresa madura não vai “proibir” isso. 

Vai estruturar. 

Vai deixar claro quais dados podem circular e quais não. 

Quais ambientes são permitidos. 

Quais integrações exigem revisão. 

Quais padrões são obrigatórios. 

Como versionar, testar, auditar, monitorar e garantir rastreabilidade. 

Faz isso porque entende que o desafio não é evitar a mudança. É operar com responsabilidade dentro dela. 

As discussões vão existir. 

Vai haver receio, exagero, uso malfeito. 

Como aconteceu com toda tecnologia que mudou a forma de trabalhar. 

Mas isso não altera o ponto central. A mudança já está em curso. 

A pergunta relevante deixou de ser se isso vai acontecer. 

Passou a ser como isso vai acontecer. 

Porque, no fundo, toda tecnologia que muda produtividade se torna inevitável. Primeiro se debate. Depois há resistência. Depois vem a aceitação. Até que, quando se percebe, ela já está sendo usada. Com ou sem preparo. 

Eu prefiro estar do lado de quem entende antes. 

De quem estuda. De quem testa. De quem propõe usos. 

Com consciência. 

Com governança. 

Com coragem. 

Com velocidade. 

E, principalmente, com a honestidade de admitir que negar já não é uma opção.