Test suite generation
You inherit a legacy service with almost no tests, and someone proposes an agent that generates a test suite for it. Design that agent: what it uses to decide what to test, what makes a generated assertion meaningful rather than coverage theater, and who reviews what it writes. Coverage will jump either way — so what would you actually measure to know the tests have value, and how do you make the case that this beats hand-writing them?
triage_generated_tests(assertions: list[str], mutants_killed: list[int]) → list[str][["result is not null","cart total equals 42 for three items"],[0,4]]out["reject","accept"][["response status is 200","handler does not throw"],[1,5]]out["review","reject"][["discount is applied once per order","user id is not none"],[3,2]]out["accept","reject"]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.