Introducing OPS: The System That Makes AI Write Code Like a Senior Engineer

AI is good at writing code. AI is terrible at discipline.

Every model — Claude, GPT, Codex — will produce working code that violates your project's conventions, ignores your file structure, skips error handling, hardcodes values, dumps everything in one file, and forgets tests. You can ask nicely in system prompts. The model ignores it half the time.

The bigger the task, the more the model drifts from your instructions.

Today we're introducing OPS — the Orbit Protocol Server. A real-time code quality system composed of 17 specialized subsystems that enforce your project's rules programmatically, the same way ESLint fails your build if you use the wrong quote character. Except OPS covers everything ESLint doesn't.

The problem with system prompts

Here's what most teams do today:

claude.md says "don't add comments"         → AI ignores it sometimes
claude.md says "use barrel exports"          → AI forgets in file 4 of 10
claude.md says "max 200 lines per file"      → AI writes 500 lines anyway
claude.md says "always handle errors"        → AI skips try/catch when lazy
claude.md says "colocate tests"              → AI puts tests in /tests folder

System prompts are suggestions. Models treat them as guidelines, not laws. There is no mechanism in any model architecture that guarantees adherence to prompt instructions. The context window fills, attention shifts, and your carefully written conventions get ignored.

This is not a model problem. Better models will still drift. The solution is not a better prompt. The solution is enforcement.

What OPS does

OPS runs as a background process alongside your language server. It watches every file change in real-time and evaluates a comprehensive rule set against your entire project — not just individual files. When an AI agent writes code that violates a rule, OPS produces a diagnostic. The agent reads that diagnostic and must fix it before proceeding. Not because you asked. Because the system won't let it continue with violations.

The result: every line of AI-generated code meets your project's standards before it reaches your codebase.

OPS is deterministic. It does not use AI to evaluate code quality. It runs programmatic checks — the same check produces the same result every time. This is intentional. You do not want a probabilistic system deciding whether your code meets standards.

17 subsystems, one system

OPS is not a single tool. It is a coordinated system of 17 subsystems, each handling a specific responsibility. They work together in real-time, share data, and produce a unified view of your project's health.

Core engine

Perihelion is the rule evaluation engine at the heart of OPS. Every rule, every file, every change runs through Perihelion. It evaluates in under 100ms, parallelized across all rules. Everything else in OPS either feeds data to Perihelion or acts on its output.

Burn is the auto-fix engine. It takes Perihelion's diagnostics and applies programmatic corrections — creates barrel exports, wraps try/catch, reorders imports, extracts hardcoded values to environment variables. One command fixes everything that can be fixed automatically.

Ring manages rule configuration. It loads your project's rule file, handles presets for different frameworks, and supports fully custom rules. You control what gets enforced and at what severity.

Gravity is the file watcher that holds everything together. It detects changes, triggers Perihelion re-evaluation, and debounces rapid saves. The fundamental loop: save a file, get instant feedback.

Intelligence

Nebula scans your codebase on first open and detects your existing patterns — what export style you use, where your tests live, how you name files, what your average file length is. It then generates rules from what it discovers. Zero configuration. OPS looks at what you already do and makes it the law.

Corona builds and queries the dependency graph. It detects circular dependencies, dead code, and architectural layer violations. Not just within a file — across your entire project.

Trajectory predicts the impact of changes. Given a set of modified files, it traces the dependency graph to show every file that will break and every test that needs to run. Before you find out the hard way.

Flux provides semantic diffs. Instead of "47 lines added, 12 removed," it tells you: new function added, type signature changed, API shape modified, database migration needed. Meaningful changes, not line counts.

Safety

Eclipse prevents regressions. It hashes code regions where bugs were fixed. If any future change touches a known fix, Eclipse flags it immediately. Nothing passes through the shadow of a previous bug fix.

Reentry creates file snapshots before agent tasks. If something goes wrong, one command restores to a clean state. A safety net for autonomous work.

Shield handles security scanning — hardcoded secrets, eval usage, XSS patterns, SQL injection, CORS misconfiguration, dependency vulnerabilities. Real-time, on every save.

Atmosphere validates your environment. It checks that every referenced environment variable exists in your .env files, detects config drift between environments, and validates types. Your code references process.env.DATABASE_URL but it's not in .env.local? Atmosphere catches it before runtime does.

Verification

Apogee calculates a confidence score (0-100) after every agent task based on how many checks passed. Teams can set auto-merge thresholds — code above 90 gets merged automatically, below 70 requires human review.

Horizon predicts CI pass/fail before you push. It runs typecheck, lint, test, and build locally and tells you the result. A green or red badge in your status bar. Nobody pushes broken code.

Probe enforces test discipline. Tests exist for exported functions. No empty test bodies. No weakened assertions. No deleted tests. If TDD is enabled, tests must be written before implementation.

Debris tracks dependency and bundle health. Outdated packages, unused dependencies, duplicate libraries serving the same purpose, known CVEs. Every npm install gets scrutinized.

Learning

Drift watches how developers correct agent output over time. When the same correction happens repeatedly — the developer keeps removing console.logs the agent adds, or reformatting the same import pattern — Drift suggests a new rule. OPS gets smarter the more you use it.

Why this is different from ESLint

ESLint checks code syntax and style within individual files. OPS checks everything else across your entire project.

ESLint knows that a variable is unused. OPS knows that src/features/auth/login.ts exists but src/features/auth/index.ts doesn't — a cross-file structural rule that no linter catches.

ESLint doesn't know that you have three date libraries in package.json. OPS does.

ESLint doesn't know that your async function in api.ts will cause CI to fail because your pipeline runs strict error-handling checks. OPS predicts it before you push.

They're complementary. ESLint handles syntax. OPS handles systems.

Built for AI, useful for everyone

OPS exists because AI models have specific, predictable bad habits that human developers don't typically share:

• Function dumping — AI puts 10 functions in one file. OPS enforces a maximum and forces separation.
• God files — AI creates utils.ts with 500 lines. OPS enforces file length limits.
• Type laziness — AI defaults to any when it can't figure out the type. OPS rejects any entirely.
• Obvious comments — AI writes // increment counter above counter++. OPS flags comments that restate the code.
• Nested ternaries — AI writes ternaries three levels deep that no human can read. OPS forces if/else conversion.
• Skipped error handling — AI omits try/catch to save tokens. OPS requires it on every async function.
• Hardcoded values — AI puts URLs, ports, and keys directly in code. OPS extracts them to environment variables.
• Duplicate logic — AI rewrites utility functions instead of importing ones that already exist. OPS detects duplication against your existing codebase.

These rules don't exist in ESLint because ESLint was designed for humans. OPS is the first system designed to discipline AI code output — and the enforcement benefits human-written code equally.

Zero configuration to start

On first run, Nebula scans your codebase and generates rules from what it finds:

ops nebula

Scanning 234 files...

Detected patterns:
  Export style:       barrel (87% of directories have index.ts)
  Test location:      colocated (92% of tests next to source)
  File naming:        kebab-case (95% match)
  Component naming:   PascalCase (100% match)
  Avg file length:    180 lines
  Error handling:     try/catch in 60% of async functions
  Framework:          Next.js 15

Generated: .orbit/rules.json (41 rules, 38 auto-detected, 3 defaults)

No manual rule writing. OPS learns your conventions and enforces them. Customize after if you want — every rule has severity levels, exceptions, and auto-fix options.

The enforcement loop

The core cycle runs on every file save:

1. Agent writes code and saves the file
2. Gravity detects the change instantly
3. Perihelion evaluates all rules in parallel (< 100ms)
4. Diagnostics appear in the editor UI and the agent's tool output simultaneously
5. Burn applies auto-fixes, or the agent fixes manually
6. Gravity detects the fix, Perihelion re-evaluates
7. Clean? Move to the next file. Still violations? Fix again (max 3 attempts, then escalate to human)

The developer and the agent see the same violations, at the same time, from the same source. One system, two interfaces. No divergence.

What's coming

OPS is in active development and approaching its first public release. We're building toward a system where any team — regardless of which AI coding tool they use — can enforce deterministic quality standards on every line of code their agents produce.

If you've ever watched an AI agent ignore your conventions on the fourth file of a ten-file task, you know why this matters.

We'll be sharing more in the coming weeks. Follow the development at github.com/Recusive/OPS.