The Pull Request: The cause of, and solution to, all of life’s problems
2026-10-21
I see two challenges emerging in software development as a result of AI coding.
First, pull requests are created faster and code reviews are becoming a bottleneck. I have seen calls to eliminate the PR and push straight to main as a way to remove the bottleneck.
Second, roles are blurring on teams that have traditional product/design/engineering roles. Non-technical team members find themselves able to solve problems that they could not before, but there may be technical or organizational blockers stopping them from getting these changes into the product. And if they are able to make a PR, this only further exacerbates the first problem. I believe these problems can be improved through the lens of open source.
Open source projects are familiar with both of these challenges.
Anyone can submit a PR to an open source project. That’s the greatness and the challenge of open source. A farmer using software to manage his farm can spot a problem, write a fix, and submit a PR. They don’t need to be a software engineer. PRs can come from anyone, anywhere, at any time.
Internal software teams have been mostly shielded from this public PR firehose. Engineers work closely within their engineering teams, review each other’s code, and are able to have some baseline level of trust in each new PR. Now, AI makes it easier for anyone in the organization to contribute. A designer can skip Figma and fix a UI issue directly in the code. A product manager can make a small improvement without going through requirements, design, and engineering. A QA engineer can find, and fix, a bug. A backend engineer can contribute on the frontend, or a mobile engineer on the web. Just like open source, anyone can contribute.
So how does open source deal with all these contributions? Maintainers.
Trusted maintainers understand a project, review contributions, and decide what gets merged. Many maintainers were the original authors of the project, but they do not need to be. They can be someone who has taken ownership of the project and guides it with both strong technical judgment and strong communication and collaboration.
The answer for internal teams is not to remove PRs, but to make PRs the main focus. Put more attention on PRs team-wide. Allow anyone to create PRs and make them easier to create. Encourage and empower all team members to contribute. Allow the process behind creating a PR to be flexible. Define clear standards and guidelines for contributions. Put more work into managing and guiding PRs. Write clear and detailed issues that PRs reference. Make it clear who maintainers are and put them in charge of reviewing and managing PRs. Allow maintainers the freedom to determine the depth at which to perform code reviews. These are things good open source projects do.
This also makes the value of different roles clearer. Roles are not defined by output like code or design files or documents. They are defined by expertise. Design, or code, or product, or platform expertise can be used in many ways and come in many forms during the development of a contribution. Contributions can come from a single person, but often they will come from cross-discipline teams. These teams should freely self-assemble to obtain all the expertise needed to develop a project.
The more people that care about and contribute to a product, the better that product will be. With new tools, more people in organizations can now contribute, and teams that adapt to accept these contributions will thrive.
Salisbury is on a peninsula, separated from western Maryland by the Chespeake Bay, with only one 
