Pull request summarization
Suppose we deploy an agent that writes the description and summary for every pull request automatically. Some argue a wrong summary is worse than no summary at all. Design the agent with that risk in mind: what it reads, when it should decline to summarize, and how reviewers know how much to trust it. How would you measure summary accuracy before rollout, and what evidence would convince you — and the team — that it's a net win?
pr_summary_decision(files_changed: int, lines_changed: int, generated_files: int, distinct_areas: int, has_linked_ticket: bool) → str[3,120,0,1,true]out"post-high"[12,600,0,5,true]out"withhold-mixed"[30,900,0,2,true]out"withhold-oversized"Turn the fuzzy goal into a bounded agent task. Say what the agent reads, what it may do on its own versus draft for a human, and what it must never touch. Then earn the trust: how you’d verify it before rollout, and the pitch (the problem, what you built, why it matters).
Agent build: design the agent in plain language (or narrate it). The coach grades the decomposition, the guardrails, the verification plan, and the pitch.