💭 How a Simple Question Led to blurt-claude-code

<center </center

Hello Blurtians!

For more than a year now, I've been experimenting with AI in almost every area I could think of.

Development, image generation, video, music, research... if a new AI tool appeared, there was a good chance I had already spent a few evenings playing with it.

Some experiments were genuinely impressive, while others were complete disasters. 😂

At first, I saw AI as a collection of independent tools.

Each had its own strengths, and I simply picked the right one depending on what I wanted to do.

But over the last few weeks, something changed.

Without really planning it, my development workflow started to evolve.

Instead of asking a single AI to do everything, I found myself naturally building a conversation between several of them.

A new idea would usually start in my own head, then I would challenge it with ChatGPT. If I was working on an existing Blurt project, one or more of my Hermes Agents sessions would inspect the real source code and audit my assumptions, confronting them with Layer 1 and Layer 2 Nexus of Blurt. Then back to ChatGPT again...

Little by little, this stopped feeling like "using AI" .

It started feeling like working with a small team where each participant had a different role.

And that's exactly what eventually led me to build something I had absolutely not planned when I woke up that morning...

<center </center

---

Hermes wasn't just another AI thing

When I first started using Hermes, it wasn't because I thought I had found the ultimate AI . Quite the opposite actually. After more than a year experimenting with different models, I had become rather sceptical. Every new AI looked impressive during the first few hours, then sooner or later I would find its limits and move on to the next one.

So Hermes started exactly the same way: a few discussions, some code reviews, a couple of audits on Blurt projects... nothing really different from what I had already done with many other AI assistants.

The difference didn't appear after the first prompt. It didn't even appear after a few days. It appeared after several weeks of working together on real Blurt projects.

Little by little, Hermes stopped behaving like a generic assistant. It started understanding the Blurt ecosystem, but more interestingly, it also started understanding the way I work. It learned that I would rather improve the reasoning than rush into writing code, that Blurt Layer 1 is always the semantic source of truth , that compatibility is something I almost never compromise on, and that before touching anything we first inspect the existing implementation and try to understand why it works the way it does.

That alone would have made the experiment worthwhile.

But something else happened that I hadn't anticipated.

Hermes started improving itself.

Not by magically becoming "smarter", but by recognising recurring patterns in our collaboration. It began creating new reusable skills, refining its own methodology, and learning to ask questions that it hadn't asked before.

Instead of immediately proposing a new function or feature, it increasingly stopped to ask:

"Which layer should own this responsibility?"

Does it belong in Layer 1 ?

Should it be implemented by Layer 2 ?

Is it really a reusable dBlurt SDK capability?

Or is it simply application-specific logic?

That single change probably had more impact on the quality of our discussions than any new model or benchmark ever could.

After a while, I wasn't explaining the same things anymore. We were gradually building a common way of reasoning about Blurt .

That's when a completely different set of questions came to my mind.

"Could everything Hermes had gradually learned be preserved?" "Could this experience be reproduced without starting again from zero?" "Could it be extracted and transferred to another AI assistant, whether freshly installed or already in use?"

And eventually, all those questions became one:

"Could weeks of accumulated reasoning, corrections, habits, architectural decisions and engineering culture be extracted from Hermes and made reusable by any Claude Code installation?"

Or, to put it even more simply:

"Can experience itself become reusable?"

---

<center </center

Building blurt-claude-code

Once I had that question in my head, I did what I usually do.

I opened ChatGPT.

Not because I expected it to give me the answer, but because over the last few months it had become my favourite place to challenge an idea before turning it into code.

The discussion started with something almost ridiculously simple:

"How can I make better use of my Claude Max subscription?"

That was it.

At that point there was no blurt-claude-code.

No framework.

No architecture.

Just a feeling that Claude Code was probably capable of much more than I was getting from it.

The more we talked, the more the discussion moved away from Claude Code itself.

Instead, we started asking questions.

How does Claude Code actually remember things?

What should be kept in memory?

What should stay in the repositories?

Should we build a RAG?

Use Obsidian?

A vector database?

Or maybe none of that?

For several hours, the discussion wasn't about writing files. It was about understanding what we were actually trying to transfer from Hermes.

At first, like many people probably would, we imagined something big.

One huge CLAUDE.md .

Hundreds of rules.

Lots of documentation.

The more we explored that idea, the worse it looked.

I still remember one sentence from ChatGPT that completely changed the direction of the project:

"The repositories are the source of truth for implementation. The framework should only be the source of truth for reasoning."

That was the first real breakthrough.

Suddenly, everything became simpler.

The framework didn't need to explain how Blurt works.

Claude Code could already read the source code for that.

It didn't need API documentation.

It didn't need implementation details.

It needed the things that don't exist naturally inside the repositories .

Why Layer 1 is the semantic authority.

Why some responsibilities belong in Layer 2 while others belong in the SDK or the application.

Why compatibility matters.

How we reason about architectural boundaries.

From that moment on, almost every discussion became an exercise in removing things rather than adding them.

Every time we wanted to create a new file, the same question came back:

"If we remove this file tomorrow, would Claude Code actually become worse at helping us develop Blurt?"

Sometimes the answer was yes.

Very often...

...the answer was no.

Little by little, the architecture gradually started designing itself.

Not because we were looking for the perfect Claude Code configuration.

But because we were trying to capture something much more difficult:

A way of thinking.

---

<center </center

Turning the idea into reality

At that point, ChatGPT and I had reached something that felt coherent enough to be worth trying.

Not a finished solution.

Not even a finished architecture.

Just an idea that finally made sense.

Instead of immediately creating files myself, I did something that, in hindsight, feels almost obvious.

I asked Hermes what it thought about the whole idea.

After all, if the goal was to transfer part of Hermes' accumulated reasoning, then Hermes itself had to become part of the design process.

That changed everything.

Until then, ChatGPT and I had been discussing concepts, challenging ideas and trying to understand what should — or shouldn't — become part of the framework.

Hermes approached the problem from a completely different angle.

It wasn't asking "What would be nice to have?"

It kept asking:

"Would this actually make me reason better about Blurt?"

That subtle difference had a huge impact on the project.

Several times it proposed ideas that looked great on paper... only to reject them itself a few minutes later because they didn't bring any real value.

Some entire sections disappeared.

Others were merged together.

The architecture became smaller, simpler and, paradoxically, much more powerful.

What impressed me the most wasn't that Hermes was generating Markdown files.

It was the way it started using everything it had learned over the previous weeks.

It naturally reused concepts we had discussed many times before.

It knew why Layer 1 had to remain the semantic authority.

It already understood why responsibilities should first be placed in the right layer before writing a single line of code.

It knew why repository documentation should never be duplicated.

It even started creating new skills for itself during the process whenever it recognised a recurring reasoning pattern.

That was probably the moment where I realised something quite unusual.

We were no longer writing documentation for Claude Code.

Hermes was gradually extracting part of its own accumulated experience and reorganising it into something another AI could understand.

Watching that happen was honestly fascinating.

It no longer felt like asking an AI to generate files.

It felt much closer to watching an experienced developer document years of engineering habits so that someone new joining the team could become productive much faster.

---

<center </center

The first real confrontation

At this point, we had reached something that honestly made us feel quite confident.

The architecture had been challenged over and over again. ChatGPT and I had spent hours discussing ideas, removing entire sections that initially looked important, simplifying others, and trying to answer one question over and over again:

"Does this really help Claude Code reason better about Blurt?"

Hermes then took over, challenged our own conclusions, rewrote part of the architecture, extracted what it had learned over the previous weeks into blurt-claude-code , and after several iterations we finally reached a version that all three of us were happy with.

At least... that's what we thought.

There was only one thing left to do.

Stop talking about it and let Claude Code judge our work.

So I moved to my Apple Silicon Mac mini, cloned the brand new blurt-claude-code repository next to the rest of my Blurt workspace , created the symbolic links expected by Claude Code, launched a completely fresh session and gave it one very simple mission:

"Audit this framework and tell me what you think."

I wasn't looking for compliments.

Quite the opposite.

If we had spent several days building something that another Claude instance could break in five minutes, I wanted to know immediately.

The beginning of the review was actually reassuring. Claude Code liked the general architecture, agreed with the separation between rules, skills, agents and context, and even confirmed that the idea of keeping the repositories as the implementation source of truth was the right direction.

Then, little by little, it started pointing out things we had missed.

Some remarks were easy to accept. A couple of repository names were inaccurate. Some hook patterns were far too broad and would quickly become annoying during real development. Nothing dramatic.

But then it made one observation that completely changed the rest of the project.

Claude Code looked at the repositories available in my local workspace and concluded that some parts of the framework were simply wrong because those repositories were not present on disk.

At first, my reaction was almost immediate.

"No... you're missing the point..."

Then I stopped.

Because the more we discussed its reasoning, the more I realised that Claude Code wasn't behaving incorrectly at all.

It was behaving exactly as we had unintentionally taught it to.

Without ever saying it explicitly, we had assumed something that had become obvious to us after weeks of discussions:

A developer's workspace is only one possible local view of the Blurt ecosystem. It is not the ecosystem itself.

We knew it.

Hermes knew it.

ChatGPT knew it.

But nowhere had we actually written it down.

That single misunderstanding triggered another round of discussions between ChatGPT, Hermes and myself. We didn't redesign the framework, but we clarified its mental model. We made the distinction between workspace and ecosystem explicit, between local repositories and durable ecosystem roles , between current projects and long-term architectural decisions .

Looking back, I honestly think this became the most valuable lesson of the entire project.

Not because Claude Code found a bug.

But because it exposed one of our own implicit assumptions.

And that's exactly why I wanted a fresh Claude Code instance to review the framework.

Not to tell us we were right.

To force us to discover where we were still thinking without realising it.

---

<center </center

Why this matters for Blurt

When I look back at everything that happened over the last few weeks, I don't think the most interesting result is blurt-claude-code itself.

The repository is simply the visible part of the project.

What really interests me is what it could change for anyone building on Blurt.

Every developer who joins the ecosystem eventually goes through the same learning process. You spend time reading repositories, trying to understand why some things belong in Layer 1 , why others have been implemented in Layer 2 , why a capability ended up inside the dBlurt SDK instead of an application, or why something that looked obvious at first would actually have been a mistake a few months later. That knowledge doesn't really exist in one place because most of it has never been written down. It lives inside discussions, architecture decisions, code reviews and, above all, experience.

That is exactly what I wanted to experiment with.

Not creating another documentation website.

Not replacing existing repositories.

Not teaching Claude Code how every API works.

But asking a much simpler question:

Can we give an AI assistant enough engineering culture to start asking the same questions an experienced Blurt developer would ask?

Questions like:

"Which layer should own this responsibility?"

"Am I solving a local problem, or should this become a reusable capability?"

"Does this respect Layer 1 semantics and the existing ecosystem boundaries?"

If Claude Code starts every new project by asking those questions before writing its first line of code, then I think we've already improved something important.

Because a bug can usually be fixed.

A bad architectural decision tends to survive for years.

And if this small framework helps even one developer avoid putting a responsibility in the wrong layer, duplicating logic that already exists elsewhere, or misunderstanding how the different parts of Blurt fit together, then all those discussions with ChatGPT, all those audits with Hermes, and all those iterations with Claude Code will already have been worth it.

---

<center </center

The real journey starts now

At this point, blurt-claude-code had stopped being my experiment.

It had become something I genuinely wanted to share with every Blurt developer .

When I started this little adventure, I simply wanted to make better use of my Claude Max subscription.

A few days later, I found myself looking at AI very differently.

The most interesting thing wasn't creating blurt-claude-code . It was discovering that a collaboration can evolve over time. Every discussion, every audit, every architectural debate and every mistake gradually made Hermes better at understanding the Blurt ecosystem, while the framework itself became a way of preserving part of that accumulated reasoning.

Somewhere along the way, I realised that something quite interesting had started to happen.

The framework improves Hermes. Hermes improves the framework. The framework becomes better. Hermes keeps learning.

That is a feedback loop I honestly didn't expect when this story began.

Now comes the part that really matters.

The framework is no longer just an idea or a repository sitting on GitLab. It has reached a point where I think it deserves to be tested in real conditions, on a real Blurt project, with real architectural decisions to make.

For that first experiment, I decided to go back to one of my favourite proof of concepts: Join Blurt Blockchain , my onboarding and account creation project. If blurt-claude-code really does what I hope it does, this project should quickly reveal both its strengths... and its weaknesses.

If you're developing on Blurt, or you're simply curious about this experiment, I'd genuinely love you to try it yourself.

The repository is available here:

If you do give it a try, I'd really appreciate your feedback in the comments . Whether you agree with the ideas, disagree with them, discover better approaches or simply find something we completely missed, that's exactly the kind of discussion that will help this framework evolve.

Because when I look back, I realise I never actually planned to build blurt-claude-code .

I was simply trying to understand whether weeks of accumulated engineering experience could become something reusable.

Maybe that's the most exciting part of this whole story.

---

<center @nalexadre <div <i Top 20 Witness • Builder • Architect</i </div </center

---

<center </center

Building the Blurt ecosystem

Producing blocks is only one part of my contribution to Blurt.

I spend most of my time analyzing, designing, building and experimenting with ideas that help strengthen the Blurt ecosystem over the long term.

Useful links

- BeBlurt frontend → - Public RPC node → - dBlurt TypeScript SDK documentation → - Blurt MCP documentation → - Source code :

Backing my Witness

If you appreciate the work I'm doing for the Blurt ecosystem, supporting my witness is one of the easiest ways to help.

Every Blurt account can vote for up to 30 witnesses , and even though I'm already in the Top 20, every vote helps strengthen the long-term sustainability of the infrastructure I maintain.

- via BeBlurt → - via Blurt Wallet →