An AI coding assistant can open a pull request in the time it takes to read the ticket. Claude Code and tools like it now draft real changes against real repositories, and Australian engineering teams are already shipping with them. The effect is that the bottleneck has moved. The constraint is no longer how quickly someone can write the code. It is how carefully someone reviews it before it reaches production. When a model writes the change, a senior engineer still owns the decision to merge, and that review is where correctness, security, and accountability actually live.
Why AI pull requests need a sharper review lens
A human author and an AI author fail in different ways, and that difference matters for how you review. A junior developer might misread a requirement, but they usually write code that reflects one consistent mental model, so their mistakes cluster together and are easier to spot. Claude produces code that reads cleanly and looks confident even when a detail is wrong. That is exactly why a rushed review can approve a subtle error. The output is plausible, and plausible is not the same as correct.
There is a real cost to getting this wrong. A single production incident traced back to an unreviewed change can cost a mid-sized Sydney firm around $45,000 once you add engineering time, customer impact, and the scramble to ship a fix. For a business that handles personal information, a data-handling slip can trigger obligations under the Privacy Act and a mandatory notification to the regulator. A structured review is cheap insurance against expensive outcomes, and it takes minutes rather than hours.
The checklist every AI pull request should pass
Run every AI-written pull request through the same set of questions. The goal is not to slow the work down. It is to make the review repeatable, so quality does not depend on whether the reviewer happened to be sharp that particular afternoon. Group the questions into four passes.
Correctness and intent
Start with the requirement, not the diff. Read the ticket first, then read the code, and confirm the change does what was asked rather than what the model assumed.
Does the change solve the actual problem described in the ticket, or a nearby problem the model invented for itself?
Are the edge cases handled? Empty inputs, null values, timezone boundaries, and large payloads are where AI-written code tends to go quiet.
Has anything outside the scope been deleted or rewritten? AI edits sometimes reach past the task and touch code they were never meant to.
Do the variable and function names describe what the code really does, or do they simply sound plausible?
Security and data handling
Never skip this pass, especially for anything that touches customer data, payments, or authentication. Australian businesses carry obligations under the Privacy Act, and APRA-regulated firms answer to CPS 234 on information security, so a weak review here has consequences well beyond the codebase.
Is every piece of user input validated and sanitised before it reaches a query, a shell command, or a template?
Are secrets, API keys, or tokens hardcoded anywhere they should never be committed?
Does the change log or expose personal information it has no reason to handle?
Are authentication and permission checks still enforced on every new code path?
Tests and proof it actually works
AI tools will happily write tests that pass without proving much of anything. Read the tests with the same care as the code they are meant to cover.
Do the tests assert real behaviour, or do they only confirm that the function ran without throwing an error?
Is there a test for the failure case, not just the happy path?
Did the author run the full suite, and can you see it pass in the pipeline rather than take it on trust?
Scope, dependencies, and style
The final pass is about fit. A change can be correct on its own and still be a poor addition to the codebase.
Has a new dependency been pulled in? If so, is it genuinely needed, actively maintained, and licensed for commercial use?
Does the code follow the conventions of the files around it, or does it import a different style entirely?
Is the pull request small enough to review honestly? If it runs to 900 lines, send it back to be split into smaller pieces.
Making the checklist stick in your team
A checklist only helps if the team uses it the same way every time. Put it directly in the pull request template so every reviewer sees the questions before they approve. For a team shipping dozens of AI-assisted changes a week, the gap between an ad hoc review and a consistent one shows up in the defect rate within a month, not a quarter.
It also helps to be clear about accountability. The engineer who approves the merge owns the change, not the tool that drafted it. That framing keeps the review honest. Claude is a fast and genuinely capable author, and it is at its best when a person with judgement signs off on the result. Several teams we work with across Melbourne and Sydney have recovered close to $30,000 a year in engineering hours by making that first review pass structured instead of freeform.
AI-written code is not going away, and the teams that come out ahead treat review as a discipline rather than a rubber stamp. If you want help shaping a review process that fits the way your engineers already work, we can map it out together.
