With the July update, I talked about the very real gains we had seen at Onebrief by adopting an Outcome Engineering mindset, by focusing on using agentic AI responsibly to increase our capacity to meet critical user needs.

As we continue to expand how and where we collaborate with agentic AI, it is increasingly clear that Sean Connery was asking the right question.

What are you prepared to do?

Because once your team is really running faster, you run into all the interesting questions. Sure, you already cleaned up bad habits around using your backlog to manage priorities, but what about everything else that breaks at agentic speed?

While a short list would include GitHub actions, merge queues, test systems, o11y, and CI, I think the most important part of the development workflow to really wrestle with next is code reviews.

Different company and team cultures overload code reviews in all kinds of interesting ways. Mentorship, company norms, inter- and intra-team communication, shared liability, quality, design/experience alignment — if you name a product engineering skill or coordination challenge, you’ll probably find a team using code reviews as their primary tool for improving it.

And those use cases collide pretty horribly with agentic. Having humans stare at agentic code is both dystopian and isolating. Using tools designed to examine a few files is worse than useless on PRs agents are capable of delivering. Many of the communication, norm-shaping, and mentoring opportunities vanish when a 50,000 loc PR hits.

So, what are you prepared to do?

You could, of course, try to limit agentic development to human-like productions. Small, incremental PRs. Humans reviewing all of them as if their friends and colleagues wrote the code. While this might be an acceptable choice for some teams — probably the same teams most comfortable thinking about agentic as turbo-charged tab completion — it isn’t for me.

Our mission is too important and adversaries clearly aren’t slowing down.

So, I believe we need a lot of invention ahead of us around code understanding, risk management, and rethinking engineer onboarding and mentoring. All three of these used to depend on the gate of code reviews, but in an agentic world — as Rachel Laycock writes — these responsibilities can shift.

As Rachel writes:

And we know now it’s not viable to continue down this path, hence why code review keeps coming up as an issue or a blocker. If an agent can produce ten times the code but every line eventually queues up waiting for a senior engineer to inspect it, we haven’t created a ten-times engineering organisation, we’ve created a big backlog and a new bottleneck.

All the same capacity we are unleashing on product development needs to apply to tools, developer experience, incident response, and code understanding as well.

And for your use case and codebase, how do you answer questions like:

• What would you need for agentic code review to release a PR to production? Does it change if the code is agentic-produced, human-produced, or hybrid?
• What systems, files, user journeys always need human review?
• Who is responsible for showing up to the incident when a defect gets through?
• Do agentic investigations of the incident have to wait on human involvement?
• More broadly, blame (in the code sense), on-call, reviewer, and incident response used to be deeply related in many orgs. Who’s on the hook for an incident when no human touched the code last?

What answers do you want for these questions? How does the evolved version of code review support those goals?