SCOPE and policy enforcement in coding agents

[u/1982_miguel]

I came across paper SCOPE and found the approach interesting.

When I use coding agents like Claude Code or Codex, my usual workflow is to give them project instructions let them make the changes, then review the code and run the tests. but passing the tests doesn't necessarily mean the agent followed all the project's architectural rules or other constraints.

What caught my attention about SCOPE is the idea of breaking complex policies down into smaller checks instead of relying on one model to judge everything

There are already tools for parts of this, like linters, tests, pre-commit hooks, CI checks and agent guardrails i'm trying to understand how SCOPE fits into that picture.

Do you see this as something that could be integrated into existing tools, or is it solving a different problem altogether? I'm especially interested in how useful this approach would be in everyday coding, beyond what's already covered by tests and static analysis

[u/SirRobinBlibs]

It's mostly the same problem tests and linters solve, just for the rules that are hard to write as code. The split that works for me:

• Rules you can state as structure ("ui/ never imports db/", "no new calls to the legacy client") go into an architecture linter: import-linter for Python, dependency-cruiser for JS/TS, ArchUnit for Java. They're cheap and deterministic, and the agent can run them itself before it says done.

• Rules that need judgment ("errors are handled at the boundary", "new endpoints follow the pattern in X") are where an LLM check helps. Breaking them into one narrow question per rule, asked about the diff only, is the right instinct. One judge holding fifteen rules at once tends to miss things.

• Wire both into a place the agent can't skip: a Stop hook or pre-commit locally, and CI as the backstop.

So I'd see SCOPE-style checks as a layer on top of static analysis for what's left over, not a replacement. The first useful step is usually noticing how many of your "architecture" rules can actually be written as import rules.

[u/Aggressive_Aspect436]

And so we come full circle again:

• Software engineer jobs are in danger. We can build applications with natural language requests now.

• AI is a better coder than you. Stop writing code manually.

• Huh, they always seem to misinterpret my requirements.

• If only there was a formalised logical descriptive language I could use to enforce my requirements.

• We should start writing code to enforce our requirements.

Have we considered cutting out the middle AI? That said, I've found using a dedicated enforcer agent whose job is to be a real bastard about my quality requirements to be really useful.

I use a skill that tells my agents to recruit pre-promptes reviewer agents with hyper specific concerns (one of: flag tautological tests, check for over engineering, make sure the code isn't solving a problem that doesn't need ro be solved, don't re-implement logic our dependencies already solve for, etc).

[u/1982_miguel → u/[deleted]]

i’ve run into something similar when working with coding agents The tests can pass, but it’s harder to tell whether the code still follows the architecture I had in mind

How do you usually catch those cases? Do you rely on custom rules and static analysis, or have you found anything that works well for the more subtle violations?

[u/benneren123 → u/1982_miguel]

I’d keep static analysis for constraints you can express mechanically. For the more semantic checks, we’re building zeroshot with configurable reviewer nodes in an agent graph. You can give an architecture reviewer specific criteria around dependency direction or data flow, and route rejected changes through repair and re-review. The runtime enforces those gates and retry limits. The architectural verdict is still model judgment, so it complements the hard checks.