The reviewer in the age of AI

The people writing most of the world’s new software increasingly are not people. They direct, and they review. In October 2024, Google’s CEO told investors that more than a quarter of all new code at the company is generated by AI, then reviewed and accepted by engineers.¹Six months later, Microsoft’s CEO put the share inside his own company’s repositories at 20 to 30 percent.² This is how software gets built now, in the present tense.

The adoption curve underneath those numbers is nearly vertical. In Stack Overflow’s annual developer survey, the share using or planning to use AI tools climbed from 76% in 2024 to 84% in 2025.³ GitHub Copilot alone crossed 20 million users last summer.⁴ For a generation of engineers, describing a change in plain English and letting a model draft it has quietly become the default way to write the first version.

Here is a claim I cannot cite, only assert. At the most technically aggressive companies, well over 90% of new code is already written by AI today, with an engineer directing and reviewing rather than typing. The published figures, a quarter of new code at Google and up to 30 percent inside Microsoft, are company-wide averages: the trailing edge of the curve, not its front. Treat the exact number as a provocation if you like. The direction is not in question, and it forces one that should be: who is accountable when the machine writes the code?

The loop is closing: AI reviews code now, too

The more consequential shift gets less attention. AI is no longer only writing code. It is beginning to review it. One engineering-analytics platform tracked adoption of AI code-review agents climbing from 14.8% of teams in January 2025 to 51.4% by October, with the sharpest jump the week automated pull-request review became generally available.⁵ The machine now sits on both sides of the diff. It drafts the change, and another model is asked whether the change is any good.

If you stop there, it sounds like the human is being written out of the story. The evidence points the other way.

The almost-right problem

The defining failure mode of AI-generated work is not that it is obviously wrong. It is that it is plausibly wrong. Call it the almost-right problem. In the 2025 Stack Overflow survey, 66% of developers named “AI solutions that are almost right, but not quite” as their single biggest frustration, and trust in AI accuracy actually fell even as usage rose, with only about a third saying they trust the output.⁶ Confidence and correctness have come apart.

The gap is real, and it is easy to misjudge. A controlled trial from GitHub found developers finished an isolated, greenfield task 55% faster with an AI assistant.⁷ When METR ran a randomized trial with experienced open-source maintainers working in large, mature codebases in early 2025, the same class of tools left those developers 19% slower, even though they expected to be 24% faster and, afterward, still believed the tools had sped them up.⁸

The same tools that made a greenfield task 55% faster made experienced maintainers 19% slower, and neither group could feel the difference.

Same tools, opposite results, decided almost entirely by context. They help most where the stakes and the surrounding code are simple, and they can quietly cost you where neither is. Almost nobody notices in the moment. And the risk is not only speed. In a peer-reviewed Stanford study, participants with an AI assistant wrote less secure code than those without one, and were more likely to believe their code was secure.⁹ An analysis of more than 200 million changed lines found duplicated, copy-pasted code climbing from 8.3% to 12.3% of changes between 2021 and 2024, while the share that gets refactored and reused fell.¹⁰ Left unsupervised, AI will happily ship more code, faster, that is harder to maintain and more confidently wrong.

Why the reviewer matters more, not less

None of this argues against AI. It argues about where the scarce human skill has moved. When drafting becomes instant and nearly free, the bottleneck and the leverage shift to judgment: deciding whether the plausible answer is the correct one, and owning the consequences when it is not.

Even the most bullish numbers keep the human in the sentence. Google’s quarter of AI-written code is “then reviewed and accepted by engineers.”¹ Developers are most reluctant to hand over the keys at the exact moment of judgment: committing and reviewing code was the task they were likeliest to say they had no plans to automate.¹¹ The senior engineer was not made obsolete by the model. The senior engineer got promoted, into two jobs at once: the last line of defense, and the teacher who encodes hard-won judgment into the system so it catches tomorrow what it missed today.

Permit review is walking the same path

We build software for a different kind of review: the review a city does before it lets someone build. The shape of the problem is uncannily familiar. A residential permit plan is a dense, structured document that has to be checked, line by line, against an adopted code: setbacks, spans, egress, load paths, energy. Read the sheets, extract the values, apply the thresholds, flag what does not conform, on every plan and not only the ones a stretched department has time for. This is work AI is good at.

It is also where the almost-right problem turns dangerous. Picture a bedroom egress window on a basement remodel. The schedule lists a unit that looks compliant, and an AI reviewer reads the nominal size off the sheet and passes it. An experienced reviewer looks at the same window and checks the clear opening, the actual gap a firefighter in gear or a child has to fit through once the sash and frame are subtracted, and the real number lands just under code. The plan looked right. It was almost right. The difference is a bedroom nobody can escape in a fire. That is not a bug ticket you patch next sprint. It is a building that should not have been approved.

So the lesson from software is not “let the AI decide.” Put AI on speed and coverage, and keep the experienced reviewer where the judgment lives: ruling on every finding, catching what the model confidently passed, and teaching it the local knowledge it has not learned yet. The bottleneck gets squeezed from both sides of the counter. Applicants stop submitting the routine mistakes, and reviewers stop spending their scarce attention catching them.

Why we’re building Permitect

Anyone who has pulled a residential permit knows the process we want to replace. Getting a permit today is a months-long, back-and-forth negotiation. An applicant submits a packet, waits in the queue, and gets a correction notice for something small: a missing dimension, an incomplete energy form, a detail that does not match the plan. They fix it, resubmit, and wait in the queue again. Each round takes weeks, and the whole time the cost of holding the project keeps running: the crew, the financing, the family waiting to move in.

The people on the other side of the counter are not the problem. City reviewers are experienced and careful, and there are not enough of them. Departments are understaffed, the queues are long, and the pressure to build more housing, ADUs, remodels, and new homes keeps rising. Permit throughput has become a board-level municipal issue. The current process spends its most experienced reviewers on the same routine, mechanical mistakes, plan after plan, which is the work most worth automating and the judgment least safe to.

That gap is what we built Permitect to close. It is pre-flight linting for permits. Before an application reaches the city, we check it against the jurisdiction’s adopted code, request the right documents, and produce a packet built to pass the completeness check on the first try. We do not replace the city’s process. Applicants can always hand-submit on the portal they already use. We make what they submit correct before it gets there, so reviewers can spend their judgment on the decisions that actually need it.

We are deliberate about where accountability sits, because in this domain it is not abstract. The authority having jurisdiction stays accountable for the decision, the way it always has. Permitect approves nothing. Every finding is grounded: it cites the adopted code and the exact sheet, or it asks instead of guessing. The system surfaces and documents, a licensed reviewer rules on every finding, and the record shows exactly why. It is the same pattern that lets Google trust a quarter of its code to a machine: generated by AI, then reviewed and accepted by the humans who are accountable for it.

The age of AI review is coming to permitting, the way it came to software. The departments that thrive will not be the ones that hand the decision to a model, and not the ones that pretend nothing has changed. They will pair round-the-clock coverage with the judgment of reviewers who have read ten thousand plans and know which one does not add up. The reviewer is not being written out of permitting. The reviewer is being moved to the last line of defense, which is exactly where you want your best judgment to stand.

References

1. Sundar Pichai, “Alphabet Q3 earnings call: CEO Sundar Pichai’s remarks,” Google, Oct. 29, 2024. blog.google
2. Maxwell Zeff, “Microsoft CEO says up to 30% of the company’s code was written by AI,” TechCrunch, Apr. 29, 2025. techcrunch.com
3. Stack Overflow Developer Survey, AI section, 2024 & 2025. survey.stackoverflow.co
4. “GitHub Copilot users surpass 20 million,” reporting Microsoft FY25 Q4 earnings, Jul. 30, 2025. itbrief.news
5. “2025 AI Metrics in Review,” Jellyfish, Dec. 22, 2025. jellyfish.co
6. Stack Overflow Developer Survey, AI section, 2025. survey.stackoverflow.co
7. “Research: quantifying GitHub Copilot’s impact on developer productivity and happiness,” GitHub, 2022 (updated 2024). github.blog
8. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR, Jul. 10, 2025. metr.org
9. Perry, Srivastava, Kumar & Boneh, “Do Users Write More Insecure Code with AI Assistants?” Stanford, ACM CCS  ’23. arxiv.org
10. “AI Copilot Code Quality: 2025 Data,” GitClear (more than 200M changed lines, 2020–2024). gitclear.com
11. Stack Overflow Developer Survey, AI section, 2025 (task-level adoption). survey.stackoverflow.co