Human Effort as an Attention Filter

The discussion around "If you are asking for human attention, demonstrate human effort" hit a live nerve because many teams now face the same overload. AI made polished communication cheap. Human attention stayed scarce.

That mismatch changes the social contract around technical work. A long issue no longer proves that a reporter investigated the bug. A smooth pull request description no longer proves that the author understands the change. A confident architecture proposal no longer proves that the proposer read the code. The old signals lost information value.

Teams need new signals.

The Collapse of Polished Text as Proof

Before generative AI, writing a coherent issue, proposal, or review request required effort. That effort did not guarantee quality, but it filtered out some careless work. A maintainer could assume that a detailed bug report represented at least a little time spent with the project.

AI weakens that assumption. A user can paste an error message into a model and receive a detailed issue in seconds. A developer can ask for a PR description that sounds careful. A job applicant can produce a tailored cover letter for hundreds of roles. A vendor can send personalized outreach at scale.

The text may be useful. The recipient still needs a way to know whether a person inspected the result and owns the request.

Technical Attention Filters

For technical teams, the best filters are artifacts that connect the request to reality:

Request Type	Weak Signal	Stronger Signal
Bug report	Long explanation	Minimal reproduction, version info, expected and observed behavior
Pull request	Polished summary	Tests run, risk notes, reviewed AI output, linked issue
Architecture proposal	Broad claims	Constraints, rejected alternatives, migration plan
Security report	Urgent language	Concrete exploit path, affected versions, proof with safe reproduction
Support request	Descriptive paragraph	Logs, timestamps, tenant ID, exact action attempted
Hiring message	Smooth cover letter	Specific product observation, relevant project, technical tradeoff

These signals cost more than generated prose because they require contact with the system. That is the point. They show that the requester spent effort in the same reality as the recipient.

AI Output Should Be Labeled When It Consumes Review Time

Teams need a norm that labels AI output when it affects someone else's attention.

For code review, the label can be simple:

I used an AI tool to draft the first version of this change. I reviewed the diff manually. The risky part is the auth middleware path. Tests run: pnpm test auth.

That note gives reviewers three useful pieces of information: the author used a tool, the author took responsibility, and the author identified the review target. It avoids the awkward theater where a reviewer has to infer whether they are reviewing the human's work or a model's uninspected draft.

For documents, the same rule applies. If a model generated a proposal, the author should add commentary that identifies which parts they believe, which parts they are unsure about, and what evidence supports the recommendation.

Unlabeled delegation creates the review burden.

Maintainers Need Better Intake Design

Open-source maintainers will feel this pressure first because their intake surfaces are public. Issue templates and contribution guidelines used to be etiquette tools. They now function as attention defense.

Good issue templates ask for:

• Version and environment.
• Reproduction steps.
• Expected and observed behavior.
• Minimal code or repository.
• Logs and screenshots where relevant.
• Confirmation that the reporter searched existing issues.
• Confirmation that the reporter can help test a fix.

The template should reject vague reports before a maintainer spends time. Automation can help here. A bot can detect missing reproduction steps or ask for environment details. The trick is to keep the automation specific and reversible. Maintainers should not replace one flood of AI text with a flood of bot nagging.

For pull requests, projects can ask authors to include:

• Scope summary.
• Files that deserve close review.
• Tests run.
• Backward compatibility notes.
• AI assistance disclosure, if used.
• Screenshots or traces for UI and agentic behavior.

This may look bureaucratic. It saves human attention when the project receives many submissions from people who can generate convincing prose faster than maintainers can read it.

The Reviewer's Side

Recipients also need discipline. When polished text is cheap, reviewers should read for evidence first and style second.

For an issue, look for reproduction. For a PR, look for tests and risk notes. For a proposal, look for constraints and tradeoffs. For a cold email, look for evidence that the sender engaged with your actual work.

This shifts review from "does it sound professional?" to "does it contain costly, grounded information?" That change helps non-native English speakers and concise writers too. A short report with a reproduction should outrank a polished paragraph with no evidence.

Product Opportunities

Developer tools can support the new norm.

GitHub, GitLab, and similar systems could expose structured fields for AI-assisted work: generated summary, human-reviewed checklist, tests run, risk area, and reproduction artifact. Code review tools could highlight large generated diffs that lack tests or ownership notes. Issue trackers could prioritize reports with runnable reproductions over long text.

AI tools themselves can help by generating evidence requests rather than final-seeming prose. A bug-report assistant should ask for version, reproduction, logs, and expected behavior. A PR-description assistant should inspect the diff, identify risky files, and ask the author to confirm tests. The tool should make the human review step explicit.

A Practical Standard

I would use this standard inside a technical team:

1. AI-generated material can enter the workflow.
2. The person submitting it owns it.
3. Requests for review must include evidence beyond prose.
4. AI assistance should be disclosed when it shapes code, claims, or review load.
5. Maintainers can close requests that lack reproduction or ownership.

That standard respects AI as a useful writing and coding tool while preserving the scarce resource: the focused attention of people who can judge, debug, merge, and maintain.

Human effort does not have to mean hand-writing every sentence. It means attaching proof that a person understood the system, checked the output, and accepted responsibility for the next human's time.

Intake Design for AI-Heavy Teams

Teams should redesign intake surfaces around evidence. The form should ask for the artifact before it asks for prose.

For a bug report, ask for:

1. Reproduction URL or repository.
2. Exact version.
3. Expected behavior.
4. Observed behavior.
5. Logs, screenshot, or trace.
6. Whether the reporter can test a fix.

The text box comes after those fields. A model can help the user fill the text box, but it cannot replace the evidence. If the required fields are empty, the system should treat the report as incomplete.

For a pull request, ask for:

1. Type of change.
2. Risk area.
3. Tests run.
4. Files that need close review.
5. AI assistance disclosure.
6. Rollback plan for behavior changes.

This structure protects reviewers. It also helps authors. A developer who used an agent to produce a patch now has a checklist for human ownership.

A Better AI Assistant for Maintainers

Many current AI helpers generate nicer prose. Maintainers need assistants that reduce ambiguity.

A maintainer-focused assistant should:

• Detect missing reproduction steps.
• Compare the report against known issues.
• Ask for exact versions when absent.
• Extract logs and error codes.
• Identify whether the issue affects docs, build, runtime, or security.
• Draft a response that requests the next missing artifact.

The assistant should avoid closing issues without human review in high-friction communities. Automated closure can feel hostile, especially to new contributors. The better path is to make the missing evidence obvious and easy to supply.

For PRs, an assistant can map the diff to review areas: database migration, auth path, UI copy, dependency change, generated code, test-only change. That helps maintainers assign review attention. It is more useful than a paragraph that says the PR "improves the codebase."

The Social Contract

AI changes the cost of producing requests, so teams need a visible social contract:

• If you ask for review, show evidence.
• If you submit generated work, inspect it first.
• If you ask a maintainer to debug, provide a reproduction.
• If you use AI to write a proposal, add your own position.
• If you cannot provide evidence, say what blocked you.

This contract should appear in contribution docs, PR templates, onboarding guides, and internal engineering norms. The point is not to shame AI use. The point is to keep attention attached to responsibility.

Sources

• Tom Bedor: Human attention and human effort