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

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

Trends,

AI in Software Engineering

15/08/2026

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

Codacy

12 mins read

In this article:

Subscribe to our blog:

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.

TL;DR

Local coding agents now produce substantial portions of many changes , so enforcement anchored only at the repo and CI/CD is reviewing work that has already happened.

AI-generated code carries measurable security and quality risks, and reviewers cannot absorb that volume at the PR stage alone.

Consistent policy has to travel with the developer: the same rule set in the IDE, at pre-commit, and in the pipeline.

Compliance evidence needs to be captured continuously at the point of change, not reconstructed later from a pipeline snapshot.

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

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...