DEV Community: SM Shahbaj

I Built Crucible to Make Claude Stop Agreeing Too Easily

SM Shahbaj — Sat, 15 Aug 2026 21:56:53 +0000

I use AI for a lot of things.

Exploring ideas. Comparing architectures. Thinking through product decisions. Debugging something at 2 AM when I probably should have been sleeping.

And honestly, it's extremely useful.

But there is one thing about working with AI that has always bothered me.

Sometimes it agrees with you a little too easily.

You give it an idea.

It sounds reasonable.

The model explains why it's reasonable.

Then you ask for a little more detail, and it gives you even more reasons why your original idea was probably a good one.

And suddenly you're 20 minutes into the conversation with a beautifully written argument for a decision that might have been wrong from the beginning.

That's the problem I wanted to work on.

So I built Crucible.

Crucible is an adaptive decision-review skill for Claude Code. You give it something that actually matters—a technical architecture, a product decision, a plan, a strategy, a recommendation—and instead of simply helping you defend the idea, it tries to pressure-test it.

The interesting part is that it doesn't just throw a bunch of agents at the problem.

That would be easy.

The difficult question was:

How much reasoning is actually necessary before a decision is stable enough to act on?

That question ended up shaping almost everything in Crucible.

The idea behind Crucible

Imagine I ask:

«Should I use architecture A or architecture B?»

A normal AI answer might compare the two and recommend one.

That's useful.

But what if the recommendation depends on one assumption that hasn't been verified?

Or what if the decision is difficult to reverse?

Or what if there's a failure mode that neither option comparison considered?

Or what if the answer only looks good because the model anchored itself to the first idea I mentioned?

That's where I wanted Crucible to behave differently.

The workflow is basically:

Frame the decision → determine how much scrutiny it deserves → verify important claims → challenge the weak point → check the failure mode → decide whether more reasoning is actually useful → stop.

That last part is surprisingly important.

I didn't want to build a system that thinks longer just because it can.

More reasoning is not automatically better.

Sometimes it is.

Sometimes it is just more text.

So I didn't make "14 agents"

Technically, Crucible contains 14 specialist agent definitions.

That sounds impressive on a landing page.

But that isn't really the interesting part.

The interesting part is that Crucible does not use all 14 agents on every question.

There are three review depths:

QUICK, REVIEW, and DEEP.

A simple, reversible decision should stay simple.

A decision with meaningful uncertainty might get a couple of independent perspectives.

A high-downside or difficult-to-reverse decision can get a deeper review with several different lenses plus targeted verification and adversarial analysis.

The router itself is intentionally small.

It doesn't solve the decision.

It first asks something closer to:

ROUTE: QUICK / REVIEW / DEEP
STAKES: low / medium / high
UNCERTAINTY: low / medium / high
REVERSIBILITY: low / medium / high
EXTERNAL_VERIFICATION: yes / no
MAIN_DECISION_VARIABLE:
WHY_EXTRA_WORK_IS_OR_IS_NOT_JUSTIFIED:
NEXT_MINIMUM_STEP:

That separation matters.

The routing layer shouldn't immediately fall in love with a solution.

Its job is to decide whether the problem deserves more work.

The part I care about most: anti-anchoring

One of the easiest ways for an AI system to become confidently wrong is to anchor too early.

Suppose the first conclusion is:

«"Architecture A is probably better."»

Now imagine five different agents are asked to review that conclusion using the same assumptions and the same evidence.

They might all agree.

That doesn't necessarily mean we've found five independent confirmations.

We might have just created a very sophisticated echo chamber.

So Crucible treats independence as a process problem, not a headcount problem.

Different lenses are supposed to be formed before the leading conclusion becomes an anchor.

That is why one of the principles behind the project is:

More agents ≠ more truth.

Fourteen agents agreeing with the same unverified premise is still one bad premise.

Evidence gets a different treatment too

Another thing I wanted to avoid was treating every sentence in a recommendation as equally important.

They're not.

Some statements are just supporting details.

Others actually determine the decision.

Those are the claims that deserve verification.

Crucible therefore separates decision-critical evidence from everything else and can escalate specific claims for verification rather than launching a giant research process for the entire answer.

That sounds like a small design choice.

It isn't.

It changes how much unnecessary work the system does.

The goal isn't:

«"Research everything."»

The goal is:

«"Find the thing that could change the decision, and verify that."»

That idea shows up repeatedly throughout the project—in the routing rules, evidence gates, verification planning, and quality-control layer.

**Failure-first instead of risk-list-first

**
There's another detail I really liked while building it.

When people review a decision, they often produce a list of risks.

Ten risks.

Fifteen risks.

Maybe twenty, just to be safe.

It looks thorough.

But most of them don't actually matter.

Crucible instead tries to identify the single highest-impact plausible failure mode—the thing most capable of changing the action.

Then it asks what would trigger that failure, what signal we'd see, what mitigation exists, and what risk remains.

This makes a review much more actionable.

A decision isn't improved because you wrote down twenty scary things.

It's improved when you find the one that can actually change what you should do next.

And then there's the stopping rule

This might be my favorite part of the whole project.

AI systems have a natural tendency to keep going.

More analysis.

Another angle.

Another comparison.

Another caveat.

Another paragraph explaining why the previous paragraph matters.

At some point, more reasoning stops being useful.

So Crucible has explicit stopping rules.

If the recommendation is stable...

If the remaining uncertainty can't change the action...

If the next verification step is redundant...

Or if a staged action can resolve the uncertainty more cheaply...

stop.

I wanted Crucible to treat compute and attention as something worth spending deliberately.

That's why the internal principle is essentially:

«Do another check only when the result could plausibly change the action.»

The architecture is deliberately boring

The project isn't a huge application with a database, API layer, queue system, or separate inference backend.

It's a Claude Code plugin and marketplace package.

The core behavior lives in the skill definition and reference modules.

The specialist agents are separated by responsibility.

The repository also contains the testing, benchmark, validation, and ledger infrastructure around that core.

The project structure looks roughly like this:

crucible/
├── .claude-plugin/
│ ├── plugin.json
│ └── marketplace.json
├── agents/
├── benchmarks/
├── scripts/
├── skills/
│ └── crucible/
│ ├── SKILL.md
│ └── references/
├── tests/
├── README.md
├── LICENSE
├── SECURITY.md
└── CONTRIBUTING.md

The nice thing about this approach is that the reasoning methodology isn't hidden inside some giant application.

You can actually read it.

The routing rules are documented.

The evidence rules are documented.

The adversarial methodology is documented.

The output contract is documented.

The quality gate is documented.

The decision ledger is documented.

That was intentional.

I wanted the system itself to be inspectable.

I also didn't want "benchmarks" to become marketing numbers

This is another thing I was fairly strict about.

It's very easy to create an offline benchmark, get a perfect score, and put "100% accuracy" on a website.

That would be misleading here.

Crucible has routing tests, golden evaluation materials, adversarial cases, stress tests, package validation, and benchmark plumbing.

But an offline benchmark that feeds expected outputs back into a scorer doesn't prove that a live language model will make the right decision.

So the project explicitly distinguishes engineering/regression validation from live model quality.

The README even warns against interpreting the offline score as proof of model accuracy.

I think that's important for a project whose entire purpose is making AI reasoning more trustworthy.

If I'm going to build something about evidence, I should probably apply the same standard to my own claims.

I tested the release locally

For the version I'm releasing as v1.0.0, I didn't just look at the files and call it done.

I ran the bundled standalone test suite against the release package.

The result:

=== 84 passed, 0 failed ===

The routing fixtures also passed completely:

8/8 routing fixtures matched the reference heuristic.

I ran the stress harness with 50 iterations covering normal cases, missing evidence, malformed payloads, timeouts, adapter errors, and contradictions.

The result was:

unexpected_failures: 0

The repository also has CI configured to run the test suite, validator, routing checks, benchmark contracts, golden benchmark contract, stress harness, syntax checks, and additional release checks.

Those numbers don't mean Crucible is magically correct.

They mean the software around the methodology is actually being tested.

And that's the distinction I want to keep.

There's a Decision Ledger too

One feature I almost considered leaving out was the local decision ledger.

Crucible can record a decision, its reasoning, the main risk, the condition that would change the recommendation, and eventually the outcome.

That means a decision doesn't necessarily disappear once the conversation ends.

Over time, you can look back at decisions and compare what you believed would happen with what actually happened.

I like this because it changes decision-making from:

«"I think this is the right choice."»

into something closer to:

«"Here's what I decided, here's why, here's what I was uncertain about, and here's what would have changed my mind."»

That's much more useful six months later.

The ledger is local rather than requiring a hosted database, which was also deliberate.

- What I actually built

So, after all of this, what is Crucible?

It's not a chatbot.

It's not a "14 agents argue with each other" demo.

It's not a majority-vote truth machine.

And it's definitely not a guarantee that an AI will always make the correct decision.

It's a decision-pressure-testing layer for Claude Code.

You can install it from the Claude Code marketplace and run:

/plugin marketplace add smshahbaj/crucible
/plugin install crucible@crucible-marketplace

Then:

/crucible Pressure-test this decision before I commit:
should we choose architecture A or architecture B?

Normal usage doesn't require a separate database or model API key. The optional live evaluation path is separate from normal plugin operation.

Why I built it

I don't think AI needs to become more agreeable.

It already is.

I think it needs to become better at telling us:

"Wait. Before you do that, here's the part of your reasoning I'd actually worry about."

That's the behavior I wanted.

Not endless analysis.

Not fake certainty.

Not a wall of agent output.

Just enough intelligent resistance to catch the thing you might otherwise miss.

That's Crucible.

Verify. Challenge. Decide.

The project is open source under the MIT license.

GitHub: Crucible Repo

Website: Crucible

If you try it, I'd genuinely like to know where it breaks, where it's too cautious, where it's too aggressive, and especially where it changes your mind.

Because if a decision-pressure-testing tool can't survive people trying to pressure-test itself, then I probably built the wrong thing.

I built a free AI-powered Linktree alternative that generates your page algorithmically — Xefna

SM Shahbaj — Thu, 14 May 2026 18:07:31 +0000

I got tired of every link-in-bio page looking exactly the same.

You know the look — white background, rounded buttons stacked in a
column, maybe a profile picture at the top. Linktree. Beacons.
Bio.link. They all look identical. Your page looks like everyone
else's page.

So I built Xefna.

What is Xefna?

Xefna is a micro-site engine that uses AI and algorithmic design to
generate a completely unique digital identity for every user — not
a template, not a button list. It analyzes your content and builds
a layout, color palette, and typography specifically for you.

Every Xefna page looks like a custom-coded portfolio. No two pages
look the same.

How it works

You go to xefna.com and hit Magic Start
Type a short prompt or bio — something like "I'm a music producer and visual artist from Dhaka"
The AI engine extracts your brand essence and generates your entire page — layout, colors, typography, structure
You customize links and content in the visual editor
Your page is live instantly at xefna.com/yourname

The whole thing takes under 2 minutes.

What makes it different from Linktree

Feature	Linktree	Xefna
Design	Static button list	Algorithmically generated
Setup	Manual	AI-powered from a single prompt
Uniqueness	Everyone looks the same	Every page is distinct
Feel	Generic	Custom-coded portfolio
Price	Free tier	Free tier

The tech stack

For the devs curious about what's under the hood:

React 19 + TypeScript + Vite (SPA)
Express server for SSR meta tag injection (so profiles are crawlable by Google and social platforms)
Supabase (PostgreSQL) for user data and profile storage
Cloudflare Pages + CDN for edge deployment globally
Google Gemini AI + OpenAI for the Magic Start generator
motion/react for micro-animations
Tailwind CSS for styling

The SSR part was the most interesting engineering challenge —
since it's a React SPA, user profile pages at xefna.com/username
needed to return real HTML to Googlebot and social crawlers
(for OG previews). The Express server detects the User-Agent and
injects pre-rendered HTML + meta tags before serving.

What I learned building this

This is a micro-startup I founded in April 2026. A few honest takeaways:

SSR meta injection is underrated. Most SPA tutorials skip this entirely but it's critical for SEO and social sharing.
AI generation UX is hard. Getting the prompt-to-page flow to feel magical rather than frustrating took many iterations.
Cloudflare Pages + Supabase is an incredible free stack. Zero infrastructure cost at this stage.

Try it

👉 xefna.com — completely free, no credit card

I'd genuinely love your feedback. Especially from devs — what
would you want from a link-in-bio tool that you can't get from
Linktree today?

Drop a comment or reach out on X: @xefnalabs

Building a "Local-First" Expense Tracker with zero server costs

SM Shahbaj — Thu, 23 Apr 2026 20:26:21 +0000

As developers, we tend to follow a common practice: frontend + api + database. Yet, when I decided to develop the Sheet Manager application, I wanted to break this paradigm. I wanted to create an application which is 100% private, offline, and completely zero-cost.

And Local-First architecture helped me achieve that.

The Architecture

There is no reason why your sensitive financial data should be stored on some PostgreSQL or MongoDB instance somewhere on the cloud. Instead, all of it is stored in the user's browser.

Persistence: I implemented a wrapper for IndexedDB which allows us to handle very large sets of structured data (in comparison to LocalStorage). Plus, unlike LocalStorage, it does not block the main thread.

Performance: Being client-side only makes our UI super responsive since there are no API calls and the latency becomes simply the execution of JavaScript code.

Privacy: This is the main advantage of local-first applications. I literally have no way of accessing the data users enter since it's being stored on their own computers. For a finance application, that's an incredible feature.

The "Zero-Cost" Infrastructure

Can we make a production-ready application without any bills whatsoever?

Hosting: Using Cloudflare Pages and GitHub Pages as the frontend hosting services.
Database: Free (It's inside the user's browser).
Analytics: Keeping analytics light and simple to stay away from trackers.

Challenges of Local-First Development

This was not as easy as it sounds. Developing without backend adds its challenges:
Data portability: In case the user clears browser storage, how can we provide him/her with the option to import/export data? Implemented a JSON/CSV export/import system.
Sync across multiple devices: This is something I want to tackle soon by using WebRTC or Peer-to-Peer synchronization technologies._

Why did I develop this?

In addition to being a software engineer, I'm also very privacy-conscious (I don't even use Facebook and Twitter). We over-engineered the idea of "the cloud" into every tiny utility. Sheet Manager became a proof that we don't necessarily need servers to develop beautiful dashboard-based applications.

Take a look at the project yourself: Sheet Manager

What do you think about the idea of local-first development? How are you handling data persistence nowadays?