Sunday
18 October 2026

As AI agents make code and prototypes cheap, teams are deciding in writing which work a person must check and which ideas have earned more effort. The rules sit in build checks and roadmap reviews, so people spend their attention where the risk and the doubt are.

Will Larson, who leads engineering at Imprint, a financial technology company that runs credit card programmes, describes one such rule (18 Oct · 01). Imprint's average engineer now merges four times as many pull requests as two years ago. The typical review now takes 77 minutes, up from 33. His team built a "small-change" check that the build runs on every pull request. A change qualifies when it is under 1,000 lines and has no serious findings from the AI review tool. Its author also needs ten or more merged changes in that service. An AI review skill then either approves an eligible change or ignores it, and never leaves comments.

The team that builds Claude Code, Anthropic's AI coding agent, goes further (18 Oct · 02). Addy Osmani, Morgan Westlee Lunt and Qing Wang write that Claude writes about 90 percent of the product's code. Every change passes AI review, security review and automated tests before a person looks. A classifier then sets how many people must approve it, from none for documentation to two for the riskiest code. An agent's approval never fills a human slot, and the person who directed the agent counts as a reviewer. From June to September, merged pull requests more than doubled while the share reverted fell by more than 40 percent.

Paul Boag, a user experience consultant writing in Smashing Magazine, describes the opposite pattern across whole companies (18 Oct · 03). Many companies buy one AI tool for every employee, give generic training and add long lists of rules. Staff who cannot do their work with the approved tool open personal accounts instead. He cites a user experience team whose plans for an AI research repository stalled while a steering group weighed a different tool. He argues for short principles, time to experiment and learning from what staff do outside the rules.

Marty Cagan, who founded the Silicon Valley Product Group, a firm that advises companies on product management, names the pressure behind much of this (18 Oct · 04). He writes that AI has made plentiful output with few results a bigger problem than ever. In his view, the real trade-off is between results and predictable delivery dates. Most companies choose the dates and hope that results follow from shipping what was promised. He also faults product managers who put untested ideas on roadmaps with dates attached.

Petros Bountis, a director of product engineering who writes the newsletter The Socratic Leadership, offers a check for those roadmaps (18 Oct · 05). Before engineers estimate an item, its owner answers five questions in writing. They cover the customer behaviour behind the idea, the change it should make and the single belief it rests on. They also ask what cheap evidence would prove it wrong and what result would stop the work. Contracts and regulatory deadlines keep their dates on the roadmap, while untested bets get a funding window and a condition for stopping. His example, an invoicing feature that took two teams most of a year and was used by four accounts, is invented to illustrate the method.

Ravi Mehta, who writes the product newsletter Top 1% Builder and previously worked at TripAdvisor, applies the same discipline to prototypes (18 Oct · 06). He gave an AI prototyping tool a requirements document that a TripAdvisor team had spent six weeks writing, and had a working prototype in about 20 minutes. The prototype also made choices he had never approved, such as removing a saved place without asking for confirmation. He argues that each prototype should be built to answer one named decision. Before launch, a formal step should ask whether the work deserves the customer's attention.

Imprint and the Claude Code team write their review rules down and let the build enforce them, so people review by risk rather than by habit. Bountis and Mehta ask for the same kind of written rule earlier, before a roadmap item gets engineers or a prototype gets built. Cagan and Boag describe companies that reward promised dates or set rules far from the work, where output grows and the risk goes unseen.

Both engineering accounts are early or self-reported, and Anthropic sells the review product it describes. Imprint's rule covers about 10 percent of its changes so far, so the gains may not hold as more code skips a human reader. The three essays describe methods and beliefs, with no measured results from a team that adopted them.