Emerging Ideas for AI-Assisted Software EngineeringEight field guides from Alpha Compose
Alpha ComposeField guideAll articles

Dirge + nREPL, assessed for my current workflow

Put the agent
inside the loop.

Dirge's nREPL plugin gives a coding agent a persistent connection to a running Clojure system. That can shorten the edit, reload, inspect, test cycle. It is not a strong reason to abandon Codex.

RecommendationUse Dirge as a REPL specialist beside Codex.

Keep Codex for intent, issue coordination, broad research, browser evidence, review, and delivery. Trial Dirge where runtime feedback is the bottleneck.

dirge - project.clj

connect .nrepl-port -> session 8af...

edit src/app/orders.clj

eval (require 'app.orders :reload)

probe (reserve-stock db order)

test (run-tests 'app.orders-test)

live state is evidence, not the final gate
261GitHub stars
26forks
1,989crate downloads
90published versions

Snapshot: 3 August 2026. Downloads include automation and are not unique users. These numbers show interest and velocity, not maturity.

01 / What changes

A live runtime becomes a first-class agent tool

Clojure's REPL is an interface to the running program, not merely a faster shell command. Dirge places that interface in the model's tool list and adds just enough connection management to sustain a debugging conversation.

01

Connect once

At startup the plugin reads .nrepl-port, opens a TCP connection, clones an nREPL session, and keeps that session alive across evaluations.

02

Edit with structure

Dirge can navigate .clj, .cljs, .cljc, .edn, and .bb with tree-sitter tools, surface clojure-lsp diagnostics, and reject syntactically broken file writes.

03

Evaluate reality

The model calls nrepl_eval to reload namespaces, exercise functions, inspect vars, run tests, and read value, stdout, stderr, and current namespace.

04

Keep the loop bounded

A per-eval timeout defaults to 120 seconds. Dirge sends an interrupt when it expires and reconnects once if the socket has gone stale.

02 / Clojure and ClojureScript

One simple CLJ path. One conditional CLJS path.

The plugin's README compresses both languages into one tool description. Operationally they need different startup contracts.

CLJGood fit now

Use the REPL as a diagnostic seam

  1. Start the project's normal nREPL so it writes .nrepl-port.
  2. Launch Dirge from the project root and confirm /nrepl-status.
  3. Ask for one vertical change and require the edited namespace with :reload.
  4. Probe the smallest useful function or live component state.
  5. Run focused tests through the REPL, then the clean full suite through the project command.

Best targets: stateful services, data transformations, lifecycle systems, slow-starting JVM projects, and bugs whose cause is visible only in a running component graph.

CLJSUseful with setup

Select the runtime before believing an eval

  1. Start shadow-cljs watch app and connect the browser or Node runtime.
  2. Read the nREPL port from target/shadow-cljs/nrepl.port.
  3. Connect manually with /nrepl-connect 127.0.0.1 PORT.
  4. Evaluate (shadow.cljs.devtools.api/nrepl-select :app).
  5. Only then reload and probe CLJS. Keep browser checks and release builds as separate gates.

For .cljc, test both semantics. A successful JVM eval says nothing about the selected JavaScript runtime, macro phase, Closure compilation, or browser behavior.

1Read and edit

Source remains the durable truth.

→
2Reload and probe

Fast runtime evidence.

→
3Focused tests

Repeatable local contract.

→
4Clean process

Detect leaked REPL state.

→
5Browser / deploy

Prove the real boundary.

03 / Dirge versus my current Codex workflow

Dirge wins a loop. Codex still owns the wider job.

This is not a generic benchmark. It compares the tools against the workflow I already use: documented intent, GitHub issue contracts, claimed tasks, TDD, browser evidence, and deployment gates.

ConcernDirgeCodex todayCall

Tight CLJ feedback

Direct, persistent nREPL connection inside the agent. This is its clearest advantage.

Your current clj-nrepl-eval command starts a small client process per call, while the REPL itself still holds state.

Dirge

CLJS setup

Works after connecting to a CLJS-capable nREPL and selecting a running build, but it does not discover or select that environment for you.

clojure-mcp-light detects shadow and other environments; your existing scripts can encode project-specific selection.

Codex today

Planning and issue work

Has an internal SQLite issue board, phased plans, goals, worktrees, and persistent project memory.

Already fits your documentation-backed grilling, GitHub issue graph, exclusive claims, task coordination, and review flow.

Codex

Web and app evidence

Terminal-first. Web search and MCP exist, but there is no equivalent integrated visual workspace.

Browser inspection, Chrome state, desktop control, connectors, visual artifacts, review panes, and automations are one workflow.

Codex

Model economics

Strong multi-provider and local-model routing. Main loop, critic, escalation, summary, and subagents can use different models.

Tighter OpenAI model integration and subscription surfaces, without managing a matrix of provider keys and bills.

Depends

Extension model

Janet hooks can reach directly into the agent lifecycle and add tools or commands in-process.

AGENTS.md, skills, plugins, hooks, MCP, and connectors are broader and easier to share across non-terminal work.

Different

Durable knowledge

SQLite-backed project and global memory, FTS5 retrieval, session checkpoints, and post-session curation.

Repo-owned guidance and issues remain inspectable, reviewable, and portable; Codex also provides memories and resumable tasks.

Trade-off

04 / Fit with the rest of the series

One stack, distinct responsibilities

Dirge belongs close to code and runtime state. The other tools should continue to own intent, application contracts, fleet state, human review, and learning. Collapsing those concerns into Dirge would duplicate the control planes this series is trying to clarify.

  1. 01 / CaptureVoice + human intent

    OpenSuperWhisper makes the request cheap to express.

  2. 02 / ShapePocock + Wayfinder

    Resolve decisions and expose the planning frontier.

  3. 03 / ContractMycelium

    Name the cell, schemas, and allowed runtime edges.

  4. 04 / CoordinateCodex or FirstMate

    Own issues, claims, isolation, and worker state.

  5. 05 / ExecuteDirge + nREPL

    Edit one bounded slice and interrogate the live system.

  6. 06 / ProveTests + instrumentation

    Gate delivery and decide whether the workflow improved.

Input layer

OpenSuperWhisper

Voice can capture a bug, observation, or experiment quickly. It should feed the grill or issue-writing step, not bypass it with a long unreviewed prompt sent straight to a code-executing agent.

Handoff: transcript -> reviewed intent
Decision layer

Pocock + Wayfinder

Use discovery, prototypes, and the decision graph before Dirge. Once the unresolved frontier is small, pass a vertical issue or specification downstream. Dirge should execute a decision, not silently make product choices while probing the REPL.

Handoff: resolved node -> bounded task
Application layer

Mycelium

Mycelium's manifest can identify the cell contract and valid connections that a worker may change. Dirge then becomes a strong cell-level implementer: read the projected brief, edit locally, and use nREPL probes to test the contract against a running graph.

Handoff: cell brief -> runtime evidence
Fleet layer

FirstMate + treehouse + No Mistakes

FirstMate could treat Dirge as one worker backend, with an adapter translating a durable brief into a headless or MCP delegation. Treehouse supplies isolation and No Mistakes remains the delivery gate. This is a possible composition, not a native integration.

Rule: one worktree, one runtime, one port
Control and review

My current Codex workflow

Codex should retain documentation-backed grilling, GitHub issue contracts, exclusive claims, browser verification, and diff review. Dirge can sit behind it as an explicit implementation delegate. Codex still reruns the acceptance evidence itself.

Handoff: issue -> Dirge diff -> Codex review
Learning layer

The workflow that learns

Compare Dirge and the existing CLI bridge with the same task class and model. Record nREPL calls, time to first useful observation, repair notices, retries, clean-suite failures, human corrections, cost, and escaped defects. Optimize outcomes, not eval volume.

Handoff: trace -> one bounded workflow change
Portable workflow layer

Skills + Babashka scripts

Keep the durable method harness-agnostic where practical. A skill can describe reload, probe, test, and clean-process gates while a Babashka script hides project mechanics. The Janet plugin is then a faster adapter, not the only place the workflow exists.

Baseline: clj-nrepl-eval remains available
Human review layer

HTML and Lavish artifacts

Dirge's terminal transcript is useful machine evidence but a poor review surface. Codex or Lavish can turn a design choice, trace comparison, or architecture change into a visual artifact the human can annotate before the next implementation pass.

Handoff: evidence -> inspectable decision surface

05 / Outside Clojure

The nREPL advantage disappears. The harness may remain interesting.

In TypeScript, Python, Go, Rust, Java, C, C++, Ruby, Elixir, or Bash, evaluate Dirge for its harness, not this plugin.

Use case

Cheap main model, strong reviewer

Route routine work to a lower-cost or local model and reserve a stronger provider for escalation or review.

Use case

Long-lived local repository

Let project memory retain build commands, pitfalls, and prior mistakes without growing one permanent Markdown prompt.

Use case

Terminal-dense parallel work

Its low footprint, worktree commands, headless mode, and goal gate suit many bounded local runs.

Avoid

Visual or connected work

Prefer Codex when the task needs browsers, desktop apps, Slack, Drive, rich artifacts, scheduled follow-up, or a polished review surface.

06 / Costs and failure modes

Small, sharp, young, and easy to over-trust

Dirge's attraction is mechanical closeness to the runtime. The same closeness magnifies stale-state and safety mistakes.

01

The plugin is deliberately small

It only discovers a root .nrepl-port. It has no clj, bb, Basilisp, or shadow environment detection, no formatter, no editor-style source position metadata, and no richer middleware operations.

02

CLJS is not automatic

A shadow-cljs nREPL begins in Clojure mode. The watch must be running, its JavaScript runtime must be connected, and the Dirge session must select the build before CLJS evaluation works.

03

Repair can conceal a bad form

The Janet matcher appends missing closing delimiters. It is not a full Clojure reader and ignores extra or mismatched closers, so a repair notice should trigger a source check, not quiet acceptance.

04

One session can carry stale state

Persistent vars are the point, but they can also let an eval pass against definitions that are not saved or no longer match a clean process. Reload, run tests, and periodically restart from zero.

05

nREPL is code execution

Keep it on localhost for development. Do not point an autonomous agent at a production REPL merely because the command accepts another host.

06

The project is moving very quickly

Dirge was created in May 2026 and had already published 90 crate versions by this research snapshot. Fast fixes are encouraging; compatibility churn and regressions are still realistic costs.

07 / What public usage says

Interesting early signal. Thin independent proof.

Search results can show attention and reported experience. They do not establish comparative quality, user retention, or production reliability.

Maintainer practice

The nREPL plugin is not a demo-only idea

Dmitri Sotnikov says it is the plugin he uses most. He describes using a stronger agent for planning and Dirge over MCP for implementation. This supports the hybrid pattern, but it remains first-party evidence.

Independent report

Fast issue response, with early bugs

One external user reported two bugs, including confusion after compaction. Both were fixed within hours, one with a regression test. That is evidence of responsive maintenance, not of mature stability.

Clojurians archive

Eleven direct mentions, mostly evaluation

The public archive shows people preparing comparisons with OpenCode and discussing harness-agnostic skills. It does not yet contain a body of independent reports about sustained Dirge or nREPL-plugin use.

Relevant comparison

The CLI nREPL pattern is already field-tested

The same archive contains concrete reports of agents using clj-nrepl-eval in monorepos, browser CLJS, and jank. Your existing approach therefore has stronger Clojure-specific community evidence than Dirge's new plugin today.

08 / Adoption plan

A two-week sidecar trial, not a migration

Do not port your full Codex workflow, global guidance, skills, and issue machinery before Dirge proves one narrower claim.

Week 0

Baseline

Pick ten recent, representative CLJ tasks. Record elapsed time, tool retries, REPL calls, full-suite result, human interventions, tokens, and cost.

Week 1

Dirge loop

Use Dirge only for five small REPL-heavy slices. Keep your current tests, GitHub issues, acceptance criteria, and Codex review unchanged.

Week 2

Hybrid loop

Let Codex shape and review work; use Dirge for implementation where a persistent live runtime matters. Do not change models mid-comparison.

Decision

Keep evidence

Adopt Dirge only if quality-adjusted cycle time improves. A faster green eval does not count if clean-process tests, CLJS behavior, or review effort get worse.

Primary metricQuality-adjusted cycle time
GuardrailClean full suite still passes
CLJS guardrailReal runtime and release build verified
Stop conditionNo clear gain after ten tasks

Sources

Repository facts separated from interpretation

Research snapshot: 3 August 2026.