Lately, if you're following AI, it's almost impossible to avoid the word "lobster".

Everyone is marveling that the "AI operating system" has finally arrived, while showing off their workflows, their Agents, and what amazing things they've made AI do again. Last month I actually went hard at it too — trying all kinds of tools, switching between all kinds of models. In just a short period, I burned through several hundred dollars worth of tokens alone.

At first I was very excited, feeling that a new era had truly arrived, but as I kept playing, I gradually calmed down instead.

It's not that these things aren't good — quite the opposite. Precisely because they are so good, they made me break out in a cold sweat.

Imagine: in the future, in a chat group of 500 people, the ones actually speaking every day might be 499 individual AI BOTs; on a short-video platform, you scroll through hundreds of videos and every single one is mass-produced garbage content made by AI; on public accounts, forums, and websites, page after page is densely packed with text and images automatically assembled by AI.

In other words, we will very likely be living in an environment flooded with AI-generated garbage information in the future.

And the further this environment develops, the more I feel there will definitely be a "counter-AI" trend — people will start emphasizing again "this was written by a human", "this was drawn by a human", "this was photographed by a human", just like today people emphasize organic vegetables and family farms.

A Bottom-Line Judgment About AI

Over the past two years I've written many articles about AI. Leaving aside large-scale application of physical AI robots, just looking at the IT and internet application level, I'm increasingly convinced that AI applications should at least have one minimum Bottom line.

I believe that for things ordinary people can directly read and feel — such as articles, images, videos, music, and human-to-human expression — these areas should as much as possible be left to real people. It's not that AI should never touch them at all, but that we shouldn't take it for granted to hand these things over to AI for mass production.

Because these contents are originally part of the real world; their value is not just "data information", but also includes the emotions of the person expressing them. When you read an article today, you're not just looking at the conclusions themselves — you're putting yourself in the writer's shoes, thinking: what exactly am I reading here, how does it help me, what would I do if I encountered this situation? In the end, everything leads back to the real world.

But for another category of things, I don't have such a strong conservative attitude.

For example, binary code, various machine languages, programming languages, or all the countless intermediate-layer languages that programmers around the world have created since the information revolution to make machines run. Strictly speaking, these things were never meant for ordinary people to read in the first place — they are for machines. Since that's the case, if AI can directly play a role in these areas, it might actually be a good thing.

The Two Recent VideCoding Projects

It was precisely with this mindset that, during this period, I used OpenCode to complete two open-source projects in a row: the first one is Pocket-Hugo, and the second is Pocket-Hugo-Theme. Both revolve around Hugo, the fastest static site generator in the world. The former is used for editing and publishing, and the latter is a site template. .

The main reason I didn't use "lobster" for VibeCoding is that I'm "poor"; the secondary reason is that the development needs of a real project are truly countless — many things need repeated modification and repeated testing to discover problems. Relying solely on lobster would be slower than just opening an IDE to debug.

Strictly speaking, these two projects are actually one integrated whole, because when I was developing Pocket-Hugo, I added a unique page-editing feature to it, and this feature must be implemented by adjusting the Hugo theme. Since that was the case, I simply made my own theme instead of doing secondary development on someone else's theme.

Because of this, while making PocketHugo, I had already planned ahead how the theme should be done later. Many things could be reused — buttons, information hierarchy, card rhythm, color scheme, etc. — all directly carried over to the second project, greatly reducing the development difficulty. During the process, while writing PocketHugo on one side and making some convenient UI or interaction, the pocket-hugo-theme on the other side could immediately reuse it; when thinking of a better card layout, multi-language switching, or mobile display method in the theme, the tool on this side could in turn absorb it. The whole process was actually researching, learning, and VibeCoding at the same time.

And in this process, I myself became the biggest beneficiary. Many things that I previously only vaguely knew "could be written this way" were truly forced into deep understanding through repeated back-and-forth tinkering. Whether it's Next.js, the Go language, front-end CSS, or Hugo's various template mechanisms, I now have a much more concrete and solid grasp than before.

And precisely because of these three prerequisites, later when doing pocket-hugo-theme, for me it was no longer simply "making another theme".

Why Make Another Theme

If I just wanted to find a theme to use, there are already plenty of choices on the official Hugo themes site. The ones I used long-term before — like Hugo-theme-stack, and later bear-cub, etc. — are all very good themes.

But what I really want is not just "usable", but "just right".

Anyone who has seen my heavily modified version of Hugo-theme-stack and bear-cub knows that I've always been fond of the "text + image bundled" mode — the default display style of WeChat public accounts. Unfortunately, because most Hugo users are geeks and most site content is related to coding, whether there are accompanying images or not basically doesn't matter to them. There are even many Small Web projects online where people compete to see how extremely small they can compress their sites — 100KB is already not impressive; the smallest ones are only a few KB.

Another important issue is that I've always wanted a stable solution for publishing articles on mobile phones. I already talked about this in the previous article about launching Pocket Hugo, so I won't repeat it here. Although I also like IDE tools very much, I can't deny that using an IDE on a phone is really painful — especially the "anti-human" interaction between the default iPhone keyboard and web input boxes. Anyone who has ever copied or edited code in the GitHub app on iPhone knows how miserable it is.

So ultimately, what I wanted to make this time is a graphic-heavy theme with more prominent cover images, stronger card feeling, and at the same time suitable for long-term personal writing.

How I Developed This Theme

Developing a Hugo theme sounds quite easy. At least in the years I've been hanging out in the Hugo forum, I've seen a bunch of Northern European and North American "old men" in their fifties and sixties casually knock out a page template with just a few lines of code every time.

But when I actually started, I found it's not that simple. Because first I needed it to run properly on my own site.

So I basically took all the various components I had used in Hugo-theme-stack and bear-cub before and moved them over one by one to test. I don't even know how many times hugo server failed to build during the process; only bit by bit did I manage to get the template set up.

But it was exactly this process that caused me a lot of trouble later in development, because the earlier phase was essentially built on the premise that it only needed to serve me alone. Various elements were hard-coded, and even some page structures and image habits were completely centered around my own writing style. For personal use this approach has no big problems — just do whatever is convenient — but the moment I wanted to open-source it, the problems immediately appeared.

For example, various elements in the site header were previously hard-coded in my site; various components, image effects, and features were also just "I know how it works". But to open-source it, I had to change them one by one into configurable options so others could understand and use them too. The most troublesome part here was actually not writing the templates, but repeatedly judging what should be kept as the theme's character and what must be opened up for users to configure themselves.

At the same time, to submit it to the Hugo themes site, I also had to do multi-language support, comments, bundling, cover images, demo site, etc. as much as possible. Later I added a bunch of example articles and pages. Only after reaching this point did I more clearly feel that making your own website and making an open-source theme are completely different things. In the former, content is the goal and the theme is just the carrier; in the latter, content becomes the documentation.

Moreover, during this process, Pocket Hugo was actually constantly forcing this theme to grow in return. Because originally when developing Pocket Hugo I built it completely according to personal needs — if someone happened to have the same needs they could use my solution. But later, in order to release it as open source, I had to refactor it from scratch. During the process, someone even opened an issue requesting a local-only version that doesn't require GitHub authentication, which cost me several more hours.

In the end, I basically turned every customizable part of this theme into specific configuration items. And this process, for me personally, was almost a complete reshaping of my understanding of Hugo — constantly questioning myself: why set it this way, why not that way, what kind of setting is actually better and more in line with real usage needs.

Of course, I certainly don't dare claim this theme is already very mature. A theme is something that naturally gets improved while being used and grows while being written. But at least today, I can say with certainty that I didn't do this to add another piece of AI-era template garbage to the internet — I wanted to add one more brick that can truly be used long-term to this old-school, clumsy, yet still very reliable Hugo world.