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 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. 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. 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. 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. 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. 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: 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. 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. 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.TL;DR
Why doesn't repository-first governance work for agentic development anymore?
Where does meaningful software engineering happen now?
What does the data show about local, agent-driven code?
What is loop infrastructure?
How do you enforce quality and security checks locally, before the pull request?
How can engineering leaders move enforcement into the engineering loop?
Where does Verity fit in?