Tom Moor of Linear explains how his team carries product history from an incoming request through implementation and review.
What the code leaves out
- An agent can read a codebase and still miss customer intent, earlier trade-offs, ownership, related work or recent reversions.
- Moor argues that maintaining a coherent product becomes harder as implementation gets cheaper; that is his assessment, not a measured result.
Enrich the issue before building
- Linear’s triage agent groups incoming reports, handles duplicates and routes work to the right people.
- It can add customer requests, logs, related issues and prior decisions to the issue for the next human or agent.
- In one example, it reproduced captions turning on and found a browser action mistaken for user intent.
- Small bugs can trigger automatic fixes; verification and continuous-integration failures feed back to the coding agent.
Review the product decision
- A separate review agent considers the original issue, product history, reversions, incidents, related changes and the coding-agent session.
- Moor describes a warning about a database transaction, a previously rejected UI icon returning, and a label-order regression.
- The database example is a team anecdote, not a controlled comparison of review tools.
- Review surfaces should also identify the people who need to make product trade-offs, not only code owners.
Turn feedback into future context
- A daily automation examines merged changes, review comments and reversions for actionable lessons.
- It writes lessons into agent instructions or documentation; Moor cautions against letting those instructions grow indefinitely.
- Fewer wrong changes and less rework are the intended benefits, not results quantified in the talk.
“Our judgment matters more as code gets cheaper.”