your first open-source contribution in 2026: what to hand the agent, what to keep for yourself

Hacktoberfest 2026 dropped the PR count. The DEV challenges this year are about building new projects with open-source AI, not farming pull requests. Good. The old format pushed people to open five shallow PRs, and in 2026 an agent can open five shallow PRs before your coffee is done.

But making a real contribution to someone else's project is still one of the best things you can do as a new dev. The question has changed, though. It used to be "how do I write this fix?" Now it's "which parts of this should I do myself, and which should I hand off?"

Here's how I split it.

hand these to the agent

Environment setup. Cloning, installing deps, getting the test suite green on your machine. This is pure friction, and nobody's career got better because they spent four hours fighting a lockfile. Let the agent read the README and CONTRIBUTING and get you to a working build.

Mapping the codebase. "Where is X handled? What calls this function? Which tests cover this file?" An agent with repo access answers these in seconds. Use it like a very fast senior dev you can interrupt as much as you want.

Reproducing the bug. Have it write the smallest script or test that shows the failure. This is mechanical, and having it in hand changes everything that comes after.

The boring parts of the diff. Boilerplate, test scaffolding, lint fixes, formatting, updating every call site after a rename.

First draft of the PR description. You'll rewrite it, but starting from a draft is faster.

keep these for yourself

Picking the issue. Read the whole thread. Who's the maintainer, what did they already reject, is someone else working on it, is this actually wanted? This is judgment about people and project direction. It's the skill that makes you useful on a team, and an agent skimming the thread won't pick up the subtext.

Watching it fail yourself. The agent writes the repro. You run it and look at the output until you understand why it fails, not just where.

The code path your fix touches. You don't need to understand the whole repo. You do need to understand every line you're changing and the two or three functions around it. Here's the test: could you defend each line in review with the agent closed? If not, you're not ready to open the PR.

Scope. Agents love to "improve" things nearby. Deciding what not to change is half of what maintainers are judging. Small, boring, focused PRs get merged. Sprawling ones get closed.

The review loop. When a maintainer asks "why did you do it this way?", the answer comes from you. Pasting their comment into an agent and pasting the reply back is the fastest way to burn trust in a project. Use the agent to make the change they asked for, not to talk for you.

Enough git to dig yourself out. Rebasing on main, fixing a conflict, squashing commits. The agent can run the commands, but when your branch is a mess at 1am you need to know what state you're in.

a workflow that actually works

1. Find an issue labeled good first issue or help wanted in a project you actually use. Read the thread and CONTRIBUTING yourself.
2. Comment that you'd like to take it. Wait for a yes if the project works that way.
3. Agent: set up the env, map the relevant files, write a failing test.
4. You: run it, read the code path, decide on the fix in plain words before any code exists.
5. Agent: draft the diff. You: read every line, cut anything out of scope, run the tests.
6. Write the PR description yourself: what was wrong, what you changed, how you tested it. Link the issue.
7. If the project asks about AI use, say so honestly. Many projects now have a policy. Read it.
8. Handle the review yourself.

why bother learning the "keep" list?

Because that list is the job now. Typing code is cheap. Knowing what's worth changing, getting a change past a maintainer, and being trusted with a codebase is the skill that compounds. If you hand all of it to the agent, you end up with a merged PR and nothing learned. If you do all of it by hand, you're training for a version of this work that's already gone.

Do the middle path once this month on a real project, and you'll learn more than any number of shallow PRs would have taught you.

i'm building easable around this exact split: give it a goal and a deadline, and it works out what you should learn yourself vs. what tools should handle. it's early, there's a waitlist at easable.app if you're curious.