#ai#management#architecture

Agents write the code, while Git, code reviews, and metrics have become the bottleneck

GitHub is rebuilding Git for agents, stacking pull requests and report limits, revealing where AI development hits process bottlenecks.

  • Code gets cheaper, while the process around it gets more expensive
  • Git was designed for people
  • PR stacks: review as the main limit
  • Security: the scanner must be deployed everywhere

Code gets cheaper, while the process around it gets more expensive

GitHub is rebuilding Git infrastructure for repositories where developers and agents work simultaneously and produce millions of commits per day. That same week, the company released pull request stacks, AI scanning status in the security overview, a fix for broken Copilot metrics, and limits on private vulnerability reports. These five developments show that in agent-driven development, code is no longer the scarce resource.

The scarce resources become the throughput of the process around the code and the accuracy of the figures leaders use to assess results.

Git was designed for people

Git is designed for a developer who makes a few commits per hour and rarely conflicts with a colleague in the same file. GitHub writes, that agentic development requires a different architecture: people and agents work in the same repositories in parallel, while the load is measured in millions of commits per day.

That is why GitHub is rebuilding the storage and Git operations layer.

The conclusion for a business owner is simple.

If you run agents on your monorepo, the first limit will be the version control system, followed by CI and the merge queue.

You can connect the model in a day

Infrastructure that can handle hundreds of parallel branches will take months to build.

PR stacks: review as the main limit

  1. An agent produces changes faster than a person can read them. A two-thousand-line pull request is more often approved on trust than actually read.

  2. A pull request stack addresses this mechanically: a large change is split into small, related PRs, each reviewed separately, then merged together. GitHub reports about the figures after the public preview.

  3. Repositories with stacks showed 9% more merged code than similar repositories without them.

  4. More than two-thirds of the top 1% of repositories use stacks and achieved a 5% better time to merge.

  5. These are platform data, and they do not prove causation: active teams may have adopted the new tool earlier than others.

  6. The direction is clear: smaller review units speed up the flow, and they are even more important for agent-generated code than for human-written code.

  7. In practice, we build this into the rules for agents: one agent makes one verifiable change backed by a test and a clear description.

  8. A reviewer can approve such a change in minutes.

  9. That is why we are building a process for AI-native development: reviews must keep up with the speed of generation.

Assess where AI can deliver impact in your process

clients@kt.team Telegram @kt_team_it

Security: the scanner must be deployed everywhere

The administrator can see how many repositories have scanning enabled or disabled, filter them with `code-scanning-ai-scan-pr-scan:enabled` and `code-scanning-ai-scan-pr-scan:not-enabled`, and export a separate CSV column.

The news is modest, but it points to a real problem.

A security tool enabled in half of the repositories creates a sense of protection while leaving the other half exposed.

As long as people wrote the code, this gap was manageable.

When an agent creates dozens of PRs a day, an uncovered repository becomes an open door.

You need a coverage map and someone responsible for closing the gap.

We apply the same principle in LLM & Security Gateway: every model call passes through unified control.

A similar story in open source

GitHub introduces daily limits to new private vulnerability reports from a single account: maintainers receive more and more low-quality automated reports, and important ones get lost among them.

Automation made submission cheaper, but review remained expensive.

A company with a public repository or bug bounty may face the same level of load.

The metric that showed a decline amid growth

The most instructive of the five news items concerns measurement.

Administrators noticed that agent activity and the number of lines of agent-generated code in Copilot metrics are falling even as usage grows. GitHub found the cause: several IDEs moved agent sessions to the Copilot SDK, and those sessions did not report which IDE they came from.

Most of the activity was missing from the reports, while some was recorded as Copilot CLI activity.

Only IDE versions using the SDK are affected; the fix is released by updating each environment. Imagine approving a budget for AI tools and seeing a falling curve on the dashboard a quarter later.

You can scale back the program, switch providers, or call the team in for an investigation.

All three decisions will prove wrong because the chart was lying

In this situation, AI without validated measurement becomes theater, and the budget is decided by the stage set.

This leads to a rule we build into projects with agents.

Define the outcome metric before launch:

  • time from task to working production code
  • share of changes
  • that passed review without rework
  • number of incidents

Data sources are verified independently of the vendor dashboard.

At least once a quarter, a team lead or analyst compares the dashboard figures with what is visible in the repository itself.

What to check in your own setup

  1. These stories yield a short checklist for a leader implementing agents. - Repository.

  2. Can your Git, CI, and merge queue withstand a tenfold increase in changes? - Review.

  3. Can agents split work into small, verifiable parts, and do people have time to read them? - Security.

  4. What percentage of repositories is covered by scanning, and who is responsible for the rest? - Measurement.

  5. Whether the dashboard matches reality and who last verified it.

  6. Technically, these challenges can be solved: PR stacks, a unified gateway to models, MCP servers with restricted permissions for agents, and independent reporting.

  7. A simple result requires a mature process behind it.

  8. Agents write code cheaply, so the winning team is the one that moves it to production quickly and reliably and validates the result with data.

  9. Teams without such a process pay for generation that gets stuck in the review queue.

Discuss the article: Agents write code, but the bottleneck became…

Enter your email or phone number so we can get back to you.

Send via:

By clicking the button, you accept the offer and grant consent to the processing of personal data.

Related Cases

All cases

Related solutions

All solutions
Demand forecasting systemGenerative AI for BusinessAI Accountant in Your Environment: Implementation CostAI Agent Platforms: Purpose and Open Options

Articles on the topic

AI in Business Collection

Related videos

All videos
Shorts What “KPI” did Amazon set for developers in the AI era? AITeams & hiringManagement
30:49 MEDSI Group President on Medicine, Their App and Hands-On AI Experience | Andrey Sokolov (Podcast) AIPodcastsManagement
Shorts Response System at Coffemania #ktteam #business #ai Food & HoReCaManagementAI

News on the topic

All news