Vibe Coding Experience: VibeX Development Log #2
Pokute
Category
Empty
New features added
Since our last update, we've added several key features to Vibex, focusing on enriching the user experience and enabling the sharing of information necessary for early product development.
+ Media and URL previews
You can now attach images and videos to threads, and pasting a URL automatically generates a preview. Adding a preview was a breeze, requiring only a couple of prompts. The only issue I had was calculating the output aspect ratio and size of images and videos. I simply followed the rules from x.com, using the existing framework as a guide.
+ Dark/light theme settings
We've added a theme setting feature that allows you to switch between dark and light modes to suit your preferences. This feature, for the first time, delivers satisfactory results with just one prompt. While there were some minor color adjustments, I was impressed by how cleanly the settings page was made.
Theme settings screen
+ AB voting function
We've added AB voting to threads to encourage user participation and provide a foundation for diverse opinions.
AB Voting is a feature developed with AB testing in mind. While actual AB testing involves presenting two UIUX variations and drawing statistical conclusions, VibeX implemented it as a voting feature for quick and easy selection.
I wanted to add a voting form to an existing thread, and implementing it myself would have been a struggle with the AI. So, I used V0 to derive the basic front-end code. It turned out to be a very good choice, as V0 already had the UI and features I wanted implemented through extensive training data. I simply copied the code and connected it to Cursor, and within 30 minutes, most of the functionality was implemented.
Version 1 results of V0
The problem was the rough type conversion coding written by Cursor, along with Supabase's policies and functions. Because the thread table needed to reference the AB vote table, functions and policies within the database were required. As I'll mention below, due to the intense Supabase configuration, I spent about five days trying to fix persistent errors.
Thread containing the final implemented AB vote
+ Multilingual support
We support three languages, including Korean, English, and Japanese, to make Vibex more convenient for global users.
The multilingual feature wasn't really something I needed to add at this point, but I assumed Cursor would be able to easily set it up. However, out of the two methods Cursor recommended (i18next and next-intl), I chose next-intl and ended up mixing the two. This was confirmed while editing the multilingual version: Cursor set the i18next method as the main method, and when I requested a modification, it considered next-intl and made the modification, causing problems. Ultimately, I settled on i18next, but it was the first time I'd seen such a tangled code, and it was a strange(?) experience. Everyone, be careful.
Timeline Optimization (and Failure)
One area where we spent the most time and effort was optimizing the timeline output. Our goal was to provide a smooth user experience, allowing users to view threads without interruption. The specific optimization goals were as follows:
•
Infinite Scroll : Prints timeline items 10 at a time until the last item.
•
Real-time sharing of like status across pages : Using cache, like status is synchronized in real-time even when viewing the same thread on multiple pages.
•
Background synchronization with DB tables : Synchronize in the background so that actions such as a user's like are immediately reflected in the DB.
•
Reuse items once they are printed : Each time you access a page with a list, loading occurs, so items that have already been printed are reused.
•
Asynchronous update of user screen : When a user clicks Like, it is reflected immediately on the screen, and through asynchronous update, it is reflected with a time difference between users, and DB update is performed in the background.
•
Maintain scroll position when returning to thread detail page : When you go to the thread detail page and then return to the timeline, the previously viewed scroll position is cached so that the position is maintained when you return.
To achieve these optimization goals, I tried to apply asynchronous (e.g., changing the like status on the screen) and synchronous (e.g., updating the database) methods appropriately. However, this process began to introduce unexpected errors, and I ended up in a vicious cycle where fixing one error triggered another.
In conclusion, after three timeline code rewrites and a week of struggle, I've finally lost. I've tried various fixes, including root cause analysis, console messages, and source code location. Even though things seemed to work fine, errors kept popping up, so I've limited the implementation to the most basic functions.
•
Loading every time you access the page
•
Infinite scroll
•
Real-time synchronization with DB
•
Share like status without cache
To summarize, I'm considering trying again with cleaner logic and exception handling. I'll do that later.
A fight with Cursor over Supabase settings
+ Cursor's Counterattack
While troubleshooting the issue, I ended up asking Cursor to modify Supabase policies, triggers, and functions, which led to me having to manually modify the database. This resulted in indiscriminate database initialization and migration.
At first, I was modifying the Cursor directly via the supabase CLI, but at some point, the database policies and items started getting reset. Since I have absolutely no knowledge of databases, I thought I must have made a mistake, but when the reset occurred more than three times, I started getting really angry. I tracked down the culprit, and it turned out that the CLI was constantly sending reset commands whenever the Cursor detected something strange. In the end, I was the one who allowed it to happen...
Afterwards, I requested, "Please write SQL instead of modifying it directly via CLI," so I proceeded by reviewing and executing it directly in the SQL Editor. I also added a "Do not modify the DB unless requested" line to the Cursor Rules. Despite this, I continued to abuse the CLI by occasionally initializing and migrating the DB. (There were even cases where migrations were performed even when I explicitly told the user not to do so in the prompt. I think they interpreted the task as a higher-level command.)
This was a very important lesson learned during the Vibecoding process.
+ Separate configuration of Development DB
Ultimately, to address these issues, we decided to configure a separate development database. We created a separate project in Supabase to separate the development database from the production database. This allowed us to establish the following rules:
•
No more arbitrary modifications to the production DB.
•
In the development version, set it to use only the development DB.
This separation greatly helped prevent potentially fatal errors that could occur during subsequent development. And, curiously, the development database hasn't attempted initialization or migration since. This appears to have been intentional.
What I learned from using Cursor (Vibe coding) for two weeks
After two weeks of developing with Cursor, I learned some important lessons.
+ Notes when requesting error correction
When requesting a correction, please provide the following information as specifically as possible:
•
Status and Evidence of the Issue: Documentation that clearly demonstrates the problem, such as console messages or error screen captures, is essential.
•
Modification target and scope: It's better to be clear about which files and which blocks of code need to be modified.
•
Rough root cause analysis: Presenting anticipated logical problems or vulnerabilities in the code can be a great help in troubleshooting.
•
Request a correction and suggest a method: Suggesting how the correction should be made, and if possible, how to fix it, will allow for a faster and more accurate resolution.
+ If the problem cannot be resolved within 2-3 times, a step-by-step review is required.
If a problem remains unresolved after two or three rounds of discussion, it's more effective to stop making fragmented requests and instead request a step-by-step approach to resolving the issue or an in-depth review of specific areas. Repeated requests are likely to lead to tangled logic.
+ Regular chat reset required
As conversations with LLM models drag on, the context can become complex, or responses can become unnecessarily distracting due to previous conversations. It's a good idea to periodically reset the chat and start fresh.
+ If the LLM model seems to have changed in the middle, it would be a good idea to explain it again.
Sometimes, due to updates or internal changes to the LLM model, it may seem like you don't remember what you've previously explained. In these cases, even if it's inconvenient, reiterating key points can help ensure smooth communication.
Midterm inspection
Developing Vibex was a series of trials and tribulations, but it was also a time where I could learn and grow a lot.
I tried to buy a domain, but vibex is a name that is used more than I thought, so it is expensive, so I kept it as vercel. (I even set it to vibexx because vibex is used on vercel.)
We will be conducting activation and service stabilization during the open test. Therefore, we will be promoting this during the intermission.
Do
Subscribe to 'Dogma13'
If you subscribe to the site, you can be the first to receive the latest updates, including new posts, via notifications and email.
Join Slashpage and subscribe to 'Dogma13'!
Join Slashpage and subscribe to 'Dogma13'!
