Published: 2026-10-21

The speaker states that recent months have invalidated many of the principles on which software development practice rested. He attributes this to a sharp rise in the volume of code. He presents seven principles that his team and he have revised, along with the replacements they adopted. He describes most of the replacements as untested and says that their validity may change within months.

The Cause: Growth in Code Volume

Over the past year, the number of commits pushed to GitHub rose fifteenfold. The number of programmers stayed the same. The speaker attributes most of the new commits to automated agents rather than people. He describes the resulting volume of code as an avalanche that displaced many existing rules. In his view, the volume now determines the working rules for software development.

Summary of Revised Principles

1. Comments Are Replaced by Minimal Code

The speaker states that people no longer read code and that agents interpret source code directly. He claims that comments can confuse an agent when they differ from the code. He cites research showing that comments can cause confusion. He states that the research is two years old and that he believes the situation has worsened since then.

His team now prohibits comments in build scripts. The team bans all comments in Haskell and JavaScript projects. In Java projects, the team is moving toward a full ban. Source code in the team's projects contains no comments.

2. Legacy Code Is Revived

Under the previous approach, outdated code was rewritten, ignored, or discarded. The speaker now considers old repositories recoverable. He describes these examples:

• Static analyzer. The speaker created a Java static analyzer 10 to 12 years ago. The project was used widely, but it became costly to maintain. Over 10 years, more than 400 tickets accumulated in the backlog. In the spring, he asked Claude Code to fix all 400 errors, restore the codebase, update it, upgrade dependencies, and convert it into a clean modern project. The work took about one week. He reports that he did not edit the code manually. The result is a restored project with a clean backlog and only a few defects.
• Second project. The speaker cites an unnamed author who spent a year and a half on a similar task. That author then completed the restoration in three weeks for a few thousand dollars.

The speaker concludes that the team no longer classifies repositories as legacy. He describes the remaining old code as code that has not yet been processed by Claude Code or another agent.

3. Agents Replace Manual Triage and Review

The speaker previously held that a maintainer's core responsibilities were:

1. Triage: deciding whether an incoming report is a defect and routing it to the backlog or discarding it.
2. Review: evaluating diffs in change requests and deciding whether to accept them.

He states that personal attention to these tasks now harms a project because volumes are too large. He reports these figures for one of his repositories:

• About 1,500 stars.
• About 100 new bug reports each morning.
• About 10 active repositories of this kind, which means about 1,000 bug reports per day in total.

He states that he cannot process this volume manually.

His current setup uses agents that run every morning, or several times a day. The agents:

• Check incoming bug reports, accept those that describe valid bugs, and accept them on his behalf.
• Check pull requests and merge them automatically.

He reports that 40 to 50 pull requests reach the codebase each day without his review. He describes the project as active, in production, and in use.

The agent escalates changes that are too complex or too radical. In these cases, it does not merge the pull request. It assigns the speaker as reviewer. The speaker reports that a few such cases occur each day and that he reviews them manually.

The speaker states that he now trusts the agent as much as he trusts himself for this task. He concludes that human attention to these tasks has become a liability. He argues that the value of human reviewers is lower than the ability of machines to analyze changes and decide. He describes this as the reason human reviewers now reduce project quality.

4. Strict Rejection Replaces Courtesy

The speaker previously taught students that contributors in open source should be treated politely. He advised using courteous language, such as "thank you," "please," and "sorry," when rejecting contributions. He noted that contributors are an asset and may return with new changes.

He now states that pull requests come from automated tools operated by people who spend about 15 minutes generating them. He argues that such operators do not program and are not affected by the tone of rejection. He concludes that discussion with them has no value. He recommends the following approach:

• Reject changes that do not match the project's direction without negotiation.
• Use automated reject tools for this purpose.

He states that no one will be offended because, in his view, no programmer is present.

5. Automated Limits on Pull Request Size

Earlier, the team held that pull requests should be short. Changes of 100 to 200 lines were acceptable. Pull requests of 1,000 lines or more were considered inherently poor. Team members debated whether large features should be split. Some argued that a large feature could not be divided into five pull requests and that a single 1,000-line request was necessary.

Six months before the talk, the team added an automated check to its GitHub platform. The check applies to every pull request:

• If a pull request adds or removes more than 200 lines in total, CI marks it red and the check fails.
• The author cannot dispute the result through discussion.
• The author must split the change into two or three smaller pull requests and submit them separately.

The speaker states that the team plans to add more automated controls to reach zero tolerance for low-quality changes.

6. Human-Readable Test Artifacts and Impact Metrics

Test Design

The speaker wrote a two-volume book on unit testing in the last two years. He states that the guidance applies to machine readers now. People no longer read such material in detail when reviewing changes.

Because reviewers no longer read code changes, the team designs its codebase so that changes produce visual artifacts that people can read. The speaker gives an example from a parser for the team's own programming language. The parser takes a program as input and produces XML.

• Previous approach: A large number of Java tests each provided an input code block and an expected XML output, and compared the two.
• Current approach: The team kept one test and a large number of YAML files, called test fixtures. Each file contains a code fragment to parse and the XML fragment it should produce.

When a pull request arrives, the speaker reviews the YAML changes. He does not read the code changes, which he says he can no longer understand, including code written by his agents. He reports that he reads the YAML diff, checks the input and output pairs, and accepts a change when the result is correct. He rejects changes when the output is wrong.

The speaker states that code is difficult to read, while YAML is easier to read. He describes text files as the traces of test execution. Tests either generate these files or read them as a source.

He states that a dozen YAML changes per day can be reviewed quickly. He describes this as the solution to the volume problem.

Replacing Diff Review with Impact Metrics

The speaker cites a statement by Robert Martin, who wrote in the summer that he no longer reads source code. The speaker notes that the statement drew millions of likes. He states that the statement is consistent with his own practice. He argues that not reading code removes the bottleneck of human review and allows agents to deliver code faster.

For the past 50 years, reviewers used diffs to judge whether a change was good, based on knowledge of the architecture. The speaker states that his team no longer reads diffs, except partially. He adds that, in his view, diffs may disappear from GitHub within a few months. He says this with an admitted degree of exaggeration.

He recommends configuring CI so that each pull request reports its impact. The report should include:

• Changes in performance.
• Changes in visual artifacts.
• Changes in the amount of code.
• Changes in other measurable quality indicators.

The speaker states that the report should describe the consequences of a change in human-readable metrics, not the mechanics of the change. He argues that teams should focus on impact control tools rather than manual review and defect analysis.

7. Speed Replaces Stability in Continuous Integration

The speaker describes the original purpose of continuous integration as detecting build failures early through regular builds. He states that this approach fails at scale. A failure found the next morning stops the team, which must then fix code that a single programmer broke the previous day. He notes that teams sometimes used a "shame hat" for the person who broke the build. He states that the practice was humorous but stopped development.

The team adopted a preflight build. In this process, a build robot, not an AI agent, merges a branch into master, runs the build, and pushes to master only if the code compiles.

The speaker states that this approach no longer works for the team:

• The team receives about 100 pull requests per day.
• Each build takes about 10 minutes.
• Because each accepted pull request changes master, subsequent pull requests must be rebuilt after it. Builds therefore run sequentially, which totals about 1,000 minutes per day.
• GitHub Actions treats any change to master as invalidating open pull requests, because their CI results refer to the previous master. Authors must then run an update branch operation.
• GitHub does not allow the number of simultaneous builds that the workload requires.

The team tried to shorten builds by splitting the project. The speaker states that 10 minutes is the minimum for a 100,000-line codebase.

The speaker concludes that stability cannot be achieved at this volume and that the volume will continue to grow. He states that the team now assumes master is broken. Master becomes broken about twice a day. The team uses the following procedure:

1. Scripts monitor master and detect when it turns red.
2. When a failure appears, Claude Code is started immediately.
3. Claude Code fixes the defect and submits a new pull request.
4. The team accepts the fix, and development continues.

The speaker states that, in the new reality, master is broken almost all the time. He says he does not know another way to handle this condition. He states that the team concluded that stability is an idea from the past and that speed is the current priority. Code should reach master quickly, even at the cost of stability.