The all-in-one intelligent cloud (Sponsored) #
Writing code is fast, shipping it is still hard. Railway’s push-button compute, storage, and networking is built for both small and hyperscale software.
Humans and agents alike operate on one vertically integrated system on our own hardware. Get superior speed, better economics, and a lot more calm.
Sign up with the link below for free cloud credits and let your agents cook.
The Roundup covers insights and trends from the world of software development.
Today, we’ll cover the following topics:
- More and more Agents are writing the 1st draft of most new code. According to GitHub, more than 40% of PRs in September have originated with an agent doing the work.
- Anthropic has gone as far as replacing Git to keep up with a constant stream of changes.
- Anthropic’s S1 filing gives an inside look at the real worth of AI coding.
- Beyond AI, the very foundation of the World Wide Web has had a pretty rough time when it comes to security. PHP had to ship emergency fixes for two critical remote-code-execution bugs that attackers were already exploiting.
Disclaimer: This post is based on publicly shared details from various sources. Please comment if you notice any inaccuracies.
1 - Agents now open 40% of PRs. The bottleneck in software development is shifting #
Git was designed in 2005 for the Linux kernel. At that time, you had 1000s of human developers. Each of them committed code a few times a day. Patches were swapped over email. For a couple of decades, these things were the normal way of doing stuff because writing code was a slow exercise.
This month, two data points have turned up that show that these norms are changing. GitHub’s Octoverse 2026 reports that more than 40% of pull requests in September started as a first draft using agents. This is up from 17% in March. For perspective, this comes to around 110 million PRs in a single month that have been started by agents.
Also, Anthropic recently released an article talking about how they replaced Git in its monorepo with an in-house system known as Scion. Daily merges in Scion grew from about 2500 in May to more than 30000 in September. A team of 7 developers moved the whole monorepo off Git in five months. The team says that the new setup uses 200X less CPU and memory than the Git mirror fleet it replaced.
Of course, there are still some questions that numbers might not answer adequately.
First, who is reviewing 110 million PRs a month? Octoverse says 90% of agent-involved PRs were merged within 2 weeks. You can think of faster merging as a sign of better code. But it could also mean that reviews are not good enough.
Second, how is GitHub even able to find out if something has been started by an agent? You can also have agents that commit stuff using a human’s account without any trace of their real identity. So it’s possible that the true share of agent work is even higher.
The third question is about Anthropic’s move to Scion. Of those 30000 daily merges, how many were later reverted? Throughput without a defect rate can’t give a complete picture.
My take is that building your own version control tool used to be a sign of a huge company because doing so required a ton of resources and bandwidth. For example, Google built Piper, and Meta built Sapling, for tens of thousands of engineers.
Anthropic solved that scale problem with a fraction of the people. They were able to do so because agents did all the coding. This is where the change has happened. Generating code is now the relatively cheaper part of software engineering. The scarce resources are time for human code review, CI capacity, and merge rate. I expect the next wave of developer tooling to be about verifying code and not writing it because that’s where the bottleneck is shifting.
Build AI agents that work in production on day one (Sponsored) #
Getting an agent to work in a perfect demo environment is easy. Keeping it working in the messy real world is where things get… interesting.
Get a live technical demo of Redis Iris, the unified, real-time context engine. This free session explores six capabilities that keep your agents resilient at scale.What you’ll learn:
- Give agents relevant context and memory
- Route requests by intent with reusable playbooks
- Set up a single context entry point
- Govern what agents remember and forget
- Trace failures to their source with less custom glue
Come build agents with the context, memory, and messaging they need to stay accurate, accountable, and efficient in prod at scale.
Join live November 12 at 9 AM PT.
2 - GitHub Universe: Copilot now picks the model, and Enterprise moves to pay-per-use #
Until now, using an AI coding tool meant you had to choose a model. For example, you might select Claude for one task, GPT for another, and Gemini for something else. With the greater adoption of a model router, you can get rid of this choice. The router looks at a task and decides which model (or which mix of models) should handle each step.
At GitHub Universe, GitHub made its router, Copilot Fusion, generally available. GitHub says that Fusion Max scored within two points of Claude Opus 5.5 Max on the Artificial Analysis Coding Agent Index, at about half the cost and 40% less time per task. GitHub also shipped Copilot projects, which run agents across multiple repos in parallel.
Cloud agent sessions can now go between your phone, VS Code, the CLI, and the web. So developers can basically handle their work on any device. Also, GitHub Enterprise customers can use every Copilot feature without any separate subscription. They only need to pay for the AI credits that they consume.
Now, this development opens some interesting thoughts. Earlier, the choice of the model was with the developer. But now it’s decided by another process.
Can you now see which model handled which part of your code? Many teams have rules about where code is allowed to go. But that might be decided by a router silently.
In my view, this is pretty similar to the cloud adoption story repeating itself from years ago. For example, AWS moved organizations from owning servers to simply paying for usage. With seat-based licensing, AI spend became predictable and difficult to optimize. With usage-based billing, you make it variable. But agents that might run for hours can make things quite spiky. And hence, teams need to be a lot more thoughtful in building AI workflows.
Strategically, Fusion aims to make GitHub a model-neutral layer above the labs. This turns your models into interchangeable parts that sit behind a router. In a way, this might be good for buyers, but it might also be a little uncomfortable for any AI lab that counted on their model being the default choice. It also raises the pressure on GitHub’s reliability because a platform that runs your agents has to always stay up.
3 - Anthropic’s S-1: The first audited look at the worth of AI coding #
An S-1 is the document a US company has to file before it can get listed on the stock market. Unlike a funding announcement, it contains audited financials and a long list of things that might go wrong. This is quite interesting because till now, the economics of AI coding tools were mostly guesswork based on leaks. This filing helps replace some of the guesswork with real numbers.
Anthropic filed its S-1 on October 26 under the planned ticker “ANT”. Revenue for H1 2026 was $16.3B, up from $1.2B a year earlier. It has 14K+ enterprise customers, and about 250 of them are spending $10M+ a year. Also, trading could begin as soon as November. There are reports of an operating profit in Q2 and 900% net revenue retention: existing customers spent nine times more in Q3 2026 than in Q3 2025.
Recently, Anthropic also shipped reporting tools that show customers what their token spend is giving them. They also provided pooled team budgets.
There were also some important disclosures. Four models were able to reach external systems during 3rd-party security testing because a misconfiguration left access to the internet open. Anthropic also seemingly delayed pre-training a new model by more than a month to strengthen protection of its model weights.
A key question is about how much of that 9X growth per customer comes from agents running for hours, versus more people actually using the model. Also, how much of the experimental budget could be cut next year? And it’s also quite possible that the decision to launch ROI dashboards the same week as the IPO filing suggests that customers are already seeking details about what they are getting in return for their spending.
In my view, for engineering leaders, the message is that AI spend will be scrutinised pretty much the same way cloud spend was scrutinised in 2022. It’s good to start measuring outcomes now, such as cycle time, escaped defects, and review load.
Also, the disclosure about the model reaching external systems requires developers to be careful. If a well-resourced, safety-focused lab could face something like that, other companies should be more wary of their AI agent’s internet access settings.
4 - PHP2Shell Vulnerabilities #
Most security advice targets your dependencies. For example, the npm packages or the WordPress plugins. But the language runtime is a dependency too. And it’s something that’s often forgotten. If you have a bug inside the PHP engine, you can’t escape its impact with framework updates or CMS updates. Every app on that server inherits the hole.
Recently, PHP shipped emergency releases for two critical bugs. They are now nicknamed “PHP2Shell”. One of these bugs corrupts request state when memory runs out. The other one lets a later request reuse state that should have been freed. Both are rated 9.2 (CVSS v4) and allow unauthenticated remote code execution.
Apache mod_php is the worst case. The demonstrated attack runs before any application code is executed. Various researchers reported the presence of these bugs. In fact, details leaked on Hacker News two days before the planned disclosure. So PHP brought its release forward a day.
The problem is that the attack traffic came before the fix. Anyone who waited for the KEV listing had already been exposed for nine days.
As per estimates, around 2.6M internet-facing services were showing a PHP version in October. About 1.9M of them (73.5%) ran PHP 8.1 or older, which PHP doesn’t patch. PHP did publish minimal source backports for 7.4, 8.0, and 8.1, but it might be unrealistic to build PHP from source on a forgotten shared host? In fact, attempts to exploit also showed up on Amazon honeypots 3 days before the leak. Did someone have the details about this weakness even earlier?
The researchers may have used AI to help find the bugs. If AI can make old and deep bugs cheaper to find, the patch window is going to go down for everyone in the industry. The cost of running an end-of-life runtime goes up in a big way. In my view, the key lesson from this incident is that developers should also list their runtimes just like the dependency packages. Most dependency scanners don’t worry about the interpreter.