GitHub launches Sentinel to automate pre-commit architectural debt detection for microservices.
What pre-commit architectural validation is for
Microservices accumulate architectural debt quietly. A service that once owned a clear boundary starts calling three peers for data it should own. A shared library becomes a hidden coupling surface. A domain rule lives in two places and drifts. Reviews catch some of that when someone still remembers the intended shape of the system. Most of the time the change looks small, the tests pass, and the design rot ships with the feature.
GitHub Sentinel targets that gap. It is an AI-driven check meant to run before commit, so architectural problems surface while the change is still local and cheap to fix. The pitch is not “better code style.” It is automated detection of structural debt in service-oriented codebases—boundaries, dependency direction, and patterns that erode modularity—before those choices harden in main.
Where it fits in a microservices workflow
Pre-commit is a useful choke point because it sits between intent and shared history. Lint and unit tests already own formatting, types, and behavior at the unit level. Architectural validation asks different questions: does this change reverse a dependency that was supposed to flow one way? Does a new call path cross a bounded context that was meant to stay isolated? Is a temporary shortcut becoming a permanent edge in the service graph?
For teams that already use CI to enforce contracts and ownership rules, a local, pre-commit signal reduces the loop. Waiting for a pipeline to flag a boundary violation means context has cooled and the fix competes with the next ticket. Catching the same class of issue on the developer machine keeps the correction inside the same edit session that introduced it.
What to enforce first
Tools like this only help if the rules match how the system is actually supposed to be structured. Start with constraints that are stable and expensive to reverse:
- Allowed dependency directions between services and shared packages
- Forbidden cross-domain imports or direct data-store access outside the owning service
- Limits on new synchronous call edges where async or event-driven paths were the agreed pattern
- Flags for duplicated domain logic that should live behind a single API
Keep the first rule set small. Over-broad policies produce noise; people learn to skip the check. Prefer a short list of high-cost violations over a long list of stylistic preferences dressed up as architecture. Document each rule in terms of the failure mode it prevents—cascade risk, deploy coupling, ownership confusion—so reviewers and authors share the same rationale when the tool blocks a change.
Adopting it without turning it into theater
Treat Sentinel as one layer in a design control loop, not a substitute for architecture review. AI-assisted validation can spot recurring structural smells at scale; it cannot decide product tradeoffs or green-light a redesign. Pair the gate with a living map of service boundaries, ownership, and intentional exceptions. When the tool and the map disagree, fix the rule or the map—do not paper over the mismatch with blanket suppressions.
Roll out in stages: advisory mode on a representative set of services, then hard fail on the highest-value rules, then expand coverage as false positives drop. Measure usefulness by whether fewer boundary-breaking merges reach main and whether rework after review decreases—not by how many warnings fire. Used that way, GA-era architectural validation becomes a practical brake on microservice debt instead of another checkbox in the commit path.