MVP

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

Sistematização da Experiência Vibe Coding utilizando o Replit

Introdução

Na Parte 1 escrevi sobre o que é o Vibe Coding, sobre os diferentes níveis de pensamento que o mesmo exige e como isso me ajudou no desenvolvimento do projeto final da Pós-graduação em Data Science for Business Strategy. Ainda dei alguns exemplos de como apliquei esses diferentes níveis de pensamento
Na PARTE 2 pretendo dar uma visão global daquilo que foi feito para o desenvolvimento do projeto e mostrar partes da aplicação prática para o desenvolvimento da POC.

 

CRISP-DM

A metodologia utilizada na elaboração do projeto foi a CRISP-DM - Cross Industry Standard Process - Data Mining.

• Entendimento do problema e do negócio – Na escolha do projeto defini o Problem statement para justificar a escolha deste tipo de projeto e os benefícios que poderia trazer para o negócio. E com isso, escolher um dataset que fosse possível ser trabalhado (se bem que à partida um data scientist não sabe o que vai encontrar).
• Entendimento dos dados – O dataset escolhido foi uma amostra representativa do Dataset da Amazon Reviews 2023 – Baby Products. Iniciou-se o trabalho inicial com 50 000 registos e depois 10 000.
• Preparação dos dados – Limpeza, remoção de duplicados, tratamento de descrições vazias e criação de stopwords específicas tendo em conta o objetivo do projeto e as necessidades do negócio
• Modelagem dos dados e Escolha do Modelo – Escolheu-se, com base nos estudos e em literatura a “Vetorização com TF-IDF (min_df=3, max_df=0.7, ~4 000 features) e cálculo de proximidade semântica através da Similaridade do Cosseno”
• Avaliação do Modelo – Algumas métricas que nos revelou o modelo foram uma diversidade de 0.542 e uma similaridade robusta na ordem dos 0.453.
• Deploy – Esta fase, por motivos óbvios, estava fora de âmbito. Mas como já sabem, houve a criação de um protótipo funcional Lo-Fi em Replit.

 

Cada uma das fases acima descritas correspondeu, grosso modo, a uma entrega/avaliação intermediária. Portanto, o que defini acima em cada uma das fases da CRISP-DM não revela metade do trabalho que foi produzido. Aliás, para terem uma ideia, que vale o que vale, o projeto final resultou numa entrega final de um PowerPoint com 108 slides, incluindo anexos.

Toda a parte referente aos diversos steps da metodologia foi desenvolvida e testada fora do Replit. Mas faltava, para proporcionar um momento mais UAU, uma interface funcional para explorar e mostrar resultados de forma simples.

 

O Ciclo Vibe Coding na prática com o Replit - App Builder

Ao longo do projeto, repeti o ciclo Prompt → Teste → Erro → Debug → Checkpoint dalgumas vezes. Neste artigo irei apenas frisar alguns dos desafios que me lembro que surgiram ao longo desse ciclo. Imagem retirada do website do Replit.

 

 

Exemplo de Prompt Inicla no Replit

Na realidade não me recordo exatamente de qual foi a prompt com que iniciei o projeto no Replit. Até porque não cheguei a optar pela versão paga. Mas, diria que foi um texto de prompt simples, claro, e do tipo Zero-shot prompt, uma vez que anexei os ficheiros .pkl gerados em Python no desenvolvimento do sistema de recomendação. A prompt inicial terá sido algo como:

"Cria uma interface de um sistema de recomendação com base em conteúdo, que permita ao utilizador escolher um produto (product_id + product_name), e vê devolvidos o TOP 5 produtos (product_id + product_name) mais similares, excluindo o próprio produto escolhido. Para o melhor output possível, analisa os ficheiros anexados referentes à função do sistema de recomendação (func_sist_rec.pkl) e ao dataset já limpo e trabalhado (dataset_clean_final.csv) que serve de base ao sistema."

 

Alguns Testes

Após a inserção da prompt, corria a aplicação no Replit. O Agente, e depois o Assistente do Replit faziam o seu trabalho e quando terminava lia e analisava (aquilo que conseguia perceber do código) o código gerado e visualizava o output. Ou seja, escolhia um product_id com o respetivo product_name associado no interface e via o resultado.

 

Os Erros

Obviamente que mesmo com a melhor prompt o sistema vai produzir erros. E temos de saber lidar com eles, corrigindo-os como mencionado na PARTE 1 do artigo. Alguns dos erros que me lembro do sistema ter produzido foram:

O produto escolhido pelo utilizador aparecia na lista de recomendações. O que até me deixada admirado ou frustrado, uma vez que há parâmetros no código que anexei onde se percebe claramente que o produto escolhido não pode ser recomendado. Ou seja, a lógica do threshold de similaridade por exemplo, foi ignorada. A tal importância dos diversos níveis de pensamento para se perceber o que o modelo está a implementar.

O HTML + CSS, ou seja a interface não saiu bem logo à primeira. Alguns dos problemas que me recordo foram:

• • Muitos elementos presentes que não eram necessários
  • Má conjugação de cores de texto e fundos das células da tabela
  • O utilizador tinha que fazer roll-up/down e row-left/right na tabela para poder ver toda a informação

 

Debugging a little

Em termos de debug, o que ia fazendo era tentando melhorar o interface, analisando algumas coisas que percebia em termos do código, nomeadamente HTML + CSS e afinando as prompts. Por exemplo:

“Adiciona um filtro para excluir o produto atual do resultado. Ajusta as imagens para 150x150 px e centraliza o texto.”

"Filtra os resultados para remover o produto atual e só mostra produtos com score > 0.45. Ajusta o HTML+CSS tendo por base a seguinte paleta de cores: Color matching de 6 cores com #845EC2."

 

Os Checkpoints…só do Replit

Na realidade o Replit ao ser um App Builder ajuda-nos com o versionamento do código, na medida em que o agente que tem integrado cria frequentemente os checkpoints (pushes) na plataforma. E assim, podemos voltar ao código anterior, caso o output de atual ou da próxima prompt corra mal.

Como disse anteriormente, por ser uma POC e por ser um adicional ao projeto, não senti a necessidade de quando algo estava mesmo funcional, copiar o checkpoint do Replit para um ficheiro para salvaguardar o progresso. Até porque há muita coisa que pode ser melhorada, como verão mais adiante e recordando que estamos a falar da utilização de uma versão free.

Aquilo que aconteceu foi o ter de ir fazendo mais prompts de forma a que o assistente corrigisse alguns temas, como por exemplo:

Evitar a repetição de recomendações duplicadas e Diversificar as categorias – Filtragem explícita no código e garantir a variedade mínima nas recomendações. Isto através de prompts mais claros, com regras do negócio e com explícita indicação para análise da parte X do ficheiro respetivo onde essas regras estava implementadas.

 

 

O que poderiam ser os Próximos passos

Se considerarmos apenas este dataset, os próximos passos imediatos seriam:

Adaptar o interface para todo o dataset e não apenas para uma amostra de produtos

Criar uma Interface que cumpra melhor as best practices de usabilidade, de design, de responsavidade e de acessibilidade e pensar em como poderia ser mais atrativa e interativa. Por exemplo, integrando imagens ou clips dos produtos recomendados.

 

Conclusão

Como disse no PARTE 1 deste artigo, foi a primeira vez que “utilizei” o Vibe Coding. Embora conhecesse bem o termo, não tinha tido até então oportunidade de dar-lhe prática. E portanto teria tudo para correr mal, ou menos bem e levar a stresses e ansiedade desnecessária do que aquela que um projeto académico já acarreta.
Mas o facto de ter escolhido uma metodologia para elaborar o projeto académico revelou-se fundamental no processo de Vibe Coding. Isto porque obrigou-me a pensar no problema, no projeto mesmo antes de abrir qualquer ferramenta de Vibe Coding. Outra conclusão que retirei, em particular deste projeto é que uma prompt é importante, mas o contexto, que neste caso foi todo o trabalhado de desenvolver o modelo e o algoritmo, é fundamental.

Ou seja, dependendo do nosso objetivo, podemos ter diversos níveis de promtp e de “utilização” do Vibe Coding. E o nível que utilizei não sendo o avançado, também não foi nem de longe nem de perto o básico.

Portanto, Vibe Coding requer pensamento, metodologia e trabalho. Trabalho esse que é iterativo “Prompt → Teste → Erros → Debug → Checkpoint”, nomeadamente nas fases de Teste e de Checkpoint

 

 

 

Agradeço à Maria Antónia Marques que fez parte do grupo de trabalho

---

by João Carlos Matos

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

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 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

---

by João Carlos Matos