Skip to content

Introducing Erode

You know how it goes. A frontend calls a backend it should not, a shared library creeps into everything, and nobody catches it because each PR looked fine on its own. Six months later you are debugging latency across services that were never supposed to talk to each other.

Someone draws a diagram of the system. It is useful for two weeks, then it rots because updating it means opening some other tool and doing a chore nobody asked for.

I kept running into this, which is why I built Erode.

Erode checks every code change against a model of your system. If a change introduces a dependency that is not declared, it flags it. It does not block merges by default. It just makes the drift visible while it is still one PR and not a six-month cleanup.

The model can be LikeC4 or Structurizr. All Erode needs is nodes and connections. It does not care which format or framework defines them.

Erode runs a multi-stage AI pipeline on the diff:

  1. Component resolution identifies which architecture component the changed code belongs to.
  2. Dependency scan extracts new dependency signals from the diff.
  3. Drift analysis compares those signals against the declared model and reports violations.

The result is a clear finding explaining what drifted and why it matters.

A violation is not necessarily a problem. Software evolves. What matters is that the change is visible and the decision to keep it or fix it is conscious.

The fastest way to try Erode is with the playground repository. Fork it, add your API key, and open a PR that introduces an undeclared dependency.

For your own project, add the GitHub Action or run the CLI directly:

Terminal window
npx @erode-app/cli analyze ./model --url https://github.com/org/repo/pull/42

See the getting started guide for setup instructions including CI integration with GitHub Actions, GitLab CI, and Bitbucket Pipelines.