(Agentic) Lane Review
The Shifting Left You Couldn't Afford
Three weeks ago I closed a post on the Lean Discipline of AI Adoption at Settle — graduate from explore to exploit. DORA’s 2025 numbers landed the same week. Individual AI output up 21%. PR review time up 441%. Almost a third of pull requests now merging with no review at all.
The generation side of your team’s workflow shifted left. The verification side stayed where it was.
I owe you the discipline that closes that gap. Shift-left has waited 25 years for tooling that could carry it past testing. Larry Smith coined the term in Dr. Dobb’s Journal in 2001, framing it as “a better way of integrating the QA and development parts of a software project.” Each wave that came after moved exactly one discipline because the calendar set the ceiling. Testing in the 2000s. Security in the 2010s. Observability in the early 2020s. Designers, PMs, business operators, the customer — they never got a wave. There was no third option. There is now, and it’s agentic.
Coding agents make it economical to run every stakeholder’s review at every checkpoint, calibrated against the humans those reviews represent.
The discipline I want to give you next is called Lane Review.
A lane is the review you couldn’t afford before
For 25 years you couldn’t put a designer in every PR review. You couldn’t put a PM in every commit. You definitely couldn’t put your customer’s compliance officer in front of every diff. Those reviews stayed batched at the milestone, three weeks downstream of the decisions they would have caught.
A lane is what you build when a non-engineer’s review becomes cheap enough to run at every checkpoint your work passes through. An agent with its own context window, loaded with the role’s actual grounding documents, returning findings tagged by severity. The designer who knows your brand system. The PM who knows your locked positioning. The business operator who knows the take-rate. The customer personas your product serves, each with their own rules. Each becomes a lane.
Every checkpoint, not just the pull request
Lane Review isn’t only at the pull request. Every checkpoint your work passes through is a chance for the right lane to catch the right thing. Strategy review. Roadmap planning. PRD. Design doc. RFC. Pre-commit. PR. Pre-deploy. Release. Each checkpoint catches a different cost of bug.
A pricing-model conflict caught at the PRD is a one-conversation fix. The same conflict caught at the PR is a one-sprint rework. The same conflict caught at deploy is a customer Slack on Saturday morning.
The earliest checkpoint a lane can plausibly run is the cheapest fix. Lane Review’s discipline isn’t “run this at the push.” It’s “run this at every checkpoint where the lane has rules to apply, starting as far left as the lane has anything to check.” The lanes that show up at PR review still matter. The lanes that show up at the design doc save more.
Your team’s checkpoints will look different. The discipline is the same.
If you’re a leader trying to bring Lane Review into a workflow your team already owns, three steps, in order. At each step the team has a job and you have a job. Yours is what makes theirs possible.
1. Name the lanes that aren’t just engineering.
The team picks one workflow they ship through pull requests. They list every kind of review that should happen on every change but only happens at milestones. Not the engineering reviews you already have. The reviews the calendar wouldn’t let you afford. Design fidelity. Product positioning. Money-flow correctness. Compliance with the domain your customer operates under. Marketing voice. Most teams find a handful of items on the first pass. Almost none of them get caught at commit time today.
What the leader sets up is the grounding documents. Each lane only works if it has the documents it needs to actually check things. The brand book the design team carries in their heads. The ADRs the product team made over the last year. The pricing model your finance partner enforces in spreadsheets. The compliance checklist your legal counsel keeps in a drafts folder. Most of these documents exist in your company, scattered. Your job is to authorize someone to assemble them into a place a lane can read from. If the documents don’t exist, your team can’t build the lane. That’s not a tooling problem. It’s an artifact problem: the rules aren’t on paper. It’s a context problem: your agents have no context to work from. Solving both is leadership work.
This is where most attempts to copy what other engineering teams are doing with AI stall. Anthropic’s Code Review and Atlassian’s Rovo Dev are agents reviewing pull requests through engineering perspectives only. Atlassian’s runs across 1,900-plus repositories with a 30.8% PR cycle-time drop. Both leave the same gap your team has now. The lanes worth adding are the ones nobody else’s setup includes.
2. Build each lane as a grounded reviewer, not a persona.
The team builds each lane as an agent with its own context window. The lane is given grounding documents and a tight checklist of what it should flag. Findings come back tagged CRITICAL / HIGH / MEDIUM / LOW. The human triages. The agent does not autopilot the merge.
A lane is not single-prompt persona injection — the kind that, as a March 2026 study showed, can degrade output. A lane carries actual rules. A money-flow lane carries the pricing model and the take-rate as explicit rules. A customer-persona lane carries the rules of one user type your product serves: what they expect, what trips them up, what regulations govern them. The lane doesn’t imagine what its named role would catch. It runs what that role’s rule set says to catch.
The agent is a linter with a name tag.
And customer-persona lanes are missing from every published setup. Not the customer interviewed after launch. Not the customer surveyed in research. The actual rules of each user type your product serves, encoded as separate reviewers, running against every change. One lane per persona you serve. Those lanes are the existence proof that Lane Review is more than engineering specialties wearing different hats.
Every lane runs at every checkpoint. A lane that has nothing to flag isn’t sitting out. It’s confirming there’s nothing here its rules say to catch. “No concern from this lens” is itself a finding. The lane defines its to-do, even when it has nothing to do.
What the leader funds is the time to write the rules down. Most companies’ lane-worthy knowledge lives in the heads of one designer, one product lead, one finance partner, one customer-experience anchor. The team can’t ground a lane on knowledge that isn’t on paper. Your job is to commission the rule extraction. Not from the agent’s perspective. From the person’s. What do you check, when, against what? The artifact that comes out is the lane. The act of writing it down is half the value, before any agent runs.
The other half is keeping the lane calibrated. The person whose rules the lane carries reviews what it catches. Not every finding. Enough to confirm the lane still judges the way they would. Without the calibration loop, the lane drifts.
3. Gate each checkpoint on the lane findings, but don’t autopilot the fixes.
The team wires the lanes into the checkpoints. The pull request is the most-instrumented one today — every diff fans out to every lane, the findings come back tagged, CRITICAL blocks the push, HIGH surfaces for triage, MEDIUM and LOW go to the audit trail. The developer fixes the CRITICAL, decides on the HIGH, ships. Thirty seconds. Local. No CI queue.
The same gate mechanic ports to the other checkpoints. The PRD gets a gate. The design doc gets a gate. The deploy plan gets a gate. The earliest gate where the lane has rules to apply is the cheapest fix.
HubSpot’s Sidekick achieved 90% faster time-to-first-feedback and 80% engineer approval with this shape, using a judge-agent layer to filter low-value comments before they post. Without that layer, lanes generate volume. With it, they generate signal.
What the leader protects is the bypass economy. --no-verify exists. The lanes will sometimes be wrong. Engineers will sometimes need to skip. Your job is to make the bypass cheap enough that engineers don’t fight the gate, and visible enough that pattern abuse shows up in retros.
Lanes will sometimes disagree. The design lane says ship; the marketing lane says block. The human is the tiebreaker. Lanes surface; the human decides. Lanes don’t replace the stakeholders whose rules they carry. They shift the conversation earlier.
The questions you already ask, just six weeks late
You’ve sat in the same meetings I have. Product review on Monday. WBR on Tuesday. Roadmap review at the end of the month. Strategy review every quarter. Office hours every Friday.
In the product review you ask: who is the customer this solves for? How does this fit the roadmap? What does it trade off against? In the WBR you ask: why is this metric moving? What’s the root cause? When does it return to baseline?
In the priority review you ask: what’s the cost-benefit ratio? What’s the opportunity cost? What’s the sequencing logic? In office hours an engineer asks why the team is shipping the smaller feature first, and you walk them through the strategic theme that ties three quarters of work together. The answer they couldn’t see from inside their sprint.
Every one of those questions is a perspective. Every one of those perspectives catches something engineering review can’t. And every one of those questions arrives six weeks after the commit that should have answered it. The product-fit question lands at product review. The cost-benefit question lands at priority review. The strategic-alignment question lands in office hours. By then the team has shipped. The catch costs a rework cycle and a conversation that should have happened at the commit.
Lane Review is what those questions look like when they show up at the commit instead of the quarter. Each question becomes a lane. Each lane is an agent loaded with the questions you would have asked, grounded in the documents you would have referenced. The roadmap. The strategy memo. The operating principles. The priority framework. (Mostly the documents you wrote.) The lane doesn’t replace the meeting. It catches the answer that wasn’t ready by the time the meeting started.
The discipline scales down to a team of three and up to Atlassian’s 1,900 repos because the unit of work is the lane, not the team.
Validated learning was the executive discipline that got your team to Settle. Lane Review is the verification that holds them there.
The shift-left promise, fulfilled
Smith’s 2001 framing wasn’t about testing specifically. It was about integrating the disciplines that ship the product, earlier than the milestone. Testing was the first beachhead because it was the first discipline cheap enough to move. Security was the second. Observability was the third. Lane Review is the next wave, and unlike the previous three, it isn’t a single new discipline. It is every other discipline at once, finally affordable to attach to every checkpoint your work passes through. Agents make the math work. Humans keep it honest.
For your team this week: ask them which non-engineering review only happens at the milestone today. Just one. If they can name it, you have your first lane. Authorize them to assemble the grounding documents and protect them while they do.
For yourself, optionally: write the rule set for one of those reviews yourself before you ask your team to. If you can’t write the rules, the lane your team builds will be roleplay, not linting.
Which non-engineering reviewer would have caught your last incident?
#Leadership #AI #EngineeringLeadership #ShiftLeft #LaneReview #AIAdoption #CodeReview