Teams Built Quality And Security Infrastructure Around The Repository And That Is Now Breaking

A pull request used to be where a change became real. An engineer wrote the code, pushed it, and opened the PR; that was the moment the rest of the team could run the checks and decide whether it was safe to merge.

Now imagine an agent working for several minutes before any of that happens. It reads the repository, changes ten files, installs a dependency, runs the tests, rewrites part of the implementation, and tries again.

By the time the PR appears, the interesting engineering work has already happened. Except it has happened on someone’s machine, inside a local agent loop.

This changes where quality and security controls need to operate. Engineering teams built their entire quality and security apparatus around the repository, because that is where software used to take shape.

Autonomous agents have quietly moved the first place meaningful engineering happens from the repo to the developer's local environment, and the pull request has become a checkpoint on work already done rather than the place where it first takes form.

The repository and CI pipeline still matter. But they are increasingly seeing the result of the loop rather than the loop itself. If an agent is going to make decisions, execute commands, and iterate locally, engineering teams need a way to carry their rules into that environment and check the work while it is happening, not only once it arrives at the PR.

The decisions that actually shape the code now happen locally, before anything reaches a place teams can see. This piece is for engineering leaders who own both code quality and security and need a working answer to where enforcement has to move next.

who own both delivery speed and security exposure are stuck translating between developers who want faster tools and a security function that has no reliable way to see what is already running in production repositories.

This article lays out a governance model that turns that standoff into an approvable, phased rollout.

Why doesn't repository-first governance work for agentic development anymore?

Repository-first governance assumes the repo is where engineering happens, so rules enforced at commit or pull request time are used to catch nearly everything worth catching.

That assumption breaks once an agent plans, edits, and runs commands across a working directory before a human opens a pull request, because a rule that binds at the repo can only see what has already crossed into it.

The shift-left promise of the last decade was supposed to solve this by pushing testing and security earlier into the pipeline. In practice, developers were already juggling coding, fixes, and compliance checks while release cycles compressed from months to hours, and the tooling added to the pipeline mostly added more gates at the same late stage rather than moving the check to where the work starts.

Rules defined at the repo and CI/CD only bind at a point the work has already passed through, and perimeter or pipeline controls cannot see what happens on the endpoint before that.

An agent reading files, resolving dependencies, and executing shell commands locally does all of that below the network's line of sight, which means a scanner sitting in the pipeline is evaluating an artifact rather than a process.

This produces a predictable failure mode: alerts without context get ignored because a flag that arrives after the work is done reads as friction rather than guidance.

Teams without a dedicated security function feel this acutely, since a fragmented toolchain of separate scanners for secrets, dependencies, and static analysis means enforcement is inconsistent from one repository to the next, and inconsistency is what developers learn to route around.

Consistent enforcement has to attach to the point of change, and that point is now local.

Where does meaningful software engineering happen now?

The first place meaningful software engineering happens is no longer the repository. It is the local environment, where an agent plans a task, edits multiple files, runs tests, and often executes commands before a pull request ever opens.

For years, teams invested in infrastructure around the repository because that is genuinely where software got built: a developer wrote code locally, then pushed it somewhere a team could review, test, and ship it.

Agentic development inverts the order of operations without changing where the infrastructure sits.

The pull request has not disappeared, but its center of gravity has shifted. A PR used to function as both a quality gate and a context-sharing checkpoint, the place where a reviewer first saw the reasoning behind a change and could shape it before it landed.

When an agent produces a multi-file change locally in minutes, the substantive engineering, meaning the planning, the generation, the command execution, is already complete before anyone opens that PR.

Review at that stage increasingly means reviewing a finished artifact rather than shaping the work in progress, which is a genuinely different activity even though it looks identical in the tooling.

The quality-checking role of review is eroding for this reason, while the context-sharing role, keeping a team aligned on why a change happened, remains as valuable as ever.

What changed underneath this is not just speed but the nature of delegation. Coding assistants suggested lines and left the decision to accept them with the developer. Agents plan across files, run their own tests, and execute multi-step tasks with minimal intervention, which means developers are no longer approving suggestions one at a time.

They are delegating actions: file access, dependency installation, shell execution, and often calls to external tools through plugin ecosystems or MCP servers. The laptop has become the place where software acts, not only where it gets typed, and that shift is exactly why file access, shell execution, and model supply-chain exposure now sit on the endpoint, underneath the layer most security tooling was built to watch.

Sandbox-escape and command-injection flaws have already turned up across popular agent tools, and prompt-injection chains that steer an agent into a privileged tool call are no longer a theoretical concern. Once an agent can act rather than merely suggest, the local environment becomes the actual point of change.

What does the data show about local, agent-driven code?

Data clearly shows that the shift to agent-driven development is showing up in both output and risk: more code is being produced, while security risks and the limits of human review are becoming more consequential.

The studies below measure different aspects of that shift, but together they show why enforcement has to keep pace with the volume and speed of agent-driven work.

What is loop infrastructure?

A pattern shows up every time the center of engineering work moves: development moved to Git, so teams built version control around it; deployment moved to the cloud, so teams built cloud orchestration around that.

Engineering is moving into autonomous local loops now, which means a layer built for that loop, not just for the repo, has to appear somewhere in the stack.

What that loop actually needs is fairly specific. It needs policy that travels with the developer rather than living only in a pipeline configuration file, endpoint-level visibility into what an agent actually accessed and did during a task, and enforcement that runs before code is pushed rather than after a scan flags it days later.

The direction of travel in the field points toward exactly this: in-IDE and pre-commit checks, agent hooks that intercept an action before it executes, and policy enforced consistently rather than through periodic scans that run long after the decision has already been made. None of this replaces the repository or the pipeline.

It sits ahead of both, as the operating layer that makes autonomous engineering observable and repeatable rather than another point solution bolted onto an already fragmented stack.

How do you enforce quality and security checks locally, before the pull request?

Local enforcement means moving specific gates, not vague vigilance, to the developer's machine: lightweight SAST, SCA, and secrets scanning running in the IDE and at pre-commit, so an issue surfaces before it ever enters version history rather than after a scanner catches it in CI.

The mechanism matters here. A pre-commit hook that runs a fast static analysis pass against staged changes catches an obvious secret or an injectable query in seconds, at the exact moment a developer or an agent is still working in that file, which is a fundamentally different intervention than a nightly pipeline scan that surfaces the same issue three days and two more commits later.

A few practices make this hold up in practice:

• Enforce consistently across every repository. A rule that applies unevenly is a rule developers learn to route around, so consistency across repos matters more than depth in any single one.

• Treat agent output like any other untrusted input. Scan agent-generated code the same way you would scan a new contractor's first pull request, since both volume and defect density run higher.

• Contain what the agent can do. Apply least-privilege access and sandboxing to any agent that can run shell commands, because a single injected instruction can otherwise exfiltrate secrets or delete files.
• Bring agent configuration files under integrity controls. Rule files and hook configurations have become an attack vector in their own right, so they need the same scrutiny as source code.
• Tune for signal, not noise. Track how often a rule fires and how long it takes a developer to respond, then adjust thresholds so real issues do not drown in low-value alerts.
• Keep compliance evidence continuous, a direction NIST SP 800-18 Revision 2 emphasizes machine-readable data formats for automated data collection. Capture what was enforced and when as changes happen, so an audit trail reflects the local point of change instead of a reconstructed pipeline snapshot.

The human review step at the pull request does not disappear in this model. It keeps its context-sharing role, spreading understanding of a change across a team, even as the mechanical quality checks move earlier and stop depending on a reviewer catching them manually.

How can engineering leaders move enforcement into the engineering loop?

• Measure your own AI-assisted development. Track what share of commits are AI-assisted, along with defect and churn rates compared with human-authored code. Use that data to decide where enforcement needs the most attention.
• Map where enforcement meets the work. Identify where your current checks bind—PR gates, CI scans, or elsewhere—and compare that with where developers and agents actually make decisions. Close that distance rather than adding another downstream check.
• Standardize golden workflows and guardrails. Apply the same policies whether a change comes from a human or an agent, removing the assumption that AI-generated code can be trusted without the same controls.
• Decide what agents can do autonomously. Determine which actions require human approval and which can happen without it. The practical constraint is not what agents can technically do, but what your team is willing to trust them to do.
• Choose the right enforcement point. If you're deciding what belongs before commit versus in the pipeline, see the breakdown of pre-commit vs. CI quality gates. Only 29% of developers say they trust the accuracy of AI tools, according to Stack Overflow’s 2025 survey.
  
  

Where does verity fit in?

Verity is Codacy's expression of this loop-infrastructure layer: it brings consistent enforcement to the local point of change, so policy travels with the developer and teams get observability across the agentic loop rather than a snapshot taken after the fact.

A core part of that enforcement is checking intent against spec, meaning Verity evaluates whether the code an agent produced actually does what it was supposed to do, not only whether it passes a static rule.

You can read more in Verity's documentation.