Como Criei uma POC de Sistema de Recomendação com Vibe Coding no Replit - Parte 1

Introdução

O principal objetivo deste artigo é o de sistematizar algum do meu conhecimento sobre Vibe Coding adquirido na pesquisa e estudo de matérias relacionadas e no desenvolvimento do projeto final de Pós-graduação em Data Science for Business Strategy.

Importante, ou curioso dizer que o projeto foi feito sem qualquer tipo de conhecimento sobre as Best Practices de Vibe Coding. Acima de tudo foi “utilizado” o senso comum e os mais de 12 anos de experiência académica e profissional em ambiente digital em agências, multinacionais e clientes.

Esta é a PARTE 1 onde se resume aquilo que é o Vibe Coding. Na PARTE 2 pretendo dar uma visão global daquilo que foi feito para o desenvolvimento do projeto e considerando que é uma POC e que tem/teria ou terá próximos passos no seu desenvolvimento.

O que é Vibe Coding

O meu entendimento de Vibe Coding é o seguinte: são as ações e as interações que um utilizador tem, através de prompts, com uma ferramenta de Inteligência Artificial Generativa, ou seja uma ferramenta que tem na sua base algum tipo de Modelo LLM (Large Language Model). E o objetivo é que essa ferramenta o auxilie na produção de “código fonte” para o desenvolvimento de um website, aplicativo, mobile app ou sistema.

Agora a definição ou de onde surgiu este “termo” de Vibe Coding.

“There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding – I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works”. Por Andrej Karapathy no Twitter em 2 de Fevereiro de 2025. Ou seja, não se pode dizer que seja algo novo.

O Benefício e a Consequência do Vibe Coding

Para mim só existe um benefício na utilização do Vibe Coding, e quando o mesmo é minimamente bem “desenvolvido”: o Aumento da Produtividade das equipas e o encurtamento do tempo do time-to-market. Ou em linguagem de Product Management, redução do tempo do “Product Market-Fit”.

Tudo o resto serão consequências desse benefício, como por exemplo:

- Possibilidade de irmos da “Ideia” ao “MVP” em muito menos tempo e, provavelmente sem qualquer ajuda de programadores ou de engenheiros de software.
- Possibilidade da redução dos custos, pelo menos na fase inicial de MVP e Product Market Fit.

Ou seja e se repararem, o Vibe Coding poderá possibilitar ganhos de produtividade na fase inicial. Porque no desenvolvimento concreto e final talvez os ganhos de produtividade não sejam assim tão significativos. De forma global, e é a minha opinião, não sei se será assim tão significativo os ganhos de produtividade. Porque Vibe Coding como vamos ver não é escrever um “prompt” na ferramenta com um modelo de LLM. E isto leva-me a…

Uma consequência menos positiva é que, e apesar de tudo, o Vibe Coding pode estar limitado pela “experiência dos developers”. Ou seja, ainda que não precisemos de conhecer, tecnicamente, (eu acredito que os ganhos de produtividade se dão se efetivamente se saiba alguns conceitos mais técnicos da engenharia de software e programação), temos de saber pensar e estruturar o nosso pensamento.

As Soft-Skills Necessárias ou Recomendas para Vibe Coding

Não existem requisitos mínimos para se começar a ter as “vibes” dentro de uma ferramenta de vice Coding. Qualquer pessoa por menos experiente que seja na área Digital ou de Tecnologia, pode desenvolver um aplicativo utilizando o “Vibe Coding”, como vimos acima. Mas, para quem trabalha na área Digital e da Tecnologia, ter-se o mínimo de Product Sense e de Atenção ao Detalhe e mais dois ou três aspetos fará toda a diferença e, efetivamente, aumentará a produtividade.

Mas em que é que isso se traduz? Traduz-se em conseguir:

- Ser Preciso – Se tivermos Product Sense e/ou Conhecimento do Negócio será mais fácil e produtivo visualizar um projeto, uma aplicação, sistema o que seja e quebrá-lo em várias fases que se revelarão várias atividades de interação com a ferramenta de LLM
- Ser Específico – Precisamos de saber fazer prompts
- Ser Organizado e Estruturado – Precisamos de organizar e estruturar o nosso projeto (mais à frente falarei sobre o Pensamento Crítico).
- Ser Paciente – Muitas vezes as coisas não vão acontecer bem logo com a primeira “vibe”. Mas se formos pacientes, tivermos minimamente uma visão daquilo que queremos desenvolver, soubermos fazer os prompts ou corrigi-los e soubermos fazer o debug ou “perguntar” como se faz esse debug e aceitar as correç\oes do debug, a “coisa dá-se ou dar-se-á”.As Hard Skills Necessárias ou Recomendadas para Vibe Coding

As Hard-Skills Necessárias ou Recomendas para Vibe Coding

Pensamento Lógico

O pensamento lógico é a base de tudo. Está relacionado com a capacidade de tirar conclusões válidas a partir de premissas. Em programação, é o que nos permite fazer perguntas como “se isto for verdadeiro, o que acontece?” ou “como garantir que determinada condição seja respeitada?”. Os If, then.

Na POC, usei pensamento lógico, por exemplo, ao decidir que o sistema só deveria recomendar conteúdos que não fossem o produto que estivesse a ser visualizado pelo utilizador. A lógica por trás desta decisão é simples: se um utilizador está a ver um produto A, seria estranho o sistema recomendar esse produto A (100% similar) e pouco valioso para o negócio.

Pensamento Analítico

Este tipo de pensamento é útil quando precisamos “quebrar” o tal projeto ou problema em partes/atividades menores para compreendê-lo melhor, e tornar mais fácil a nossa vida e a vida da IA.

No contexto da minha POC, utilizei pensamento analítico ao dividir o desafio geral de “criar um sistema de recomendação” em subproblemas: obter dados de entrada, definir uma estratégia de recomendação simples (por exemplo, baseada em similaridade), apresentar os resultados, etc..

Pensamento Computacional

O pensamento computacional é o que permite transformar ideias em soluções automatizadas. Vai além da lógica e da análise: trata-se de pensar como uma máquina, estruturando os dados e as ações de forma que o computador consiga executar.

Na prática, apliquei este tipo de pensamento ao desenhar um algoritmo simples que percorre a base de dados e encontra itens similares com base em características em comum. Também pensei computacionalmente ao decidir como representar os dados dos utilizadores e dos itens — listas, dicionários, arrays, etc.

Pensamento Procedimental

Por fim, o pensamento procedimental foca-se na criação de uma sequência de passos claros e reutilizáveis. É a base para construir funções, loops e fluxos organizados de execução.

Durante o desenvolvimento da POC, criei funções como generate_recommendations() ou filter_items() para encapsular lógicas reutilizáveis e tornar o código mais limpo e modular. Isso não só facilita a leitura e manutenção, como também me permitiu testar partes do sistema isoladamente.

Os Diferentes Níveis de Desenvolvimento no Vibe Coding

Existem 3 níveis de desenvolvimento no Vibe Coding:

Planeamento – Antes de começar a “enviar vibes”, é fundamental ter uma ideia estruturada do que queremos desenvolver. Este é o momento de esclarecer o problema, definir funcionalidades básicas e imaginar o fluxo do utilizador. Por exemplo, na POC do Sistema de Recomendação, comecei por perceber o que era um sistema de recomendação com base em conteúdo e a trabalhar os dados nesses sentido, mesmo antes de abrir o Replit. Aliás, só houve decisão de utilizar o Replit para tornar a apresentação final mais real e menos monótona.

Pensamento Lógico e Estruturado – Mesmo que a ferramenta de LLM nos ajude a gerar o código, somos nós que devemos guiar a lógica do projeto. Isto implica saber raciocinar em termos de condições, estruturas, inputs e outputs. Foi aqui que apliquei a lógica de “não recomendar o produto que o utilizador já está a ver”, por exemplo.

Comunicação com o LLM – Asim, estamos a falar das condições mínimas para se fazer prompts, a tal “Engenharia de Prompt”: saber como explicar ao modelo o que queremos, testar, adaptar e iterar. Percebi que quanto mais específico e organizado for o meu pedido, mais eficiente e preciso é o resultado. E mesmo assim houve coisas que falharam por falta de tempo, nomeadamente ao nível da User Interface Design. Mas como era uma POC, não me preocupei, mas sei o que está mal ou o que está menos bem, porquê e como melhorar.

O Conhecimento Mínimo das Frameworks

Existem inúmeras frameworks utilizadas para desenvolver ativos digitais. Por exemplo existe a Laravel para desenvolver em PHP, existe o React para desenvolver em JavaScript e por ai forma.

Mas mais importante do que perceber as ferramentas é entender como é que os websites, as apps, os aplicativos, os SaaS ou os sistemas funcionam? Existe uma base mínima para o seu funcionamento. Por exemplo, os websites têm um front-end, um Back-end e dependendo do website podem ter uma ou várias bases de dados. Entender estes conceitos vai-nos ajudar na altura de começar a produzir as “vibes” junto do LLM presente na ferramenta que escolhemos. Se entendermos isto, sabemos o que a ferramenta vai conseguir ou deve desenvolver e aquilo que não consegue ou não pode porque não faz sentido. No caso da POC a framework seria o modelo ou os modelos estatísticos e de NPL a serem utilizados.
Não vamos pedir a um construtor automóvel para na sua plataforma de automóveis ligeiros, construir um motociclo e colocar-lhe portas.

Afinal o que são os Checkpoints

Por várias razões, por exemplo como veremos mais à frente o código pode não funcionar da forma como pretendemos. E para isso é preciso criar checkpoints. Checkpoints nada mais são do que versões do código que fazemos ou devemos fazer

Na engenharia de software ou na programação, os checkpoints são o versionamento do código feito no GitHub ou no BitBucket (ferramentas de código mais comuns para versionamento de código) vi “pushes”, “pulls” e “forks”.

A Importância do Debugging e do QA

OK, estamos a ter as nossas “vibes” com a ferramenta que por trás corre um Modelo de LLM. Mas como sabemos se aquilo que está a ser desenvolvido está a funcionar. Sabemo-lo através do debugging/QA. E o que é importante perceber ou analisar: como é que o código está a funcionar? Temos todas as dependências instaladas e a funcionar? Onde é que o erro está a acontecer? Porque o erro está a acontecer? Podemos responder a esta pergunta recorrendo à AI.

Além disso, é importante que tal como se deve quebrar o projeto em atividades, devemos fazer o debugging e/ou o QA por atividade. É quase como se estivéssemos a fazer testes unitários. Qualquer pessoa por menos experiente que seja na área Digital ou de Tecnologia, pode desenvolver um aplicativo utilizando o “Vibe Coding”, como vimos acima. Mas, para quem trabalha na área Digital e da Tecnologia, ter-se o mínimo de Product Sense e de Atenção ao Detalhe e mais dois ou três aspetos fará toda a diferença e, efetivamente, aumentará a produtividade.

Entender o Contexto e Como Evitar Alucinações

Fundamental!!! 100% Relacionado com o Product Sense e/ou Business Sense. Além disso, consoante as nossas “vibes” vão tornando a nossa interação com o modelo LLM mais longa, mais difícil fica para o Modelo entender o que se pretende (Memória do modelo) e mais a probabilidade do Modelo começar a ter alucinações. Isto porque existe um limite máximo de informações que o modelo consegue processar por unidade de tempo. É como se nós explicássemos algo a alguém no primeiro dia de trabalho e passados 1 ou 2 anos se a pessoa não pegar nisso porque não tem o contexto para tal, certamente que se vai esquecer.

Conclusão

O Vibe Coding não é apenas prompts e até talvez não seja um “hype”. É uma nova forma de pensar o desenvolvimento produtos digitais — mais acessível, mais rápida e, quando bem aplicada, extremamente poderosa. E quer queiramos ou não, os engenheiros de software, programadores e quem se interessa pela parte técnica, sai na frente, na minha opinião.

Até porque o Vibe Coding não resolve tudo. A produtividade que se alcança depende diretamente da nossa capacidade de estruturar ideias, comunicar com clareza, raciocinar logicamente e utilizar o “Systems Thinking”, tão importante na Experiência do Clientes e na Transformação Digital das Empresas. Se tivermos estas bases — e mesmo que não sejamos programadores profissionais — podemos construir soluções surpreendentes.

Esta foi apenas a primeira parte do meu processo. E já ficaram com alguns exemplos de como fiz isso na prática. Mas na PARTE 2, vou tentar partilhar como utilizei estes princípios na prática no desenvolvimento da POC Sistema de Recomendação onde utilizei o Replit e o seu modelo LLM.

Alguns dos conceitos foram aprendidos através da Deeplearning.ai