DEV Community: Ram Chandra Samal

ArxLearn for learners and institutions

Ram Chandra Samal — Fri, 09 Oct 2026 16:52:53 +0000

ArxLearn: connecting visual CS lessons, personal paths and institutional curricula

From the ArxLearn team at Architonix Labs LLP. This draft was created with AI assistance.

A visual explanation solves one problem: making a mechanism observable. A learning platform has to solve the next problems too—sequencing, returning to unfinished work, and helping a teacher organise a cohort.

A learner can watch a clear explanation and still struggle to decide what to study next. A teacher can share useful links and still lack a common view of what a cohort has completed. ArxLearn connects animated computer-science lessons with learning paths and institutional organisation.

ArxLearn is built by Architonix Labs LLP. Its explainer library covers subjects from sorting and data structures to operating systems, networks, databases and mathematics. Topic pages connect lessons to prerequisites and recommended next topics. Available explainers show how a mechanism evolves, giving learners a place to stop and ask what should happen next.

For an individual learner, the useful workflow is concrete: choose a topic, check its prerequisites, study the explanation, work through a fresh example, and continue through a course or a personal path. Signed-in learners can save progress and resume their work. Curated courses organise related topics into modules; personal paths support a different order when a learner needs one.

For a college or university, the problem is different. A shared library needs to fit a programme and its cohorts. ArxLearn supports curricula organised by year, term and module, with published versions that keep an enrolled cohort attached to its assigned structure. Institution staff can enrol learners through supported invitation workflows, organise sections and review progress reports.

Progress is a starting point for a teaching conversation. A completed topic does not establish that someone can implement the algorithm or defend its correctness. Pair the explainer with a prediction question, a small practice task and a short explanation written by the learner. Use section-level progress to decide where follow-up might help, then assess understanding through the institution’s own teaching and assessment process.

Completion certificates have public verification, and institutional certificate templates can carry the institution’s branding. They record completion under the course’s rules; they should not be presented as proof of a proctored examination, professional accreditation or job readiness.

A practical first evaluation is one topic, one teaching objective and one small group. For example, begin with binary search: ask learners which interval can be discarded, let them follow the trace, and then give them an absent-target case. Compare the quality of their explanations, the ease of finding the next topic and the usefulness of the staff workflow. Decide on wider adoption from that evidence rather than an assumed improvement percentage.

Some explainers are available without an account; other available lessons require a free account. The public catalogue also includes topics whose explainers are still being built. Check the selected topic and course before promising a complete animated curriculum. Institutional access and rollout arrangements should be confirmed with the team; this article makes no pricing or service-level promise.

Choose a starting point

For self-study, explore the topic library or browse the curated courses. For a programme-level evaluation, read the institution overview.

What would make a one-topic evaluation useful for you: a clearer trace, a practice task, a path through prerequisites, or a simpler way to organise a cohort?

Stop pasting tokens into random websites: meet SmartDevUtils

Ram Chandra Samal — Fri, 29 May 2026 01:07:02 +0000

If you've done any of these in the last week —

Googled "decode jwt online", clicked the first result, and pasted a real token into a textbox on a domain you'd never heard of.
Opened an ad-cluttered "JSON formatter" site to clean up a 2-KB payload.
Pasted a row of customer data into a "CSV to JSON" converter to massage it for a support ticket.

…you already know the problem. The web is covered in single-purpose developer utility sites, and most of them are some combination of slow, ad-infested, and quietly logging whatever you paste into them.

SmartDevUtils is one answer to that: a single tab that bundles the everyday developer utilities you keep googling, running entirely client-side in your browser. No backend round-trip, no accounts, no upload of your inputs.

The everyday friction

These tasks come back day after day:

Decode a JWT to inspect a claim
Format and validate a JSON response
Convert between Unix timestamps and human time
Generate a UUID for a test record
Hash a string for comparison
URL-encode a tricky query parameter
Parse the cron expression you copied out of a YAML file
Diff two near-identical config blobs

Individually each is a 5-second task. Collectively they are a real attention tax — and the "search for a tool every time" pattern means you're constantly evaluating an unfamiliar, untrusted page right when you're trying to focus on something else.

What's in the toolbox

Roughly what you'd expect from a complete swiss-army-knife site, grouped by category:

Encoding & Crypto — Base64, JWT debugger, MD5 / SHA hash, URL encode
Data & Formats — JSON format/validate, YAML ↔ JSON, CSV ↔ JSON, XML
Generators — UUID / ULID, strong passwords, QR codes, Lorem Ipsum
Text & Code — Regex tester, text diff, case converter, string inspector
Web & Design — Color converter, Markdown preview, meta-tag builder
Time & Numbers — Unix timestamp, number-base converter, cron parser

The exact lineup may differ on the live site, but the shape is familiar.

The interesting bit: it runs in your browser

This is the part that matters more than the tool count.

Most "online converter" sites work like this: your input is POSTed to their server, processed, logged (probably), and returned. The data flow passes through infrastructure you have zero visibility into. For a JSON formatter that's annoying. For anything containing a JWT, an API key, a secret, a customer email, or a config blob, it's a quiet but real data-exfiltration risk you absorb every single time.

SmartDevUtils flips that. Everything happens in your browser's JavaScript runtime. If the implementation matches what it advertises, you should be able to open DevTools → Network, use any of the tools, and see no outgoing requests on your input. Once the page is cached, it keeps working offline.

That single architectural choice has nice downstream effects:

Safe with secrets. Decode a JWT containing a real session token without it leaving your laptop.
Fast. No round-trip latency. Output updates as you type.
Offline. Works on planes, behind firewalls, on locked-down corporate networks where most online tools fail.
No accounts, no rate limits. There's no backend to gate you on.

How to get it

Beyond the web app, SmartDevUtils is also available as a browser extension, served directly from the website itself — no app-store account, no review delay. Visit smartdevutils.com, choose Add to browser, and pin the icon to your toolbar.

The next time you need to base64-decode something, hit the toolbar icon and the whole toolbox is there.

Why this pattern matters

There's a broader point lurking here. Single-purpose dev utility sites are a category that defaults to client-side processing — every operation in that toolbox is pure transformation logic that doesn't need a server at all. The fact that so many of them still ship a backend (and the analytics/ads that come with it) is a quiet vote against the user's interest.

Tools like SmartDevUtils are useful as tools. They're also useful as a reminder of what this whole category should look like:

Local computation by default
No telemetry on user input
Offline-capable, because every dependency is in the bundle
Free, because there's almost nothing to host

If you build internal tooling for your team, the same posture is worth borrowing. The fastest, most trustworthy version of "small utility tool" is almost always the one with no backend at all.

Try it: 👉 smartdevutils.com

Have a favorite browser-native dev tool you keep open in a tab? Drop it in the comments — always looking for more.

Multi-Repo Microservice Changes Are a Coordination Problem. I Solved It With AI Agent Teams.

Ram Chandra Samal — Mon, 25 May 2026 08:12:03 +0000

A walkthrough of RepoOrch — an open-source Claude Code plugin that turns a multi-repo workspace into a deliberating team of AI specialists, with peer-to-peer messaging and a hard read-only safety model.

github.com/architonixlabs/RepoOrch · MIT licensed · v0.3.0

The honest workflow for a multi-repo bug in a microservice org looks like this: open three codebases, read until your eyes blur, hope you didn't miss a contract break in the fourth.

This isn't a code problem. It's a coordination problem. And it's the exact shape of problem that the new Agent Teams primitive in Claude Code is built to solve.

In this post I'll walk through:

Why subagents (the older primitive) can't handle multi-repo change planning
What Agent Teams add — specifically, the mailbox abstraction for peer-to-peer agent messaging
How I built RepoOrch, an open-source plugin that uses this pattern to turn a multi-repo workspace into a deliberating AI team
The propose-only safety model and why it's enforced at the platform layer, not in prose
How knowledge graphs cut per-triage token cost on large workspaces

If you've ever opened five tabs for a single microservice change and thought "there has to be a better division of labor here," this is about that.

1. The shape of the problem

Imagine the workspace below — a perfectly ordinary microservice layout:

my-project/
├── auth-service/
├── payments/
├── notifications/
├── inventory/
└── shipping/

A ticket arrives in your queue:

"Users are getting 401 errors after the auth refactor."

The bug almost certainly lives across multiple repos. Maybe auth-service changed the shape of a JWT claim, and payments still expects the old shape. Maybe notifications never validated the claim properly and is silently dropping events. The only honest way to know is to read each codebase, trace the contract, and hope you didn't miss something.

This is a textbook agentic AI use case — except for one thing: the agents need to talk to each other. And until recently, they couldn't.

2. Why subagents can't do this

The standard agent-orchestration pattern in Claude Code (before Agent Teams) looked like this:

master agent
    ├─→ subagent A (auth-service expert)
    ├─→ subagent B (payments expert)
    └─→ subagent C (notifications expert)

Each subagent gets a question, does some research, and reports back to the master. Subagents cannot talk to each other. They form a tree, not a graph.

That's fine for "go read this file" or "summarize the schema." It falls apart the moment two specialists need to negotiate.

Consider what actually needs to happen for the 401 bug:

The auth specialist proposes: "I'll change the JWT sub claim from user_id to UUID."
The payments specialist needs to answer: "Does my service depend on the shape of the sub claim?"

In a subagent tree, the only path between them goes through the master. So the master has to:

Understand the auth proposal deeply enough to translate it into a question for payments
Get the payments answer
Translate it back into a constraint on auth
Repeat for every cross-repo edge

This doesn't scale, and worse — it forces the master into a coordinator role it's not really equipped for. The result is plans that look complete but have stale assumptions baked in.

3. Agent Teams: the mailbox primitive

Claude Code 2.1.32 introduced Agent Teams. The key difference is one small but transformative addition: each teammate gets a mailbox, and teammates can message each other directly.

master agent
    ├─→ auth specialist  ──┐
    │                      │  direct peer messages
    ├─→ payments spec.  ──┤  (mailbox)
    │                      │
    └─→ notifications  ───┘

Now the conversation that actually needs to happen can happen:

auth → payments: "I'm proposing changing the JWT sub claim from user_id to UUID. Does your service read sub directly, and if so, how do you parse it?"

payments → auth: "Yes, we read sub in auth.middleware.ts:42 and call parseInt() on it. Your change will break us unless we update to UUID parsing in the same release."

That deliberation is what produces a plan you can actually trust. The master doesn't have to be smart enough to mediate the contract — the specialists are.

4. How RepoOrch puts this together

RepoOrch is a Claude Code plugin that operationalizes this pattern for the multi-repo microservice case. Setup is one command:

/repo-orch-setup

The setup runner:

Discovers every git repo under your workspace root.
Indexes each repo (language, frameworks, endpoints, events, dependencies).
Writes an editable context document per repo — and pauses for your review. (This is the most important step. The owns field in the context drives routing later.)
On your confirmation, generates a specialist agent per repo and a registry.json the master uses for routing.

Then, for any incoming ticket:

/repo-orch-triage "Users are getting 401 errors after the recent auth refactor"

The master reads the registry, scores which repos are likely involved, and spawns the relevant specialists as an Agent Team. They emit VERDICTs, deliberate over cross-repo contracts via their mailboxes, and the master synthesizes a single ordered change plan with:

Cross-repo dependency ordering (which repo's change must land first)
Risks called out per repo
Validation hints (the tests / endpoints to exercise)
Zero files modified — which brings us to the safety model.

For incidents where the root cause isn't known, there's an adversarial variant:

/repo-orch-deliberate "Payments failing intermittently — unknown root cause"

This spawns the team in a mode where specialists are biased toward challenging each other's hypotheses, not converging too fast on the first plausible cause.

5. Propose-only, enforced at the platform layer

There is a recurring AI-agent failure mode where the prompt says "do not modify files" and then the agent modifies files anyway. Prose is not a security boundary.

RepoOrch enforces propose-only in two layers:

Tool restriction. Every specialist agent is spawned with tools: Read, Grep, Glob, Bash. There are no write, edit, create, or delete tools available. This isn't a prompt instruction — it's the actual tool inventory the agent sees.
PreToolUse hook. A platform-level hook intercepts every Bash call and hard-blocks write-like commands: rm, mv, git commit, git push, sed -i, > redirection, and others. Even a malicious or hallucinated bash invocation is rejected before it runs.

The /repo-orch-triage and /repo-orch-deliberate commands additionally spawn agents with permissionMode: "plan", so the spawning context itself is read + delegate only.

The v0.2 guarantee, written into the README: the agents produce a plan document. The developer executes it.

6. Knowledge graphs and token savings

The naive way to run a triage is to have every specialist cold-read its repo on every ticket. That works, but it adds up. The optional /repo-orch-graph command builds a Claude-native knowledge summary per repo:

/repo-orch-graph    →  Claude reads each repo and writes summary.json
     ↓                  (one-time cost, no API key)
/repo-orch-triage   →  master pre-loads summary.json into a ~600-token
     ↓                  GRAPH_SUMMARY
specialist          →  reads GRAPH_SUMMARY first, targeted file reads
                       only for gaps

This entire flow runs inside the Claude Code session — no Python, no API key, no external service. If no summary exists, the plugin degrades gracefully to direct file reads.

On large workspaces this is the difference between "feels expensive" and "feels free." On small workspaces it's not worth the setup; the plugin lets you skip it.

7. Headless mode for CI

For teams that want triage to happen automatically when a Jira ticket or GitHub issue is filed, RepoOrch exposes a headless entry point via the Anthropic Agent SDK:

import { runTriage } from '.claude/plugins/repo-orchestrator/automation/repo-orch-triage_runner.mjs';

// In a GitHub/Jira webhook handler:
const plan = await runTriage({
  ticket: issue.body,
  workspaceRoot: '/path/to/your/workspace',
});

await postComment(issue.number, plan);

This runs in permissionMode: "plan" — same read-only, propose-only constraints as the interactive flow. The output is the same change-plan document, posted as a comment on the source ticket.

What I'd build next

A few directions I'm exploring for v0.4 and beyond:

Confidence-weighted plans. The aggregate confidence formula already lives in skills/routing/SKILL.md — surface it more prominently so devs can sort risks by uncertainty, not just severity.
Graph-aware deliberation. Today the mailbox is fully connected. For 10+ repo workspaces, routing the mailbox along actual service-dependency edges would cut deliberation overhead.
An execute mode behind an explicit consent prompt. Still propose-by-default, but with a guarded path to apply the plan repo-by-repo with diff approval.

Try it

# Add the marketplace (one time)
/plugin marketplace add architonixlabs/RepoOrch

# Install the plugin
/plugin install repo-orchestrator@repo-orchestrator

Then run /repo-orch-setup in any workspace that has 2+ git repos as immediate subdirectories.

Source, issues, and discussions: github.com/architonixlabs/RepoOrch

If RepoOrch saves you a single hour of multi-repo triage, a GitHub star is how I know to keep building. And if you try it and it breaks — file an issue, I'll respond. v0.3 just shipped a ten-fix security hardening pass; v0.4 is being shaped by feedback like yours.