Forem: VH Costa

Code Is Cheap. Review Isn't.

VH Costa — Wed, 29 Apr 2026 22:13:19 +0000

AI made it easier to produce code-shaped output. Good contribution still means making your work easy to understand, review, and trust.

You can now produce a pull request in the time it takes to make a coffee.

Often less.

This depends on the coffee, obviously. If you grind the beans, heat the water properly, and have opinions about extraction, the pull request may win by a comfortable margin.

That should make us pause.

Fast tools are useful. A coding assistant can help you read unfamiliar code, sketch an approach, write a test, or spot an edge case you would have missed. There is no virtue in doing everything the slow way just because it gives the work a faint smell of candle wax and suffering.

The problem starts when the diff becomes almost free.

A pull request has never been only a diff. It asks someone else to spend attention, apply judgment, take responsibility, and decide whether this change belongs in a project other people depend on.

That cost still lands on a human.

Ashley Wolf on the GitHub Blog recently described open source as entering its own “Eternal September”: contribution friction has dropped, volume is rising, and maintainers are having to respond with better trust signals, triage systems, and project-level controls. The key sentence is brutally simple: “The cost to create has dropped but the cost to review has not.” (Source: GitHub Blog)

Abigail Mayes, also on the GitHub Blog, made the same point in their writing on mentorship in the AI era, noting that developers merged nearly 45 million pull requests per month in 2025, up 23% year over year. More pull requests. Same maintainer hours. (Source: GitHub Blog)

That is the bridge from “Don’t Open a Pull Request Yet”. In that piece, the point was: learn the project before asking it to absorb your change.

This is the next step: once your work reaches a maintainer, make the review cheaper than the diff was to create.

A pull request is a question

A pull request looks like a contribution because GitHub gives it a nice interface.

It has a title. It has a diff. It has a button. It may even have a green checkmark, which is the software equivalent of a tiny approving priest.

But to a maintainer, a pull request starts as a series of questions:

Is this needed?
Is this correct?
Does this fit the project?
What behaviour changes?
What did the author test?
What happens if we merge it and they disappear?

The code matters. Broken code is rarely rescued by a charming personality. But the diff alone does not answer enough.

A one-line change can still be expensive if it arrives without context. Someone has to work out why it exists, whether the issue is real, whether the change is too narrow or too broad, whether it matches the project’s direction, and whether the contributor can respond to review.

That is why “small PR” and “easy PR” are different things.

A small PR changes few lines.

An easy PR reduces guesswork.

Aim for the second one.

The new problem is polished uncertainty

Polished uncertainty is work that looks credible before anyone knows whether it is correct.

That is the new burden.

Weak contributions used to look weak faster. Not always. People have been confidently wrong for longer than we have had package managers. But there were usually signs. The issue description was vague. The patch ignored the contribution guide. The author had not read the surrounding code. The proposed fix had that special “I changed the thing that looked closest to the error message” aroma.

AI changes the packaging.

A shallow contribution can now arrive with a polite description, a reasonable structure, a test plan, and the emotional posture of a senior engineer in a calm meeting room.

Lovely.

Now someone has to find out whether any of it is real.

The Register recently reported on this shift in curl. Daniel Stenberg, curl’s founder and lead developer, said the project had largely stopped receiving obvious AI-slop security reports. Instead, it was receiving more good-looking, AI-assisted reports, faster than before, which still created a growing workload because maintainers had to verify them. (Source: The Register)

Obvious nonsense is annoying. Plausible uncertainty is expensive.

When something looks credible, you cannot dismiss it quickly. You have to inspect it, reproduce it, and compare it against the project’s actual behaviour rather than the story around it.

Developers already know this feeling from their own AI-assisted work. Stack Overflow’s 2025 Developer Survey found that 84% of developers use or plan to use AI tools, while 46% said they do not trust the accuracy of AI output. The most common frustration was AI answers that are “almost right, but not quite”, cited by 66% of developers. (Source: Stack Overflow)

“Almost right” sounds harmless until you have lived inside it.

It means the import exists, but not in this version. The API call is real, but the arguments are wrong. The algorithm works for the example, then quietly eats the edge case. The explanation sounds confident until you realise it skipped the one constraint the whole project cares about.

Clean code can still be the wrong code. A passing test can still test the wrong promise. A tidy refactor can still erase a weird-looking behaviour that was there because three users, one browser, and a printer from 2011 formed a pact with the underworld.

Maintainers know this because they have seen the ghosts.

A contributor who wants to help should respect that. The goal is not to perform confidence. The goal is to make verification cheaper.

Make verification cheaper

This is the contributor standard I would use now:

A good contribution reduces the amount of guessing required to review it.

That applies whether you used AI or not.

Before you open a pull request, make sure the reviewer can see the path from problem to change. Do not make them reverse-engineer your reasoning from the diff like a crime scene investigator with worse lighting.

A useful pull request explains:

what problem you are solving
where that problem was discussed or observed
why this change is the right size
what alternatives you considered
what you tested
what could still be wrong

That last part matters.

A contributor who says “I am least sure about this branch because I could not find an existing test for this behaviour” is easier to review than one who arrives with a polished paragraph of total certainty.

Total certainty is cheap now. You can generate it in seconds.

Specific uncertainty is more useful. It tells the maintainer where to look. It shows that you understand the edge of your own understanding. It turns review into collaboration instead of excavation.

A good pull request does not need a novel attached.

Please do not write a novel. Maintainers have families, hobbies, pets, and in some tragic cases, other repositories.

But the PR should contain enough context to be reviewable without guesswork. For many projects, that means five small things.

First, link the reason. If there is an issue, discussion, bug report, failing test, or documented confusion, point to it. If there is no prior discussion, explain why you are opening code first.

Second, explain the change in project terms. “Refactored logic” is vague. “Moves validation before normalisation so invalid input fails before it reaches the parser” is useful.

Third, describe the test. Name the command you ran. Mention the case you added. If you did not test something, say so. Silence does not create confidence. It creates homework.

Fourth, keep the diff aligned with the claim. If the PR says it fixes one bug, it should not also rename files, reformat half a module, and introduce a new helper because the old one offended your sense of symmetry.

Fifth, stay available. A pull request is a conversation until it is merged or closed. If you disappear after opening it, the maintainer has to decide whether they are reviewing a contribution or adopting an orphan.

That is the minimum. Not perfection. Reviewable shape.

Use AI before you ask for attention

There is a good way to use AI in open-source contribution.

Use it before the public part.

Ask it to explain unfamiliar code. Ask it to compare two possible fixes. Ask it to list edge cases. Ask it to help you turn messy notes into a clearer issue comment. Ask it what assumptions your approach might be making.

Then do the work a contributor has always had to do:

Read the relevant files. Run the tests. Check the project’s conventions. Compare your change with past pull requests. Remove the parts that are too broad. Write the explanation yourself.

The public artefact should show your understanding, not the tool’s fluency.

A useful rule:

Do not submit anything you cannot explain with the tab closed.

This is responsibility, not purity.

The maintainer is not merging your chat transcript. They are merging a change into a living project.

Your name is on the work. Your judgment has to be in it.

That also gives us a practical rule for disclosure: disclose when AI materially shaped the code, test, security claim, or design choice.

GitHub’s recent writing on mentorship in the AI era uses three filters for deciding where maintainers should invest attention: comprehension, context, and continuity. Does the contributor understand the problem? Have they given enough information to review the work? Do they keep engaging after the first interaction? (Source: GitHub Blog)

AI use can affect all three. The point is not to force ritual humiliation. Nobody needs a little badge that says “assisted by robot, spiritually complicated”.

The point is to help the reviewer calibrate.

A simple note is enough:

I used an AI tool to help trace the call path and draft the initial test case. I reviewed the final change manually and can explain the touched code.

That tells the maintainer where the tool helped, and where your judgment entered the process.

The dangerous version is unowned work. If the tool wrote something you do not understand, you are handing the project an IOU made of fog.

Do not do that.

Boundaries protect useful attention

When projects tighten contribution rules, it is easy to read that as hostility.

Sometimes it is. Some communities do become opaque, defensive, or needlessly sharp. “Quality standards” can be a real principle, or it can be a decorative shield for bad manners.

But many boundaries are less dramatic than that.

They are attention budgets.

GitHub has shipped repository settings that let maintainers disable pull requests entirely or restrict them to collaborators. It describes these controls as useful for read-only projects, mirrors, or projects that want to share code publicly without managing outside contributions. (Source: GitHub Changelog)

That sounds severe until you remember the imbalance.

A contributor may spend ten minutes generating a patch. A maintainer may spend forty minutes proving it does not belong. Repeat that across a popular project, and the “open” in open source starts to feel less like generosity and more like an inbox with a roof leak.

Clearer rules are not automatically a rejection of newcomers. Done well, they protect the conditions that let good newcomers receive real attention.

If every drive-by patch gets a careful mentorship session, nobody gets mentored for long.

The boring skills got more important

There is a comforting fantasy that better tools make fundamentals optional.

I would love this to be true. I have many fundamentals I would like to place gently in a lake.

But better generation makes review skill more important.

When code appears quickly, you need a stronger model for deciding whether it deserves to stay. That means reading code carefully. Understanding tests. Knowing how data moves. Noticing ownership, boundaries, side effects, and failure modes.

This is where the C Systems Lab bias enters the room wearing steel-toed boots.

Low-level programming is not useful because everyone needs to write C every day. Most people do not. The world has suffered enough segmentation faults for several lifetimes.

It is useful because it makes certain review questions harder to avoid.

Where does this memory live? Who owns this resource? What happens at the boundary? What does the caller assume? What fails if the input is weird? Which part of the system now has to carry the cost?

Those questions still matter when the code is written in a friendlier language. They matter even more when the first draft came from a machine that can produce plausible code without understanding the project’s ghosts.

Machines remain machines, even when the assistant explains them in a soothing voice.

So yes, learn the boring things. Not because boredom is noble. Boredom is often just bad documentation wearing a tie.

Learn them because they make you harder to fool.

Trust is the contribution

The first post ended with a simple idea: good contribution starts before the pull request.

This one adds the pressure of 2026: the pull request itself is easier to produce than ever, so the work around it matters more.

Do not let the tool’s fluency become your public judgment. Do not make maintainers guess why your change exists. Do not send code you cannot explain once the tab is closed.

The diff is the visible part.

The contribution is the trust you build around it.

Everything else is just another notification.

Don't Open a Pull Request Yet

VH Costa — Tue, 28 Apr 2026 23:51:18 +0000

How to become a genuinely useful open-source contributor before you write a line of code.

You want to contribute to open source, but you do not want to be that person.

Not the one who opens a pointless pull request just to add their name to a README.md. Not the one who pastes in AI-generated code, wraps it in a polished PR description, and assumes “looks right” means “is right”. And not the one who leaves a maintainer with more work than before they saw your name in the notifications.

That fear is healthy.

Because the uncomfortable truth is this: a lot of visible contribution is not useful contribution. A maintainer is rarely asking, “Did this person submit something?” They are asking three quieter questions:

Is this needed?

Is this correct?

Is this easy to trust?

Most weak contributions fail on one of those three points before the code itself matters.

That is why good open-source contribution starts earlier than most people think. It does not start with a pull request. It starts with context.

Context comes first

People love to say, “Just find an issue and start.”

That is fine advice if your goal is activity. It is bad advice if your goal is usefulness.

A repository is not a bucket of chores waiting for strangers. It is a living system with trade-offs, history, backlog pressure, and people trying to keep it moving. If you open a pull request before you understand any of that, you are not really helping yet. You are asking someone else to assess your judgment.

That is why tiny, visible changes can still be poor contributions. A one-line diff is not automatically a one-minute ask. Someone still has to read it, place it in context, decide whether it belongs, and often explain why it does not.

The “add your name to the README” wave made that painfully clear. In February 2024, Express contributors were openly discussing how to curb spammy README.md pull requests from new contributors because they were creating noise and extra moderation work rather than meaningful progress.

That gives you a better test than “Can I open a PR?”

Ask instead:

Does this change solve a real problem the project actually has?
Can I explain why this approach makes sense here?
Have I made it easy for someone else to trust what I’m proposing?

If the answer is not yet “yes”, you probably need more context, not more code.

Read the project’s social architecture

Open-source projects do not just have technical architecture. They have social architecture too.

There is usually a pattern to how decisions get made, how questions get answered, what gets prioritised, and what gets pushed back on. If you miss that layer, you can write a technically decent patch and still make a poor contribution.

Start with the obvious documents, but treat them as operating instructions rather than admin clutter. Read the README, contribution guide, issue templates, pull request template, code of conduct, and governance notes. Those pages tell you what kind of help the project wants, where different kinds of discussion belong, and what behaviour creates friction.

Then look past the documents and study the project in motion.

Read a few open issues from start to finish. Read a few recently merged pull requests. Then read a few that were closed without merging. That comparison is often more useful than any generic open-source advice because it shows you how this project behaves in practice.

You will start to notice patterns.

Maybe small, scoped changes land faster than broad clean-ups.

Maybe maintainers care a lot about tests.

Maybe they want discussion before implementation on larger changes.

Maybe support questions belong somewhere else entirely.

Maybe the project values consistency more than cleverness.

That is the social architecture. It tells you what “helpful” means here, not in theory.

It also changes how you ask questions.

A weak question hands your confusion to someone else.

A strong question shows the thinking you have already done.

“Can someone explain this whole module?” is a weak question.

“I traced this behaviour to this file, and I think this branch is why the bug appears, but I’m not sure whether that behaviour is intentional” is a strong one.

The second question gives someone something concrete to respond to. It narrows uncertainty instead of exporting it.

That is the habit you want.

Find the project’s pressure points

If the social architecture tells you how the project behaves, the pressure points tell you why.

From the outside, an open-source project can look like a simple list of issues and pull requests. From the inside, it is usually a bundle of maintenance costs competing for limited attention. Bugs need reproducing. Pull requests need review. Regressions need testing. Releases need preparing. Duplicate reports need closing. Docs need updating.

That is why project behaviour can look harsher than it really is.

A slow reply is not always dismissive.

A short reply is not always rude.

A closed issue is not always a judgment on you.

Sometimes it just means the project has learned to protect scarce attention.

If you want to be useful, figure out where the pressure actually is.

If the issue tracker is full of vague reports, a careful reproduction is useful.

If pull requests keep stalling on tests, test work is useful.

If the same confusion keeps appearing in issues, a precise docs fix is useful.

If maintainers keep redirecting people to the same answer, someone who reads first is already easier to work with.

This is where many contributors go wrong. They choose work that looks like contribution instead of work that relieves pressure.

Maintainers do not need more contribution-shaped activity. They need fewer unknowns, fewer unnecessary reviews, and fewer loose ends.

That is the day-to-day reality you need to acquaint yourself with before you try to change anything.

Read the codebase like an investigator

A lot of new contributors open a repository and try to understand the whole thing.

That is usually wasted effort.

You do not need total understanding. You need enough local understanding to make a trustworthy change.

The best way to do that is to read the codebase like an investigator, not a tourist. Start from a concrete question and follow the path that question takes through the system.

If you are looking at a bug, start where the bug appears and trace inward.

If you are looking at a feature, start where the user encounters it and follow the flow.

If you are looking at an error message, search for the exact text and find where it originates.

This is much more effective than browsing files until something feels familiar.

Look for landmarks. Where is the setup logic? Where are the tests? Which modules appear repeatedly in recent pull requests? Are there architecture notes? Are there directories whose names keep coming up in issue discussions?

Those clues tell you where the important paths are.

Tests are especially valuable here. They tell you what the project thinks “correct” means. They also show you how contributors are expected to express changes. If you want to understand how a piece of behaviour is meant to work, the test suite often explains it more clearly than the implementation.

Past pull requests help too. Find a recent change in the same part of the codebase. Read the diff, then read the review comments. You will often learn more from what had to be clarified, shrunk, or reworked than from the final code alone.

The goal is not to read widely. It is to become specific.

When you can say, “The bug starts here, seems to flow through these two modules, and is probably covered by this test,” you are in a much better position to contribute.

Not because you know the whole codebase, but because you know the part you are touching well enough to make your reasoning visible.

Use AI to compress learning, not responsibility

AI is now part of open-source contribution whether people like it or not. The real question is not whether you use it. The question is whether you use it in a way that makes your contribution better or just faster-looking.

A simple rule cuts through most of the noise:

Use AI to compress learning. Do not use it to compress responsibility.

That means AI can help you understand a pattern, compare approaches, summarise documentation, suggest cases you might want to test, or help you phrase a question more clearly before you post it. CPython’s contributor guide allows this kind of use, while making clear that contributors remain responsible for the usefulness and quality of what they submit. It also says maintainers may close issues and pull requests that are not useful or productive, including ones that are fully generated by AI.

What AI should not do is become your proxy.

NumPy’s AI policy is unusually clear: contributors are responsible for any code they submit, whether written manually or generated by AI; they must understand it and be able to explain it. NumPy also says it will reject pull requests it deems “AI slop” and tells contributors not to use AI to automatically generate normal project communication such as issue descriptions, pull request descriptions, or comments.

That is the right standard because maintainers are not reviewing for local plausibility. They are reviewing for fit.

Does this solve the real problem?

Does it match the project’s conventions?

Does it introduce churn for little benefit?

Can the author explain why this approach makes sense here?

AI is often decent at producing plausible-looking code. Plausible-looking code is not the same thing as a good contribution.

So use AI privately if it helps you think. But do not let it speak for you in public, and do not submit work you cannot defend line by line.

If you would struggle to answer “Why this change?” in a review, AI has not saved you time. It has just delayed the cost until someone else has to pay it.

Choose work that removes ambiguity

Once you have context, understand the project’s pressure points, and know your way around the relevant code, you still do not need to start with a grand fix.

Start with the kind of contribution that removes ambiguity.

That is the sweet spot for first contributions because ambiguity is what drains maintainers. They are constantly trying to work out whether a report is reproducible, whether a bug is current, whether a change is safe, whether a proposed fix matches the project’s direction, and whether a contributor understands what they are touching.

The best early contributions make those answers easier.

A strong first contribution might be:

a bug report with exact reproduction steps
a focused test that proves a failure clearly
a docs fix that removes a common point of confusion
a small patch in an area you have already traced properly and can explain with confidence
a careful confirmation that an issue still exists in a current version

What matters is not whether the change is glamorous. It is whether the thinking is legible.

That is a better filter than “good first issue”, which can be useful but often hides the real question. The real question is not “Is this easy?” It is “Can I understand this fully enough to make a change that is needed, correct, and easy to trust?”

That is how you choose a first contribution that actually helps.

Make it easier to trust you

Good open-source contribution starts earlier than code.

It starts when you learn how a project makes decisions, where it is under pressure, and what kind of work reduces uncertainty rather than adding more of it. It starts when you read the codebase with a concrete question in mind. And it starts when you use AI, if you use it at all, as a tool for understanding rather than a way to outsource judgment.

That is the standard worth aiming for.

Not “I opened a pull request.”

Not “I got something merged.”

But: I made this project easier to work on.

That is what maintainers notice. That is what builds trust. And that is what turns you from someone showing up in the notifications into someone the project is genuinely glad to see.