System Conditions

Every engineering team I’ve worked on struggles with the same problem: reviewing Pull Requests (proposed changes to the code) and moving them through. It’s a constant. You have your own workload of tasks, and you also have the added weight of reviewing the code other engineers write. You don’t know when they’re going to request a review, so it’s usually reactive work. It’s not part of your set of tasks; it’s “another thing.” And there’s higher urgency on the author to move their work through than you have to stop your work and expend mental energy to review their work. Most teams use the “team mentality” cultural norm and hope that works:

“If we all just take a little time each day to review open Pull Requests, we’ll be good.”

Or so the thinking goes…

Now throw AI into the mix.

Pull Requests are opening at an even higher rate. Anthropic, the makers of Claude, shared that changes landing per day in their monorepo went from about 2,500 in May to more than 30,000 in September. 30,000! Per day! There are teams that would be lucky to get out 100 Pull Requests per week. Not all changes are equal, though. You could have a 10-line docs update or a 2,000-line update. I don’t know how the data Anthropic shared is being normalized, if at all. The trend is still consistent and directionally accurate.

GitHub just released its Octoverse 2026 report, sharing that:

Developers pushed code to GitHub 17.9 billion times in the past 12 months, more than in 2024 and 2025 combined.

The numbers are staggering. But they’re also not surprising; well, not to me. I spend time writing and reviewing code every day with Claude. I use it for a wide range of tasks, seeing it as a new intelligence at my disposal rather than a shortcut to my abilities and critical thinking. Like any tool, you can use it for good or for evil; to make yourself better or worse. I choose to find ways where AI can accelerate my thinking and understanding, and create space to do the messy creative work I enjoy most.

I spent a lot of time working on the process for code reviews this past week. Something I’ve learned about myself is how much I love designing systems. Complex systems require a deep understanding of the components, relationships, and principles governing them, which is the exact thing I talked about in System Reasoning. It’s also why I believe it’s so important to understand System Models. Reviewing code, like a lot of work, is changing. When you learn to see systems, sense where to make changes, and shape interventions to influence their output, you gain a superhuman ability to create change on a massive scale. You become a linchpin, not a cog, as Seth Godin would say.

It’s important to distinguish the difference between a process and a system. I define a process as a linear, sequential, deterministic set of steps to take inputs and convert them to outputs. Each time you run the process, you expect similar results. A system, on the other hand, relies on relationships and a rich network of dependencies. A system is emergent. Behavior emerges from the interactions between the components, making complex systems difficult to predict, hard to understand, and even harder to change. It’s the same reason you can’t yell at a garden and tell it to grow. It won’t work. And nature is a complex system. You need to understand the environmental conditions of the garden before you can influence its behavior:

• Is there enough sunlight and water?
• Are there enough nutrients in the soil?
• Are bugs attacking and harming the plants?

The conditions matter. If I want to improve the process for reviewing work and moving it through at the right pace, I need to first understand the current state, and which conditions need to change. Sure, I could write up a doc (or have Claude generate some AI-generated unreadable slop), but that’s not how you influence change in complex systems. Please don’t put more slop into the world. Don’t be a MPSCOF. You have to understand what conditions are creating the behavior before you can change them.

System behavior emerges from the conditions governing it

I looked at the past 100 Pull Requests as a sampling to understand review patterns. The majority of our reviews were handled by a few engineers. We have a small team, but it was a clear imbalance. So then I started to wonder why these engineers were disproportionately reviewing the work. In my experience, it’s usually the engineers with the most codebase knowledge who handle the reviews. But then I’ve also seen engineers who believe in the benefit of reviewing others’ code to improve their understanding of the work. My theory is that both of them are just very conscientious, and one of them fits into the “knows the code really well” category.

To get to something testable, I needed to understand what conditions to consider as part of my assessment. These are five conditions I consider when trying to understand and influence a complex system:

1. Relationships show the interactions.
2. Incentives show the motivations.
3. Constraints show the limitations.
4. Context shows the understanding.
5. Feedback shows the learning.

Relationships. There are relationships between engineers, services (Linear, GitHub, email), and even the AI bots reviewing code.

Incentives. There are specific reasons why code reviews even happen: team culture, job expectations, individual motivations.

Constraints. Skills, knowledge, experience, capacity, time, attention. An engineer is constrained by their knowledge of the system they’re reviewing, as well as their workload.

Context. The issue driving the Pull Request, the code changes (diff), and the engineer’s (or agent’s) description of the changes.

Feedback. Reviews from agents and human engineers, error reports, usage data, and feedback from customers and stakeholders.

You can try to define a simple process as a function that converts X into Y through Z, but I guarantee you’ll experience divergent responses the more you do it. Conditions must be cultivated before you can influence behaviors through specific interventions.

Intentional conditions create more reliable coordination

So then I thought, “what if I design the optimal conditions to create the right behaviors?”

What are the right relationships? How does the system interact today? Does the team review in GitHub or Linear? Are they using their agents to review the code? Are they testing the functionality or going line by line?

What are the right incentives? What’s making someone review someone else’s work? How do they feel about the priority of their own work and their review requests? How does someone who reviews more than the rest of the team feel about the work distribution?

What are the right constraints? What’s the right balance of your own work and work you need to review? How many PRs is too many to have open at once? How many reviews should one engineer be completing each day? Are there limitations to the size of each change?

What is the right context? What information is in the issue description? How is the PR described by the agent? What does a human need to understand about the changes to effectively review the work?

How do we capture feedback? How are reviews requested? Where do notifications show up? If something isn’t working, how do we know? How do we know when something goes out to production with problems?

That’s a lot of questions. And I’m sure you could think of even more. You don’t have to answer every question. You need to move into the solution space mindfully, intentionally, and with specific interventions designed to answer questions and validate assumptions.

So I designed a set of interventions whose purpose was to create the necessary conditions (relationships, incentives, constraints, context, feedback) to influence behavior:

1. Relationships. I built a new app called the “Review Queue” that pulls data from GitHub and Linear to capture the current status of reviews. The core purpose is to create visibility and a shared mental model of the system versus each team member interpreting their version, which creates a sprawling network of dependencies.
2. Incentives. The Review Queue makes it clear where the imbalances are. Those same engineers shouldering the load now show up loud and clear. I also created a companion job that runs every 15 minutes to assign a single engineer to review each PR. It’s based on their capacity and capability, not an arbitrary blast to everyone while hoping for the best. Our team works well with issues assigned to them, so PRs function the same now. And it looks at their Linear workload, so keeping it updated is a happy side-effect.
3. Constraints. The capacity of each team member is considered, so they aren’t assigned when they are overloaded. And the assignments rely on domain knowledge of specific areas, even in the age of agentic coding. I also added a check to auto-close PRs that have been sitting for 30 days. They get a comment and then automatically close 7 days later unless they’re updated. They say that time kills all deals, but I think the same applies to the work. Revisiting old PRs is rarely worth the cognitive energy. And you can always reference the changes as needed.
4. Context. I use my Equilio Coding skills, so my issues and PR descriptions represent the latest understanding of the work. Some engineers use their agent to review PRs, which skirts the line of meat-proxying because you’re only a conduit for the information instead of taking part in the process of understanding. It’s important to consider where human judgement matters most now when reviewing code. I built a new skill into Equilio Coding, called equilio-review, for walking through a PR and flagging key changes worth understanding. It works great, but be mindful of your tokens.
5. Feedback. We use CODEOWNERS files in GitHub to auto-assign people when a PR is opened, but the bots (Claude and CodeRabbit) do their review first. So then the engineer has to respond to those reviews, which means it’s not really ready for a human yet. So I removed those files and the job now waits for all of the bot comments to be resolved before it picks someone to assign. The timing and choice are intentional, and the same information is piped into our team chat so someone knows when their review is required.

Better coordination creates space for deeper understanding

Interventions in a complex system improve your understanding of it. Why? Because the behavioral changes generate new emergent properties you can inspect. Keep digging, testing, learning, and eventually you uncover the core purpose of the system.

For code reviews, the core purpose is evolving.

Instead of engineers reading each line of code to understand changes, maintain coherence, and create efficient standards, humans need to look to the System Model instead.

What are the key components of the system?

How do they interact with one another?

And what principles govern their behavior?

Components, relationships, and principles.

That’s the recipe for building a coherent understanding in the product and codebase, but you still need the same level of diligence working inside any complex system. Code reviews are only one example of the many sub-systems and sub-processes embedded in the working environment. Learning to see them is step one. Then you can sense and shape them.

You need to know what behaviors you want to emerge to stay mindful of the outcomes.

Considering the system for code reviews meant examining desired outcomes:

1. The workload for reviews is distributed across the team.
2. Individual review owners create an accountability contract.
3. Assignments consider each team member’s full pipeline.
4. Reviewers know what to focus on when reviewing changes.
5. Each reviewer knows how, when, and where to review work.

Collectively, the outcomes emerge from an intentional set of conditions. Instead of the cognitive energy expended on coordination, it’s spent on developing a deeper understanding of the changes made to the system—to the System Model.

If each engineer is doing code reviews differently, there are too many relationships to find the right intervention. If an engineer is told the expectation is a certain number of reviews completed per day or per week, they’ll focus on the wrong things. If some of the team is overloaded while holding too much of the review burden, there’s an imbalance. If engineers don’t have the right amount of context required to review, quality and coherence suffer. And if feedback is sprawling or infrequent, momentum is lost.

Relationships + Incentives + Constraints + Context + Feedback

They are independent and related, conditions built as components and relationships. It’s up to the system designer to find the right interventions. Knowing I want to help the team develop a deeper understanding of the System Model means designing a system with interventions that improve the conditions required for such behaviors to emerge. There’s only so much mental energy your team has. It’s a constraint. It should be focused not on nitpicking the names of React components, but on enhancing your understanding of key system changes: new changes to the shape of data, new use-cases in authentication handling, additional endpoints.

When I think about years of doing code reviews, the consequences of missing something are bugs, regressions, and second-order effects that can take years to surface. As AI and agents continue to write more of the code, the focus changes. The diff matters less than the intentions, impact, and verification in the design of the system.

Focus on conditions to influence the system.