In the morning, you find 30 review request notifications piled up. Opening them reveals diffs generated overnight by agents, with hundreds of lines across 20 files in a single PR. If you try asking the author why a specific change was made, there is no human author to ask. When custom development projects fall into this state, code review becomes more than just a bottleneck—both quality and accountability grind to a halt simultaneously.
Implementation is no longer the rate-limiting factor. The speed at which AI agents write code has long surpassed the pace of human review, quietly shifting the bottleneck to PR reviews. A domestic industry survey reported that after introducing agents, the number of merged PRs roughly doubled and PR sizes grew by more than 2.5 times, while time spent on reviews increased by the same margin. Because code can be written faster, the review side collapses under the load.
Against this backdrop, moves have emerged to rebuild source control services from the ground up around an agent-first premise. In this article, while touching on GitLab's new service as an example of this direction, we outline practical procedures for redesigning source control, code reviews, and quality assurance in custom development settings.
Git's assumption of manual human handling is reaching its limits
Source control systems like Git, GitHub, and GitLab were originally designed on the premise that humans write code manually and commit by hand. When agents run in parallel to generate diffs every second, the load from clones and pushes spikes in unexpected ways.
In June 2026, at the GitLab Transcend event in London, GitLab announced a next-generation Git-compatible source control service designed for AI agents. According to coverage by Publickey, this service (introduced as “Project Switch”) redesigns the backend while maintaining compatibility with the Git protocol. GitLab claims it offers up to approximately 50x speedups, reduces network traffic to about 1/1,000, and cuts token consumption in half. However, these figures are claims based on the company's internal testing, and concrete details regarding specifications remain scarce at present. Rather than serving as direct criteria for adoption in custom development projects, it is more appropriately viewed as an indicator that source control has begun treating agents as first-class citizens.
The key takeaway is that even if tools become faster, the structure of responsibility in custom development does not change. In the end, humans make the commitment to clients to deliver and maintain the code. If you cannot explain what an agent has written, that speed simply turns into technical debt. That is precisely why operational design matters.
First, break PRs back down into human-readable units
In a world where agents have removed the implementation bottleneck, the first step should not be introducing new tools, but enforcing the granularity of changes. Break tasks down so that one task equals one small PR, and place a cap on the number of changed lines per PR. Simply keeping PRs within a scope that reviewers can read while maintaining context noticeably restores review quality.
In a custom business system project supported by our company (for a manufacturing client, company name withheld), when development was initially delegated to agents, PRs averaged over 600 lines each, and reviews stalled at around 40 minutes per PR. To address this, we instituted a rule during task decomposition: “one feature per PR, changes kept to 200 lines as a rule, with a separate design review required if exceeded.” As a result, review time per PR dropped to around 10 minutes, eliminating the backlog. What mattered was not the exact line count itself, but embedding the “break it down small” constraint right into the agent's prompt instructions. Reviewable PRs are made during the generation phase, not the review phase.
It is also essential to clarify the focus of reviews. AI-generated code tends to take longer to interpret because it offers less contextual explanation than human-written code. That is why roles should be clearly divided.
| Decision type | Owner | Details |
|---|---|---|
| Why / What | Human reviewer | Does this change meet requirements, and are the design decisions sound? |
| How (standards and formatting) | Automated gate | Formatting, naming, static analysis, and routine linting feedback |
| Behavioral verification | CI and testing | Do tests pass, and are there any regressions? |
Humans should focus on the “why” and the “what,” leaving the “how” checks to automated gates and agents. This division of labor is essential for reducing review burden while maintaining quality. For details on structuring quality assurance, including test automation, see AI-Driven QA Automation with Playwright for concrete configurations to reference when designing CI gates.
A framework to keep diffs of unknown authorship out of production
The greatest risk in custom development is having untraceable changes slip into production. In an era where agents commit code in high volumes, auditability and accountability cannot exist without explicitly designing commit identities and access permissions.
At a minimum, establish the following three operational rules.
| Discussion point | Design principle |
|---|---|
| Commit identity tracking | Record agent executions under dedicated accounts or bot signatures to distinguish them from human commits |
| Principle of least privilege | Grant agents write permissions strictly for the scope required by the task, and prohibit direct pushes to protected branches |
| Merge accountability | Require human review and approval before merging any agent-generated diffs, and log the approver |
Block paths that allow agent diffs directly into main, permitting changes into protected branches only via reviewed and approved PRs. This is not a novel concept; it simply means reapplying the controls traditionally practiced in custom development with greater rigor now that commits are machine-generated. Preventing credential leaks follows the same principle: incidents where authentication credentials or tokens slip into agent-generated code do happen in practice. For integrating secret scanning into your development pipeline, see Integrating GitHub Secret Scanning MCP Server into SecOps, and for auditing source code and credentials, consult Secret Audits for Source Code when preparing pre-handover checks for custom projects.
For designing permission and secret management throughout the entire development workflow, refer also to Automating DevSecOps with GitLab 19 Developer Flow and Secrets Manager to get a sense of how much can be enforced on the tooling side.
Stack upstream automated gates and make human review the final line of defense
To structurally reduce review burden, filter out as many issues as possible automatically before a PR reaches a reviewer's eyes. This is the multi-stage gate approach.
Specifically, have the agent run test-driven cycles during code generation, followed by static analysis and formatting prior to commit. Once a PR is opened, CI executes tests, type checks, and security scans; only code that passes these checks reaches human review. Human review should be positioned not as the first barrier, but as the final line of defense. The sequence is vital: route code through multiple upstream automated gates, and only then have humans evaluate requirement compliance and design decisions in the final stage.
However, be careful not to accept AI review feedback uncritically. Some suggestions produced by automated gates or AI reviews can be off-target. In custom development, saying “we changed it (or didn't) because the AI said so” is not acceptable to clients. Humans must retain final decision-making authority and document the rationale. This serves as the ultimate safeguard for maintaining accountability amid mass-produced code.
Accountability to clients must not be overlooked either. Be transparent in contracts and project reporting about the fact that agents are used in development and how deliverables are verified. Pitching only “faster and cheaper” risks giving the impression that QA processes were cut. Instead, presenting how quality is guaranteed through reviews and automated gates alongside agent generation will be a key differentiator for custom development moving forward.
Where to begin
Code mass-produced by agents is not inherently the problem. The issue is that receiving, reviewing, and auditing workflows designed for mass production have not kept pace. While tools will continue to get faster, what custom development must uphold remains unchanged: keeping deliverables explainable and maintainable.
As a first step, we recommend tracing your own or your vendor's development workflow to see whose approval agent diffs require before entering production. From there, identifying whether you lack PR granularity rules or automated gates will clarify where to begin.
If you are unsure how to set up an agent-ready source control and review framework or integrate it into existing custom workflows, please reach out through GleamHub's contact page. We will review your current repository operations and help you redesign your review and quality assurance processes.
Sources
- GitLab Announces Next-Generation Git-Compatible Source Code Management Service “Project Switch” for AI Agents: Up to 50x Faster with Half the Tokens - Publickey
- GitLab Announces New Capabilities to Give Enterprises Speed and Control at Agentic Scale － GitLab Investor Relations
- GitLab: Built for the agentic engineering era － GitLab Blog
- PRs Tripled but Releases Didn't: Shifting Bottlenecks in the AI Era and Their Remedies - Zenn
