Daily AI Stew · 2026-10-12

Robin's Salty Talk — the Daily AI Stew

Daily AI Stew · 2026-10-12

Daily AI Stew · 2026-10-12

This is Robin’s Salty Talk — the Daily AI Stew.

More than one million robots are already working around the clock in Amazon’s warehouses. A GitHub infrastructure incident disrupted Actions, Pull Requests, and Issues, with the status page acknowledging degraded performance across those services during the event, and the surrounding discussion tied the surge in activity to AI coding agents. QGIS’s Enhancement Proposal #387 is still a proposal — it would ban AI-assisted contributions from the codebase and require merged code to carry a named human author.

Over a million robots, already running day and night in the warehouses

No organization on Earth operates more robots than Amazon. The company already has more than one million robots working around the clock in its warehouses, shipping tens of millions of same-day and next-day packages every day. One million is a number already in motion, not a target still written into a plan. Over the next few years, Amazon intends to grow this fleet substantially by building new factories that mass-produce increasingly capable robotic workers. Source: Ars Technica

Even with robots deployed at this scale, Amazon remains the world’s second-largest corporate employer. Its 2025 annual report counts more than 1.5 million full-time and part-time human employees combined. The executive line is that as the robot fleet has grown, the burden on human workers has eased. The easing comes from task transfer: the hardest jobs in fulfillment centers are handed to robots, and those jobs are exactly the ones with the highest physical fatigue and injury risk. Labor advocacy groups and independent researchers point out that there is evidence that AI-driven warehouse automation is not purely beneficial for the people who must work alongside the robots.

The difference lies in how close the machines are to people, and who sets the pace of work. Brian Greenwood, a professor of business at George Mason University, told Ars: “Most of the automation we’ve seen over the past 100 years typically happened far away from workers — you take that high-risk task away from the worker, and you do it in a way that isn’t physically close to them.” He added: “The rise of collaborative robots really changes this picture, for two reasons: first, they are physically close to workers, and second, robots have the ability to dictate the pace of work.” The first point is about distance — the machine stands right next to the worker; the second is about tempo — how fast the work goes can be set by the robot. That is the opposite of the past century’s approach of removing dangerous tasks from people’s side and keeping humans and machines apart. Executives emphasize that the hardest work has been taken over; researchers and labor groups emphasize that the people left next to the robots have not, as a result, received only benefits.

The status page recorded degraded performance; the discussion attributes the volume to coding agents

A GitHub infrastructure incident disrupted three services: Actions, Pull Requests, and Issues. The company’s status page acknowledged that these services experienced degraded performance during the incident. These three are the core surfaces of the developer workflow. Actions provides CI/CD automation, triggered by events on Pull Requests and Issues, and that triggering runs at the scale of the entire platform. What the status page recorded is that these three services degraded during the incident. Source: GitHub status page

Discussion around the incident attributed the underlying pressure to a rapid rise in platform activity. According to these discussions, the daily volume of Actions, PRs, and Issues climbed from 50 million to 2 billion over roughly eight months. Another account puts the daily event volume as growing from about 50 million to about 2 billion in roughly eight months. A third frames it in daily operations. Commenters connected this order-of-magnitude jump to the mass arrival of AI coding agents. These agents work programmatically, generating commits, workflows, and issues at scale, and creating branches, commits, issues, and pull requests far faster than a human developer would on their own.

The incident marks an inflection point in scaling. The inflection point is this: the platform’s architecture was never designed to absorb this class of automated load, and now it has to catch the volume agents are pushing onto it. Commenters broadly attributed the load spike to AI coding agents. Some stated the consequence bluntly: going from 50 million to 2 billion daily operations would nearly break any system built on pre-AI assumptions. Others worried about the next step of scale — hundreds of such automated projects running every day. A few pointed to a path of reduced dependence, using self-hosted alternatives like Forgejo to rely less on GitHub. In the discussion, the figures of 50 million and 2 billion came with hedges like “about” and “reportedly,” and the timeframe was roughly eight months.

QGIS’s #387 is still a proposal: merged code must name its human

QGIS is proposing to ban AI-assisted contributions from its codebase. The proposal is Enhancement Proposal #387, and it is still a proposal — not a ban already in effect. The reason it cites is the growing number of low-quality, LLM-generated pull requests and the increasing burden on volunteer maintainers. The proposal locates the divide in contributor responsibility: people must answer for the code they submit, rather than the project being hostile to AI tools across the board. It aims to set two explicit standards for code that gets merged. One is that human authorship must be stated; the other is that review follows clear rules. Source: QGIS Enhancement Proposal #387

QGIS is a free, open-source geographic information system maintained under the GPL. Users can view, edit, and analyze geospatial data on Windows, macOS, and Linux. It is one of the most widely used desktop GIS platforms. The Hacker News discussion, with 323 points and 348 comments, placed QGIS alongside Zig, NetBSD, GIMP, Gentoo, and QEMU — projects that are all rejecting pull requests containing LLM-generated code. Generating code with AI tools keeps getting easier, while the review capacity available to vet external contributions stays limited; the two have not moved together. Maintainers are therefore increasingly forced to ration review time, by restricting AI-generated pull requests or rejecting them outright.

Maintainers say they are already drowning in PRs. These PRs look plausible but are thin in substance, and the accounts behind them rarely respond to review comments — sometimes never. Meanwhile, the work has shifted from writing code to verifying what code actually does. Commenters broadly agreed that maintainers are carrying an unsustainable review load, one driven by plausible-looking but weak LLM-generated PRs. One Plotly maintainer described the concrete damage caused by unresponsive bot submitters. Developers also pointed out another area of particular unreliability: LLMs tend to get geospatial math wrong, even while sounding confident. The hard part is no longer writing the code, but keeping yourself aligned with what the code actually does. That verification cost now dominates the work of individual developers and reviewers alike. When a project itself is hard to sustain over the long term, provable human authorship — plus staying engaged after submitting — may become the baseline for contributing.

More than a million robots already work day and night in the warehouses; collaborative robots stand close to workers and have the power to set the pace of work, and new factories in the coming years will keep producing more capable robotic workers. What the GitHub status page acknowledged is that Actions, Pull Requests, and Issues degraded during the incident, while the discussion attributes the jump from roughly 50 million to roughly 2 billion in about eight months to AI coding agents that programmatically generate branches, commits, and pull requests. QGIS’s #387 remains a proposal. Maintainers have shifted their time from writing code to vetting plausible-looking but thin pull requests, and the proposal asks that merged code name its human author. The three stories produce different outputs, but what remains on the human side is the same kind of thing: collaborative robots can dictate the pace of work, the platform must absorb volume its architecture was never designed for, and maintainers must verify what the code actually does.

🎧 This episode is also available as a podcast: listen to 每日AI乱炖 · 2026-10-12.