Who Should See AI Plan Review Findings First?

We talk to a lot of cities about AI in plan review, and nearly everyone is asking some version of the same two questions:

Should we adopt AI?

If we do, how accurate is it?

Both are important questions. But we think there are two others that cities should be asking first: Where should AI sit in our workflow? And who should see its output first?

Those two decisions matter more than you might think. An AI tool can be genuinely helpful in one part of the process but runs the risk of creating more problems than it solves in another. And which situation you end up in can come down to who sees the AI findings first.

Here's how we think about it.

AI can help at several points in the permitting process

When people talk about AI in plan review, they're often talking about automated code compliance checks. Can AI read a set of plans, compare them against adopted building codes, and identify potential violations?

That's an interesting application, but it's only one of several AI applications that plan reviewers should be excited about.

At ePlanSoft, we think there are at least five places where AI can help cities and their staff:

1. Pre-submittal applicant guidance. Helping applicants understand submission requirements, answer common questions, and prepare their materials before they submit an application.
2. Intake screening for review-readiness. Checking incoming applications for missing documents, incomplete plan sets, or other issues that prevent a submission from being ready for review.
3. Automated code review with findings. Evaluating plans against adopted codes and local amendments to identify potential compliance issues.
4. Reviewer assistance. Helping reviewers navigate plan sets, index sheets, find information, develop comments, and identify changes between submissions.
5. Inspection support and records retrieval. Helping inspectors and other staff find relevant information from approved plans, permits, and historical records.

What makes these five applications different isn't just the technology involved. It's the work we're asking AI to do and where that work happens in the permitting process. Helping an applicant figure out what to submit is a very different job (with very different stakes) from helping a reviewer decide whether a plan meets code.

And in most cases, the job makes it pretty obvious who should see AI's output first. Applicant guidance goes to the applicant. Reviewer assistance goes to the reviewer. Inspection support goes to the inspector.

But automated code review is different. You can put essentially the same technology in two different places in the process, show its findings to two different people, and end up with very different consequences when it gets something wrong.

Why it matters who sees the output first

Consider two ways automated code review could work.

In the first, an applicant submits a set of plans. Before those plans reach a professional reviewer, AI identifies what it believes is a code violation and tells the applicant what needs to change.

In the second, AI identifies the exact same potential violation, but presents it to a professional reviewer first. The reviewer evaluates the finding, considers the context, and decides whether to accept, modify, or reject it.

Both approaches could be described as AI-powered code review, and both are trying to accomplish essentially the same thing. But they create very different experiences for the people involved, particularly when the AI gets something wrong.

Let's say AI identifies a potential code violation that turns out not to be a violation at all.

If the finding goes to a reviewer first, the reviewer can dismiss it. The mistake stays inside the department. Maybe it costs the reviewer a few seconds, but the applicant never sees it.

Now imagine that finding goes directly to the applicant. They might spend time revising a perfectly acceptable plan, or contact the department for clarification. Eventually, a human reviewer may have to explain that the original AI finding was incorrect.

From the applicant's perspective, that's understandably frustrating. They followed guidance provided through the city's permitting process, only to have the city contradict it later. And now the reviewer is left sorting out the confusion.

None of this means applicant-facing AI is a bad idea. In fact, the potential benefit is enormous. If applicants can identify and correct legitimate problems before formal review, cities could reduce unnecessary back-and-forth and help projects move through the process faster.

But that benefit depends on whether the AI's findings are consistent with the decisions the department's reviewers would actually make. And the more directly AI communicates a judgment to an applicant, the more confidence you need in that judgment.

That's why, here at e-PlanSoft, we believe professional reviewers should generally see AI-generated code compliance findings first.

We build the system where reviewers do their work, and our broader approach to AI in plan review is to automate the predictable tasks while keeping professional judgment in the hands of reviewers.

The extra benefit with this approach is that it also gives cities a practical way to build confidence in the technology. Over time, they can see which findings their reviewers consistently accept, which they reject, and which types of checks might be safe to move earlier in the process.

In this conversation, ePlanSoft CEO Debra Senra explains why the placement of AI in the plan review workflow matters, and why cities need to think carefully about who sees its findings first.

Start with the work, not the product

There's a lot of attention around AI-powered code review right now, and understandably so. The prospect of catching code issues before they reach a reviewer is compelling.

But we're concerned that the attention on this particular application is causing cities to approach AI adoption backward.

They hear about a new product, see a demonstration, or read about another jurisdiction experimenting with AI, and the conversation immediately becomes whether they should adopt something similar.

We think there's a better way to approach it, and it starts by looking at your own permitting and plan review process.

Where is work getting stuck? Are applicants submitting incomplete plan sets? Are reviewers spending too much time organizing files or comparing resubmissions? Is staff time being consumed by repetitive administrative work? Or is substantive code review genuinely the biggest bottleneck?

Once you've identified the job you want to improve, you can start thinking about where AI could help and who should see its output first. Only then can you make a meaningful judgment about how accurate it needs to be, what an acceptable error looks like, and whether a particular product is right for your department.

And depending on the job you're trying to accomplish, you may find that some of the less glamorous applications of AI are the ones that offer the most immediate value.

A better way to evaluate AI in plan review

We believe AI has an important role to play in the future of electronic plan review. But not every AI application needs to solve the same problem, and not every application should be held to the same standard.

A tool that helps a reviewer find information in a plan set is fundamentally different from one that tells an applicant their building plans violate code. Cities should evaluate them differently.

So before asking whether you should adopt AI, we'd encourage you to start with the work you're trying to improve. Figure out where AI belongs in that process, who should see its findings first, and what level of accuracy the job requires.

Those answers will put you in a much better position to decide which applications of AI are actually worth pursuing, and which ones aren't ready for your department just yet.