DEV Community: crovia

Git tells you what changed. Causari tells you why.

crovia — Wed, 08 Jul 2026 18:56:48 +0000

AI coding agents are becoming good enough to touch real codebases.

They can refactor files, write tests, change architecture, move logic around, and sometimes modify more code in ten minutes than a human would in an afternoon.

That is powerful.

But it creates a new debugging problem.

Git can tell you what changed.

When an AI agent was involved, you often need to know something deeper:

Why did this change happen?
Which prompt caused this line?
Which model produced it?
What files did the agent read before writing it?
What later changes depended on this agent action?

That is the problem I wanted to solve with Causari.

Causari is a local CLI for intent-addressable code.

It records AI agent actions as causal events: prompts, models, reads, writes, diffs, reasoning, cost, and relationships between actions.

The goal is simple:

Git tracks bytes. Causari tracks intent and causality.

Repository: https://github.com/croviatrust/causari

Website: https://causari.dev

The problem

When a human developer changes code, there is usually some context.

A commit message.

A pull request.

A ticket.

A discussion.

A design decision.

With AI coding agents, the workflow is different.

You ask something like this:

Refactor the auth flow and add JWT refresh logic.

The agent reads files, makes assumptions, writes code, maybe fixes tests, maybe changes something unrelated, then moves on.

At the end, you have a diff.

But the diff does not tell the full story.

A suspicious line appears in auth.ts.

Git can show when the line appeared.

But Git cannot answer:

which prompt produced this exact line?
what completion did it come from?
did the agent read the right files first?
was this part of the original request or an accidental side effect?
if I revert this, what downstream work am I also undoing?

That gap becomes bigger as agents become more autonomous.

The more work agents do, the more we need provenance.

Not only code provenance.

Intent provenance.

The idea: intent-addressable code

Causari treats an AI agent action as something that should be traceable.

Not just as a Git diff.

But as an event with cause and effect.

An event can include:

the prompt
the model
the files read
the files written
the diff
the reasoning or message
token and cost information
the causal relationship with previous and later events

So instead of only asking:

what changed in this file?

You can ask:

why does this line exist?

Example:

re why src/auth.ts:42

Or:

re trace src/auth.ts:42

Or:

re impact <event-id>

This is the core of Causari.

It is not trying to replace Git.

Git is still the source of truth for version control.

Causari sits next to it and answers a different question:

Git answers what changed.

Causari answers why the agent changed it.

Capturing provenance without trusting the agent

One thing I did not want was a system that only works if the AI agent politely reports what it did.

That is fragile.

Agents forget.

Tools differ.

IDE integrations are inconsistent.

Some agents expose hooks, others do not.

Some workflows happen through proxies, some through local tools, some through editors.

So Causari has multiple capture paths.

1. `re proxy`

Causari can run as a local OpenAI-compatible or Anthropic-compatible LLM proxy.

re proxy

Your agent sends requests through it.

Causari sees the prompt, completion, model, tokens, and cost as they pass through.

The request still goes to the provider.

The difference is that the interaction becomes part of a local causal ledger.

2. `re watch`

Causari can also watch the filesystem.

re watch

When files change, Causari records snapshots and diffs.

Then it tries to connect the code that appeared on disk with the completions captured through the proxy.

If a completion generated a block of code, and seconds later that same code appears in a file, that is a causal fingerprint.

The provenance is no longer only a self-report.

It is observed from two independent streams:

LLM traffic + filesystem changes

3. `re hook`

Where an agent exposes lifecycle hooks, Causari can capture more directly.

For example:

re hook claude-code

This allows native capture from the agent runtime when available.

So Causari can work in layers:

proxy capture
filesystem capture
native hook capture

The more signals available, the more precise the provenance becomes.

What you can ask Causari

Once actions are recorded, you can query the causal history.

Some examples:

re why src/auth.ts:42

Show what produced a specific line.

re trace src/auth.ts:42

Show the upstream causal chain behind that line.

re impact <event-id>

Show the downstream blast radius of an agent action.

re lens src/auth.ts

Render a file with per-line provenance annotations.

re find "JWT refactor"

Search prompts, messages, reasoning, and events.

re bisect --test "npm test"

Find which agent action broke the build.

re churn

Measure how much AI-generated code survived versus got rewritten.

re report --open

Generate a local report or dashboard.

This is the part I find most interesting.

With normal version control, the unit of analysis is usually the commit.

With AI agents, the more useful unit may be the agent action.

A single commit may contain 30 agent decisions.

Causari tries to make those decisions inspectable.

Why this matters

At small scale, this may feel like overkill.

If you ask an agent to write a small helper function, maybe you do not care about causal provenance.

But as soon as agents start making larger changes, the workflow changes.

Debugging regressions

A test breaks after many AI-assisted edits.

Instead of reading chat logs manually, you can ask which agent action introduced the break.

re bisect --test "npm test"

Reviewing AI-generated code

A reviewer sees a strange line.

Instead of asking "who wrote this?", they can ask:

re why path/to/file.ts:120

And inspect the prompt and context behind it.

Understanding downstream risk

Before reverting an AI action, you can ask:

re impact <event-id>

Because later changes may depend on that action.

Measuring wasted AI work

If an agent writes a lot of code that gets rewritten shortly after, that matters.

Not only because of cost.

Because it may reveal bad prompts, bad context, bad model choice, or bad workflow.

re churn

This makes AI coding work measurable in a way that normal Git history does not.

Local-first by design

Causari is built as a local developer tool.

The ledger lives in your repo under:

.causari/

The goal is not to send your code or prompts to a third-party dashboard.

The goal is to make the agent activity around your own codebase inspectable locally.

Causari is written in Rust and uses content addressing for events.

The repository describes it as:

intent-addressable code for AI agents

That phrase is important to me.

Because I do not think the future of AI coding is only "generate more code faster".

I think the next problem is:

Can we understand, verify, replay, and debug what the agent did?

Skills: turning verified work into reusable experience

Causari also has an experimental skill layer.

The idea is that completed, verified work can be distilled into signed reusable units.

re skill distill

A skill can contain the task, the steps, the files changed, and the outcome.

Then it can be exported:

re skill export <id>

And verified later:

re skill verify

This is still early, but the idea is important:

Agents should not repeat the same mistake forever.

If a repository already has a verified solution to a class of problem, the next agent should be able to recall that experience before acting.

Not as vague memory.

As signed, local, inspectable provenance.

A small example

Imagine this prompt:

Add JWT refresh logic that rotates tokens every 24 hours.

The agent modifies auth.py.

Later, you inspect a line:

re why auth.py:42

Causari can show that the line came from that prompt, which model produced it, and which event introduced it.

Then you can ask:

re trace auth.py:42

To see the upstream context.

Or:

re impact <event-id>

To see what later work depended on it.

That is the workflow I want:

not only code review,
but intent review.

What I am looking for feedback on

Causari is still young, and I would love feedback from developers who are using tools like:

Cursor
Claude Code
Cline
Windsurf
Aider
Continue
other agentic coding workflows

The main questions I am trying to answer:

Would you use provenance/debugging like this in your AI coding workflow?
Is "which prompt caused this line?" a problem you already feel?
Should this live mostly as a CLI, an IDE extension, an MCP server, or all of them?
Is the re proxy + re watch capture model practical enough for real developers?
What would make you trust or adopt a tool like this?

Closing thought

AI agents are starting to write and rewrite real software.

That means our tools need to evolve.

Git gave developers a way to track changes.

But AI-generated code needs another layer:

intent
causality
provenance
impact
replay

That is what I am trying to explore with Causari.

If this problem feels real to you, I would love your feedback.

What would you want from a tool like this before trusting it in a real codebase?

Repository: https://github.com/croviatrust/causari

Website: https://causari.dev

I built a GitHub Action that works with any stack — here's how

crovia — Fri, 29 May 2026 18:18:40 +0000

The problem

Every time I clone a repo, I have to figure out how to run it.

Go project? go test ./... — unless it uses make test
Node project? npm test — unless it uses pnpm or yarn or bun
Rust? cargo test. Python? Could be pytest, python -m unittest, or poetry run pytest.

This is fine for my own projects. But when I'm reviewing a PR, onboarding a new teammate, or setting up CI for a polyglot team, it becomes noise.

What I built

rex is a single Go binary that detects your project's stack and runs the right command. No config file. No reading the README.

git clone https://github.com/someone/unknown-project
cd unknown-project
rex test   # it just works

How it works under the hood

The detection logic is surprisingly simple — and that's the point.

Step 1: File scanning

rex walks your project root and looks for known files:

File	Stack	Package manager
`go.mod`	Go	go modules
`package.json` + `pnpm-lock.yaml`	Node	pnpm
`Cargo.toml`	Rust	cargo
`pyproject.toml` + `uv.lock`	Python	uv
`pom.xml`	Java	Maven
`build.gradle`	Java	Gradle
`Gemfile`	Ruby	bundler
`composer.json`	PHP	composer
`mix.exs`	Elixir	mix
`build.zig`	Zig	zig

This happens in <50ms because it's just os.Stat calls — no network, no parsing heavy files.

Step 2: Command mapping

Once the stack is known, rex maps standard verbs to the right tool:

// Go
test  -> "go test ./..."
run   -> "go run ./cmd/server"
build -> "go build ./..."

// Node (pnpm)
test  -> "pnpm test"
run   -> "pnpm run dev"
build -> "pnpm run build"

Step 3: Priority chain (the smart part)

rex doesn't blindly guess. It respects what's already there:

1. Justfile / Makefile (task runner overrides everything)
2. package.json scripts / Cargo.toml / go.mod (ecosystem native)
3. Language heuristics (fallback)

If a Makefile defines a test target, rex test runs make test — even in a Go project.

The GitHub Action

The most interesting part is how this became a GitHub Action.

Instead of requiring Go to be installed in the runner, the action downloads the correct binary directly from the release page:

- uses: rexrun-dev/rex@v0.4.0
  with:
    command: test

This single step replaces 10+ lines of stack-specific YAML. Works for all 12 supported languages.

Why composite actions?

I used GitHub's composite action type instead of Docker. Why?

Faster: no container startup
Smaller: no image to pull
Portable: works on any runner (ubuntu, macOS, Windows)

The trade-off? The install script has to handle OS/arch detection:

OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m)
case "$ARCH" in
  x86_64) ARCH="amd64" ;;
  aarch64|arm64) ARCH="arm64" ;;
esac
URL="https://github.com/rexrun-dev/rex/releases/download/${VERSION}/rex_${VERSION#v}_${OS}_${ARCH}.tar.gz"
curl -sL "$URL" | tar xz -C /usr/local/bin rex

Watch mode

A recent addition: rex watch polls the filesystem and re-runs your command on change.

rex watch test   # re-run tests when files change
rex watch build  # re-build on change

It's not using inotify or fsnotify — just a lightweight polling loop with hash-based change detection. This makes it portable across all platforms without CGO or platform-specific dependencies.

CI generator

rex ci generates a GitHub Actions workflow file customized for your detected stack:

$ rex ci
✓ created .github/workflows/ci.yml (go project)

The generated YAML uses the official setup actions for each language (setup-go, setup-node, setup-python, etc.) and runs the correct test command.

Numbers

Binary size: ~3.5 MB
Startup time: <50ms
Languages supported: 12
Lines of Go: ~2,000
Zero runtime dependencies

Try it

brew tap rexrun-dev/tap && brew install rex
# or
go install rexrun.dev/rex/cmd/rex@latest

Or try the interactive playground at rexrun.dev — paste any GitHub repo URL and see what rex would detect.

GitHub: github.com/rexrun-dev/rex
Marketplace: github.com/marketplace/actions/rex-universal-project-runner

I built a CLI that eliminates README reading forever

crovia — Thu, 21 May 2026 16:02:26 +0000

The problem

Every developer knows this pain:

Clone a repo
Want to run the tests
Open the README
Scroll... scroll... find a "Development" section... maybe
Figure out it's pnpm test (not npm test, not yarn test)
Run it wrong anyway because you needed pnpm install first

Multiply this by every repo you touch. Every PR you review. Every onboarding.

I got tired of it.

The solution: rex

git clone https://github.com/some/repo
cd repo
rex test

That's it. Rex looks at your project files, detects the stack, and runs the correct command. No config. No setup. No reading anything.

How it works

Rex reads files in your project root:

File found	Stack detected	`rex test` runs
`go.mod`	Go	`go test ./...`
`package.json` + `pnpm-lock.yaml`	Node + pnpm	`pnpm test`
`Cargo.toml`	Rust	`cargo test`
`pyproject.toml` + `uv.lock`	Python + uv	`uv run pytest`
`composer.json` + `artisan`	PHP + Laravel	`php artisan test`
`Gemfile` + `app/`	Ruby + Rails	`bundle exec rails test`
`pom.xml`	Java + Maven	`mvn test`
`build.gradle`	Java + Gradle	`./gradlew test`
`build.zig`	Zig	`zig build test`
`mix.exs`	Elixir	`mix test`
`Makefile`	Make	`make test`
`Justfile`	Just	`just test`

12 ecosystems. It also detects which package manager you use by looking at lockfiles.

Demo

Watch the video demo

$ cd my-go-project/
$ rex

  my-go-project

  stack  go

  commands
    rex test   go test ./...
    rex run    go run ./cmd/server
    rex build  go build ./...
    rex deps   go mod download
    rex fmt    gofmt -w .
    rex lint   go vet ./...

$ rex test
> go test ./...
ok   github.com/example/app   1.2s

The > arrow always shows exactly what rex will run. Full transparency.

All the verbs

Command	What it does
`rex test`	Run tests
`rex run`	Start the app / dev server
`rex build`	Build the project
`rex deps`	Install dependencies
`rex clean`	Remove build artifacts
`rex fresh`	clean, deps, build in sequence
`rex fmt`	Format code
`rex lint`	Lint code
`rex clone <url>`	Clone + detect + install deps in one command
`rex init`	Generate rex.toml for your team
`rex doctor`	Diagnose environment issues

Killer feature: rex clone

rex clone https://github.com/someone/project
# cloning...
# detected: node + pnpm
# deps: pnpm install
# ready! cd project && rex run

From URL to working project in one command. No README needed.

Monorepo support

Rex auto-detects monorepos (packages/, apps/, services/):

$ rex

  my-monorepo (monorepo)

  workspace  3 sub-projects detected

    packages/api         node + pnpm
    packages/web         node + pnpm
    services/auth        go

Team workflow: rex init

rex init
# created rex.toml (go project)

Generates a rex.toml from detected commands. Commit it. Now every teammate runs the same commands without asking.

.env loading

Rex automatically loads .env files before running commands. No extra tools needed.

Why I built this

I maintain projects across Go, Node, Python, and Rust. I context-switch between repos dozens of times per day. The cognitive load of remembering pnpm test vs go test ./... vs cargo test is small individually, but it adds up.

Rex makes every repo feel the same:

rex test   # always works
rex run    # always works
rex build  # always works

It's the muscle memory tax I no longer pay.

Technical details

Single binary, no runtime, no dependencies
Written in Go, cross-platform
Less than 50ms startup, faster than your shell prompt
Zero network calls, fully offline
Correct exit codes, works in CI
Shell completions for bash, zsh, fish
Apache 2.0 license
Mentioned in Awesome Go

Install

# Homebrew (macOS/Linux)
brew tap rexrun-dev/tap && brew install rex

# Go
go install rexrun.dev/rex/cmd/rex@latest

Or grab a binary from GitHub Releases.

DEV Community: crovia

Git tells you what changed. Causari tells you why.

The problem

The idea: intent-addressable code

Capturing provenance without trusting the agent

1. re proxy

2. re watch

3. re hook

What you can ask Causari

Why this matters

Debugging regressions

Reviewing AI-generated code

Understanding downstream risk

Measuring wasted AI work

Local-first by design

Skills: turning verified work into reusable experience

A small example

What I am looking for feedback on

Closing thought

I built a GitHub Action that works with any stack — here's how

The problem

What I built

How it works under the hood

Step 1: File scanning

Step 2: Command mapping

Step 3: Priority chain (the smart part)

The GitHub Action

Why composite actions?

Watch mode

CI generator

Numbers

Try it

I built a CLI that eliminates README reading forever

The problem

The solution: rex

How it works

Demo

All the verbs

Killer feature: rex clone

Monorepo support

Team workflow: rex init

.env loading

Why I built this

Technical details

Install

Links

1. `re proxy`

2. `re watch`

3. `re hook`