AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
As one of Harness’s field CTOs, Martin Reynolds spends much of his time asking engineering leaders one question with no easy answer. It’s how they’re keeping up with all the pull requests their coding agents now produce. One of them recently answered with two words, “we’re not,” and explained that his team’s threshold for pushing code into production had dropped, Reynolds tells The New Stack. TNS spoke with Reynolds a few days after Harness launched a rebuilt Code Repository and a new AI Code Review product — and a few weeks after GitHub’s nearly eight-hour platform outage on August 17. In our conversation, we discussed how the review bottleneck arose, why Harness rebuilt its Git repository for agent traffic, and which parts of the pipeline should remain deterministic. Drowning in pull requests Reynolds says he first ran into the bottleneck during Harness’ early trials of GitHub Copilot and Amazon CodeWhisperer. “We were getting more PRs, but all the PRs were getting stuck,” he says, “and the test team was shouting, saying, we can’t keep up with all of this.” “Imagine what that test team feels like right now.” —Martin Reynolds, Harness Field CTO. The 1.5x to 2x increase in new code pushed the testing teams to the breaking point, he says, and now, he sometimes sees teams at 10x, with some claiming 50x. “Imagine what that test team feels like right now.” Reynolds notes that during hallway conversations with engineering leaders at the conference, drowning in pull requests was a recurring theme. And what he sees when talking to customers tends to split three ways: Some have raised their risk tolerance, some have a backlog they can’t manage, and most sit in the middle. “The somewhere in the middle, I think, is the most common,” Reynolds says. “We’re using some kind of another AI tool to help us in that space, but it doesn’t necessarily solve the problem.” Review what’s changing, not the scaffolding Ideally, a reviewer opening a pull request should see the most important changes first, Reynolds says, and he suggests reviewers should come from whoever has worked on that part of the codebase before, “not the person who did the prompt or wrote the code.” “This other stuff is like 30 files because they updated a dependency. That’s less important in terms of getting eyes on,” he says. Reviewers should “actually review what’s changing rather than a bunch of stuff that’s scaffolding around it.” “It’s not just the model on its own,” he also notes. Harness spent “a good chunk of the last 12 months” building what it calls a software delivery knowledge graph, a map of a customer’s pipelines, deployments, incidents, and policies, so the reviewer can pull context “at speed and not burn lots of tokens.” The company’s own example is a migration flagged because an earlier incident review found an unindexed CREATE INDEX statement had locked a production table for 14 minutes. By the company’s own count, its engineers saved more than 10,000 hours of manual review time a month. The day Harness launched, GitHub’s Copilot code review began reviewing pull requests opened by bots, including its own coding agent. Agents don’t work nine to five Recently, Harness customers on GitHub “would quite often genuinely send us screenshots of GitHub being down,” Reynolds says. The reason for GitHub’s struggles, he believes, is that GitHub “was ultimately built for people, teams of maybe up to 10, 15, who are changing code, creating pull requests. Those pull requests will be there for a few hours to maybe a couple of days.” But agents “don’t work nine to five.” Harness has been selling a repository service since 2023, when it launched Harness Code on top of its open-source Git project, and Reynolds says the company rebuilt it as “a ground-up AI-first repository that works for humans and AI.” He describes it as Kubernetes-based, running across multiple clouds and regions, tested at thousands of commits per second, and used by about 20 enterprise customers during beta, none of which Harness has published. GitHub CTO Vlad Fedorov’s postmortem on the August 17 outage said “a critical infrastructure component in our Central US data center failed to scale” as traffic hit a new peak. GitHub now handles 2.9 billion commits a month, a little more than 1,000 a second on average. That’s not the scale Harness operates at, of course, but for its enterprise users, that may just be an advantage. Harness is also starting to look beyond the traditional process. The capabilities for an autonomous delivery lifecycle exist today, Reynolds argues, but “are organizations and companies ready for that? I’m not entirely sure.” Either way, he says deterministic tooling needs to stay, and test results still come from the test runner. “There’s no need to rip those out and replace them. It’s like, where can you enhance them?” The reviewer is the part of this launch most teams will touch first. It works on pull requests that already live on GitHub, and moving a repository is a long project at most enterprises. The engineering leader who told Reynolds “we’re not” doesn’t need a new Git host to change that answer. He needs something that tells his reviewers which files in a pull request still need a human and which 30 came with a dependency bump. That’s a much smaller promise than an autonomous delivery lifecycle, but for now, it’s also likely the more useful one. The post Harness rebuilt its Git repository for nonstop AI agent traffic appeared first on The New Stack.