Today, I created a backoffice tool that will let me manage several aspects of the game, specifically:
- Which cards are "active" (can be used within SPL Tactics)
- Which cards are "starters" (can be used by players regardless of whether they own the card - this will enable a fully free-to-play option for the game)
- I am now syncing all card names, types, rarity, stats, and abilities from the Splinterlands API
- I have implemented and tested 14 abilities so far (second screenshot below) (given that the gameplay is quite different to the original Splinterlands game, each ability must be mapped to a new mechanic that makes sense for the tactical turn-based style of SPL Tactics)
Over the course of the week, I plan to implement:
- Hive login, along with the ability to read which cards the player has access to
- Activating additional usable cards (as mentioned before, I will whitelist available cards rather than making all cards available)
- Map all remaining Splinterlands abilities to SPL Tactics abilities
- Adding a login/intro screen
- Adding a player settings screen
- Many UX and UI updates
I saw some other folks including our very own 
With that in mind, here are a few tips and tricks if you're planning on making substantial applications:
(1) Only start vibecoding when you have a good idea in mind. You can use AI to go back & forth on an idea, but only start after it's already somewhat refined. Get AI (Claude in my case - highly recommended) to help you write the initial spec, in detail, so that it's very clear to Claude Code what you want to do.
(2) Always, ALWAYS use a CLAUDE.md file to store key logic/architecture/design decisions. This file, stored at the root of your repo, is ESSENTIAL to maintaining context as your app grows. Over time, practice on keeping good documentation infrastructure. For SPL tactics I currently have CLAUDE.md with all my core architecture, and I have several other files to maintain ability details, mapping info (aka how to read Splinterlands data), terrain information, AI details (how the AI plays the game), and visual details. This ensures my CLAUDE.md doesn't become to cluttered (important because LLMs don't have infinitely large context windows).
(3) Phase out difficult tasks into multiple parts. Claude is terrific at breaking up a big GOAL into multiple phases, so that you can go about it bit by bit and are more likely to build to spec, and you won't be spending huge amounts of time debugging. Also, after each phase, you can ask Claude to give you test cases to give to Claude Code as well as manual test cases for you to try to ensure the phase was completed as per your expectations.
Vibecoding isn't about having AI just do everything for you. It's about fundamentally EXTENDING your capabilities as well as drastically reducing the time it takes to do simple tasks.