In the AI Era, Code Is Cheap. Reputation Isn’t.

Source: Dev.to

Source: Dev.to

In the era of AI it’s easier than ever to be an Open Source contributor!

But, at the same time, and quite paradoxically, it’s harder than ever.

Why? Because it’s now mechanically easier, but reputationally harder.

Previously you competed against other incredibly smart volunteers, employed developers contributing their expertise in free time, or newcomers.
Now you compete against all of that and an army of AI agents generating pull requests, issues, refactors, and vulnerability reports faster than any human can.

It’s tempting. Using an LLM can dramatically reduce the cognitive work required to understand a codebase and to produce a valuable change request. Things that were previously “very hard” are now a few prompts away, lowering the entry barrier for contributions—great! But it also creates a massive increase in volume, which is flooding repositories.

What’s the problem?

• Maintainer capacity did not increase
• Review cost did not decrease

These two truths have already forced maintainers to resort to drastic measures, like what happened with curl:

How to Become a Valuable Open‑Source Contributor in the Era of Infinite Code Generation

Below are practical tips distilled from handling a large volume of contributions.

1. Think. Then think again.

AI can generate brilliant code and the worst code ever written. The outcome hinges on:

• Prompt quality
• LLM capability
• Context you provide
• Your own coding abilities (the most important factor)

Why you need to know how to code before using LLMs

An LLM can’t know everything. Consider this PR that attempted to replace console.error with a logger:

// Original
} catch (error) {
    console.error('Some error:', error);
}

// LLM‑generated change
} catch (error) {
    logger.error('Some error:', error);
}

At first glance the change looks fine—swap console for logger.
The problem: the project recently changed the logger’s typings, so the above code no longer type‑checks.

A valid change would be:

} catch (err) {
    logger.error({ msg: 'Some error', err });
}

Higher‑quality models (Claude, Codex, etc.) might catch the issue, but many will not—unless you ask the right question. You can’t prompt for something you don’t know exists.

Key point: You cannot prompt for what you don’t know exists.

A contributor who trusts an LLM blindly will miss type‑checking errors, ignore project conventions, and overlook caveats. For such programmers, LLMs become a mechanical aid, freeing mental bandwidth for the real work—thinking and reviewing. This protects your reputation: maintainers will notice a pattern of low‑signal PRs and may stop reviewing them (or worse). LLMs speed up contribution, but they don’t replace your brain unless you let them.

2. Respect volume. Review is not free.

Open‑source work is noble: it makes repositories safer and sharpens your skills—a win‑win. However, maintainers have:

• Limited capacity
• Limited time
• Limited patience

Consider these realities:

• The cost of opening a PR is now near zero.
• The cost of reviewing a PR is not.

This asymmetry creates the real tension of the AI era.

If you:

• Comment “please review” repeatedly,
• Ping maintainers aggressively,
• Demand specific merging timelines,

you increase the cognitive cost of your contribution—even if the PR is valid.

Harsh truth: Maintainers are human. If interacting with you feels expensive, they may subconsciously deprioritize your work, resulting in fewer reviews, merges, and release‑note mentions.

When you use LLMs or agents, you can generate dozens or hundreds of PRs quickly. If maintainers can’t review them all, many will simply be ignored. That’s effectively a Denial‑of‑Service (DoS): you’re sending more requests than the maintainers can process.

3. Deliver quality that doesn’t cut corners

Maintainer capacity is low. In the past month we:

• Closed ~700 issues (stale, invalid, or already fixed)
• Received ~300 new issues

Some were valid; many were not. We have to check every issue manually because we can’t know in advance which are worthwhile. An LLM can’t reliably filter “slop” because the model itself may be trained on noisy data.

Related example: HackerOne Curl report – a case where maintainers dealt with AI‑generated vulnerability reports.

How to respect maintainers’ time

• Validate locally before opening a PR (run tests, lint, type‑check).
• Follow project conventions (naming, documentation style, commit message format).
• Provide a concise description of what the PR does and why it’s needed.
• Limit the scope: one logical change per PR.
• Avoid “spammy” behavior (repeated pings, demanding merges).

Be human. Respect the maintainers’ time and work.
How? Help them reduce the cost of reviewing your code.

TL;DR Checklist for AI‑Assisted Contributions

By combining AI’s speed with your own expertise and respect for maintainers, you’ll become a valuable contributor rather than a source of noise. Happy coding!

Before Submitting

• Did you reproduce the issue yourself?
• Did you run CI locally?
• Did you include screenshots for UI changes?
• Did you provide benchmarks for performance claims?
• Did you include a PoC for security reports?
• Did you check if a feature request already exists?

Checklist

• If you claim a performance improvement, show numbers.
• If you fix a bug, explain the root cause.
• If you propose a feature, ask first.

High‑quality contributions get reviewed faster.
Low‑signal contributions accumulate and slow everyone down.

In the AI era, reputation compounds. When maintainers can trust you, your PRs are reviewed faster and you’ll feel happier—a win‑win!

4. Bundle Trivial Changes

Typos and small mistakes happen. For example:

Before

if (!sub) {
    throw new Error('subsciption not found');
}

After

if (!sub) {
    throw new Error('subscription not found');
}

The bug is the missing r in subscription. The contribution is valid—we want correct English.

Does it deserve a PR?

Not by itself, but it can be combined with other small fixes. If you find ten misspellings, which approach is easier for maintainers?

• 1 PR with 10 changes
• 10 PRs with 1 change each

If you were the maintainer, which would you prefer?

Every PR incurs overhead: CI runs, notifications, review time, merge time, and mental context switches. Reduce that overhead by batching trivial work.

AI can generate an enormous list of fixes. If you tell an agent like Claude or “Clawd” “Hey, for each issue create a PR,” you’ll quickly become the most hated contributor on the project.

Don’t do that. Be mindful. Be human.

LLMs vs. Human Work

LLMs are fun, but human work is better. We can’t fight AI—it’s here to stay. What we can control is how we use it.

• GSoC values human contributions; that’s the program’s purpose: turning more humans into open‑source contributors.
• We need a new generation of maintainers who use LLMs wisely.
• LLMs can help you do amazing things, but they’ll never replace your unique human creativity.

It’s easier to contribute, but harder to stand out.

• Reputation matters.
• Trust is earned.
• You build it by doing good work.

Note: This is personal experience. Some projects have different rules—some might even welcome 1 000 PRs a day (unlikely, but who knows).

Bottom line: AI isn’t human, but maintainers and contributors are. Remember that.

Welcome to Open Source!

Further Reading

• AI is destroying Open Source, and it’s not even good yet – Jeff Geerge​ling
• Over the weekend, Ars Technica retracted an article because the AI a writer used hallucinated quotes from an open‑source library maintainer.
  • The maintainer, Scott Shambaugh, was harassed by an AI agent over “slop” code that wasn’t merged.
  • The bot was likely running on a local “agentic AI” instance (perhaps OpenClaw).
  • The creator of OpenClaw was recently hired by OpenAI to “work on bringing agents to everyone.”

Jeff Geerling’s site