DEV Community: Roger Wang

Stop "Jokering" My Project: Why AI is Too Good at Ruining Your mission.

Roger Wang — Tue, 21 Apr 2026 05:06:59 +0000

Stop "Jokering" My Project: Why AI is Too Good at Ruining Your mission.

Why is a deck of cards more honest than a project?

If you were at the card table last night, you might have witnessed a very familiar scene.
Someone says: "Let’s build a simple single-player poker game. It’s easy."
Another person immediately chimed in: "Shuffle, deal, compare ranks—AI can write that in a second."
A third person was even more optimistic: "Let’s throw in a Joker for variety; it’ll look cooler."

It sounds perfectly reasonable.
In this day and age, almost every project starts this way—
The inspiration is fast, the AI is fast, and the output is fast.

But the real problem usually doesn't start with "Can we build it?"
It starts from a much smaller place:
Is this deck of cards still the same deck you started with?

In the beginning, everyone thought the problem was small.

The initial requirements were quite simple:

Build a poker dealing process.
Use a standard 52-card deck.
Deal to 4 players.
5 cards per person.
Just demonstrate the flow; don't worry about full rules yet.

At this point, everything is clear.

REQ is clear: Validate the dealing process, not build a full casino system.
SPEC is clear: Shuffle, distribute, display results.
ADR is clear: Build the Minimum Provable Case (MPC) first.
CONTRACT is even clearer: Standard deck, fixed boundaries, no extra extensions.

In this scenario, having AI write the code for you feels great. It acts like a high-speed engineering assistant, rather than an accomplice who secretly changes the rules without anyone noticing.

The problem isn't that AI writes poorly; it's that humans find it too easy to say "one little change won't hurt."

The real turning point usually comes from a single sentence:

"Actually, let’s add a Joker. It’ll make the gameplay more interesting."

The danger of this sentence isn't the Joker itself. It’s that it sounds too reasonable.
Because once an AI is powerful enough, it won't just add a Joker for you; it will "thoughtfully":

Update your data structures.
Modify the win-condition logic.
Fix the display logic.
Adjust your test cases along the way.
Rewrite the entire spec to make it look like it was always meant to be this way.

In the end, what you see isn't an error. You see something that looks incredibly complete—perhaps even more polished than the original.

That is the true danger.
Projects rarely die because "things couldn't be built." More often, they die because every step was reasonable, but the sum total is no longer the original thing.

AxiomFlow: The Sober Observer at the Table

The interesting part of AxiomFlow isn't helping you deal the cards. It’s asking first:
"Can this hand even be dealt?"

This is the essence of PDR (Project Design Review).
In the current version of AxiomFlow, PDR is no longer just a standard checklist. It acts like the person standing by the card table who isn't gambling but remains the most sober: He doesn't play the cards; he just asks right before you start—"Is the game you’re playing now the same one that was approved?"

When SPEC-001 faithfully implements the original flow, PDR sees Alignment.

When SPEC-002 secretly changes the scoring rules but the REQ hasn't been updated, PDR sees a Conflict.

When SPEC-003 adds a Joker and breaks the original deck boundaries, PDR doesn't see a "cool new idea." It sees a definitive: > Conflict Detected.

In that moment, the entire story changes. While most tools try to help you move faster, AxiomFlow aims to help you stop earlier.

It’s not about stifling creativity; it’s about protecting intent.

When people hear "governance," their instinct is to think of something that slows them down. But if you've actually run a project, you know that the biggest waste of time isn't "spending 10 minutes confirming boundaries." It’s:

Realizing after three days of work that the direction has drifted.
Having a beautiful document that solves the wrong problem.
New members taking over who can see the what (result) but not the why (reason).
AI producing a new "reasonable" answer every time, with no one able to prove which version is correct.

This is what AxiomFlow repeatedly emphasizes in its README: The problem isn't that AI produces too little; it's that when it produces too fast, the team loses the ability to decouple "Problem, Method, Reason, and Boundary."

That’s why it separates these layers:

REQ: What are we actually trying to solve?
SPEC: How do we plan to do it?
ADR: Why did we choose this path?
CONTRACT: Which boundaries must not be crossed?

Once these four layers get blurred, the project becomes like a deck of cards that someone has secretly swapped. You think you’re still playing the same game, but the rules changed long ago.

The poker story isn't really about cards.

It’s about those common, yet rarely addressed moments in a project:
"We didn't mean to drift. We just thought 'this little change is fine' every single time."

AI amplifies this "little bit" of drift with terrifying efficiency.
If you are just looking for a tool that writes code better, AxiomFlow might not be your favorite. But if you’ve begun to realize that AI doesn't need more freedom—it needs clearer governance coordinates—then this poker story is more than just a toy example.

It asks every project lead:
As a system grows more powerful, do you have the ability to know—is it doing what you asked it to do, or is it just making the deviation look more beautiful?

Because a truly mature team isn't brave enough to deal every hand.
They are the ones who know which hand requires a pause.

Conclusion

If the boundaries of a simple 52-card deck are worth defining clearly, then a software project involving AI certainly shouldn't run on "tacit understanding."

AxiomFlow doesn't aim to replace human judgment. It aims to take the judgments that only exist in your head and turn them into a system that can be seen, inspected, and, when necessary, intercepted.

It’s not asking: "Can AI help you build this?"
It’s asking a much more important question: "Before it’s built, can you be sure this is actually what you wanted?"

https://pigsly.github.io/AxiomFlow/

The more AI does, the clearer the system becomes—instead of more chaotic.

Roger Wang — Thu, 16 Apr 2026 14:24:34 +0000

Have you noticed that many AI tools look incredibly powerful, yet once you try to use them in a real project, they still feel hard to trust?

Today, they can help you generate a solution draft. Tomorrow, they can write a document for you.
But the real problem is not whether they can do it. It is this:

Why did the output turn out this way?
What was it actually based on?
Once requirements change or team members rotate, the whole process starts to drift
The project may move fast, but not necessarily in the right direction, while risk keeps piling up

This is exactly the problem many teams are starting to face:
AI has accelerated output, but governance has not kept up.

That gap is what AxiomFlow is designed to solve.

It is not another attempt to repackage AI as a “better chatbot.”
Instead, it puts AI back into the place it actually needs to occupy inside teams, workflows, and governance systems.

According to the project description, AxiomFlow is positioned as a governance model for AI-assisted software delivery. Its core goal is to ensure that even under AI-accelerated execution, delivery remains aligned, bounded, and traceable.

That may sound abstract, but it is actually extremely practical.

Because in real projects, what people fear most is never that AI is not smart enough.
What they fear is realizing too late that:

It solved the wrong problem
It crossed boundaries it should never have crossed
It quietly turned a one-time judgment into a long-term structure
It left behind outputs, but not the reasoning behind the decisions

What makes AxiomFlow powerful is that it does not only talk about how to do things.
It starts by separating different layers of project thinking.

It uses document roles to structure reasoning:

REQ defines what problem should be solved
SPEC explains how it will be done
ADR explains why this architectural direction was chosen
CONTRACT clearly defines which boundaries must not be crossed

The value of this design is significant.

Because once a team mixes together the problem, the implementation, the rationale, and the boundaries, AI will only amplify the confusion.
But if these four layers are clearly separated, AI has a chance to become a stable execution amplifier rather than a high-speed source of chaos.

From a product perspective, I would say the real value of AxiomFlow is not just the method itself.
It is that it addresses a market gap that very few people are tackling directly:

Most AI products are focused on generating faster.
AxiomFlow is focused on what happens after generation—how a team can still stay in control of the whole system.

That is also what makes it fundamentally different from ordinary AI tools.

Most tools are strong at giving immediate answers.
AxiomFlow is strong at making those answers usable inside a long-term system.

Most tools give you outputs.
AxiomFlow cares more about whether those outputs can be explained, verified, and carried forward.

There is a line in the README that captures this very well:

“Turn AI agents into governable builders.”

That is almost the entire product thesis in one sentence.

It does not treat AI as a black-box agent that operates freely.
It turns AI into something that can actually be governed.

What does that mean?

It means the AI systems that truly succeed in the future may not be the ones that feel the most human or speak the most fluently.
They may be the ones that can be trusted, handed over, reviewed, and evolved inside real organizations.

If you are only looking for a tool to help you write a few more paragraphs, AxiomFlow may not be for you.

But if you are already thinking about questions like these:

How does AI enter real software delivery workflows?
How can teams avoid losing control as AI accelerates execution?
How can documents, decisions, architecture, and boundaries form a positive feedback loop?
How does a project move from simply “working” to being governable and evolvable?

Then AxiomFlow is a direction worth paying attention to.

In one sentence:

It is not about helping AI do more.
It is about helping teams build a new capability:

The more AI does, the clearer the system becomes—instead of more chaotic.

Project link:
https://github.com/pigsly/AxiomFlow

Two powerful tools, but missing a layer in between.

Roger Wang — Sat, 11 Apr 2026 04:44:34 +0000

We already have great tools.

OpenAI → helps you think
Logseq → helps you store

Both are powerful.

But together, they still leave a gap.

AI generates reasoning.
Notes capture results.

👉 But the reasoning itself disappears.

You get:

outputs from AI
knowledge in your notes

But not the process that created them.

And that process is the most valuable part.

Because thinking is not the answer.

Thinking is the path.

So I started asking:

What if reasoning itself could be stored?

Not just the result —
but the full thinking flow.

That question led to this:

https://github.com/pigsly/ClawMind

OpenAI gives you answers. Logseq stores your knowledge. ClawMind builds how you think.

Roger Wang — Fri, 10 Apr 2026 23:47:28 +0000

Most of us use AI like this:

Open OpenAI
Ask a question
Get an answer

And that’s it.

It feels powerful.

But there’s a hidden problem:

👉 Your thinking doesn’t stay.

A few days later,
you face a similar problem —

and start from zero again.

Like you’ve never thought about it before.

So we try to fix it with tools like Logseq.

We write things down.
We connect ideas.

But something is still missing.

AI helps you think.
Notes help you remember.

👉 But they don’t connect.

You end up with:

answers
notes

…but no thinking system.

That’s the gap I wanted to solve.

https://github.com/pigsly/ClawMind