Shift Left, Ship Right: Pre-Push Agents That Catch Issues Before Code Review

In any large migration project, multiple engineers may be working across dozens of modules at the same time. That creates two recurring bottlenecks in pull request (PR) review: volume and rework. Reviewers have too many submissions to examine thoroughly, while a meaningful share of those submissions require several rounds of changes because of standards violations, incomplete implementations, or non-compliant patterns that could have been caught earlier.

Each rework cycle carries a compounding cost. The author must re-establish context on code written days earlier. The reviewer must read and evaluate it again. The merge is delayed. Multiply that across every open PR in a sprint, and the loss of velocity becomes systemic. The problem is not that engineers write bad code; it is that they discover violations too late, when correction is more expensive.

That led us to a simple principle: if a machine can catch an issue, a human should not have to. And the earlier the machine catches it, the cheaper the fix.

When I discuss the approach with engineering teams, the conversation usually moves from the idea of shifting left to a practical question: what changes when an agent becomes the first quality gate? These are the questions I hear most often.

What does ‘shifting left’ actually mean in this context?

Shifting left means moving quality enforcement closer to the point of code creation. In a traditional workflow, checks tend to happen at three progressively more expensive stages:

• Code review – the reviewer spots the issue, writes a comment, waits for a fix, and reviews the change again
• Continuous integration (CI) pipeline – the build or test suite fails, the engineer diagnoses the issue remotely, and pushes a fix
• Production – an incident triggers an investigation, hotfix, and post-mortem

Pre-push validation creates an earlier gate: before the code leaves the engineer’s machine. Defects caught here cost very little to fix because the engineer is still in context, the change is fresh, and the mental model is loaded. A five-second correction before a push can replace a 30-minute review cycle. It changes where quality is enforced and prevents avoidable issues from entering the review pipeline.

How does the pre-push validation agent work?

The agent is integrated as a Git pre-push hook. It runs automatically when an engineer executes a push command, with no additional action required. There is no new tool to learn and no extra command to remember. It stays invisible when the code is clean and becomes unmissable when it is not.

If every check passes, the push proceeds silently. If the agent detects an issue, it blocks the push and displays a structured report in the terminal, identifying the issue, its file and line location, and the rule it violates. The engineer addresses the findings and pushes again.

The agent checks:

• Strict type compliance: no untyped variables, implicit ‘any’ types, or type assertions that suppress safety
• Framework pattern enforcement: component structure, lifecycle hook usage, dependency injection patterns, and change detection strategy
• Custom lint rules: the project’s domain-specific ESLint configuration, not only generic best practices
• Import correctness: no circular dependencies, incorrect module references, or layer-boundary violations
• Completeness: required companion files, including test specifications, barrel exports, and translations, accompany new additions
• Security patterns: no console logging in production paths, hardcoded secrets, or bypassed sanitization

This combination makes the agent more than a conventional linter. It brings static analysis and pattern-aware validation together, applying the project’s own conventions alongside language rules.

Why is this more than a conventional linter?

A linter checks syntax and basic rules. The pre-push agent also checks architectural intent.

For example, a linter can confirm that an import statement is syntactically valid. The agent can also verify that the import does not cross a layer boundary, such as a user interface (UI) component importing directly from a data-access library in another domain. A linter can confirm that a class has a decorator; the agent can check whether that decorator uses the right change-detection strategy for its position in the component hierarchy.

That distinction matters because the violations that cause PR rework are rarely syntactic. They are structural. Code may compile and pass its tests while still breaking a convention that exists only in documentation or team knowledge. The agent turns those conventions into executable checks, making previously invisible rules visible at the point of violation.

How do standardized prompts make the agent reliable?

The pre-push agent is one example of a broader practice: standardized prompt structures that make artificial intelligence (AI) agent behavior more deterministic and reusable.

A standardized prompt defines the exact format, context, and constraints the agent receives. Instead of relying on free-form instructions that can produce variable results, each prompt includes:

• Role definition: what the agent is and which domain knowledge it possesses
• Task specification: the precise action it must perform, without ambiguity
• Output format: how results must be structured, including the file, line, rule, and severity for each finding
• Constraint declarations: what the agent must never do, such as automatically fixing code without confirmation, suppressing findings, or implying false confidence

When every invocation follows the same structure, the agent produces consistent output regardless of who triggers it. This addresses the ‘it works differently for me’ problem common in ad hoc AI use. The prompt becomes a versioned engineering artifact, reviewed, tested, and maintained with the same discipline as production code.

We developed these prompt standards iteratively, testing early versions against representative development tasks and refining them based on output consistency. The behavioral guidelines are documented and version-controlled alongside the agent configurations, allowing any team member to create a new agent that follows the established quality standard.

How does pre-push validation change the reviewer’s job?

Once the agent handles routine compliance and completeness checks, PR review can focus on the work that benefits most from human judgment.

Before implementation, reviewers spent considerable time on ‘should have been done’ comments: missing test files, incorrect import paths, inconsistent patterns, or forgotten barrel exports. These comments were necessary, but low-value; they enforced known rules rather than applying judgment.

After implementation, each submitted PR reaches review with a stronger structural baseline. Reviewers can focus on architectural correctness, business logic, edge-case coverage, naming clarity, and design decisions. The conversation moves from ‘you forgot to add OnPush’ to ‘this abstraction may not scale when we add the next domain.’

The process is not only faster; it is qualitatively better. When reviewers spend their attention on architecture, the team gets better architectural feedback. When they spend it on formatting and omissions, the output is limited to corrections a machine could have identified.

How does the agent fit into the engineer’s daily workflow?

The most important design decision was requiring no behavioral change from engineers. The agent is not a separate tool to invoke or a checklist to remember. It runs on the push action engineers already perform.

When checks pass, as they do for most pushes once engineers internalize the conventions, the experience is invisible. When checks fail, the feedback is immediate, specific, and actionable. Remediation typically takes seconds or minutes because the engineer is still looking at the code, holding the mental model, and working in the same flow.

Reviewer feedback may arrive hours or days later, forcing the engineer to reload the context, reread the code, recall the original decision, and then make the correction. The pre-push agent removes much of that context-switching cost.

What impact has the team measured?

The team tracked three indicators before and after introducing pre-push validation:

• Validation time per PR: reduced from 40 minutes to 10 minutes, a 75 percent decrease
• Review rounds: decreased as standards violations no longer required repeated rework cycles
• Review comments: shifted away from compliance corrections and toward architectural observations

The 30 minutes saved in each PR cycle is measured across the team’s daily work, not a theoretical projection. With multiple PRs per engineer each day, the improvement compounds into hours of recovered engineering capacity every week, redirecting time from mechanical rework to problem-solving.

The 100 percent adoption rate is equally important. Tools that depend on optional behavior often achieve partial adoption. Because the hook runs automatically, every push from every engineer passes through the same quality gate from day one.

What did we learn from introducing the agent?

Late-stage failures are a systems problem, not a discipline problem. Asking engineers to ‘be more careful’ does not scale; automated gates at the least expensive intervention point do.

Tooling is adopted more readily when it fits naturally into existing behavior. Quality enforcement works best when engineers do not need to remember an additional step.

Prompt standardization is infrastructure, not documentation. Treating prompts as versioned, reviewed, and tested engineering artifacts produces more consistent agent behavior than treating them as informal instructions.

Reviewers are a scarce resource. Spending their attention on pattern compliance creates little value. Pre-push validation preserves that attention for architectural judgment, the work that genuinely requires a person.

The least expensive defect is the one caught before it leaves the engineer’s machine. Every stage it survives increases its cost, making pre-push validation an economic argument for placing quality gates earlier.