I’d like to introduce CKBadger, a local-first CKB-native explorer. It’s a small homebrew project that I’ve been working on for months.
CKBadger is highly opinionated and not meant to be for everyone. It’s built around a few questions that I wanted to explore.
Why I built it
CKBadger started from several personal interests.
- I wanted to know how far “100% vibe coding” can go today. By that I mean: only talking to AI agents, not hand-writing code myself, and not doing code review. What kind of project can this approach actually produce?
- I wanted to understand what role a human should, and can, play in such a project. If AI agents can write most of the code, what is still left for the human? What should the human own?
- I have some ideas about how CKB on-chain data could be presented differently. CKB has a very distinctive UTXO/Cell model, and I think many existing blockchain explorer patterns are still too account-oriented. A CKB-native explorer should not merely copy the UX assumptions of Ethereum-like explorers.
- I also wanted to see whether a very ordinary application becomes meaningfully different when built with a local-first and Web5-like mindset.
Why a blockchain explorer?
I chose the explorer scenario because it fits all of the above goals.
An explorer is useful enough to be real, but also safe enough to be a good playground. CKBadger only needs to read data from a CKB node. It does not need to manage private keys, sign transactions, or run on-chain scripts. That means I could focus on product structure, data presentation, performance, local-first architecture, and the human-AI development workflow, instead of worrying about high-risk security requirements.
What I learned
Now I’m pretty sure that 100% vibe coding can already produce a medium-sized project with good usability, maintainability, optimization, and production-level usefulness.
That does not mean the human becomes irrelevant. Quite the opposite.
The human may not need to code, but the human still needs to make design decisions. The human needs to choose trade-offs. The human needs to decide what matters, what can be ignored, what should be simplified, and who the project is for.
The human may not need to code, but the human still needs to know how to write documentation, how to design tests, and how to manage a codebase where they cannot personally review every line. A developer working with agents becomes a product+project manager.
AI can help with execution. It can generate the flesh and bones. But only the human can give a project its soul.
A note about the demo
I deployed a public demo so people can try CKBadger before deciding whether it is worth running locally. This is not very “local-first” but a preview should help the project’s cold start and overall understanding - a reasonable compromise 
It also shows a well-designed local-first app may run as a web2 app, while a centralized web service usually cannot easily become a local-first app.
Please do not treat the demo as a long-term official service. It is only a preview and demonstration. It will be taken down after a month or so. 0% service gurantee.
The best way to use CKBadger is to run it yourself, locally.
Enjoy and have fun!
