Vibe Coding 101: Um Workshop Prático do Zero ao Um

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros tipográficos, uma vez que o bot não está correto a 100% do tempo.

Hannah Clark: Muito bem, pessoal. Aviso sobre o episódio — se já é especialista em Vibe Coding, este episódio pode não ser para si. Mas se já ouviu falar de Vibe Coding e quer conhecer os factos em vez dos mitos, e tem curiosidade em saber como pode utilizar esta tecnologia para alcançar os seus próprios objetivos, vai adorar este episódio.

Se não tem acompanhado as nossas newsletters, como aquelas em que pode subscrever em theproductmanager.com/subscribe, não tenho conseguido parar de falar sobre o fantástico Workshop Prático de Vibe Coding que realizámos há algumas semanas, com Drew Falkman, Diretor da Moves The Needle. Este episódio do Product Manager Podcast é, na realidade, uma gravação do seminário de 30 minutos que fizemos antes de iniciarmos a nossa sessão de prototipagem em direto. Vai ouvir uma explicação do que é e do que não é o Vibe Coding, casos de utilização inspiradores para a tecnologia e recomendações de ferramentas para começar a experimentar e a descobrir os seus próprios casos de utilização. Vamos começar.

Ah, já agora, temos conversas como esta todas as semanas. Por isso, se isto lhe parece interessante, porque não subscreve? Muito bem, vamos começar.

Eu sou Hannah Clark. Se não me conhece, sou a Editora Executiva de The CPO Club e apresentadora do podcast The CPO Club. E tenho comigo a minha coapresentadora, Katie.

Katie Sanders: Olá a todos, sou Katie Sanders. Sou Editora Executiva do The CTO Club. Talvez também do The QA Lead. Há algumas pessoas dos sites que fundimos. Por isso, estou muito entusiasmada. Este é o meu primeiro workshop e estou muito feliz por fazê-lo com a Hannah, porque existe uma grande ligação entre produto e diretores de tecnologia. Portanto, estou entusiasmada por conhecer toda a gente. Bem-vindos!

Hannah Clark: Estou muito entusiasmada por trabalhar com a Katie neste projeto. Se ainda não a seguem no LinkedIn, procurem Katie Sanders; ela é mesmo incrível. Tem conteúdo excelente, por isso estou muito contente por poderem conhecer-se melhor.

Gostaria também de apresentar o nosso orador convidado. Temos aqui o Drew Falkman. O Drew é um líder de produto, consultor e formador, focado na estratégia de produto desde a fase pré-seed até à seed. Estruturou equipas iniciais. Otimizou produtos para alcançar a adequação ao mercado.

Ele já fez de tudo. É um grande amigo da publicação. Trabalhou imenso connosco. E trabalhou muito comigo, o que significa que é um homem muito paciente. Por isso, estão hoje em boas mãos. Também tem muita experiência em produtos web, móveis, de blockchain e de IA. Portanto, temos aqui um especialista incrível.

Drew, queres cumprimentar as pessoas simpáticas que nos estão a ouvir?

Drew Falkman: Olá a todos, estou muito entusiasmado por estar aqui. Isto vai ser divertido.

Hannah Clark: Vamos começar por desmontar alguns mitos. Vou iniciar com a primeira pergunta e depois a minha adorável coapresentadora, Katie, vai abordar alguns mitos e pedir ao Drew que os esclareça. Vamos começar por estabelecer algum contexto.

Parece que toda a gente está a falar de Vibe Coding e que este tema aparece atualmente em todas as publicações do LinkedIn, incluindo muitas das minhas. E as pessoas parecem estar muito entusiasmadas, muito assustadas ou muito confusas. Por isso, vamos falar sobre a razão pela qual o Vibe Coding é tão popular. Porque é tão importante neste momento? Vamos explorar o mito associado a isso.

Katie Sanders: Muito bem, primeiro mito: o Vibe Coding está a substituir os engenheiros. Obviamente, existe a ideia geral de que a IA está a substituir o emprego de toda a gente. É isso que se diz. Eu diria que isso é um mito e que talvez esteja a mudar o trabalho dos engenheiros e a criar código pronto para aplicações, mas certamente não está a substituir completamente o trabalho de um engenheiro.

Como sempre acontece com a IA, queremos manter uma pessoa envolvida no processo. Por isso, diria que nada será lançado sem ser analisado por pessoas, e penso que podemos desmistificar esse mito.

Hannah Clark: Drew, querias acrescentar alguma coisa?

Drew Falkman: Sim, diria que é algo de que um engenheiro deve estar consciente e que deve ter em consideração, porque está a aproximar-se.

Pode simplesmente acelerar o seu processo. E, enquanto designer, gestor de produto ou fundador não técnico, agora têm a capacidade de criar MVPs, criar e validar protótipos e fazer várias coisas, entregando-as depois aos engenheiros. Quando quiserem chegar a código de nível de produção, de um modo geral, para além de um MVP,

nesta época, precisam certamente de fazer revisões de código e analisar tudo para garantir que está devidamente aperfeiçoado, especialmente se existirem questões de conformidade ou qualquer outro aspeto de que precisem de estar conscientes.

Hannah Clark: Vamos avançar para o mito número dois. Algumas pessoas dizem que o Vibe Coding está fora do ciclo de desenvolvimento.

Por outras palavras, se construirmos algo numa aplicação de Vibe Coding, isso continua a não ser realmente utilizável e temos de reconstruir tudo completamente de raiz com um programador que codifique manualmente toda a solução. Drew, é mesmo assim?

Drew Falkman: As ferramentas evoluíram imenso e esta é uma daquelas áreas que está literalmente a mudar todos os dias.

A Claude lançou recentemente uma nova espécie de iteração da sua geração de código, há cerca de um mês, e está muito melhor do que antes. Por isso, está continuamente a melhorar. Tal como acontece com todas as ferramentas de IA generativa, pode ter alucinações, fazer coisas disparatadas e realizar ações inesperadas. Assim, pode ser integrada no ciclo e permitir-lhe criar estes tipos de componentes de código.

Pode entregá-los aos engenheiros, mas precisa realmente de estar consciente de que provavelmente vão precisar de algum retrabalho. Pode ser necessário reutilizar alguns componentes, e penso que alguns engenheiros podem ficar algo surpreendidos com a qualidade efetiva do código.

Hannah Clark: Muito bem. Outro mito que tenho ouvido muitas vezes é que não é necessário ter um PRD ou uma estratégia de produto para criar uma ferramenta com Vibe Coding.

Drew, Katie, o que pensam sobre isso?

Drew Falkman: É preciso pensar sempre. Penso que, por vezes, as pessoas pensam: se estou a fazer Vibe Coding, posso simplesmente começar, abrir a ferramenta e ter uma aplicação amanhã. E, tal como acontece com qualquer outra coisa, se não refletir previamente sobre o assunto, o resultado não será aquilo que pretende. Deve pensar em quem é o seu público e qual é o seu mercado-alvo.

Deve pensar na sua proposta de valor. Deve pensar nas funcionalidades e nos fluxos principais que a aplicação terá. Por isso, vale mesmo a pena dedicar algum tempo a preparar algo. A beleza disto é que não precisa de criar um PRD de cinco a dez páginas que defina a tecnologia a utilizar, nem de criar diagramas de todos os fluxos e assim por diante.

Não precisa de pensar nisso. Basta delinear qual é a sua visão e o que está a construir. Na verdade, criei um pequeno PRD de Vibe Coding, com uma a duas páginas, apenas para si e para qualquer pessoa com quem possa estar a colaborar, para que estejam todos alinhados e possam abordá-lo de forma organizada.

E para que o seu código fique mais limpo a longo prazo.

Hannah Clark: É bom saber. Vamos avançar para o próximo mito, sobre setores altamente regulamentados. Agora, a Katie representa o CTO Club. Katie, queres abordar este mito?

Katie Sanders: Sim, penso que há outro ponto que queria abordar: a ideia de que isto é algo novo. Temos feito Vibe Coding há anos.

Só não lhe chamávamos isso até recentemente. Copiar e colar código do GitHub, do Reddit ou do Hacker News, por exemplo, é algo que os bons engenheiros fazem: resolvem problemas, pesquisam, identificam padrões, adaptam e constroem. Por isso, penso que este tipo de instrução é simplesmente a próxima evolução de algo que sempre existiu. E, Hannah, qual era o outro mito que querias desmontar?

Hannah Clark: O mito de que, se trabalharmos num setor altamente regulamentado, não podemos fazer Vibe Coding. Que não é seguro.

Katie Sanders: Sim. Obviamente, quando pensamos em cuidados de saúde ou finanças, estamos a falar de setores altamente regulamentados. Tal como em qualquer outro setor, é preciso garantir a conformidade com a HIPAA e com todos os outros requisitos.

Sei que os LLM podem, por vezes, obter informação. Por isso, tenha em consideração as questões de conformidade específicas do setor. Penso que existe uma camada adicional de proteção quando estamos a falar de cuidados de saúde, finanças ou algo semelhante.

Hannah Clark: Sim, penso que é semelhante a muitos processos de desenvolvimento diferentes, nos quais as ferramentas de Vibe Coding não substituem as pessoas.

Funcionam como um complemento para acelerar o ciclo de desenvolvimento. Mas um processo rigoroso de revisão de código é provavelmente mais essencial do que nunca, agora que estamos a subcontratar parte desse trabalho. Muito bem. Vamos falar um pouco sobre alguns casos de utilização. Será divertido explorar algumas das diferentes formas como as pessoas estão atualmente a utilizar o Vibe Coding de forma eficaz.

A Katie vai conduzir esta parte do programa e abordar alguns dos casos de utilização mais interessantes.

Katie Sanders: Na verdade, retirei muitos destes exemplos do Reddit quando o Vibe Coding começou a ganhar força. Queria ver exemplos reais. Toda a gente falava sobre o assunto, mas eu não conseguia encontrar nada que tivesse sido bem-sucedido.

Por isso, escrevi um artigo sobre o tema. Uma das coisas de que falámos foi uma pessoa que criou, penso eu, uma aplicação para organizar jogos de futebol de nicho. Era um interesse pessoal, um passatempo. Não era programador, mas compreendia o funcionamento das aplicações full-stack e sempre teve de contratar programadores para dar vida às suas ideias.

Mas, quando começou a experimentar o Lovable, o Cursor e todas estas outras ferramentas, criou esta aplicação de nicho para organizar jogos de futebol semanais e acabou por a lançar com sucesso. Penso que criou uma aplicação de IA com cem linhas de código e conseguiu obter lucro em poucas semanas. Se não me engano, estava a gerar cerca de 700 dólares por semana. Era o Michael?

Seriam cerca de 700 dólares por semana, ou algo semelhante. Outro exemplo que encontrámos chamava-se Workaid, uma ferramenta de gestão de tarefas gamificada e baseada em IA. Revolucionava a lista de tarefas, utilizando aplicações para fazer com que o trabalho parecesse um jogo. Foram alguns exemplos bem-sucedidos que encontrei no Reddit e podemos partilhar convosco a ligação para essa publicação.

Havia mais alguns exemplos e penso que muitas pessoas vão simplesmente experimentar esta tecnologia, mas também haverá pessoas que conseguirão obter muito sucesso com ela, o que é realmente interessante de observar.

Hannah Clark: Sim, é um exemplo muito interessante. Não queria interromper, mas temos uma pergunta muito boa da Katya.

A Katya pergunta: enquanto gestora de produto, ainda teria de criar wireframes e maquetes para o front-end? Poderia simplesmente criá-los com Vibe Coding e depois os programadores poderiam utilizar o meu front-end como ponto de partida para o seu próprio desenvolvimento?

Drew Falkman: Sim, a 100%. Na verdade, diria que, com a maioria destas ferramentas, seria mais difícil utilizar Vibe Coding para implementar um design existente.

É difícil importar ecrãs e fazer tudo isso. Na realidade, é mais fácil defini-lo e trabalhar com a IA generativa para obter o aspeto e a experiência corretos, e depois entregar o resultado aos programadores, que poderão garantir a conformidade com qualquer sistema de design ou outro recurso que estejam a utilizar.

Hannah Clark: Obrigada por responderes a essa pergunta, Drew. Desculpa, Katie, por interromper. Queres voltar aos casos de utilização? Sei que ainda tens alguns exemplos.

Katie Sanders: Michael, queres partilhar o caso de utilização de alguém da nossa empresa? Criaram este analisador do impacto de despedimentos. Michael, não sei se querias partilhar esse exemplo.

Michael Mordak: Claro. Este é um exemplo fantástico que um dos nossos colegas utilizou no seu site. Trabalha para uma publicação de recursos humanos e queria criar uma ferramenta que as pessoas pudessem utilizar para analisar o impacto de um despedimento que estivessem a planear. O que ele fez foi programar a ferramenta, ou melhor, fazer com que o bot a programasse, de forma a que os utilizadores tivessem de preencher um questionário antes de poderem utilizar a ferramenta.

Dessa forma, recolhe dados sobre as pessoas que a utilizam, algo que queria fazer para os seus próprios fins. Depois de preencherem o questionário, a aplicação encaminha-as para esta calculadora. Existem alguns exemplos incorporados. Se trabalharem numa empresa de produção e estiverem a planear despedir 200 funcionários, podem selecionar esse exemplo apenas para ver como funciona.

Essencialmente, introduzem todos estes detalhes e respondem a perguntas como: que nível de conhecimento têm estas pessoas? Quanto tempo seria necessário para formar novamente alguém para esta função? Depois, podem calcular o impacto desse despedimento e a ferramenta indicará exatamente o tipo de efeito que terá.

Seria uma excelente ferramenta para pessoas de recursos humanos que estejam a planear um despedimento. Ele disponibilizou-a gratuitamente para quem quiser experimentá-la e dar feedback. Esse é um exemplo de alguém da nossa equipa. O segundo exemplo que posso partilhar é a ferramenta de sondagens que estávamos a utilizar. Fui eu que a programei.

Não tenho experiência em programação, ou tenho muito pouca. Criei esta sondagem, ou esta aplicação de sondagens, para podermos recolher os votos do público em direto e apresentar os resultados, em vez de termos de pagar por uma ferramenta que fizesse isso. Muitas vezes, as aplicações têm essa funcionalidade, mas é preciso pagar por ela, acabando por pagar também por todas as outras funcionalidades que não se utilizam.

Eu só precisava da sondagem, por isso criei tudo para poder fazer as minhas próprias sondagens. Posso atribuir-lhes o nome que quiser, adicionar o número de opções que desejar, pré-visualizá-las antes de serem publicadas e depois lançá-las ou desativá-las a partir daqui, eliminá-las e assim por diante. É assim que são apresentadas no ecrã.

Vocês estão a votar na aplicação que criei. Não estou a recolher quaisquer dados vossos, não se preocupem. Os dados ficam apenas aqui. E foi assim que vimos os resultados. Foi algo que preparei rapidamente. Estava a trabalhar nisso 30 minutos antes desta chamada, mas, no total, provavelmente demorei uma a duas horas a montar tudo e a aplicar uma identidade visual que achei agradável.

Mas também não sou designer, por isso não sigam os meus conselhos.

Katie Sanders: Sim, temos falado das vantagens. É claro que há pessoas que estão a experimentar isto e a pensar que nunca mais vão precisar de ninguém com conhecimentos técnicos. Mas há um exemplo de um homem chamado Leo Junior.

A publicação dele tornou-se viral no X. É o fundador da Enrich Lead, uma ferramenta que recolhe endereços IP e utiliza um LLM para gerar potenciais clientes. Criou a aplicação inteira com o Cursor e afirmou orgulhosamente que não havia código escrito manualmente: a IA era o construtor. Podíamos queixar-nos ou começar a construir, com muita arrogância e pouca humildade.

Por isso, é claro que a Internet reagiu e, em 48 horas, os hackers assumiram o controlo, as subscrições foram contornadas e os custos dispararam. O LLM começou a inventar dados de potenciais clientes. O Leo teve de publicar um pedido de ajuda no Twitter, dizendo: Estou sob ataque. Estão a acontecer coisas aleatórias.

Não sou técnico, por isso estou a demorar mais do que o habitual a perceber o que se passa. E agora está a aprender a programar da forma mais difícil. Portanto, mais uma vez, a lição é que é sempre necessário ter uma pessoa envolvida no processo. É divertido experimentar enquanto pessoa não técnica, mas é sempre necessário que alguém com conhecimentos técnicos reveja o código.

Hannah Clark: Michael, querias fazer uma breve descrição de como foi a curva de aprendizagem quando começaste a experimentar estas ferramentas?

Michael Mordak: Claro. Como disse, tenho conhecimentos de programação muito limitados. Isto é algo que vejo por vezes, quando as pessoas dizem: sou uma pessoa de ideias. Nunca construí realmente nada antes. É exatamente esse o grupo a que pertenço, porque estou muitas vezes a pensar em diferentes formas de reduzir processos internos ou fazer coisas sem ter de pagar por aplicações de terceiros, mas construir realmente a solução é difícil.

Respondendo ao Grand, que perguntou como é a curva de aprendizagem na prática, a ferramenta que vamos utilizar hoje é o Lovable. O processo é semelhante nas outras aplicações disponíveis. Honestamente, a curva de aprendizagem é muito gradual. Foi muito baixa, porque, como podem ver, tudo se baseia em instruções de texto.

Basta descrever exatamente o que gostariam de ver, os objetivos da aplicação e os resultados que pretendem alcançar. Depois, a ferramenta apresenta alguns exemplos do que poderia construir. Também podem fornecer detalhes adicionais. Se tiverem algo em que se basear — por exemplo, neste caso, disse que queria algo semelhante ao slido.com, que é uma aplicação de sondagens — a ferramenta pode utilizar exemplos do mundo real como referência. Depois podem introduzir a vossa identidade visual e quaisquer outros requisitos que a aplicação tenha de cumprir.

Quando a primeira versão estiver criada, isso não significa que o trabalho terminou. Podem continuar a conversar com a ferramenta. Existe um modo de conversação no qual podem fazer perguntas antes de ela alterar o código ou construir alguma coisa.

Além disso, o que também funcionou comigo foi, quando as coisas ultrapassavam um pouco os meus conhecimentos, pegar em algumas explicações do Lovable, copiá-las para o ChatGPT e pedir: explique-me isto como se eu tivesse cinco anos.

Assim, a ferramenta simplificava o assunto para alguém como eu, que não compreende todas as questões técnicas, e explicava tudo de forma muito detalhada. Portanto, foi um processo muito simples e tornou bastante fácil tentar construir algo deste género.

Hannah Clark: Isso é muito interessante. Espero que seja encorajador para aqueles de nós, incluindo eu própria, que estão a começar praticamente do zero.

Queria apresentar uma pergunta da Tal. Vamos colocá-la ao Drew. A Tal pergunta: qual seria um bom fluxo de trabalho para empresas de produto já existentes? Sou gestora de produto numa startup. Temos um sistema de design e um produto funcional com utilizadores. Como posso utilizar o Vibe Coding para funcionalidades ou ideias específicas?

E quando é que o trabalho deve voltar ao design, ou pode saltar essa etapa e seguir diretamente para o desenvolvimento?

Drew Falkman: Penso que todo este fluxo de trabalho ainda está 100% em desenvolvimento. Ainda não existem boas práticas. Continua a ser um território desconhecido no que diz respeito a juntar todas estas peças. Mas, se estivesse numa empresa, a forma como faria isto seria saltar a etapa de design, embora coordenando o trabalho com o designer.

Eu faria o seguinte — e vou mostrar o meu PRD de Vibe Coding —: prepararia algo que descrevesse de forma geral os ecrãs e os elementos. No entanto, certifiquem-se de obter a aprovação dos designers. Eles também podem colaborar neste processo. Lembrem-se de que isto não é algo que tenhamos de fazer isoladamente. Podemos consultar o mesmo projeto e trabalhar nele em conjunto.

Depois, criaria a solução. Pelo menos com o Lovable, não conheço nenhuma forma mágica de integrar sistemas de design. Algumas das outras ferramentas, como o Cursor, são ferramentas de nível inferior mais adequadas para este caso, porque permitem ligar as conversas e tudo o resto, mas estamos realmente a trabalhar no código.

É como trabalhar num ambiente de desenvolvimento integrado e, muitas vezes, requer executar comandos na linha de comandos. Por isso, é um pouco mais técnico para pessoas totalmente não técnicas, mas permite uma maior integração e interação com o código. Assim, pode ser uma ferramenta melhor para este caso de utilização. Se estivesse a fazer isto, utilizaria a sincronização bidirecional com o GitHub, que tentarei mostrar se tivermos tempo hoje.

Podiam criar uma iteração de um ecrã e publicá-la no GitHub. Depois, os programadores poderiam transferi-la, aplicar todos os componentes e sistemas de design e voltar a publicá-la. Quando voltassem a entrar na aplicação, deveriam conseguir ver todas essas alterações e, idealmente, tudo funcionaria muito bem.

Hannah Clark: Excelente. Esta pergunta é do Donald para o Drew. Qual é a tua experiência com Vibe Coding para algo mais semelhante a outra solução, entre parênteses, através de outro gestor de tarefas, em comparação com algo mais original, como uma sonificação de dados do Google Trends? Por outras palavras, Vibe Coding para algo que seja uma versão de algo que já existe em muitas formas, em comparação com uma ideia completamente nova, que nunca tenha sido realmente concretizada?

Drew Falkman: É uma excelente pergunta. A minha experiência geral com ferramentas de prototipagem e ferramentas de Vibe Coding é que tudo o que já existe é relativamente simples. A ferramenta compreende essas soluções. O nosso exemplo-padrão de hoje é uma aplicação de viagens. Ela consegue criar aplicações de viagens o dia inteiro. Mas, quando entramos em algo como a sonificação de dados do Google Trends, será mais difícil.

Acrescentaria que, se entrarmos em algo que exija ferramentas de visualização muito personalizadas, para além dos elementos comuns de interface, como menus pendentes, botões e coisas desse género, vamos ter dificuldades com este tipo de ferramentas, pelo menos com o Lovable e no ponto em que estamos atualmente.

Pode haver outras ferramentas que tornem isto mais fácil, mas, neste momento, serão necessários especialistas e trabalho adicional se estiverem a fazer algo invulgar e realmente fora do padrão.

Hannah Clark: Muito bem. Chegámos ao fim do tempo. Quero agradecer imenso à Katie por ter participado e, naturalmente, ao Drew, por ser um recurso tão fantástico e por disponibilizar o seu tempo e conhecimento.

Obrigado por nos terem acompanhado. Para obter mais informações, guias práticos e análises de ferramentas, subscreva a nossa newsletter em theproductmanager.com/subscribe. Pode ouvir mais conversas como esta subscrevendo o The CPO Club onde quer que ouça os seus podcasts.