Your agents don’t read your conventions. They skip your linters, ignore your formatters, and commit code that fails CI. I’ve lived this frustration — watching an AI rewrite half my codebase and then push code that fails on the simplest lint check.
Why DevRail? Because every team eventually builds its own tooling stack. Linters, formatters, security scanners, test runners — installed differently on every developer’s machine, pinned to different versions in CI, and completely invisible to the AI agent that just rewrote half your codebase.
The result is predictable. Code that passes locally fails in CI. An agent commits unformatted code because it doesn’t know your project uses shfmt. A new hire spends a day installing tools that should have been one command. Environment drift compounds over time, and the response is always the same: more documentation that nobody reads, more onboarding steps that go stale, more “works on my machine.”
The root cause is not carelessness. It is the absence of a universal contract – a single interface that produces identical results regardless of who (or what) runs it.
What DevRail Provides #
DevRail gives you that contract with three components:
- One Makefile — Public targets (
make lint,make format,make test,make security,make scan,make check) delegate to a Docker container. No tools run on the host. - One container — The dev-toolchain image packages every linter, formatter, security scanner, and test runner for all supported languages. Pin a version tag and forget about tool management.
- One config file —
.devrail.ymldeclares which languages your project uses. The Makefile reads it and runs only the relevant tools.
The outcome: make check produces the same results on your laptop, in CI, and inside an AI agent’s sandbox. If it passes, the code meets the standard. If it fails, the output tells you exactly what to fix.
Agent-Ready by Default #
This is what excites me most. DevRail was built with AI coding agents in mind. The template repositories ship with instruction files for Claude Code (CLAUDE.md), Cursor (.cursorrules), OpenCode, and a generic AGENTS.md. Each file inlines the critical rules so agents follow the standard even if they don’t read cross-file references.
The shortest path to agent compliance:
This project follows DevRail development standards. Read DEVELOPMENT.md before making changes. Run
make checkbefore marking any task complete.
Agents that follow file references get the full picture. Agents that don’t still get the minimum viable rules. Either way, make check is the gate.
What’s in the Box #
Eight language ecosystems supported: Python, Bash, Terraform, Ansible, Ruby, Go, JavaScript/TypeScript, and Rust. Each comes with opinionated defaults for linting, formatting, security scanning, and testing.
Universal tools — Trivy, gitleaks, and git-cliff — run for every project regardless of language.
The Bottom Line #
DevRail isn’t about adding more tools. It’s about removing the guesswork. One command. One gate. Every agent, every developer, and every CI pipeline plays by the same rules.
If you’re deploying AI agents in your workflow — or even just standardizing a human team’s tooling — DevRail is worth a look.
- Quick start guide
- Retrofit guide – add DevRail to an existing repository
- Standards reference – per-language tooling and configuration
I’m already using it on a few projects. The difference in CI pass rates and agent-mediated code quality is noticeable.