AI agents have made building cheap, so the decisions that matter now come before the build. These include what to make, what a prototype must prove and what an agent may do alone. Three writers describe ways to put those decisions in writing early, where other people can dispute them.
Dominik Schmidle (15 Oct · 01) writes for Giant Swarm, a company that helps platform teams run Kubernetes, the software many firms use to run applications across servers. Pull requests from its staff and their AI agents rose from about 700 a month to more than 2,100 within a year, more than reviewers could read. The team moved human review to a written plan, which people argue over and merge before AI agents write the code. Agents check each factual claim in the plan against the real code, and a separate step tries to shrink or cancel the plan. Most code changes then merge without a person reading them, unless the plan shows they touch a public interface or security.
Uditi Sharma (15 Oct · 02) is a product manager who writes a newsletter about product management for AI products. She disputes the common advice that AI prototyping makes the written requirements document unnecessary. When preparing for a senior product manager interview at Hopper, a travel booking app, she built a working AI booking assistant and also wrote several versions of the requirements document. In her account, the prototype showed how the experience felt, while the documents explained the reasons, the scope and the measures of success. She suggests writing down, before building, the one question a prototype must answer and the result that would change the plan.
Jakob Nielsen (15 Oct · 03) is a usability researcher who writes the UX Tigers site. He describes a newer kind of AI product, the always-on AI agent, which holds a standing goal and acts without being asked, such as OpenAI's Dots and Meta's Muse. He argues that these agents create problems a chat window never had, such as a passing remark that the agent turns into a permanent rule. His guidelines include asking whether an instruction applies once or from now on, and listing every standing rule on one page the user can revoke. He also recommends a visible status, so that a silent agent cannot hide the fact that it has stopped.
All three pieces move the human decision earlier and into writing: a merged plan, a card that names the prototype's one question, and a page of an agent's standing rules. In each case a person can read, dispute and withdraw the decision without reading the code or watching the agent work. The comparison is an inference across three separate pieces, and none of the authors makes it.
Giant Swarm's process depends on strong tests and local test environments, and written plans may simply move the unread pile from code to documents. Nielsen also says the evidence on always-on agents is thin, so his guidelines are informed opinion rather than tested findings.
Giant Swarm moved human review from code changes to a written plan, so people settle intent before AI agents build and most code merges unread.
Product manager Uditi Sharma argues that AI prototypes show how a feature feels but do not replace the written document that explains scope and success.
Jakob Nielsen sets out design guidelines for always-on AI agents, including scope checks on instructions, a single page of standing rules and a visible status.