In the Face of the AI Deluge, Hire Agents Instead of Using Them

GitHub has introduced safeguards against automated pull requests, a symptom of an unprecedented volume of contributions generated by models. In response, an approach is emerging: giving agents isolated workstations, guiding them through a two-door approval kanban, and shifting human effort towards reading specifications. The organizational chart, rather than the "swarm," serves as a compass to orchestrate these non-human colleagues.

GitHub restricts flows: disabling PRs and limits counting AI

In February 2026, GitHub introduced a setting that allows users to completely disable pull requests or limit them to collaborators with write access. The product team described the targeted issue as "large-scale AI mess," referring to maintainers overwhelmed by low-quality submissions generated by models, which are quick to produce but time-consuming to review. GitHub then imposed caps on the number of pull requests a person can open, specifying that those created by Copilot or other AI agents are included in this calculation. By June, similar restrictions were applied to issues. According to the author, the volume of work generated by AI shifts the bottleneck to the available human attention, rather than the speed of production.

When AI codes, humans arbitrate: the Bun case and the shift of the bottleneck

Bun, described as a JavaScript runtime now owned by Anthropic, illustrates this shift: its creator noticed that thousands of issues opened on GitHub were already formulated as requests for an agent and proposed to entrust them to Claude to generate pull requests, publicly inviting the submission of well-reproduced bugs. According to the author, in a concerned team, the problem does not disappear but shifts to human review. This team reportedly stated that they had not written code themselves for months and had rewritten about 960,000 lines of Zig to Rust in a week, primarily with AI. The bottleneck then becomes the review and validation of the produced work.

Assigning a position to each agent: Linux containers and live supervision

A monitored team found the limits of cohabiting multiple agents in the same repository, with destructive commands launched without coordination. They chose to isolate each agent in a distinct virtual office, in the form of a Linux container with its own file system, browser, terminal, and editor, where it can install its dependencies. The rendering, accelerated by GPU and using streaming techniques akin to cloud gaming, allows for live observation of activity, including from a phone. For front-end development, the fact that the agent can see and test what it builds in a real browser is deemed essential. This model also facilitates handover across time zones and understanding of the codebase by observing the agent's navigation in the editor. Watching the agents' work helps keep everyone involved in the engineering process.

From on-prem to a two-door kanban: specify, validate, code, merge

Part of an on-premise solution to run models on internal servers, the team was led to focus on coding, realizing that existing tools were poorly suited for teamwork. They added a kanban layer above the virtual offices, with each card representing a task the size of a user story. The cycle begins with a simple request, then an agent reads the codebase and writes a three-part specification: requirements, technical design, implementation plan. A human validates the specification, the agent builds, and then a code review precedes the merge. Two approval doors structure the flow: specification and code. The first, short and in Markdown, is intended for humans, while the pull request can extend over thousands of lines. Spotting an error early is less costly. To facilitate this, the team developed a collaborative view allowing for line-by-line annotation of the specification; these comments are relayed to the agent as constraints. Engineers describe their main activity as searching for the few misunderstood lines in these documents.

What works and what gets stuck: framed tasks yes, exploration no

According to the author, this method works particularly well for tasks with a clear outcome. As soon as the activity becomes creative or exploratory, it encounters difficulties.

Automating the process, not just the flow: the organizational chart rather than the swarm

The author identifies the true limit in the decision gates that punctuate all information jobs: collect, decide, act for a manager; build, test, approve, deliver for a quant. He distinguishes workflow, a fixed sequence of steps, from process, which adds judgment and arbitration to achieve a broader goal. Traditional automation tools model the former but fail as soon as the sequence depends on context. In contrast, large language models respond better to high-level objectives, allowing for the automation of processes that incorporate judgment. The author criticizes the swarm model of agents, which he sees as lacking shared context and overall improvement, and proposes relying on the organizational chart, a universal model of delegation and responsibility, integrating non-human colleagues. This vision fits within a spectrum of AI adoption and the idea of treating agents as entities to "hire," in a context where the main challenge becomes human attention and verification.