Proof of Effort: Combating AI-Generated Noise

If You are Asking for Human Attention, Demonstrate Human Effort | Tom Bedor's Blog

The only way to get a human to actually listen to you now is to prove you spent time on the request. We're drowning in AI-generated noise. When a teammate sends over a block of code or a debug summary, the first thing most of us do is scan for the tells of a LLM. If it looks like a raw prompt output, we subconsciously value it less.

It's a weird new etiquette problem. On one hand, an AI that has deep access to our internal codebase and docs can produce something genuinely useful in seconds. It's efficient. But forwarding that raw output to a colleague feels like a shortcut that signals a lack of effort.

We've reached a point where the quality of the answer matters less than the perceived work that went into it. So, where do we draw the line between being productive and being lazy?

The Signal-to-Noise Crisis

LLMs have made the cost of generating "perfect" communication zero. When everyone can produce a polished, professional email in two seconds, the polish itself becomes a signal that the content is low-effort. We're seeing a psychological shift where we no longer value efficiency; we value evidence of human effort. If a message looks like it came from a template, it's ignored.

This creates a weird paradox for developers. We're told to automate everything, but automating our communication makes us invisible. I've noticed that a messy, bulleted list with a few typos often gets a faster response than a perfectly structured proposal because the former proves a human actually sat there and thought about the problem.

The technical way to fight this is to stop using LLMs for the final output and start using them for the raw synthesis of data. Use the model to extract the 4 or 5 most important points from a log file or a thread, then write the actual message yourself.

import re

log_data = "ERROR 404: Not Found; INFO: Heartbeat; ERROR 500: Internal Server Error"
errors = re.findall(r"ERROR \d+: \w+ \w+", log_data)

print(f"Found {len(errors)} critical issues: {errors}")

It's a clumsy workflow, but it's the only way to ensure the signal actually reaches the other person. If you automate the delivery, you're just adding to the noise.

Applying the Effort Principle

Generic outreach is a waste of time. When you send a template to 50 people, you're signaling that the recipient is interchangeable. The Effort Principle is simple: the amount of effort you put into a request is the strongest signal of how much you actually value the other person's time. If your request takes 30 seconds to write, it's reasonable for the recipient to spend 30 seconds deciding to ignore it.

Specificity is the only way to move the needle on response rates. Instead of asking for "feedback on a project," you should point to a specific line of code or a specific design decision. This changes the cognitive load for the recipient. They don't have to figure out what you want; they just have to answer a concrete question.

If you're automating this process, don't use a generic script. Use a structured format to track exactly why you're contacting a specific person. This part is genuinely confusing for some because people mistake "personalization" for "flattery." Telling someone you like their blog is flattery. Telling them how their specific implementation of a Raft consensus algorithm solved a race condition you're currently facing is a technical observation.

outreach_queue = [
    {
        "contact": "jane_doe@tech.io",
        "target_repo": "distributed-db-core",
        "specific_interest": "The implementation of the write-ahead log in commit.sh",
        "question": "Why choose a circular buffer over a linear log here?"
    }
]

for request in outreach_queue:
    # This ensures the message contains a concrete technical hook
    print(f"Emailing {request['contact']} regarding {request['specific_interest']}")

The difference in results is usually stark. I've seen response rates jump from 5% to 40% just by swapping a "hope you're doing well" intro for a technical observation. It's a trade-off: you send fewer emails, but the ones you do send actually get read.

Proof of Work in Communication

The debate over "slop" isn't really about quality—it's about the social contract of communication. When I see people arguing that AI-generated walls of text create "cognitive debt," they're talking about the hidden cost of processing a message that took zero effort to produce. If you spend twenty minutes polishing a technical proposal to make it digestible for your team, you're signaling that their time is valuable. If you dump a raw LLM output into Slack, you're effectively offloading the labor of editing and synthesis onto the recipient.

I think the counterargument—that the "result" is all that matters—ignores how trust works in a technical organization. We don't just trust the data; we trust the person who vetted the data. When the effort (the proof of work) disappears, the signal for accountability disappears with it. If a document looks like it was generated in three seconds, I'm going to scrutinize it more, not less, because I can't be sure the author actually understands the nuances of what they're sending.

This means we're heading toward a weird inversion where "unpolished" or idiosyncratic writing becomes a proxy for authenticity and competence. I suspect we'll see a shift where the most respected engineers are the ones who explicitly avoid AI for high-stakes communication, precisely because the friction of writing is where the actual thinking happens.

The real question is whether we can actually maintain a culture of "proof of work" when the volume of generated content makes it impossible to tell who did the heavy lifting.

Conclusion

The reality is that we're drowning in low-effort content, and AI just gave everyone a bigger megaphone to scream into the void. Most of the "communication" we're seeing now isn't actually communication; it's just noise that looks like a professional email.

I'm still not convinced that a few productivity hacks can fix this. If the cost of sending a message drops to zero, the value of that message usually follows.

The only real filter left is effort. If you want someone to actually pay attention to you, you have to do something that a prompt can't. The question is: how much friction are you actually willing to tolerate to be heard?