Sabitlenmiş Tweet
I vibe-coded an agent & token launchpad on BNB Chain @octopurrbot, by myself.
AI is moving insanely fast. Honestly, I still can’t believe I was able to finish this project in under a month.
I come from a pure research analyst background, with very limited coding experience. But the recent explosion of @openclaw pushed me to finally try building something.
I chose to build a Token & Agentbound Token Launchpad on @BNBCHAIN.
It started with some very naive conversations with AI:
“Can I vibe-code a token launchpad?”
“What do I need to build one on BNB Chain?”
Then came days of researching existing launchpad platforms. Openclaw even generated a massive report for me, hundreds of pages long. To be honest, I haven’t even finished reading it.
I wanted to move fast into the implementation phase, but that turned out to be the hardest and most time-consuming part. Since I had some prior experience working with AI, I made sure to create a detailed implementation plan from the beginning and kept updating it after each session. Still, the project was large, and sessions often got interrupted. AI forgetting what had already been done became a frequent issue.
The real challenge wasn’t just managing AI to follow the plan. The nightmare was handling changes during development. It’s not as simple as saying, “hey, update this feature like this.” Every feature is connected to others. Even though I repeatedly asked AI to carefully trace the codebase and sync everything, it often showed overconfidence and bias. Bugs only truly surfaced during teéting, and fixing them took a lot of extra time.
Building a full web3 app end-to-end through vibe coding made me realize something important: developers deal with far more complexity than most users think. Coding is just one part. Throughout development, there are constant trade-offs that the product owner has to decide on.
For example, when building the “launch token via social” feature, I had to choose between custodial wallet or non-custodial wallet. A custodial wallet would enable many additional features like buy, sell, and transfer on behalf of users. But it also means taking on the risk of managing user funds? which is extremely risky for a vibe-coded project at this stage. So I chose the non-custodial approach, letting users control their own wallets.
Another example is gas fee sponsorship for token deployment. Since deploying a token on #BNBChain costs around $0.3, I had to restrict this feature to verified accounts on X. This helps reduce costs and ensures that deployed tokens actually carry some meaning.
A bigger trade-off came with permissionless fee claiming. #Octopurr separates users into two groups: wallet addresses and identities (like social accounts or ERC-8004 agents). Wallet addresses are naturally permissionless and immutable. But for identities, it’s more complicated. If a user’s social account gets hacked or something goes wrong, a fully permissionless system would leave no way to intervene. The same applies to the ERC-8004 agent registry. So I had to introduce emergency controls, the ability to freeze this functionality when needed. Of course, I also designed a “renounce ownership” mechanism to eventually make it fully permissionless once everything is stable.
You think that’s all the difficulty for a vibe coder? Not even close.
After finishing the product, you realize that finding users is even harder than building. With a small voice, no one notices. No one uses your product. My advice: find your market first, then build fast.
This is my real experience as a research analyst doing vibe coding.
AI is evolving at an incredible pace, turning what once felt impossible into reality.
Don’t get left behind.
English
