Software engineer Tom Bedor has proposed a simple norm for teams adopting generative AI: a request for another person’s attention should show evidence of the sender’s own effort. The principle responds to a growing volume of machine-written debugging notes, documents and code moving through workplace review systems.

Bedor’s concern is not that AI output is inherently useless. He says tools connected to internal code and documentation can produce valuable material. The problem arises when producing text becomes much cheaper than carefully reading it. That imbalance can transfer the cost of checking relevance and accuracy from the person who generated the material to a colleague who did not ask for an unfiltered transcript.

The essay describes a design discussion in which a teammate used an AI system to critique Bedor’s proposal, then forwarded the result with a warning that they had not read it and that it might be inaccurate. For Bedor, the disclaimer exposed the etiquette failure: the sender was asking someone else to spend time on material they had not considered worth reviewing themselves.

His suggested practice has three parts. Machine-generated content should be clearly identified, the sender should add their own interpretation, and AI-written code should be checked by its requester before being submitted for human review. These steps do not certify correctness. They show that the sender has filtered the output, accepts responsibility for passing it along and can explain why it deserves another person’s time.

The proposal reframes AI use as an attention-allocation issue rather than a contest over authorship. Teams already depended on peer review before generative tools became common, and reviewers’ capacity remains limited. If automated systems greatly increase the amount of plausible-looking work, review demand can grow faster than the number of people available to perform it. Clear labels and prior human checking can help recipients judge what kind of scrutiny is required.

The essay does not supply survey data, productivity measurements or a formal policy tested across organizations. It is one practitioner’s rule based on a workplace experience. Different settings may need stricter requirements, particularly where code affects security, safety or regulated systems. In those cases, documented tests and accountable approvals matter in addition to personal commentary.

As a baseline norm, however, the proposal is concrete: automation may assist in preparing a message or patch, but it does not remove the sender’s obligation to understand what they are asking another person to review. The human contribution becomes selection, verification and context, not merely pressing the button that produced the initial draft.