When AI agents make changes cheap to produce, the scarce resource becomes people who can explain and judge those changes. Three pieces from the past four days describe how that judgement fails quietly, and what teams can measure before it does.
Paul LaPosta, a DevOps and cloud infrastructure leader, writes for LeadDev, a publication for engineering leaders (1 Oct · 01). He starts from a failed change that was rolled back quickly with little harm to customers. The team could show what changed, who approved it and what the tests said, but nobody could explain why it failed. LaPosta argues that AI tools have lowered the cost of producing a change without lowering the cost of understanding it. His test is to ask the team that owns a critical service to explain its recent changes without its go-to engineer and without the AI tool. If the team cannot, he says it should have the authority to delay a release before any reliability target is breached.
Jakob Nielsen, the usability researcher who writes at UX Tigers (1 Oct · 02), makes a parallel argument about the people who approve an AI agent's actions inside a product. He cites a 2026 study by Ting Yan, in which 113 adults supervised a simulated AI assistant that attempted seven actions nobody had asked for. People who wrote standing permission rules in advance blocked 40 percent of those actions, against 60 percent for people who approved every action by hand. Nielsen recommends asking rarely, tiering approvals by consequence and offering undo for actions that can be reversed. He also says teams should log how long approvals take and how often people say yes, because very fast approvals mean the check has stopped working.
Lenny Rachitsky, who writes Lenny's Newsletter for product managers (1 Oct · 03), published every main-stage talk from his summit and summarised what the speakers agreed on. The speakers disagreed about software factories, roadmaps and whether product managers should ship to production. They agreed that choosing what to build and knowing what good looks like matter more as building gets easier. Rachitsky concludes that product, design and engineering roles are expanding rather than merging into one "builder" role. Robby Stein, a product vice president at Google Search, said the value of a product manager now lies in judging and taste.
All three pieces place the risk after the build, at the point where a person must explain or judge what an AI agent produced. LaPosta and Nielsen both propose measuring that point directly, through who can explain a change and how quickly approvals are given. One inference follows, and it is not the authors' claim. The explanation of an agent-built change has to be held by the whole owning team, not only by its builder or its tool.
LaPosta gives no data from any team. Nielsen's study involved people with no software background supervising a simulated assistant, so neither piece shows that trained engineers or designers lose judgement in the same way.
Paul LaPosta, a DevOps leader writing in LeadDev, an engineering leadership publication, argues that AI makes changes cheap to produce but not to understand.
Jakob Nielsen, a usability researcher, argues that people approving an AI agent's actions stop paying attention, and that products should ask less often and offer undo.
Lenny Rachitsky, who writes Lenny's Newsletter for product managers, reports that summit speakers disagreed on process but agreed that judgement matters more as AI makes building easier.